方格精選
Code 寫得好對公司有用嗎？
更新於 2022/04/14閱讀時間約 5 分鐘
tl;dr, 絕對有用！
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美元去買前者？軟件公司又為何要花資源在軟件的內部質素？
內部質素與軟件持續開發
作為一個程式員，最花時間的工作理應就是處理、改動程式編碼，即使是全新的軟件開發，程式員仍需要在已完成的程式基礎上去編寫源碼。要加一個新的功能，首先要知道如何將新功能放入原本程式的流程裡，然後改動現有流程並放置新功能。而由於通常會接觸到／使用到原本的程式編碼，程式員不得不先理解程式是如何編寫。
問題來了，如果原本程式的內部質素奇差，邏輯紊亂，數據難以跟隨，程式員就要花很多時間去理解、使用原本的程式。這種程式當下的狀態與其理應狀態之間其差異，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
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
一款遊戲的開發，肯定伴隨大大小小的修改和調整。
創作者不能怕改。但問題是，改東西需要花時間。一些看似簡單的改動，背後程式邏輯可能要好幾天，甚至幾星期才能修正。
對於不懂程式的人，有時很難判斷東西好不好修。所以今天就來說一下，對程式來說什麼樣的修正會令我們頭痛呢？
先以一個草莓奶油蛋糕為例
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
程式與頻率時間
看起來這個問題有些奇怪，程式與頻率時間有什麼關係呢？一旦程式完成，似乎就不需要再理會頻率和時間了。實際上，這可能是一些不熟悉程式設計的人所提出的疑問。了解程式設計最重要的一點是，頻率和時間的安排會直接影響程式的效能和展現速度。
時間的利用
舉例來說，假設一個表單的每筆處理時間為
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
一款遊戲的開發，肯定伴隨大大小小的修改和調整。
創作者不能怕改。但問題是，改東西需要花時間。一些看似簡單的改動，背後程式邏輯可能要好幾天，甚至幾星期才能修正。
對於不懂程式的人，有時很難判斷東西好不好修。所以今天就來說一下，對程式來說什麼樣的修正會令我們頭痛呢？
先以一個草莓奶油蛋糕為例
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
程式與頻率時間
看起來這個問題有些奇怪，程式與頻率時間有什麼關係呢？一旦程式完成，似乎就不需要再理會頻率和時間了。實際上，這可能是一些不熟悉程式設計的人所提出的疑問。了解程式設計最重要的一點是，頻率和時間的安排會直接影響程式的效能和展現速度。
時間的利用
舉例來說，假設一個表單的每筆處理時間為
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人