雖然你說的的確是多數接案公司狀況，但不免一竿子打翻一船人，
真正運作良好的接案公司，絕對不是寫拋棄式的程式碼，而是再利用性很高的模組，
而這些模組還是該建立相關的軟工程序保證它們可以在不同案子穩定利用。
而多數非接案(以產品為例)的公司，程式碼根本就是「低內聚，高耦合」，因為當初
製作的人覺得根本不會被再利用，所以這些「模組」都是一次性被使用而已，根本沒
考慮未來需求變動的痛苦。
開發層面的需求不同，所以最先考慮的不同。
不管是案子還是產品上面可能都有一個要你做得快的對象，權衡之下選擇比較差的方
式先求有也不是什麼多大的罪過，還是得依情況決定。
這些原罪在於大環境，而非公司型態，
連任職的公司型態都會有鄙視鏈也不是很好..需求不同嘛。
少數接案公司也是努力的在讓每一個案子成為自己下一個案子新的能量。
少數產品公司也是努力的在讓產品穩定、快速的迎接每一次的需求變動。
共勉之..
※ 引述《alihue (wanda wanda)》之銘言：
: 這種狀況容易發生在轉換不同類型的工作環境
: 從 接案型公司 到 非接案型公司 最容易有這種落差
: 接案型公司，在固定的專案金額下，RD 越快，人越少，利潤越高，
: 最好一個人可以從 sa 包到 pg
: 可以留下的 RD 通常都是精英(接案界的菁英)
: 但是！ 接案特性通常就是先有再說，案子結束就不會再碰到了，
: 因此軟體工程思維非常薄弱。
: 從設計 design pattern, interface, inversion of control
: 到寫測試、code review、自動化、容器化等等完全沒有，
: 因為沒有用，案子都是一次性的。
: 老闆問你說為啥動作這麼慢，結果你說你在重構? 下週要驗收了你重構三小
: 但這種人到非接案型公司，就會顯得自己速度真的滿快的
: 但是真正的問題是不會馬上顯現出來。
: 因為以前在接案公司很少碰過大系統，所以把以前的壞習慣都帶過來
: 在 object 亂偷渡不相干資料、db 偷塞 json、用 try/catch 做 flow control ....
: 過一陣子，系統開始在某些特殊操作下出現 bug，往回一追發現你是罪魁禍首
: 會發生什麼事?
: 資深同事：寫得快有什麼用? 還不是 OOXX
: PM：你的程式品質很差，BUG 很多
: 到最後不得人緣，開始覺得這是爛公司
: 另外一方面，同一個功能為什麼其他同事會比較慢?
: 有時候這是老經驗，因為自己手上不會只有這一件事要處裡
: 你給我全職只開發這一項當然 1 天沒問題
: 但是我同時有 N 個任務要做，
: 而且依照經驗這種需求往往要牽動到 XX / 有沒有其他更好的設計
: 開發完還要跑一次 unit test/integrated test, code review, design review
: 所以眼前的快不是快，可能有很多你沒看到的東西
: 當然，也有可能你是天才拉... 速度快、架構漂亮、什麼會、什麼都懂
: 那這間公司不適合你，繼續往上跳，跳到 FLAG 之後同事還在稱讚你又快又強再說
: 否則軟體學海無涯，一個 Feature 做到完美就夠讓你殺時間了
: 以上故事如有雷同純屬巧合
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.225.139.105
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1534905760.A.850.html
推
08/22 10:47, , 1F
08/22 10:47, 1F
→
08/22 10:47, , 2F
08/22 10:47, 2F
討論串 (同標題文章)