不要浪費時間寫完美程式碼
一個系統可以維持5年,10年,甚至20年以上,但是程式碼和設計模式的生命週期非常短,當對一個解決方案使用不同的方法進行迭代的時候,通常只能維持數月,數日,甚至幾分鐘的時間。
程式碼重要性區分
隨著對程式碼是如何改變的研究,致力於程式碼修改藝術的人發現了一個程式碼庫的規律曲線。每個系統都有很多從未改變的程式碼。但是也有小部分非常重要且有用的程式碼一次又一次的改變,經過了多次重構和重寫。
當你對一個系統,問題域,或者架構方法越來越熟悉的時候,就更容易發現和預測哪些程式碼會經常修改,哪些程式碼不會被修改,即區分重要程式碼和非重要程式碼。
我們應該嘗試追求完美程式碼?
眾所周知,我們應該寫乾淨整潔的程式碼,而乾淨整潔就應該是儘可能一致,易懂,簡單。
有些人追求極致,強迫自己寫的程式碼要漂亮且優雅,接近於他們所能達到的完美,瘋狂的進行重構,並致力於每一個細節。
與寫完程式碼不再變動相比,一直修改的程式碼會讓完美的需求和具有前瞻性的設計變得有些多餘和沒必要。
你不能寫出完美的軟體,這樣的結果會使你受傷了?沒必要,把它當做人生格言,信奉並祝賀,因為完美的軟體並不存在,在計算機歷史中沒一個人曾經寫出過完美軟體,當然,你也不可能成為第一個,只有接受這樣一個事實,你才能不再在浪費時間,將精力放在可能實現的理想中。
Andrew Hunt, 實用程式設計師:從路人到大師
曾經寫過的程式碼不需要優美優雅。它必須是正確的且容易理解的,因為在系統的生命週期中那些從不用修改的程式碼也會被多次訪問。同樣這些程式碼不需要又整潔又緊湊——只要整潔就足夠了。在一定程度上,複製貼上和其他快捷方法寫出的程式碼是允許的。即使這些程式碼周圍的程式碼變了,這些程式碼不需要反覆修改,不需要重構(直到你需要修改它)。這樣的程式碼是不值得花費額外的時間的。
那些經常修改的程式碼該如何處理呢?苦思冥想程式碼風格和提出最優雅的解決方案是浪費時間的,因為這些程式碼可能會在幾天或幾周之內再次修改,甚至重寫。因為希望程式碼應該變得更好而痴迷地重構那些需要經常修改程式碼,或者重構那些基本不會修改的程式碼。程式碼一直可以變得更好,但這並不重要。
最重要的是:程式碼是否做到了它應該做的事?程式碼執行正確且可用又高效嗎?能夠處理錯誤和錯誤資料而不奔潰或者至少是安全地出錯嗎?容易除錯嗎?能簡單又安全地修改程式碼嗎?這些不是對於完美程式碼的主觀想法,而是用來區分成功和失敗的切實可行的措施。
實用的編碼和重構
精益開發的核心思想是:不要浪費時間在那些不重要的事情上。這句話已告訴我們該怎樣寫程式碼,怎樣重構程式碼,怎樣評審程式碼,怎樣測試程式碼。
為了把工作做好,只重構你需要的——Martin Fowler 稱為機會主義重構(理解、清理不切實際的東西)和預先重構。足夠讓修改變得更簡單更安全即可,其他的不必考慮。如果你不修改那些程式碼,那麼那些程式碼長什麼樣子是無所謂的事。
在程式碼評審中,只關注那些重要的。程式碼正確嗎?有防範機制嗎?安全嗎?容易理解嗎?能夠安全地修改嗎?
忘掉編碼風格(除非編碼風格達到可理解的程度)。讓你的 IDE 處理格式化。不要過多爭論:程式碼是否可以是“更多的OO”。只要它有意義,不管它是否適當地遵循這種或那種模式,這些都不重要。無論你喜歡還是不喜歡都沒關係。無論你能否以更好的方式做到這一點並不重要——除非你在教一個對平臺和語言都不熟悉的新手,而且你需要做一些程式碼評審作為指導的一部分。
寫測試是有必要的。測試那些涵蓋主路徑和重要例外情況的測試。測試可以讓你以最少的工作量獲得最多的自信心。大規模全範圍測試或者小規模區域性測試——在編寫程式碼之前測試還是之後測試,都沒關係,只要做了這個工作就行。
這不(僅)是關於程式碼
建築學和工程學的隱喻從未在軟體開發中生效。我們不是設計和建造橋樑或摩天大樓 —— 它們會在幾年或幾代內保持基本相同。我們正在建造一些更富有創造力和抽象性、更加短暫的東西。程式碼編寫之後是用來修改的 —— 這就是為什麼它被稱為“軟體”的原因。
“經過五年的使用和修改,成功的軟體的原始碼通常與最初版本完全不一樣,而五年之後的成功的建築幾乎沒有什麼變化。”
Kevin Tate, 可持續軟體開發
我們需要將程式碼看作是我們工作的一個暫存:
…有時在面對更重要的事情時,我們被引導到盲目崇拜程式碼。我們經常會處於這樣的幻象中:在移交產品時最有價值的東西是程式碼,實際上這可能是對問題域的理解、設計難題的進展甚至是客戶反饋。
Dan Grover, 程式碼和創造性破壞
迭代開發教會了我們通過實驗來驗證我們工作的結果 —— 我們是否已解決了這個問題,如果沒有,我們學到了什麼,我們該如何改進?我們正在構建的軟體永遠不會完成。即使設計和程式碼是正確的,它們可能也只是在一段時間內是正確的,直到環境要求其再次改動或被替換為更好的東西。
我們需要編寫好的程式碼:可理解、正確、安全和可靠的程式碼。我們需要重構和審查它,並寫出好的有用的測試用例,直到其中的一些程式碼(也可能是全部(),可能會很快被拋棄,或者可能永遠不會被再次看到,或根本不會使用了。我們需要認識到,我們的一些工作必然會被浪費掉,並要為此進行優化。做那些必須做的,不做無用功。不要浪費時間嘗試編寫完美的程式碼。
相關文章
- 不要浪費時間寫完美的程式碼
- 不要浪費時間去寫所謂的完美程式碼
- 不要將時間浪費到編寫完美程式碼上
- 忠告:不要在愚蠢時間寫程式碼
- 不要相信程式設計師在加班時間寫的程式碼程式設計師
- 你在程式設計的時候,浪費了多少時間?程式設計
- 你在程式設計的時候浪費了多少時間?程式設計
- 千萬不要相信程式設計師在加班時間寫的程式碼!程式設計師
- 測試是浪費時間,我的程式肯定沒問題
- 遊戲學 | 玩電子遊戲是浪費時間?遊戲
- 如何利用工時表軟體管理員工時間 避免時間浪費
- 千萬不要寫程式碼不要讀博
- 為什麼“敏捷”會浪費這麼多時間? - Reddit敏捷
- 總結那些艱難的抉擇、浪費的時間
- 程式設計開發中最浪費時間和資源的7個錯誤程式設計
- swistak35:不要追求完美的程式碼;爭取完美的界限!
- Scrum不是一顆銀彈,有時可能會浪費大量時間 - RemoHJansenScrumREM
- 工作時玩遊戲並非浪費時間: “微休息”有很多好處遊戲
- 研發團隊開晨會真的是浪費時間嗎?
- Eric Schwarz:闡述浪費玩家遊戲時間的設計模式遊戲設計模式
- 多些時間能少寫些程式碼
- 有了測試團隊,再寫單元測試,是否是浪費開發時間呢?
- python中頻繁的print到底能浪費多長時間Python
- 程式設計師,千萬不要重寫程式碼程式設計師
- JavaScript 計算程式碼執行花費時間JavaScript
- 前蘋果副總裁:如果你做的事情毫不費力,就是在浪費時間蘋果
- weblogic + ejb + jbuiler 每次修改程式碼都要重新編譯,太浪費時間了,又沒有結決辦法?WebUI編譯
- 程式碼真的有必要寫到完美嗎?
- 研究顯示安全分析師 25% 的時間浪費在誤報上
- 程式設計師十誡:第三誡:不要在休息時間談論程式碼程式設計師
- Swift 之父正式退出 Swift 核心團隊:這只是在浪費我的時間Swift
- 時間小人程式碼
- 技術總監到底要不要寫程式碼?
- 架構師究竟要不要寫程式碼?架構
- 為什麼程式設計師千萬不要重寫程式碼?程式設計師
- 《程式碼大全》程式設計師們怎樣花費自己的時間程式設計師
- 開會=浪費時間?阿里技術團隊這樣開專案覆盤會阿里
- Electric Cloud:調查顯示軟體工程師將20%時間浪費在等待上Cloud軟體工程工程師