国外的程序员有一句自嘲的话叫做：CoffeeIn,CodeOut.程序员是最喜欢自嘲的一群人，这不失为一种积极的生活态度。但有些话如果你当真了，结果往往不会很好
阿海入职以后接到的第一个任务，就是更新和修复现有的部门签名系统。
这个系统可以根据当前登入的帐号自动从后台获取相关信息，填入到签名档的对应位置上，因为自动获取到的信息可能有误差，所以还支持用户手动修改。
用户修改完成后可以生成一张图片保存下来，加入到邮件的签名档中。因为设计了新一版的邮件签名，所以需要按照新的设计图更新签名样式，同时需要解决当前系统中某一行过长时不能自动换行的bug，以及后台信息获取不全的问题。
接到任务后，阿海大致浏览了一遍现有系统的源代码以后就马上着手改版了。
在他看来，对于原有的系统来说，这些任务只是一些小修小补，所以直接选择了在现有的系统上加Patch的方法。对于新增加的设计图与原来的系统产生的不兼容的部分，也通过一些Patch来修改掉。
这样做的结果就是，这个任务完成后，系统里充斥着各种各样的Patch，逻辑异常复杂，如果不仔细想的话，就连自己再读一遍代码也未必能马上明白所有地方。
花了一天完成的新系统虽然上线了，布置任务的领导和阿海自己都不太满意。所幸这只是一个内部的系统，他还有机会补救。阿海提出重构整个系统。为了不让重构仅仅是重蹈覆辙，他们对于出现的问题进行了分析。
了解需求背景
回顾从接到任务开始到重构前这整个的过程，问题出在了哪里呢？在接到任务以后，阿海做的是马上着手执行。第一个问题可能就出在「马上」上面。
第一次完成后的系统虽然能正常工作，但面临的最大的问题就是，当需要添加新的设计图或者对现有的设计图做出修改时，非常难以维护。
然而在动手之前，阿海并没有考虑过这些问题。这个系统曾经供五六个不同的部门共同使用，每个部门都有自己的签名档，并且每个的设计也在不断地变化当中。
也就是说，这个系统需要高度可维护和可扩展是一个隐含的需求，然而因为他并没有对整个系统的背景进行了解，只是执行眼前的任务，造成了最终难以维护的问题。
测试资源的可用性
在解决后台信息获取不全的这个问题时，阿海花费了大量的时间在对接接口上。然而最终发现当时系统所用的PHP后台接口已经很久没有人维护了，连文档中给出的示例都无法正常运行，这样的经历无疑让人沮丧。
究其问题在于，在接到任务的时候，他仅仅了解到后台提供了这样的接口就作罢，没有对接口进行可用性测试，最终浪费了自己的时间。换句话说，需求方提供的资源不一定都是可用的，在正式开始工作之前，需要对资源进行可用性测试。
对时间进行合理预估
在学校中，我们常常说Deadline是第一生产力。没有时限的工作往往是很难有效推进的。学校里的Deadline通常由老师根据经验来确定，而工作中就很难这样了。
布置任务的时候，领导问阿海说，三个小时能不能做完？阿海大概只是简单的过了一下脑子，就回答可以。结果最终花了一整天的时间。这里就涉及到一个时间评估的问题。
在真实业务场景下，需求方通常要和程序员协商一个时间线，从程序员的角度来讲，这个时间如何评估才比较合理呢？
在上一步需求拆分完成后，针对每一个具体可执行的小步骤，都预估一个时间。那些很难直接给出预估时间的地方，就是任务的风险点。
比如在这个任务中，阿海对于XXX的操作不是很熟悉，这里可能占用很多时间，就是一个风险点。对于风险点，要找出解决方案，并且给出足够并且合理的预留时间。
把所有时间加到一起，再向上浮动10%，才是一个比较准确的预估时间。预估的时间对于整个项目的流程都起着至关重要的作用。
与相关人员及时沟通问题
在做完以上所有的工作之后，才到了具体的执行阶段。也就是之前我认为的程序员工作的全部——写代码。
在完成这个任务的这一过程中，也不是没有可以改进的地方。在写代码时候，遇到的问题我都倾向于独立解决，即使在已经花费了很长时间的情况下，也没有及时与领导沟通。
我们都遇到过这样的情况，自己苦苦想了很久的问题，其实已经进入了死胡同，然而局外人一句话就可能帮我们解决。
对于实际项目来讲，沟通不仅仅局限于技术人员之间，发现问题后作为程序员，还应该及时与需求方沟通，保持信息的通畅，来帮助需求方协调整个项目。
完成这个系统的时候阿海遇到技术上的问题没有及时和别人沟通，在约定的时间快要截止的时候没有通知任何人，这在真实项目中是需要坚决避免的。
现在有很多程序员抱怨自己在公司中只是一枚镙丝钉，多了不多，少了不少。他们每天埋头写代码，需求来了，执行任务，再等待下一个需求。
至少我认为，「人」的价值不应该仅限于此。要做一个「程序员」还是「代码工具人」，这值得思考。