《产品研发过程实践》（21）开发人员

作者:asky 日期:2007-04-29

字体大小: 小中大

OK，产品开始构造了，这段时间中，一般都是团队士气比较高涨的时期，看着产品逐渐地被构造出来，而且没有很多烦人的事情，这一切都很愉快不是吗？我想绝大多数开发人员都有这样的感触，疯狂地写代码，然后看见程序逐渐地出现，这是一件多少令人愉快，且具有成就感的事情啊。

那么首先，做为一个开发人员，从项目经理的角度出发，希望什么样子的开发工程师，会认为是一个好的开发工程师呢？

首先，我们希望他的思路清晰，这是一句类似于废话的表达，我们希望所有的人思路都很清晰，但是这的确很重要；

其次，我们希望他思维慎密，我们代码的一个大问题是，只考虑正常路径，对于异常路径考虑不足，这在小型应用中，一旦出现问题，很容易进行判别，但是对于大型应用来说，一旦逻辑由于异常而飞掉，那么想要判断出来问题何在就很麻烦了。异常路径的考虑绝不仅仅是Try，然后Catch一把这么简单。记住这一点，在你写程序的时候，多考虑一下，如果这样会发生什么？如果那样会发生什么？如果用户不按照你的设计的流程来做，那么结果是什么（即使你说，程序会出错，也没有问题，但是必须是我们知道他会出错，而不是不清楚结果是什么）？如果I/O出现问题，那么会发生什么情况？等等。

再次，我们希望不管你面对的压力如何，请动动脑子，不要写一些采用一些非常近视，将来必然会发生问题的做法。原则上来说，这些问题应该设计来解决，但是正如我们所知道的，设计一般来说，真的很难做到那么Detail，那么还是有很多问题，会留在开发阶段来解决。我在2001年看过一个程序，这是一个贺卡发送程序，用户点击了贺卡发送后，会生成一个页面，然后把URL发送给接受贺卡的人员邮箱中，开发人员把所有的贺卡生成的页面都放在一个文件夹中，结果时间略微长一些，在那个文件夹下，就生成了上百万的文件，以至于系统维护人员几乎认为机器崩溃了，因为根本无法访问这个目录。这是一个很幼稚的错误，不是吗？如果多考虑一下，这些错误是可以很容易避免的。而且很麻烦的是，这些问题，如果不是在使用中，你采用功能性测试，是根本无法测试出问题的。

另外，尽量采用规范化的代码撰写方式进行代码的撰写。我虽然不是很赞成采用上百条的代码撰写格式来约束大家的思路，但是常规的做法还是需要做好的，比如代码缩进等等，尽量使自己的工作看上去专业一些，不是对于我们来说，更好一些吗？

另外，一般来说，项目经理会和你就你的工作进行沟通，比如本周是否能够完成某一个模块程序的编写，请合理进行估计，如果你确实不能完成，请第一时间告诉你的项目经理，这对于他的工作非常重要，同样，对你的工作评价也很重要，请保护一下自己，也保护一下你的项目经理，让大家工作多少愉快一些。不要去承诺自己无法完成的工作！

另外，我希望开发人员能够具备良好的沟通能力，当你发现一些问题的时候，请提出来，不要想当然地去解决，你的解决方案不见得就是我们所希望看见的解决方案。在PM一级，他们看见的东西会比你多，所以判断事情的准则也会比你高一个层面，有时候从你的角度出发的一个好的解决方案，从整体来说，未必就是一个好的解决方案；

另外，请务必在你撰写代码以前，进行单元性测试的代码的撰写。你需要明白，你应该如何自动化测试你的代码，而不是仅仅写一个Main函数，然后简单跑一跑，就认为可以提交了。健壮的模块，是一个良好稳定程序的先决条件。所以，如果你需要，可以把开发时间拉长一倍，但是我更希望你的代码在提交测试以前经过你自己良好的unit test。

最后想说的是，做为一个开发人员，不要被所谓的蓝领程序员一说给迷惑了。如果有人愿意使用蓝领程序员，那么他们可以去使用，这是别人的自由。但是做为一个优秀的开发工程师，你永远都能找到一个组织，他们希望有第一流的开发工程师来进行项目的开发，而不愿意使用所谓的蓝领程序员。理由很简单，开发工程师也许将来使用的工具会越来越高级，比如最初的时候，我们用汇编来执行32位乘法，非常非常累人，但是今天在Java中实现一个乘法，则是很容易的事情了。但是，这只是我们的工作在日益向我们的客户靠拢，去考虑我们所最需要关注的东西，而不是说，我们就不需要好的开发工程师了。开发工程师是一种美妙的，值得终身去投入的职业，一个8年工作经验的开发工程师，撰写出来的代码不是2-3年经验开发工程师所能够比的，这一点我深有感触，在一些关键性模块中，我情愿付给高级开发工程师2-3倍于初级工程师的工资，来进行关键模块的撰写，从长远意义上来说，他们的成本相对更低，因为节省了测试成本，而且程序更健壮等等。这一点我想很多项目经理会更有感触。我坚信一点，无论时代如何进展，只要这个工作是一个头脑驱动的工作，那么我们就永远无法象管理流水线上工人一样，管理软件工作者，我们还是需要采用知识人员的管理方式进行管理。当然，蓝领这个词本身就是一个很模糊的用词，我倒是觉得，如果说我现在的工作是蓝领的话，我也无所谓，蓝领就蓝领吧！但是奇怪的是一点，当传统行业都开始越来越重视流水线上工人的主观能动性的同时，我们中国软件行业倒是开始贬低自己的开发者了。并且认为这种观点，能够是推动中国软件业的发展的根源，这多少让我有点感觉奇怪了！

在软件行业，我们不时听到这样一种声音，某某公司又提供了某种中间件，某种系统级的开发不需要开发工程师来完成了，所以我们的代码越来越简单，我们的入门门槛越来越低了，我们将变得越来越没有价值了。从某种意义上来说，这是对的。原因是我们很多软件工程师的技能集中在工具使用上，和API使用上，那么一旦开发工具发生改变，你的很大一块知识将变得过期。当然了，你非得这样定位自己的核心价值，你被工具和时代抛弃就是必然的了。但是在另外一层意义上来说，这句话也是错误的。如果说开发工具可能变，但是根本的设计方式和根本的一些理念，是不会发生变化的。我在1998年使用ASP开发，2000年以后，基本上使用Java和一段时间的C++，我没有明显感觉使用JSP就和ASP不一样，ASP+DLL的模式我看起来和JSP+JavaBean没有什么太多的不同。我们该如何设计还是如何设计系统，现在我们使用EJB或者使用dot net，除了某一些特征点以外，还有多少根本的东西在发生变化了吗？我们还是不断在需求阶段给项目埋下最根本的失败根源，我们还是开发出大量无人使用的软件，我们还是在抱怨别人的设计是如此低能等等。而且，无论使用何种工具，无能的开发者开发出来的程序，要不是很难使用，要不就是根本无法使用。当你觉得开发工具不那么重要的时候，就是你在驾驭开发工具来实现你的想法，而不是开发工具在指导你的思维的时候，这时候，你会更上一层楼了。

好了，开发人员大家自勉，为能够开发出一个好的，能够有大量的人来使用的软件而努力吧。虽然这70%取决于你在哪个项目组，30%取决于你的努力，但是，让我们做得更好吧。让很多愚蠢的说法见鬼去吧。我们踏实做好自己的事情就可以了。