工程师在项目中的角色不应该只是执行者，而是整个项目的参与者。注：国外程序员有一句自嘲的话叫：coffeein,codeout。程序员是最喜欢自嘲的一群人，这是一种积极向上的生活态度。但是如果把一些话当真，结果往往不是很好，比如刚才那句话。入职后接到的第一个任务是对现有的部门签名系统进行更新和修复。本系统可以根据当前登录的账号自动从后台获取相关信息，并填写在签名文件的相应位置。由于自动获取的信息可能存在错误，因此也支持用户手动修改。修改完成后，用户可以生成图片并保存，添加到邮件的签名文件中。因为设计了新版的邮件签名，需要根据新的设计图更新签名样式。同时需要解决当前系统在某行过长时无法自动换行的BUG，以及后台信息获取不全的问题。接到任务后，我粗略浏览了现有系统的源代码，立即着手修改。在我看来，对于原有系统来说，这些工作只是一些小修小补，所以我直接选择了对现有系统打补丁的方式。对于新增的设计图与原系统不兼容的部分，也使用了一些补丁进行修改。这样做的结果是，任务完成后，系统上到处都是各种补丁，逻辑极其复杂。如果不仔细思考，即使再读一遍代码，也未必能立马明白一切。花了一天时间完成的新系统虽然上线了，但是给我布置任务的兄弟们和我自己都不是很满意。好在这只是内部系统，我还有补救的机会。我建议重构整个系统。为了不让重构重蹈覆辙，我们分析了出现的问题。问题分析回顾一下从接到任务到重构的整个过程，问题出在哪里？接到任务后，我要做的就是立即开始执行。第一个问题可能出在“马上”。虽然第一次完成后的系统可以正常工作，但最大的问题是当需要添加新的设计图或需要修改现有的设计图时，维护起来非常困难。然而，在做之前，我并没有想过这些问题。该系统过去由五六个不同的部门共享，每个部门都有自己的签名文件，并且每个部门的设计都在不断变化。也就是说，需要这个系统具有高度的可维护性和可扩展性，这是一个隐性需求。但是，由于对整个系统的后台不了解，只是简单的执行眼前的任务，导致最终难以维护的问题。因此，工程师不仅要写代码，还要了解需求的背景来指导自己的工作。在解决后台信息获取不全的问题时，在对接界面上花了很多时间，最后发现当时系统使用的PHP后台界面很久没有维护了，连例子都没有了文档中给出的无法正常运行。.这样的经历无疑是令人沮丧的。问题是我接到任务的时候刚知道后台提供了这么一个接口就放弃了。我没有对界面进行可用性测试，结果浪费了我的时间。也就是说，并非需求方提供的所有资源都是可用的，需要在开工前对资源进行可用性测试。因此，工程师不仅要编写代码，还要测试支持他们工作的资源的可用性。接到的任务并不复杂，但是直接写代码执行还是花费了很多时间和精力。对于文字换行的bug，其实有很多种情况可以考虑：一种是因为部门信息本身太长，直接从后台获取的结果多了一行；另一种是用户修改多行时产生的结果。第二种情况又可以细分为两种，即用户输入换行，或者同一段落的内容在添加文字后超出一行。对于逻辑处理，这几种情况需要的处理是不同的。如果没有想清楚就去执行，或者过程中发现问题，逻辑反复变化，或者上线后发现自己没有想清楚，这不是我们想看到的。因此，工程师不仅要写代码，还要对需求进行完整的分析，将需求拆分成具体的可执行动作，以保证自己的工作严谨、透彻。在学校，我们常说Deadline是最好的生产力。没有时间限制，往往很难有效推进工作。学校的截止日期通常由教师根据经验确定，但在工作中很难做到。分配任务的时候，弟弟问我，三个小时能完成吗？我可能只是简单地考虑一下并回答是。结果花了一整天。这里是一个时间评估的问题。在实际业务场景中，需求方通常需要与工程师协商时间线。从工程师的角度来看，如何评价这个时间比较合理？上一步需求拆分完成后，为每个具体可执行的小步骤预估一个时间。那些难以直接给出预估时间的地方，就是任务的风险点。比如在这个任务中，我对Canvas的操作不是很熟悉。这里可能要花很多时间，这是一个风险点。对于风险点，要想办法解决，并给予充分合理的预留时间。把所有的时间加起来再上浮10%，就是比较准确的预估时间。预计时间在整个项目的流程中起着至关重要的作用。因此，工程师不仅要写代码，还要合理预估时间，配合需求方制定项目的时间流程。以上工作完成后，进入具体实施阶段。这就是我认为的工程师在编写代码之前的工作。在完成这项任务的过程中，并非没有改进的余地。在写代码的时候，我倾向于独立解决遇到的问题。即使过了很长时间，我也没有及时和兄弟们沟通。我们都遇到过这样的情况。一个问题我们想了很久，却走进了死胡同，但一个外人可能一句话就帮我们解决了。对于实际项目，交流不限于技术人员。发现问题后，作为工程师，也要及时与需求方沟通，保持信息畅通，帮助需求方协调整个项目。当我完成系统时，遇到的技术问题没有及时跟别人沟通，约定的时间快到了也没有通知任何人。在实际项目中应该坚决避免这种情况。因此，工程师不仅要编写代码，还要及时与相关人员沟通问题，帮助自己和他人高效工作。经过对重构问题的分析，对于我来说，这个重构的过程也是一个重新认识工程师在项目中的位置的过程。这个过程我写下来了，有兴趣的同学可以去这里看看。结语现在很多工程师都在抱怨自己只是大公司的螺丝刀，多的不多，少的多。他们每天埋头写代码，需求来了，执行任务，等待下一个需求。至少在我看来，“人”的价值不应该仅限于此。如果把人看成是黑盒子，咖啡进，代码出，那么人和工具有什么区别？是做“程序员”还是“代码生成器”，值得思考。原文：http://code.mforever78.com/essay/2015/08/02/programmer-or-code-generator/作者：MForever78
