我們公司內部有一套軟體一直在跑, 可是一些部份非常之難用, 跟人性不太符合,
我死薦N 次後終於軟體部門的人說話了: 因為當初寫這套軟體的人離職了, 沒其它人會修改程式...

我都不知道該怎麼說我們公司了...

沒錯一堆低能還須要看什麼 javadoc
拎背看 bytecode 就行
那些低能還要做三小 knowledge base
拎背隨便瞄一下就知道 你那幾個鳥 API 怎樣用
低能還要做三小 pair programming \ code review
拎背一人抵三個用..... 拎背還不須要別人收爛尾
還有那三小 TDD, Continue Integration, Functional Test, Acceptance Test, Unite Test, Integration Test
幹....拎背自己人寫那幾百個 Modules/Classes/Methods 拎背熟晰到跟我屁眼有幾跟毛一樣...
拎背每天幾千個 commit 都沒可能給你 Breaking Test 的那啦...
還三小 self documenting ..... 拎背 function name/ method name 都用亂碼啦......

唉！我還曾經遇過很糟糕的 coding，所有 function 及變數都用什麼 aaaa、bbbb、cccc、a123、b456、etc.,.....

看到時都快瘋了，問他有些變數是做什麼用的，他還想了很久，程式上捲下捲了好久才弄清楚，我也不知道該如何幫他 debug 起...



-

COOL!!

-

軟體工程的原意是讓團體作戰下產出的軟體品質更好，
減少溝通造成的軟體品質落差。

寫程式的時候替一些後輩著想，
也在程式技術的範圍中。

當別人看不懂自己的程式或設計原意時，
註解能夠讓接手的人有一個設計的依據。

當然你可能接觸的人都是這方面的高手，
不用言語溝通，
光看程式碼就可以達到心靈的交流，
不用多說廢話，
就可以達成程式的功能，
但在職場實務上，
我是沒有遇到那麼貼心的同事啦

你不懂就是不懂啦....
有沒有聽過 Legacy System?
我們公司都不用去 maintain 也不用去 refactor 的啦
就全外包給阿叉給它重寫啦

你們的矛盾就是不願提昇自己的程式技術, 然後再做一堆虛功來掩蓋,
虛功做越多越沒時間去提昇自己的程式技術, 最後永遠卡死在這裡,
自己卡死就算了還要拉好的人下水, 結果下場就是所有人加班加不完, 程式技術永遠停在那裡.

呃，個人好像都是照這些胡扯在作，結果是團隊績優於他人，工作輕鬆愉快! 尤其是系統要上線的時候，帶著兩個娘子軍留守以防程式出錯，但是一有問題回報，當場幾分鐘就解決，整個過程無聊的很。反觀那些沒有照這些章法作的人，平日加班就加不完了，上線時更是熬夜到隔天，連個程式清單都列不出來，真不知要怎麼上線？搞得所有人都快累死了。

個人所有的資源也沒比別人多，帶的娘子軍到後期還能準時上下班，由於專案很大，裡面有一堆團隊，怎麼比都是個人的團隊比較好過，而且只要來我這的軟體工程師，沒多久就能上手，表現比在其它團隊要好! 就是照這些胡扯作的，呵，這可是經過實戰出來的結果。

問題到底在那？資源不夠永遠都是第一個問題，以軟體工程師，不會作計畫，那就鐵定無法估出何時推出可執行的程式，沒有測試，那就只能在上線時作測試才知道程式會不會動。因為寫程式不是軟體工作師要用的，是給客戶用的，那些 open source 他們寫程式是「沒有什麼時間壓力的」跟一般「軟體專案」要上線有時程及費用來比，是不能比的。當有無限的時間及資源，什麼程式都寫得出來。

第二個問題是部分軟體主管的決心，他們是否真的貫徹這些章法才是真正的重點! 當初在帶團隊開發時，由於客戶也有人在開發程式，特地要我們代訓，當時就嚴格要求這些章法，而且打死不退，對方還上報，但寧可專案不作，也不會放棄這些堅持，結果是幾個月後，效果顯著出來，他們後來自己帶團隊時，就是照這些胡扯在作! 為什麼？因為有效!

至於部分能力明顯不足的軟體主管，身為軟體工程師要跟他對抗，那這些胡扯更是要作，除了提昇自己對付胡扯主管的能力之外，這些技術可是未來昇主管的管道呀

寫這篇文章的人一定不了解軟體工程到底是什麼，建議他可以去看看溫柏格的書，早在三十年前這些類似的問題，他就有對應的想法及因應之道了。