從事資訊業以來，一直都有一個問題，通常老闆或高階主管知道我們有哪些專案，但除非主管剛好也是資訊業出身，否則通常不知道公司花了這麼多資源與金錢，請這麼多工程師開發出來的產品，到底品質如何？ 如果問每個人『自己的產品品質重不重要？』，答案一定是肯定的，如果產品不穩定、不好用、很多臭蟲，我想神也救不了你，客戶馬上就會離開。 所以大家都覺得品質重要，可是誰會替自己的產品把關呢？ 尤其今天講的是軟體內部的品質，工程師都希望有好的架構，畢竟現在唯一不變的事情就是『客戶的需求一直都在改變』，可是我接過很多案子，許多的工程師都自以為自己開發出來的東西品質超好，是的，相當自以為，其實殊不知，這產品只是外觀能動，裡面卻是一堆違章建築，很好的分辨方式就是：

1.新接手的工程師要花多久才能看的懂系統的程式碼？

2.這個系統會不會修好一個bug，另外就有bug跑出來？

所以工程師都不喜歡接別人的專案，原因很多：風格不同、架構難以理解、寫法老舊…等等，而通常唯一的解法就是『重寫』，當然重寫後的品質又是另外一個故事了….

我想軟體跟建築其實有點相似，沒有設計師能不能蓋房子（寫程式）？ 有設計師設計過的房子（架構）一定比較好？未必，誰知道外觀看似華麗的房子裡面的耐用程度如何？ 那我們該依賴什麼去判斷房子的好壞？ 總是有些規格，防震程度、水管保用時間、鋼筋軟硬度等等，我想軟體世界裡面應該也是一樣的，應該有很多ISO去評斷，雖然不是唯一，但是可以當做一個參考，下次就來找找看有哪些ISO好了。

PS: 我最害怕的其實是工程師不覺得自己寫的code有問題，寫程式是需要考慮各種狀況，不是這個能動就行了，能用跟好用差的可遠了。我現在判斷工程師的程式碼好壞是用code review的時間，看看他們的code有沒有修改過，修改過幾次，如果只寫一次就交卷了，通常大有問題，因為寫程式的過程中一定會遇到有更好的解決方式或是更有效率的寫法，沒經過多次思考的程式碼，一定只有一個commit，看個幾分鐘，通常就一堆問題了….