品质来自对细节的讲究”是我一直以来的信念，对于软件开发上的种种细节我都不放过，尽量不让自己处于模糊地带，这样才能在下次遇到相同或类似问题时得以迅速理解并解决，除了可以缩短处理问题的时间外，最重要的是可以提升软件质量，以及在撰写程序初期能就避免细节中潜藏的瑕疵。

　　我目前在公司里最主要的工作是带领一群软件工程师开发软件项目，时常带大家一起写 Code、看 Code，有时间的时候还会替他们做 Code Review 并点出一些程序撰写的问题或提供更好的写法，对他们的要求不曾少过。

　　曾经有位工程师问我：「保哥，我以前都一直认为写程序不就是 "解决问题" 而已吗？而且以前的主管也从来不会问我为什么要这么写或哪里写不好要改，为什么你还要花时间看我们写的 Code，有时还会要求我们将写好没问题的 Code 进行重构(Refactoring)或整个打掉重练？」

　　我回答他：「我们是个软件团队，每个人都需要自律，并且负起一位工程师应付的责任，每个人的技术知识都应该不断精进，你不应该满足于 "解决问题" 这个层级，而应该进而 "理解原理" 与 "探究细节"，从这个角度出发所写的东西不但有成就感，也更踏实。」

　　我还说：「我们彼此都应能互相支持，任何时刻都可以轻易的接起另一位工程师写的程序并让软件继续发展下去，没有怨言，只要架构清楚、程序代码撰写习惯一致就比较不会有问题。像我们公司有些四、五年前做的项目到现在还在维护，如果当初没要求程序写法，我想现在维护起来一定非常辛苦，想想你过两年后如何维护你现在写的程序吧。」

　　我是个热爱程序设计的人，对我来说写程序很有趣、很有新鲜感，但有趣的地方绝不止于 "解决问题" 而已，我曾经也这么想过，但后来我理解到，问题总会有解决的一天，但当同样的问题不断出现时，你会知道问题可以解决，但慢慢的你就会失去新鲜感、失去成就感，写程序就会变成例行公事，就不好玩了。

　　软件不像建筑工程般做不好会危及人的性命，我们不见得需要先规划好所有细部蓝图才开始施工，我们只要有个架构、了解大致的需求就可以开始动工了，做错了就是 "改"，责无旁贷的"改"，写软件一定要预留 "修改" 的空间，这就是我尽力要求 "可维护性" 的关系。我们公司一年可以接数十件大大小小的软件项目，如果每个项目都只能由开发的人来维护，那人力配置一定会极度不平衡，相对的软件质量迟早出问题。

　　再者，你应该也知道客户讲的东西经常 "昨是今非"，越大的项目越是这样，连签了名的文件都还能不算数，对于一些小范围的更动对软件来说本来就应该是合理的，但我看到有些朋友对于客户修改规格的举动经常忿忿不平，还有一些经常接项目的外包人员来说，也经常在为一些很小幅度的规格变更坚持己见，但是光花在不愿意修改所沟通的时间，我想软件早就不知道修完几遍了，一切都出在对软件项目错误的认知，或是自己的写的软件不容易修改所做出的 "合理反应"。

　　客户心情好或是内心极度愧对我们时，有时还会好心的主动提出愿意付钱请我们修改程序，我们为了继续经营客户，这种项目当然要继续接下去。所以无论如何只要是我们开发出来的软件，一定要尽量预留软件修改的空间，以免每个客户都只做一次生意，那很累。若是客户不要求，且项目真的确定完成后需求不可能会变更情况下，那也真的没什么好要求的了。

　　隆重声明一下，我当然不可能认同客户狂乱的规格变更，凡事总有个界线在，我只是想强调做软件项目应该与客户站在同一阵线，以客户满意度为依归。但若遇到超级没 sense 又很爱凹你做东做西且打死不追加预算的客户时，你可以有两个选择：(1) 直接退钱说不做了 (2) 硬着头皮改到底。

　　我几年前曾经花了几万块去上超强记忆力的课程，印象最深的只有一句话：「人的 "记忆" 几乎是无限的，人之所以会忘记是因为 "回忆" 的方式有问题。」

　　技术的细节如此的多，有人会问我：「我怎么可能把所有细节都记得，有需要再查 Google 就有了啊。」首先，Google 查到的东西不见得是对的，你不了解细节自然也无法判断对错。当然，我也不例外，我会忘事情，技术细节也会忘，但那不是忘记，只是回忆不起而已，有些知识被消化了，已经进入潜意识，写程序时你会很自然的会将你曾经学过、认真研究过的东西都给用上，只是你不知道而已。

　　若真的要回忆起旧时记忆的最佳方式，就是不断的在脑中建立索引！像我自己写博客文章，脑子里记得的只有关键词而已，这些关键词就是我的索引数据，因为都是自己写的东西，关键词自己最清楚，所以我随时可以找到想要找的数据，找不到才会去翻 Google 的数据。

　　我前几天就有个有趣的经历，我在看别人写的程序，他写的数据统计程序一直有数据不正确的情况，我看了好几个小时竟看不出问题所在，最后无意间发现原来他写的类定义了一堆类层级(Class)的字段变量(Field)，并且共享于多个方法，他以为这些变量只要宣告一遍然后所有方法(Method)都可以直接使用很方便，却完全没有想到这会造成极大的副作用(Side Effect)。我最早一开始写程序时很喜欢使用「全域变量」，当时是我在写 Perl、php 的时代，但就因为吃过很多 Debug 的亏，老早就不用这种开发技巧了，但在看别人的 Code 时却不会直觉的想到，只有自己写 Code 时才会避开这个问题，而这就是对技术细节内化的最佳证据。

　　有一句话说得很好：「时间花在哪里，成就就在哪里」想要做好软件工程师的角色，就应该多花时间专研技术细节，这并非是一条不归路，做软件的人，不满意随时可以转换跑道，但你走这条路的时候不认真就是浪费时间，你只要有付出努力就一定会获得有价值的东西，毕竟写程序是脑内革命，不是每个人都走的下去的，但要长期走下去就必须要有源源不绝的热情、对新知的无限渴望与用不完的新鲜感。

it知识库：品质来自对细节的讲究，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。