Code 寫得好對公司有用嗎？
tl;dr, 絕對有用！
IT部門的同事間可能經常遇到這種問題，「究竟應該花多點時間去寫好編碼，還是應該快快寫好新的功能，往後才改善編碼的質素」，雖然大家心裏面都希望花時間寫好每一個功能的編碼，但面對開發時間永遠不足、上司的壓力，很多時就會無視編碼的質素，來成就新功能／新產品可以及早推出，然後就安慰自己之後才執拾殘局。不過程式員都是人類，難以敵不過「Later means never」這個定律，所以質素往往成為節省開發時間、成本下的犧牲品。
即使我們知道應該花時間一開始就寫好一點，但我們怎麼說服你自己、你的上司、你的老闆一開始的編碼質素是何其重要？寫下軟件工程界的大作之一《Refactoring - Improving the Design of Existing Code》的Martin Fowler 近日一篇文章《Is High Quality Software Worth the Cost?》就為我們提供了清晰的解答，軟件的質素其實是牽引住各種層面。 （From：https://twitter.com/ghjhbbbnn/status/1026721753924550656）
外部質素（external quality）與內部質素（internal quality） Martin Fowler首先將軟件的質素分開為外部質素和內部質素，外部質素指的是用家能夠看得到的，例如UI和程式缺陷，而內部質素即是用家難以分辨好壞的部分，例如軟件結構。
現今不少公司都很注重UI、UX的設計，因為用家很容易因為用得不暢順而氣餒，投訴甚至放棄使用。程式缺陷亦固之然是要盡量避免，也是因為這直接影響用家的使用體驗。相對來說，編碼結構的好壞藏在華麗的UI之後，用家其實難以知道軟件內部的編碼究竟寫得好不好。Martin Fowler舉例說兩個軟件UI一樣好，亦沒太多的程式缺陷，一個內部編碼整潔有序，賣10美元，另一個內部編碼一團糟，但賣6美元。既然用家都不能看到內部編碼如何，編碼是否整潔有序亦看似無礙軟件運作，誰會花多4美元去買前者？軟件公司又為何要花資源在軟件的內部質素？
技術債項 Technical Debt
內部質素與軟件持續開發 作為一個程式員，最花時間的工作理應就是處理、改動程式編碼，即使是全新的軟件開發，程式員仍需要在已完成的程式基礎上去編寫源碼。要加一個新的功能，首先要知道如何將新功能放入原本程式的流程裡，然後改動現有流程並放置新功能。而由於通常會接觸到／使用到原本的程式編碼，程式員不得不先理解程式是如何編寫。
問題來了，如果原本程式的內部質素奇差，邏輯紊亂，數據難以跟隨，程式員就要花很多時間去理解、使用原本的程式。這種程式當下的狀態與其理應狀態之間其差異，Martin Fowler 稱之為 cruft, 一種程式上的冗餘。他提到另一位著名的程式設計師Ward Cunningham 對cruft所提出的一種隱喻，Technical Debt 技術債項，因為當一位程式員為了各種原因去無視內部質素，其產生出來的技術債項會導致將來所有有份涉足該源碼的程式員付出更多時間去進行程式上的修改，這些額外所費的時間可視為技術債項的利息。 內部質素對開發時間的影響
雖然用家無法直接體會到軟件的內部質素，但用家卻在意軟件新功能開發的時間，這就直接受到內部質素的影響。技術債項多，每一項新功能的添加就會附上相應衍生出來的利息，亦即開發時間增加，用家亦要等待同樣的時間才能使用到新功能。在這個情況下，技術債項少的軟件會比債項多的軟件更快推出新功能，而用家相對之下很有可能會轉用較貴但功能更多的同類軟件。路遙知馬力，技術債項多的軟件可能可以很快跑出，但往往輸在持久力上。 債項多少的差異，使到軟件持續開發進度的交叉點數週就出現
Martin Fowler指出，即使最好的開發隊伍，亦難免有技術債項的產生，皆因開發的時候很多時處於不確定的未知狀態，開發成員亦只有大概的概念去知道軟件需要什麼，只能夠見步行步，越後期迷霧才越散去，加上軟件所用的開發語言、資源庫、平台亦在開發期間不斷變更，就如興建大廈時，在興建好一半後大改圖則、建築材料一樣。
We made good decisions, but only now do we understand how we should have built it.
而成功的開發隊伍就會透過寫自動化測試（automated test）、重構（refactoring）、持續整合（continuous integration），以積極清除足夠的冗餘，令到新功能開發時間減低。在這個意義底下，內部質素高的軟件也許一開始的開發成本較高。但以長遠發展，高內部質素的軟件開發成本卻是比較低廉。
所以，各位程式員應該知道如何和上司解釋軟件質素的重要，而各位老闆亦懂得怎樣分配時間、資源在軟件開發吧？
聯絡我們:
電郵地址: hello@ones.software
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
ONES Publication
We share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software
IT部門的同事間可能經常遇到這種問題，「究竟應該花多點時間去寫好編碼，還是應該快快寫好新的功能，往後才改善編碼的質素」，雖然大家心裏面都希望花時間寫好每一個功能的編碼，但面對開發時間永遠不足、上司的壓力，很多時就會無視編碼的質素，來成就新功能／新產品可以及早推出，然後就安慰自己之後才執拾殘局。不過程式員都是人類，難以敵不過「Later means never」這個定律，所以質素往往成為節省開發時間、成本下的犧牲品。
即使我們知道應該花時間一開始就寫好一點，但我們怎麼說服你自己、你的上司、你的老闆一開始的編碼質素是何其重要？寫下軟件工程界的大作之一《Refactoring - Improving the Design of Existing Code》的Martin Fowler 近日一篇文章《Is High Quality Software Worth the Cost?》就為我們提供了清晰的解答，軟件的質素其實是牽引住各種層面。
外部質素（external quality）與內部質素（internal quality） Martin Fowler首先將軟件的質素分開為外部質素和內部質素，外部質素指的是用家能夠看得到的，例如UI和程式缺陷，而內部質素即是用家難以分辨好壞的部分，例如軟件結構。
現今不少公司都很注重UI、UX的設計，因為用家很容易因為用得不暢順而氣餒，投訴甚至放棄使用。程式缺陷亦固之然是要盡量避免，也是因為這直接影響用家的使用體驗。相對來說，編碼結構的好壞藏在華麗的UI之後，用家其實難以知道軟件內部的編碼究竟寫得好不好。Martin Fowler舉例說兩個軟件UI一樣好，亦沒太多的程式缺陷，一個內部編碼整潔有序，賣10美元，另一個內部編碼一團糟，但賣6美元。既然用家都不能看到內部編碼如何，編碼是否整潔有序亦看似無礙軟件運作，誰會花多4美元去買前者？軟件公司又為何要花資源在軟件的內部質素？
技術債項 Technical Debt
內部質素與軟件持續開發 作為一個程式員，最花時間的工作理應就是處理、改動程式編碼，即使是全新的軟件開發，程式員仍需要在已完成的程式基礎上去編寫源碼。要加一個新的功能，首先要知道如何將新功能放入原本程式的流程裡，然後改動現有流程並放置新功能。而由於通常會接觸到／使用到原本的程式編碼，程式員不得不先理解程式是如何編寫。
問題來了，如果原本程式的內部質素奇差，邏輯紊亂，數據難以跟隨，程式員就要花很多時間去理解、使用原本的程式。這種程式當下的狀態與其理應狀態之間其差異，Martin Fowler 稱之為 cruft, 一種程式上的冗餘。他提到另一位著名的程式設計師Ward Cunningham 對cruft所提出的一種隱喻，Technical Debt 技術債項，因為當一位程式員為了各種原因去無視內部質素，其產生出來的技術債項會導致將來所有有份涉足該源碼的程式員付出更多時間去進行程式上的修改，這些額外所費的時間可視為技術債項的利息。 內部質素對開發時間的影響
雖然用家無法直接體會到軟件的內部質素，但用家卻在意軟件新功能開發的時間，這就直接受到內部質素的影響。技術債項多，每一項新功能的添加就會附上相應衍生出來的利息，亦即開發時間增加，用家亦要等待同樣的時間才能使用到新功能。在這個情況下，技術債項少的軟件會比債項多的軟件更快推出新功能，而用家相對之下很有可能會轉用較貴但功能更多的同類軟件。路遙知馬力，技術債項多的軟件可能可以很快跑出，但往往輸在持久力上。 債項多少的差異，使到軟件持續開發進度的交叉點數週就出現
Martin Fowler指出，即使最好的開發隊伍，亦難免有技術債項的產生，皆因開發的時候很多時處於不確定的未知狀態，開發成員亦只有大概的概念去知道軟件需要什麼，只能夠見步行步，越後期迷霧才越散去，加上軟件所用的開發語言、資源庫、平台亦在開發期間不斷變更，就如興建大廈時，在興建好一半後大改圖則、建築材料一樣。
We made good decisions, but only now do we understand how we should have built it.
而成功的開發隊伍就會透過寫自動化測試（automated test）、重構（refactoring）、持續整合（continuous integration），以積極清除足夠的冗餘，令到新功能開發時間減低。在這個意義底下，內部質素高的軟件也許一開始的開發成本較高。但以長遠發展，高內部質素的軟件開發成本卻是比較低廉。
所以，各位程式員應該知道如何和上司解釋軟件質素的重要，而各位老闆亦懂得怎樣分配時間、資源在軟件開發吧？
聯絡我們:
電郵地址: hello@ones.software
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
ONES Publication
We share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software
作為一個程式員，最花時間的工作理應就是處理、改動程式編碼，即使是全新的軟件開發，程式員仍需要在已完成的程式基礎上去編寫源碼。要加一個新的功能，首先要知道如何將新功能放入原本程式的流程裡，然後改動現有流程並放置新功能。而由於通常會接觸到／使用到原本的程式編碼，程式員不得不先理解程式是如何編寫。
問題來了，如果原本程式的內部質素奇差，邏輯紊亂，數據難以跟隨，程式員就要花很多時間去理解、使用原本的程式。這種程式當下的狀態與其理應狀態之間其差異，Martin Fowler 稱之為 cruft, 一種程式上的冗餘。他提到另一位著名的程式設計師Ward Cunningham 對cruft所提出的一種隱喻，Technical Debt 技術債項，因為當一位程式員為了各種原因去無視內部質素，其產生出來的技術債項會導致將來所有有份涉足該源碼的程式員付出更多時間去進行程式上的修改，這些額外所費的時間可視為技術債項的利息。
雖然用家無法直接體會到軟件的內部質素，但用家卻在意軟件新功能開發的時間，這就直接受到內部質素的影響。技術債項多，每一項新功能的添加就會附上相應衍生出來的利息，亦即開發時間增加，用家亦要等待同樣的時間才能使用到新功能。在這個情況下，技術債項少的軟件會比債項多的軟件更快推出新功能，而用家相對之下很有可能會轉用較貴但功能更多的同類軟件。路遙知馬力，技術債項多的軟件可能可以很快跑出，但往往輸在持久力上。
Martin Fowler指出，即使最好的開發隊伍，亦難免有技術債項的產生，皆因開發的時候很多時處於不確定的未知狀態，開發成員亦只有大概的概念去知道軟件需要什麼，只能夠見步行步，越後期迷霧才越散去，加上軟件所用的開發語言、資源庫、平台亦在開發期間不斷變更，就如興建大廈時，在興建好一半後大改圖則、建築材料一樣。
We made good decisions, but only now do we understand how we should have built it.
而成功的開發隊伍就會透過寫自動化測試（automated test）、重構（refactoring）、持續整合（continuous integration），以積極清除足夠的冗餘，令到新功能開發時間減低。在這個意義底下，內部質素高的軟件也許一開始的開發成本較高。但以長遠發展，高內部質素的軟件開發成本卻是比較低廉。
所以，各位程式員應該知道如何和上司解釋軟件質素的重要，而各位老闆亦懂得怎樣分配時間、資源在軟件開發吧？
聯絡我們:
電郵地址: hello@ones.software
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
ONES PublicationWe share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software分享至
成為作者繼續創作的動力吧！
© 2024 vocus All rights reserved.