※ 引述《keke0421 (zrae)》之銘言： : 覺得好貼切...分享給各位 : 轉貼於 https://goo.gl/dEpoJQ <--medium 好讀版 : 身為軟體工程師，你應該要盡量寫出無法維護的程式碼，而且絕對不寫測試。 : 你應該要知道：在績效管理下，你愈是認真負責，愈是做到符合專業倫理的要求，你反而 : 看起來績效愈差。而你大概會有 87% 的比例，會遇到這種績效管理。 : 舉個例子，假如你是警察，你決定要認真抓小偷，於是上個月在你的管區破獲了五十起竊 : 盜案，這個月因為你的努力，破獲的案件增長到一百件Xo代表什麼呢？這代表看起 : 來你的管區治安變差了，而你應該要為治安變差負責，你才是應該被檢討的對象。於是你 : 知道，警察好像應該要想辦法破案，但實際上，你的績效並不是來自破案，而是吃案。 : 如果你花了半年時間，抽絲剝繭理清了複雜的商業邏輯，建立了清爽明確的抽象層，並且 : 預先額外設想了其他的使用情境，最後開發了一套易於擴充的軟體架構，讓一個大學剛畢 : 業的新人，都可以在你的架構上不到一個星期就可以開發出新功能。這代表什麼呢？這代 : 表你的績效很差XA的管理者只會看到，你花了半年才做了一件事清，一個新人剛來 : ，卻只需要花上一個星期就可以完成一件事，那還要你來做什麼呢？ : 至於可以輕鬆開發出新功能的新人，他會怎麼看呢？可以這麼快開發出新功能，當然是因 : 為他自己的功能啊！跟你有什麼關係呢？真的要了解你到底做了什麼，其實只有一個辦法 : ，就是要閱讀你的程式碼，但，放心好了，不會有人會去讀的。 : 你要做的事情就是：管理者設定了什麼績效，你就想辦法達成什麼績效。如果管理者設定 : 的指標是你修好了多少 bug，那麼你就要想辦法一開始就在你的程式中製造許多 bug，免 : 得日後需要修 bug 的時候沒有 bug 可以修。如果管理者的目標是加速開發，你就應該要 : 不計後果加速開發新功能，明知道是加速邁向毀滅，你也要加速開發。 : 事實上，身為軟體工程師，你也根本不用考慮後續維護的問題。如果你在一家公司寫了一 : 大堆完全不考慮耦合關係、程式邏輯糾纏不清、命名混亂、使用大量 anti-pattern、到 : 處都是怪氣味、效能極差而且宛若天書的程式碼，而你開始為了繼續維護這樣的技術負債 : 感到痛苦的時候，其實只代表一件事情：你已經在這家公司獃得太久，而且還沒有升上去 : 當主管。 : 這個時候你就會知道加速開發的好。你完成了這麼多項功能，於是在你想要換工作得時候 : ，你可以寫出洋洋灑灑的履歷表X洃均A你會把你寫了幾條單元測試、達成多高的覆 : 蓋率這種數字放進履歷表裡頭嗎？把力氣放在測試這種無助於發展事業的事情上，完全就 : 是在浪費你的時間。 : 你也同時應該感謝Xˇ撅o是誰想出來軟體產業園區這種德政，原本製造業的產業園 : 區是讓上中下游供應鏈可以集中在一起，降低運輸成本，但軟體這一行又沒有供應鏈這種 : 事情，成立園區只是讓相互競爭的軟體公司其中在一起，唯一降低的就是人員流動的成本 : ，換工作都不用搬家。多好啊你看。 : 如果你有機會高升，開始擔任主管，你就會知道，當初寫下的那些無法維護的 legacy : code，其實更有助於你擔任主管的管理工作。 : 擔任主管最重要的工作，不是別的，就是一邊把持住自己的位子一邊想辦法繼續往上爬， : 所以主管絕對不可以讓部屬表現得比自己更優秀，而你當初寫的程式碼，就是部屬事業道 : 路上最好的絆腳石。你除了可以一邊抱怨為什麼新功能開發愈來愈慢，一邊說嘴當年你只 : 花了多短的時間就寫了多少程式碼，果然只有你有資格擔任大家的主管。 : 當然，總有一天技術負債會大到你的部門什麼東西都做不出來，你的公司什麼服務都拿不 : 出來賣，但是這一點都不會影響你找新工作，你瞧，現在，你的履歷表上面，可寫著你當 : 過主管呢！拿著這份履歷表，你更有機會去別的地方，空降擔任更高階的主管。 : 技術負債從來就不是什麼問題。誰說你製造了技術負債之後，你就得要自己還債？ : 在你的人生中，你不需要要為其他人而活，也不是為了程式碼這種死物而活，你真正應該 : 要負責的對象只有你自己；而你知道人是經濟而自私的動物，既然你的本性就是貪婪，你 : 就應該成就貪婪。你要捨棄專業才能成就事業，你應該要把握當下的績效，而不要為了可 : 能不存在的悲劇結果恓恓惶惶。凱因斯不就曾經說過：「In the long run, we are all : dead」？ : 身為軟體工程師，你應該放心大膽地創造技術負債。這麼做唯一的風險，就只有在你換工 : 作的時候，也會接手一大筆前人留下來的技術負債。不過，這種事情反正也早就已經發生 : 了。 來個中性分析。 1. 這些招數只有特定情況可用。 A) 主管非資訊專業，可以放任底下的人搞。 (因為不懂細節，只能看成果) B) 接案公司，案子以後改動幅度不大，只要驗收過關就好。 (同上，驗收不看細節) C) 特殊情況要搶時程 2. 正規一點的軟體公司早有應對方式 A) Code Review。 亂寫很快就會被盯上 B) Bug Review。 常寫出太蠢的bug也會被盯上。 C) Case assign。 依照Bug修復難易度分派任務，簡單的bug給菜鳥修，順便練經驗。 避開老鳥自己寫bug自己解的情況。 D) Fix review。 Bug 修完check-in前再看一次，避免明顯的side-effect 3. 大一點的案子都有相依性，準時完成 > 搶快 4. 用這招或許可以在特定領域成功。 但如果想往軟體業前段班的公司移動，好好鍛鍊自己比較實在。 不是不能用，而是要懂得何時能用。 5. 這也證實了軟體管理的重要性。 如果你是主管，要怎樣管理/帶領這樣的工程師? 其實是一門有趣的學問。 6. 至於技術債： 當時程的商業價值大於技術債時，用技術債換時間是有意義。例如 Demo 用途 但正式產品、系統或專案這樣搞，就自求多福了。 -- 了解更多 【職場沒人教的事】 https://www.facebook.com/Work168.net --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.229.72 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1510476144.A.65F.html