※ 引述《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
以上，献丑了