先前在网络看到很多人在推荐与分享 Clean Code 这本书，当时，并无很强烈动机想要看这本书。先入为主的觉得这又只是一本介绍程序 Design Patten 的书罢了。实际上到书店翻开这本书之后，尤其在前面几页中看到下面这一张图。心中Wow一声，心想这本书一针见血的刺进我的痛。
这本书介绍非常多程序开发者因该注意的程序撰写概念跟守则，这里就不一一介绍，有兴趣的人建议可以买来看看。不过个人觉得此书有些章节中，阅读者若是没有两三年的实务程序开发经验或是维护许多大型系统的经历，可能无法感同身受或是认同书中的一些作法及想法。
Clean Code对于维运成本有甚么关系呢?个人认为有良好的Clean Code概念，不仅可以降低团队的开发成本，也可以让系统维运成本也跟着降地。系统维运项目大致有下面几点:
系统数据维护
Bug修正
功能规格的修正或是修改
开发新功能与新需求
维运成本考虑就只有下面三项:
时间
人力
风险
个人认为最耗成本的维运项目是第二项到第四项。一般而言企业内部的IT要真正只需维护自己所开发的系统的情况并不多，绝大多数的人都必须去承接前人所留下或是外部导入的系统。由此可知，当新团队或是新人承接后，不仅是对原本系统架构及ProcessKnowhow不熟外，可能连代码在写甚么都看不懂也大有人在。故经常发生 好的代码带你上天堂，坏的程序码会让你生不如死 的戏码。因此，当系统的代码是很杂乱时，所付出的代价就是，若系统要进行Trouble shooing时，问题被解决的时间就会被拉长，且若是用户有新新需求或是功能变更时，程序的开发时程将会被拉长，纵使只是加一个小功能，所花费的的时程会比之前系统创建的时间还长。尤其当这系统架构随时间越来越大或是错综复杂时，所花费的修改或是添加功能的成本也随之越大。最可怕的是，当新团队接手后，完全无法针对该系统进行修改或是维护时，势必需要重新创建一套新系统时候，这是不仅是成本的消耗，同时，还必须承担新旧系统交换上下线、新系统须包含旧系统功能、新系统时程…等风险，当然，风险与时间是成反比的。
当一个团队在开发系统时，若只在乎"完成"系统功能而不考虑架构及代码规范，进而产出杂乱的代码，在短期内或许可以满足需求，看似用很少的成本，发挥极大的效益。但是，就系统营运的时间拉长，，实际上后续的维运却是必须再花费更多成本支出，才能满足其维运需求。
从上图可知，若是该系统的代码越杂乱(只求速度与代码产能的后果)，此系统后续的各项功能开发或是变更，所完成的时间是越来越长，因为，程序产能是越来越低了。然而，主管为了解决这现象，往往就会出现人月神话的场景。但是，往往只能治标无法治本。
程序产能码 / 人力 = 时间
就一般程序员而言，在程序开发约三个月后，大概就会忘记之前程序为什么要这样写。可想而知，一开始就把的代码变得很杂乱，不易阅读。在三个月后有新需求或是用户功能变更的时候，团队又需要花大量的时间成本重新Review Code，造成往往只需要花几个小时就可以完成的功能，却必须痛苦的好几天或是好几周才有办法完成。若是又有遇到时间压力，最后不是系统品质下降，就是另一个杂乱的代码诞生。在这本书中提到「我们抱怨需求一变再变，违背原本的设计，我们感叹开发进度过于紧凑，导致无法把事情做好。我们滔滔不绝将原因归咎于愚蠢的主管,偏执的客户,无用的市场型态，但是错并不在这些事物上，而是在我们本身，我们不够专业」，这句话我认为说得很好，因为，无论是PM或是用户都是针对他们需负责的工作而做事，相对的开发者或IT人员该负责的工作就是在交付功能之余，也须保护代码不要过于混乱。而若是要达到所谓 Clean Code 那样不是要花费更大的成本? 我认为不然，就以可靠度工程中的浴缸曲线理论来思考。当一个系统开发期间，花费较高的成本，其实是在初期的系统分析与架构设计，中间的程序开发成本相对是低的，而若是因为初期的架构有问题或是中间开发代码是不易维护，则会影响到后面的维运或是需求增加，进而将会造成维运成本的垫高，而越后面的修正是会花费比初期更高的成本才有办法完成任务。
最后，软件工程常常会提到开发需要有许多文档或是单元测试及一堆测试后才可以上线，基本上这是无误的，不过，就以制造业的IT开发者来说，往往时程与需求都被压的喘不过气，若是有分析文档与说明手册，就已经很不错，要做到测试部分，如果可以在上线进行压力测试及集成测试就很棒了。要进行单元测试实在不可能，且也不一定公司会有这样测试单位，因此，常常开发者就是测试者，结果就是甚么都没有。上线的系统不可能完全都没有任何Bug或是一个完美的系统，甚至不修改功能的系统，我觉得在制造业这是不太可能发生，但是，至少保持良好的代码或是可读性高的代码，对于后续的维运是有帮助，至少出问题时候，还可以快速找到问题所在，而不是像侦探一样大海捞针去找线索，系统需要Enhance时，开发时程也会较快许多。
