方格精選

Code 寫得好對公司有用嗎?

更新 發佈閱讀 6 分鐘

tl;dr, 絕對有用!



raw-image

IT部門的同事間可能經常遇到這種問題,「究竟應該花多點時間去寫好編碼,還是應該快快寫好新的功能,往後才改善編碼的質素」,雖然大家心裏面都希望花時間寫好每一個功能的編碼,但面對開發時間永遠不足、上司的壓力,很多時就會無視編碼的質素,來成就新功能/新產品可以及早推出,然後就安慰自己之後才執拾殘局。不過程式員都是人類,難以敵不過「Later means never」這個定律,所以質素往往成為節省開發時間、成本下的犧牲品。

即使我們知道應該花時間一開始就寫好一點,但我們怎麼說服你自己、你的上司、你的老闆一開始的編碼質素是何其重要?寫下軟件工程界的大作之一《Refactoring - Improving the Design of Existing Code》的Martin Fowler 近日一篇文章《Is High Quality Software Worth the Cost?》就為我們提供了清晰的解答,軟件的質素其實是牽引住各種層面。

raw-image


外部質素(external quality)與內部質素(internal quality

Martin Fowler首先將軟件的質素分開為外部質素和內部質素,外部質素指的是用家能夠看得到的,例如UI和程式缺陷,而內部質素即是用家難以分辨好壞的部分,例如軟件結構。

現今不少公司都很注重UI、UX的設計,因為用家很容易因為用得不暢順而氣餒,投訴甚至放棄使用。程式缺陷亦固之然是要盡量避免,也是因為這直接影響用家的使用體驗。相對來說,編碼結構的好壞藏在華麗的UI之後,用家其實難以知道軟件內部的編碼究竟寫得好不好。Martin Fowler舉例說兩個軟件UI一樣好,亦沒太多的程式缺陷,一個內部編碼整潔有序,賣10美元,另一個內部編碼一團糟,但賣6美元。既然用家都不能看到內部編碼如何,編碼是否整潔有序亦看似無礙軟件運作,誰會花多4美元去買前者?軟件公司又為何要花資源在軟件的內部質素?


raw-image


內部質素與軟件持續開發

作為一個程式員,最花時間的工作理應就是處理、改動程式編碼,即使是全新的軟件開發,程式員仍需要在已完成的程式基礎上去編寫源碼。要加一個新的功能,首先要知道如何將新功能放入原本程式的流程裡,然後改動現有流程並放置新功能。而由於通常會接觸到/使用到原本的程式編碼,程式員不得不先理解程式是如何編寫。

問題來了,如果原本程式的內部質素奇差,邏輯紊亂,數據難以跟隨,程式員就要花很多時間去理解、使用原本的程式。這種程式當下的狀態與其理應狀態之間其差異,Martin Fowler 稱之為 cruft, 一種程式上的冗餘。他提到另一位著名的程式設計師Ward Cunningham 對cruft所提出的一種隱喻,Technical Debt 技術債項,因為當一位程式員為了各種原因去無視內部質素,其產生出來的技術債項會導致將來所有有份涉足該源碼的程式員付出更多時間去進行程式上的修改,這些額外所費的時間可視為技術債項的利息

raw-image

雖然用家無法直接體會到軟件的內部質素,但用家卻在意軟件新功能開發的時間,這就直接受到內部質素的影響。技術債項多,每一項新功能的添加就會附上相應衍生出來的利息,亦即開發時間增加,用家亦要等待同樣的時間才能使用到新功能。在這個情況下,技術債項少的軟件會比債項多的軟件更快推出新功能,而用家相對之下很有可能會轉用較貴但功能更多的同類軟件。路遙知馬力,技術債項多的軟件可能可以很快跑出,但往往輸在持久力上。

raw-image

Martin Fowler指出,即使最好的開發隊伍,亦難免有技術債項的產生,皆因開發的時候很多時處於不確定的未知狀態,開發成員亦只有大概的概念去知道軟件需要什麼,只能夠見步行步,越後期迷霧才越散去,加上軟件所用的開發語言、資源庫、平台亦在開發期間不斷變更,就如興建大廈時,在興建好一半後大改圖則、建築材料一樣。

We made good decisions, but only now do we understand how we should have built it.

而成功的開發隊伍就會透過寫自動化測試(automated test)、重構(refactoring)、持續整合(continuous integration),以積極清除足夠的冗餘,令到新功能開發時間減低。在這個意義底下,內部質素高的軟件也許一開始的開發成本較高。但以長遠發展,高內部質素的軟件開發成本卻是比較低廉。

所以,各位程式員應該知道如何和上司解釋軟件質素的重要,而各位老闆亦懂得怎樣分配時間、資源在軟件開發吧?

原文:https://ones.software/blog/index.php/2019/05/11/software-001/

聯絡我們:

主頁: https://ones.software/tw/

電郵地址: 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
留言
avatar-img
Offision 智能辦公室資訊平台
8會員
50內容數
通過 Offision 立即提高您的辦公績效!免費試用! 無需信用卡 即開即用
2022/06/22
深入了解如何提供訪客真正需要的服務 Bookings ONE簡單快捷辦理登記手續,從而給人留下深刻的印象,而您可以專注於給他們致以熱情的問候。 訪客體驗不只是提供服務,應以方便訪客為先 訪客可能是潛在的客戶,良好的訪客體驗服務有助你增加生意 訪客服務中經常遇上的難題 安全問題 健康問題
Thumbnail
2022/06/22
深入了解如何提供訪客真正需要的服務 Bookings ONE簡單快捷辦理登記手續,從而給人留下深刻的印象,而您可以專注於給他們致以熱情的問候。 訪客體驗不只是提供服務,應以方便訪客為先 訪客可能是潛在的客戶,良好的訪客體驗服務有助你增加生意 訪客服務中經常遇上的難題 安全問題 健康問題
Thumbnail
2020/12/08
之前我們已經介紹兩個今年Google 新提出的網站性能基準, Largest Contentful Paint 最大內容繪製,和 First Input Delay 首次輸入延遲。這次就看看 Cumulative Layout Shift 累計版面配置轉移。
Thumbnail
2020/12/08
之前我們已經介紹兩個今年Google 新提出的網站性能基準, Largest Contentful Paint 最大內容繪製,和 First Input Delay 首次輸入延遲。這次就看看 Cumulative Layout Shift 累計版面配置轉移。
Thumbnail
2020/09/30
Google 經常更新網站性能的指標和工具,務求在衡量網站方面的用戶體驗與時並進。那讓我們來看看今年Google 提出的網站性能基準其中之一:FID — First Input Delay 首次輸入延遲吧。
Thumbnail
2020/09/30
Google 經常更新網站性能的指標和工具,務求在衡量網站方面的用戶體驗與時並進。那讓我們來看看今年Google 提出的網站性能基準其中之一:FID — First Input Delay 首次輸入延遲吧。
Thumbnail
看更多
你可能也想看
Thumbnail
vocus 慶祝推出 App,舉辦 2026 全站慶。推出精選內容與數位商品折扣,訂單免費與紅包抽獎、新註冊會員專屬活動、Boba Boost 贊助抽紅包,以及全站徵文,並邀請你一起來回顧過去的一年, vocus 與創作者共同留下了哪些精彩創作。
Thumbnail
vocus 慶祝推出 App,舉辦 2026 全站慶。推出精選內容與數位商品折扣,訂單免費與紅包抽獎、新註冊會員專屬活動、Boba Boost 贊助抽紅包,以及全站徵文,並邀請你一起來回顧過去的一年, vocus 與創作者共同留下了哪些精彩創作。
Thumbnail
當你想升級設備、投放廣告,或是為了雙 11 提前備貨,卻發現現金流卡住時,除了等銀行、跟親友開口,其實還有一個常被忽略、卻很有力的選項。讓房子,成為你事業的贊助商——國峯厝好貸。
Thumbnail
當你想升級設備、投放廣告,或是為了雙 11 提前備貨,卻發現現金流卡住時,除了等銀行、跟親友開口,其實還有一個常被忽略、卻很有力的選項。讓房子,成為你事業的贊助商——國峯厝好貸。
Thumbnail
產品開發的成功,除了品質,更在於是否能夠在適當的時程內推出並滿足客戶需求。 身為開發、設計人員,從文中提供的三個角度來思考,以確保產品與公司的競爭力。
Thumbnail
產品開發的成功,除了品質,更在於是否能夠在適當的時程內推出並滿足客戶需求。 身為開發、設計人員,從文中提供的三個角度來思考,以確保產品與公司的競爭力。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
最近常在思考,軟體開發的品質到底是什麼,我們能承擔的品質出問題的風險有多大?在軟體開發過程,無論你是走Scrum或是DevOps的開發流程,都希望交付出來的軟體品質是好的,因此,每當談軟體開發中的測試種類就包含這些議題
Thumbnail
最近常在思考,軟體開發的品質到底是什麼,我們能承擔的品質出問題的風險有多大?在軟體開發過程,無論你是走Scrum或是DevOps的開發流程,都希望交付出來的軟體品質是好的,因此,每當談軟體開發中的測試種類就包含這些議題
Thumbnail
這本書是在 Agile Tour 2015 聽完作者本人演講後買的,不過,還真的沒挪出什麼時間把它看完,直到最近因為一些因素終於有時間把它看完了,所以上述很多摘錄都是心有戚戚焉。看是看完了,也別因為我上面都把好處寫出來就覺得看板方法好棒棒,一定也可以適用在你的團隊,真的嗎?
Thumbnail
這本書是在 Agile Tour 2015 聽完作者本人演講後買的,不過,還真的沒挪出什麼時間把它看完,直到最近因為一些因素終於有時間把它看完了,所以上述很多摘錄都是心有戚戚焉。看是看完了,也別因為我上面都把好處寫出來就覺得看板方法好棒棒,一定也可以適用在你的團隊,真的嗎?
Thumbnail
「幫我做的跟 Facebook 一樣單純就好」 「嗯 … ?」 不管怎麼估計都可能失準,在一件事做完之前你怎麼知道能不能做到?
Thumbnail
「幫我做的跟 Facebook 一樣單純就好」 「嗯 … ?」 不管怎麼估計都可能失準,在一件事做完之前你怎麼知道能不能做到?
Thumbnail
近期花了一些時間研讀 Robert C. Martin 所著的 Clean Architecture 這本書,剛好看到了一些概念恰巧可以與工作上遇到的架構做一些印證,於是便想寫一些文章做一些紀錄。 在 Clean Architecture 中,提到了軟體元件的內聚與耦合的概念。
Thumbnail
近期花了一些時間研讀 Robert C. Martin 所著的 Clean Architecture 這本書,剛好看到了一些概念恰巧可以與工作上遇到的架構做一些印證,於是便想寫一些文章做一些紀錄。 在 Clean Architecture 中,提到了軟體元件的內聚與耦合的概念。
Thumbnail
我前陣子在 Linkedin 上看到一篇有趣的推文,表現軟體開發時,從企劃階段到實際成品的巨大落差。這是永遠無法解決的難題嗎?我分享過去做專案和產品的經驗,希望能帶給各位思考解法的參考。
Thumbnail
我前陣子在 Linkedin 上看到一篇有趣的推文,表現軟體開發時,從企劃階段到實際成品的巨大落差。這是永遠無法解決的難題嗎?我分享過去做專案和產品的經驗,希望能帶給各位思考解法的參考。
Thumbnail
隨著軟體開發方法、工具、以及成品應用方式的變化,軟體開發已經不能只靠單一證照、程序、手段來完成;雖然如此,為了專案的進度與品質控管,仍然有一些共通的道理是必須遵守的。本文就來談談這些同樣也適用於其他專案管理的基本原則。
Thumbnail
隨著軟體開發方法、工具、以及成品應用方式的變化,軟體開發已經不能只靠單一證照、程序、手段來完成;雖然如此,為了專案的進度與品質控管,仍然有一些共通的道理是必須遵守的。本文就來談談這些同樣也適用於其他專案管理的基本原則。
Thumbnail
「究竟應該花多點時間去寫好編碼,還是應該快快寫好新的功能,往後才改善編碼的質素」,雖然大家心裏面都希望花時間寫好每一個功能的編碼,但面對開發時間永遠不足、上司的壓力,很多時就會無視編碼的質素,來成就新功能/新產品可以及早推出。我們怎麼說服你自己、你的上司一開始的編碼質素是何其重要?
Thumbnail
「究竟應該花多點時間去寫好編碼,還是應該快快寫好新的功能,往後才改善編碼的質素」,雖然大家心裏面都希望花時間寫好每一個功能的編碼,但面對開發時間永遠不足、上司的壓力,很多時就會無視編碼的質素,來成就新功能/新產品可以及早推出。我們怎麼說服你自己、你的上司一開始的編碼質素是何其重要?
Thumbnail
所有的軟體開發專案,都會有這麼一個天字第一號大挑戰:控制時程。在M社的研發手法,就是透過工程管理決定什麼要做、什麼不做,來控制開發的總時間,並利用功能規劃的手法決定開發內容。
Thumbnail
所有的軟體開發專案,都會有這麼一個天字第一號大挑戰:控制時程。在M社的研發手法,就是透過工程管理決定什麼要做、什麼不做,來控制開發的總時間,並利用功能規劃的手法決定開發內容。
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News