引述电影寒战的台词:
每一个机构，每一个部门每一个岗位都有自己的游戏规则。不管是明是暗，第一步学会它
，不过好多人还没有走到这一步就已经死了，知道为何？自以为是。
第二步，就是在这个游戏里面把线头找出来，学会如何不去犯规，懂得如何线上球里面玩
，这样才能勉强保持性命。
结论: 你要在无论在软件界或在其他环境生存，一定要学会明的或暗的规则。每个环境都
有它的游戏规则，搞清楚规则再玩，才是明哲保身之道。
进公司没多久，应该要把公司游戏规则搞懂，有时候软件会用这种管理方式是有它的历史
因素存在的，也许一只程式经手好几十人，一段程式码可能是因为专案评估错误造成要
加班努力赶出来；也有可能是相同模组卖给不同客户但接口不同，功能需要客制化等因素
造成你现在看到的结果。你看到的是结果，就说这个管理不好，这个要改、架构要改...
老鸟大概会觉得这样的新人是自以为是
所以进公司第一件事情就是把请把线头找出来，学会在这一个游戏规则下生存，在你可以
掌控的资源中来进行你觉得应该要做的事情
Ruby on Rails在web application framework生产力比JSP高出30%，这样为什么一堆公司
还在用JSP开发呢? 维运成本跟资源的掌控才是大部分的公司考虑的重点。你光要换掉JSP
后端，除非你是主管有勇气承担替换过程的混乱时期，不然你就提个所谓的
"加速后台生产力执行计划书" 并且提出WBS(Work Breakdown Structure)，以专案
执行的方式来看待此事，以专案管理的做事方法来进行此事，你就是此计划书的PM，
因此你要做的事情要有:计画、时程、资源分配、风险评估、预期效益、Staffing Matrix
(就是谁要负责哪件事情)、教育训练、范围为何等诸多任务以及其解构之后的工作细项。
在执行的过程中要有高度的意志力来贯彻此专案一定要成功，不然也是嘴砲而已。
引述电影寒战的台词:
基于一个片面分析，没经过严密的逻辑推算。浪费你们的宝贵时间是不是很兴奋啊，
等你坐上我的位子，你就会心里有数。
这不是一个新人说我觉得这个很好，所以后我们就全部换成这种管理模式，这么简单
再来讲维运成本:
会JSP比RoR的人可能是好几10倍，在人力市场上要找到可以立即上工的人机率很高，
加上如果案子从研发转移至维护单位，驻点也许只要学Apache以及网页的基本设定以及
依照安装手册跟问题排除程序就可以保持良好的维运状态，因此聘请驻点工程师的成本
就会降低。要是你换掉了，万一负责开发的人离职了，可能替代的人要在人力市场上找
很久还不见得找到可用的人。
因此有些主管会要求说程式不要写太难，因为接你的人会看不懂也是一样的道理
你用 git SVN想要取代旧有的专案以及软件维护方式，也许这一套软件在客户端已经安装
上千套，程式可能在几十年的开发下已经在既有的管理模式运作得好好的，要改变的话
在初期光commit跟版本分类就需要讨论很久了，替换计画为何? Role & Responsibility?
老鸟有很高的机率在赶案子，对老鸟来说维持现有的模式一定是风险最小，而且你忽略了
RD的主要工作不是这个，是 "产出"，长期来看这个投资是值得的，但是需要有一个计画
来完成，你确定你的主要工作(main job)是这个? 还是coding? 你的KPI有这一项吗?
如果你跟你同事的KPI都没有，请问谁要来干这件事情?
另外有这样的想法很好，但想法最终还是要回归执行力，因为用嘴写程式永远比实作来的
容易。你要实力足以让同事以及主管认可，如果没有的话，那还是在你可以掌控的资源中
进行你觉得应该要做的事情。例如: 自己的程式自己管，同时也让你同事知道你在做
可能改天同事突然性情大开，希望能跟你一起改造这个巨大的程式怪兽
举我的例子好了:
我刚进公司的第一个礼拜就在观察RD的工作方式，结果就看到Execel纪录Bug, 资料夹命
名法, 要什么程式跟文件都要问特定的人, 主管记得在几年前有哪几个功能要找出来，就
直接叫我去问负责开发的RD,大概有25%的机率会得到的答案是这个做的人已经离职了，
你确定要吗 ? 我找到后再寄给你；或是"这个功能当初只给某某客户用而已，因为合约有
写到，但不在主要程式中"等等这种开发模式。研发部门RD有一半待超过6年以上，而且
公司规模还不小(>100人)。
所以我前两个礼拜就在公司自己架设 Redmine + SVN, git用来管理我自己的程式，因为
我是主要负责一个新产品的开发，主管也没在管我管理的方式。之后我就锁定几个同事
询问有没有兴趣试用看看，结果都是开帐号后就再也没登入过了。或是得到的答案是
"等我这个案子忙完"、"我很有兴趣、但我现在没时间"、"有没有相关的资料寄给我"等
后来新人补进来后，我强制规定一定要用Redmine管理，程式上版本控制系统，几个月后，
主管发现我在用这种管理方式，现在想要推广到其他产品跟专案试试看，但目前仍然是
很沮丧的状态。转换工具的过程需要时间跟缜密计画，最重要的是要有权力的人支持你，
让你的同事相信学这样的东西，可能每天花你10%的工作时间，但是可以让他的工作效率
提升30%。你要让他相信你做这件事情不是挖洞让他跳，最重要的是这需要时间慢慢来
如果你的实力被大家认可的话，相信你应该可以做得到，不要只是出张嘴而已。
引用用寒战最后一句台词，作为结尾:
我以前都看不起你 因为你没有实务经验 但我错了
就因为你没有实务经验 所以可以用更宏观的角度看事件 00局 00署 都是你运用的工具的
(后面不太记得)
※ 引述《tyc5116 (累人啊....)》之铭言：
: ※ 引述《superpai (超级白)》之铭言：
: : 我只想问改用 Git 的风险在哪里...
: : Git又没有很难也不用钱也不会帮你code加入bug
: : 也不是最新的科技，也没听过不稳
: "为了便于新人学习,所以程式@#$%^&*()",简单说就是引用工研院的程式架构MSD
: MSD意思就是把程式分成Model,Status,Design,将程式分为数个次模组
: 每个模组有各自的状态切换,然后将其转换为程式,细节就不说了
: "我们的程式架构虽然有很多改进的空间,但是堪用"
: 因为公司到现在程式的管理都是,今天开一个20140519的资料夹,
: 明天再开一个20140520的资料夹,导入Git总没问题了吧?还是免费的东西耶!!
: 不但免费,现在也发展的很稳定了(应该是吧....XD)
: mail给小主管,cc给主管,小主管的回应是"有机会分享给其它同仁"
: 心得:
: 1.新人还是安静点,说太多没人会理你
: 2.自己有好东西自己留着,如果人家主动想要学再教别人
: 3.如果教别人要花很多时间,人家还不见得听的懂,那就直接跟他说"我不会"
: (分享一下我老师说过的话XD)