※ 引述《mickeyboy (mickey)》之銘言：
: 爬了一下版規，如果有觸犯到，再刪文 謝謝
: 幫朋友代PO
: 最近接手公司的新專案，結果發現該專案
: 幾乎完全沒註解，可能一個檔案裡面
: 註解不超過10個字，也沒手冊
: 雖然變數名稱那些都是用"有意義的英文"命名
: 大致上能猜得出"可能是跟什麼有關"
: 例如薪資單可能是A檔案，但A檔案中又一堆function
: 目前只能從MVC開始慢慢追，想請問版上的前輩們
: 如果遇到這種專案維護，有什麼技巧可以快速入手的
: 問公司的前輩，意思是摸索久了，自然就會記得了
: 感謝
「沒註解的專案該如何維護」 但其實如同推文中很多板友說的
沒註解不代表程式寫得不好 最高境界的 clean code 是無註解的
題外話：「好程式 -> 不寫註解」並不等價於「不寫註解 -> 好程式」
程式寫的爛還是乖乖寫註解比較實在...XD
我先假設你要問的其實是 「很難閱讀的專案該如何維護」
我建議的藥方是 Unit Test
￣￣￣￣￣
套上 Unit Test 有兩層意義：
1. 確認每個工作單元的行為是否和你猜想的相同
也可作為後續維護程式的「規格文件」
2. 作為重構的保護網，確認重構後行為沒有改變
實務上的步驟的大概是：
1. 建立可以方便撰寫、執行 Unit Test的環境
這得仰賴 IDE 是否有相關的框架、套件可以支援
例如 Visual Studio 內建的 MSTest
2. 小部份重構（還沒有加 Unit Test 保護，切勿大規模重構）
接下來或多或少會面臨 Unit Test 根本就包不上去的情況
因為程式撰寫時根本就沒有考慮過可測試性、耦合的程度太過嚴重
所以比須先使用一些技巧提高程式的可測性（例如依賴注入之類的）
3. 包上 Unit Test，確認工作單元的行為
4. 重構。讓程式碼更好閱讀、具有更高的可測性、可維護性
真的重構不出夠漂亮的程式碼，就乖乖加上註解吧～
Unit Test 是一門博大精深的學問
如何寫出好的test case、測試的工作單元該如何切割、各種情況如何驗證、...等
都是不小的學問，這邊我就不多作贅述了～
Google 「91 TDD」會有很多很棒的文章 :p
以上，獻醜了

話說有沒有專文是在討論嵌入式系統的unit test...Q_Q

案子都結束了，看TDD?沒有分層，邏輯交錯，架構很亂，ㄧ個函數包ㄧ堆功能，要怎麼unit test?我是假設性的提問、請教，語氣上若不週全，還請見諒

有些專案談不上維謢，打掉重練還比較快~~~

像這種很亂的程式碼 只能砍掉重練吧 小部份重構有點難

真的是講幹話

先把該函式慢慢拆解分層，拆到足以有明確的輸出輸入，針對新拆出來建立的函式作Unit test

重點是主管要承認做測試跟重構的價值 不然你一下就黑了

推 一堆人瘋狂加班就只是因為沒有正確的開發方式

不管是嵌入式系統或架構很亂，個人是建議去瞭解IC Design中的design for test之類的方法...

感謝建議，長知識了

老闆看到大家瘋狂加班反而會覺得很爽，耐操=有價值=賺到了