※ 引述《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推進了。
殺豬公也殺得夠了吧？也許還上不了太空，但起碼沖天炮先放個兩支如何？