※ 引述《leoace (leoace)》之铭言：
: 引述电影寒战的台词:
: 每一个机构，每一个部门每一个岗位都有自己的游戏规则。不管是明是暗，第一步学会它
: ，不过好多人还没有走到这一步就已经死了，知道为何？自以为是。
: 第二步，就是在这个游戏里面把线头找出来，学会如何不去犯规，懂得如何线上球里面玩
: ，这样才能勉强保持性命。
保住性命？你是来写程式的，不是来演戏的，推个新技术而已不给推你把我开除嘛。
是能枪毙我？
工作就是这里有我要的，那我就忍着待着追求着，没有你不开我我自己也会走。
那问题是：你如何定义你自己？你是个程式设计师，还是只是个‘帮别人写程式的’？
: 结论: 你要在无论在软件界或在其他环境生存，一定要学会明的或暗的规则。每个环境都
: 有它的游戏规则，搞清楚规则再玩，才是明哲保身之道。
这种想法就是问题，想要明哲保身没有错，只是你的底线在哪里？
如果没有底线，那这工作就不是什么个软件工程师，而只是个需要有人来写程式的。
我如果当个‘被找来写程式的’当得很开心，那是我个人选择，我可不会大声嚷嚷跟
新入行的菜鸟说‘这也该是你的选择’。
出来混就要还，人希望有一天做自己尊敬的工作，希望有一天不论大小能做出一番成绩，
那有些事情就不能妥协，然后机会成本要会算。
人如果还年轻、没有一家老小牵挂，这么会算那些冥折饱身的东西是干嘛？
还年轻，该考虑的东西就只有一个：这到底可以对user有多少贡献？
这些user你根本无法认同，那这工作你就不该做。
这间公司只剩下还活着，那老板不赶你你都该自己走。
当继续下去要求你冒险，那战胜恐惧就是你保有自尊的唯一方法。
: 进公司没多久，应该要把公司游戏规则搞懂，有时候软件会用这种管理方式是有它的历史
: 因素存在的，也许一只程式经手好几十人，一段程式码可能是因为专案评估错误造成要
: 加班努力赶出来；也有可能是相同模组卖给不同客户但接口不同，功能需要客制化等因素
: 造成你现在看到的结果。你看到的是结果，就说这个管理不好，这个要改、架构要改...
: 老鸟大概会觉得这样的新人是自以为是
: 所以进公司第一件事情就是把请把线头找出来，学会在这一个游戏规则下生存，在你可以
: 掌控的资源中来进行你觉得应该要做的事情
同意啊，但这种事情是互相的，你进公司向公司学习、公司雇用你用你的产出赚钱。
当发现看似不合理的东西，当然要找出来到底这为何如此。
因为历史因素妥协很多时候也是不得不然。
但这东西不是没有代价、也不会没有计算。天下什么东西最贵？时间最贵
一间公司可以为他目前所有的潜规则找出充足的理由。
但只要这间公司这个部门跟外界、跟竞争对手比起来就是没有效率，这些理由就通通
都是借口、通通都可以是屁话。
要不要把自己的生命，也就是时间，继续奉献给这个已经没有机会赢的东西，
人当然也可以找各种理由，但，当人不相信却还继续去做的时候，这些理由都是借口。
即使到最后瞎猫碰上死耗子，这公司不晓得为啥起来了，这人于其中也是一点好处也
没有的。人今天可以碰运气得到，某天就要随机的被掠夺。
: Ruby on Rails在web application framework生产力比JSP高出30%，这样为什么一堆公司
: 还在用JSP开发呢? 维运成本跟资源的掌控才是大部分的公司考虑的重点。你光要换掉JSP
: 后端，除非你是主管有勇气承担替换过程的混乱时期，不然你就提个所谓的
: "加速后台生产力执行计划书" 并且提出WBS(Work Breakdown Structure)，以专案
: 执行的方式来看待此事，以专案管理的做事方法来进行此事，你就是此计划书的PM，
: 因此你要做的事情要有:计画、时程、资源分配、风险评估、预期效益、Staffing Matrix
: (就是谁要负责哪件事情)、教育训练、范围为何等诸多任务以及其解构之后的工作细项。
: 在执行的过程中要有高度的意志力来贯彻此专案一定要成功，不然也是嘴砲而已。
ROR 比 JSP高30%，那得看你后端衔接什么系统。
你后端就是接Java EE，团队编制超过50人，那ROR讨不了什么便宜。
: 引述电影寒战的台词:
: 基于一个片面分析，没经过严密的逻辑推算。浪费你们的宝贵时间是不是很兴奋啊，
: 等你坐上我的位子，你就会心里有数。
我没看过那部电影，但这边有严重的基本假设不适用的问题。
以作商用开发的团队来说，今天导入一个技术，失败了会死人吗？
或者说，失败是能失败到哪里去？
时间Buffer 开大一点，找团队中的快手下去作POC出来，几个主要的Architect 从
各自专擅的领域去review过一遍，就可以看要不要推了啊。
这又不是什么Rocket science，讲难听点，有需要做到这么复杂的冲击影响评估的
新技术导入，台湾没几个领域有需要这样搞拉。我可以想到的只有高铁的机电整合
自动控制，这种有复杂的讯号控制配上软及时需求的，但这太不算一般商用开发的领
域吧？
能碰上最头痛的就是效能跟安全性，阿一个新技术一旦知道是做什么的，会打到哪里
能打多痛，当Architect的不能明确地提出模型senior们一起来看，这还叫Architect
吗？
有办法的人，是会把很复杂的东西用很简单的模型掌握，清楚地掌握概念边界后，
去提升周围的人对问题的理解的。
而不是摆老、讲得不清不楚然后吓唬新人。
: 这不是一个新人说我觉得这个很好，所以后我们就全部换成这种管理模式，这么简单
: 再来讲维运成本:
: 会JSP比RoR的人可能是好几10倍，在人力市场上要找到可以立即上工的人机率很高，
: 加上如果案子从研发转移至维护单位，驻点也许只要学Apache以及网页的基本设定以及
: 依照安装手册跟问题排除程序就可以保持良好的维运状态，因此聘请驻点工程师的成本
: 就会降低。要是你换掉了，万一负责开发的人离职了，可能替代的人要在人力市场上找
: 很久还不见得找到可用的人。
还有一个是开发工具的成熟度，以及语言能否支援，这点Java是强到爆炸的。
: 因此有些主管会要求说程式不要写太难，因为接你的人会看不懂也是一样的道理
程式没有难或简单，只有恰如其分的安排，还有制造的问题比产生的价值小得多。
当需求就是要求这样水准的架构设计时，你该做的不是让架构设计去迁就看不懂的人，
而是让看不懂的人提升到看得懂。
这重点在于，标准在那里？你的设计真的是‘恰如其分’吗？
我的经验是这只有设计被挑战过才能证明，这就是为什么需要code review还有pair
programming的部分原因。大家坐下来大乱斗，你提出的点别人同意这重要，也找不到
其他更好的解法，那就是这样了。
而这六七年长久观察下来，我是觉得大部份的情况没有所谓的‘太难’，只有无谓的
复杂度可以砍掉。
: 你用 git SVN想要取代旧有的专案以及软件维护方式，也许这一套软件在客户端已经安装
: 上千套，程式可能在几十年的开发下已经在既有的管理模式运作得好好的，要改变的话
: 在初期光commit跟版本分类就需要讨论很久了，替换计画为何? Role & Responsibility?
换VCS跟产品安装多少套没有关系。
以Git SVN来说，不论是直接切换还是混用都有人做过，也都有既有套装方案。
真正的困难在于工作模式的改变，Git 鼓励用branch，要习惯SVN的人接纳狂开Branch
测试各种不同方案的思维是最花时间的部分。
: 老鸟有很高的机率在赶案子，对老鸟来说维持现有的模式一定是风险最小，而且你忽略了
: RD的主要工作不是这个，是 "产出"，长期来看这个投资是值得的，但是需要有一个计画
: 来完成，你确定你的主要工作(main job)是这个? 还是coding? 你的KPI有这一项吗?
: 如果你跟你同事的KPI都没有，请问谁要来干这件事情?
: 另外有这样的想法很好，但想法最终还是要回归执行力，因为用嘴写程式永远比实作来的
: 容易。你要实力足以让同事以及主管认可，如果没有的话，那还是在你可以掌控的资源中
: 进行你觉得应该要做的事情。例如: 自己的程式自己管，同时也让你同事知道你在做
: 可能改天同事突然性情大开，希望能跟你一起改造这个巨大的程式怪兽
这就是个人考量了：到底这间公司值不值得你花这样的心血陪他玩。
就我来说，如果是之前那位原PO举的例子：
SVN to Git借口一大堆，还是什么JSP里面可不可以用EL的要参详个半天的，我不会。
我不觉得自己的生命值得这样浪费，而基于我希望台湾的软件产业可以更好，我也
不会认同要‘年轻开发者们应该继续把生命花在这种公司上头是合理的’这种言论。
隔了五年，好不容易网络舆论终于倒向认同‘一间软件公司一定会有VCS’。
我觉得是时候该往下一个milestone推进了。
杀猪公也杀得够了吧？也许还上不了太空，但起码冲天炮先放个两支如何？