作者mysteriousGE ( )
看板Soft_Job
标题Re: [请益] 没注解的专案该如何维护
时间Sun Jul 23 00:05:15 2017
※ 引述《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
以上，献丑了
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.169.90.185
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1500739518.A.27B.html
1F：→ james732: 话说有没有专文是在讨论嵌入式系统的unit test...Q_Q 07/23 00:31
2F：→ dnabossking: 案子都结束了，看TDD? 07/23 01:13
3F：推 dnabossking: 没有分层，逻辑交错，架构很乱，ㄧ个函数包ㄧ堆功能 07/23 01:16
4F：→ dnabossking: ，要怎麽unit test? 07/23 01:16
5F：→ dnabossking: 我是假设性的提问、请教，语气上若不周全，还请见谅 07/23 01:17
6F：→ newversion: 有些专案谈不上维謢，打掉重练还比较快~~~ 07/23 01:22
7F：→ vi000246: 像这种很乱的程式码 只能砍掉重练吧 小部份重构有点难 07/23 01:24
8F：推 tvbic: 真的是讲干话 07/23 02:10
9F：推 JingX: 先把该函式慢慢拆解分层，拆到足以有明确的输出输入， 07/23 08:04
10F：→ JingX: 针对新拆出来建立的函式作Unit test 07/23 08:05
11F：推 wuliou: 重点是主管要承认做测试跟重构的价值 不然你一下就黑了 07/23 14:26
12F：推 evan176: 推 一堆人疯狂加班就只是因为没有正确的开发方式 07/23 19:48
13F：推 GameGyu: 不管是嵌入式系统或架构很乱，个人是建议去了解IC Design 07/23 20:54
14F：→ GameGyu: 中的design for test之类的方法... 07/23 20:54
15F：推 mickeyboy: 感谢建议，长知识了 07/23 21:00
16F：推 JingX: 老板看到大家疯狂加班反而会觉得很爽，耐操=有价值=赚到了 07/24 07:31