軟體成功的 3 / 7 法則


        今年三月底,為了挽救公司的新產品,我臨危受命飛往馬來西雅。也是第一次我才一下飛機,透過越洋國際電話,就決定放生一位團隊同事。

        下令放生之前,我寫了封信,跟團隊談談我心中認為『成功的系統』的關鍵要素:



        「嗨, 昨天『X系統』錯帳的事情,大家辛苦了。尤其感謝那些在公司待很晚、待命到問題解決的同事仁們。  
        我常覺得:『人的成功,若是三分天才 + 七分的努力才能獲得那軟體系統的成功,就是三分技術 + 七分的紀律與嚴謹驗證的態度。』 
        技術再新再好,頂多創造三十分的價值。但是就算技術老舊,只要有紀律和不斷測試驗證,就能替使用者創造出七十分的價值。 
        去年有次晨會我就跟大家說過,軟體就是比玻璃還要易碎的東西,打破一個玻璃杯你還要花相當的力氣,但是弄壞一個系統,你只要手指不小心在鍵盤上發抖一下,大小寫拼錯或是加減打反,就壞得一踏糊塗,不費吹灰之力。 
        所以雖然人人都可以寫軟體,千萬不要以為寫好一個不出錯的軟體系統很容易。 
        我所知道軟體界很優秀的人,都不是什麼技術很高、很會玩弄或破解什麼別人看不懂的技術,而是那些態度嚴謹、永遠想著如何避免犯錯的人,這些大師創造出許多軟體工程的方法論,就是這些人知道人一定會出錯,所以想破頭在思考如何用流程來預防。 
        這次『X系統』的錯誤的原因,是在開發『Y功能』第二階段的期間, 3 / 19 日那天『X系統』的『Z程序』有附件內的修改: 將原本判斷財務金流增減的那段 IF 條件中的⋯⋯(略)。

        而移掉這個 IF 判斷的條件,卻造成這『Z程序』再也無法判斷『X系統』的財務金流,而讓所有的使用者的帳都損失。 
        這個出乎意料的順手改,所造成的問題之明顯,可以知道修改的人改完之後絕對沒有測過! 
        我不是反對修改,原本就正常的東西你若有心想把它改得更好,我也很鼓勵!就像我們最近積極地 refactor 一樣。 
        這件事最大的錯誤,不是『修改了本來正常的東西』,而是『改了卻沒有測』!沒有驗證!沒有讓任何人知道!  
         如果你太忙,不打算測,那我寧願你不要改! 尤其改的還是 DB 內跟錢有關最重要的『Z程序』! 
        我對這種嚴謹的要求,絕對不是現在給大家放馬後炮,當初要上 report pre-gen 這個改善校能的機制,前前後後跑了多少次驗證? 還專門寫了一支程式(略)每天跑各種查詢條件來跟 on-fly 的版本做交叉比對,確定好幾天都沒錯誤才敢給 User 使用?不只如此,而且還特意保留一個切換功能給大家在緊急的時候可以 runtime 切換 pre-gen / on-fly 兩種版本。 
        而且,pregen 還不是我自己開發的,上述我做這些都是為了幫別人把關驗證。你們對這整套系統前前後後有比我熟嗎?若沒有,那理應比我更小心更謹慎啊!怎麼可以比我不熟,卻還可以比我更鬆懈隨意呢? 
        你盡力測但仍有 case 沒測到,這大家可以理解。但改了卻完全不測,認為自己不可能會修改錯的人,能力太強了,應該去 Google,不應該跟我們在這邊浪費生命。 這也是我當時讓 EXX 去找更好的發展的原因。  
        記住:你懂的技術再多再新,頂多創造三十分的價值。但是就算技術老舊,只要有紀律和嚴謹的態度,就能替使用者創造出七十分的價值。 
        我不想讓這件事造成以後大家都不敢修改任何東西,害怕 refactor 。 
        所以不要弄錯焦點,我不責怪修改,我要責怪的是『改完卻不測』!
Best Regards」


熱門文章