程师在名目中的角色不应只是口头者，而应是整个名目标介入者。
入职接到的***个义务，就是降级和修复现有的部门签名系统。这个系统可以依据登入的帐号智能从后盾失掉关系消息，填入到签名档的对应位置 上，由于智能失掉到的消息或许有误差，所以还支持用户手动修正。用户修正成功后可以生成一张图片保留上去，参与到邮件的签名档中。由于设计了新一版的邮件 签名，所以须要依照新的设计图降级签名样式，同时须要处置应前系统中某一行过长时不能智能换行的 bug，以及后盾消息失掉不全的疑问。
接到义务后，我大抵阅读了一遍现有系统的源代码就马上着手改版了。在我看来，关于原有的系统来说，这些义务只是一些小修小补，所以我直接选用了 在现有的系统上加 patch 的方法。关于新参与的设计图与原来的系统发生的不兼容的局部，也经过一些 patch 来修正掉。
这样做的结果就是，这个义务成功后，系统里充满着各种各样的 patch，逻辑意外复杂，假设不细心想的话，就连自己再读一遍代码也未必能马上明白一切中央。花了一天成功的新系统只管上线了，安顿给我义务的师兄和我自己都不太 满意。所幸这只是一个外部的系统，我还无时机弥补。我提出重构整个系统。为了不让重构仅仅是吃一堑，长一智，咱们关于发生的疑问启动了剖析。
疑问剖析
回忆从接到义务开局到重构前这整个的环节，疑问出在了哪里呢？在接到义务，我做的是马上着手口头。***个疑问或许就出在「马上」上方。
***次成功后的系统只管能反常上班，但面临的***的疑问就是，当须要参与新的设计图或许对现有的设计图做出修正时，十分难以保养。但是在入手之前， 我并没有思索过这些疑问。这个系统曾经供五六个不同的部门独特经常使用，每个部门都有自己的签名档，并且每个的设计也在始终地变动当中。也就是说，这个系统需 要高度可保养和可裁减是一个隐含的需求，但是由于我并没有对整个系统的背景启动了解，只是口头眼前的义务，形成了最终难以保养的疑问。
所以，工程师不只有写代码，还要了解需求的背景，以指点自己的上班。
在处置后盾消息失掉不全的这个疑问时，我破费了少量的期间在对接接口上，但是最终发现事先系统所用的 PHP后盾接口曾经很久没有人保养了，连文档中给出的示例都不可反常运转。这样的阅历无疑让人丧气。究其疑问在于，在接到义务的时刻，我仅仅了解到后盾提供了这 样的接口就作罢，没有对接口启动可用性测试，最终糜费了自己的期间。换句话说，需求方提供的资源不必定都是可用的，在正式开局上班之前，须要对资源启动可 用性测试。
所以，工程师不只有写代码，还要测试资源的可用性，以支持自己的上班。
我接到的义务不算复杂，但直接就去写代码的口头模式还是白白破费了不少期间和精神。关于文字换行这一个 bug，其实可思索的状况有很多：一种是由于部门消息自身就过长，从后端取得的结果直接就超出了一行；另一种是用户在自己修正的时刻让结果超越了一行。而第二种 状况又可以细分为两种，即用户输入了换行符，或许参与文字后同段的内容超越一行。关于逻辑处置来说，这几种状况每种须要做的处置都不一样。假设没有想分明 就去口头，要么是在环节中发现疑问，逻辑重复更改，要么上线后才发现没有思索周全，这都不是咱们想要看到的。
所以，工程师不只有写代码，还要对需求启动完整地剖析，把需求拆分红详细可口头的举措，以确保自己的上班谨严和缜密。
在学校中，咱们经常说 Deadline 是***消费劲。没有时限的上班往往是很难有效推动的。学校里的 Deadline通常由教员依据阅从来确定，而上班中就很难这样了。安顿义务的时刻，师兄问我说，三个小时能不能做完？我大略只是繁难的过了一下脑子，就回答可以。结果最 终花了一终日的期间。这里就触及到一个期间评价的疑问。在实在业务场景下，需求方通常要和工程师协商一个期间线，从工程师的角度来讲，这个期间如何评价才 比拟正当呢？在上一步需求拆分红功后，针对每一个详细可口头的小步骤，都预估一个期间。那些很难直接给出预估期间的中央，就是义务的危险点。比如在这个任 务中，我关于 Canvas的操作不是很相熟，这里或许占用很多期间，就是一个危险点。关于危险点，要找出处置打算，并且给出足够并且正当的预留期间。把一切期间加到一同，再向上浮 动 10% ，才是一个比拟准确的预估期间。预估的期间关于整个名目标流程都起着至关关键的作用。
所以，工程师不只有写代码，还要对期间启动正当预估，配合需求方制订名目标期间流程。
在做完以上一切的上班之后，才到了详细的口头阶段。也就是之前我以为的工程师上班的所有——写代码。在成功这个义务的这一环节中，也不是没有可以改 进的中央。在写代码时刻，遇到的疑问我都偏差于独立处置，即使在曾经破费了很长期间的状况下，也没有及时与师兄沟通。咱们都遇到过这样的状况，自己苦苦想 了很久的疑问，其实曾经进入了死胡同，但是局外人一句话就或许帮咱们处置。关于实践名目来讲，沟通不只仅局限于技术人员之间，发现疑问后作为工程师，还应 该及时与需求方沟通，坚持消息的通顺，来协助需求方协调整个名目。成功这个系统的时刻我遇到的技术上的疑问没有及时和他人沟通，在商定的期间快要截止的时 候没有通知任何人，这在实在名目中是须要波动防止的。
所以，工程师不只有写代码，还要把疑问及时与关系人员沟通，协助自己也协助他人高效地上班。
重构
疑问剖析事先，关于我来说，这一重构的环节也是我对工程师在名目中的定位的从新意识的环节。我记下了这个环节，感兴味的同窗可以移步 这里 检查。
结语
如今有很多工程师埋怨自己在大公司中只是一枚镙丝钉，多了不多，少了不少。他们每天埋头写代码，需求来了，口头义务，再期待下一个需求。至少我以为，「人」的价值不应该仅限于此。假设把人当作黑盒， coffee in, code out ，那人又和工具备什么差异呢？要做一个「程序员」还是「代码生成器」，值得思索。
原文：