程序员 vs 码农

码农工作的方式很多时候更像是一个“翻译”，他们在拿到需求时，从不去考虑业务需求是否正确、合理，也从不去了解需求背后的业务逻辑，而是第一时间就开始动手写代码，一味简单机械地把需求“翻译”成代码后即算完成任务。这样久而久之、日复一日做的都是重复式的劳动，即使编码能力再强，从整个软件项目的角度来看，做的也只是相对简单的“翻译”工作，而且这些工作在需求不明确甚至发生错误的时候，往往会成为无用功……

程序员则通常在拿到需求之后，不是第一时间就去写代码，而是去关注需求形成的前因后果，理解需求背后实际的业务诉求，理清整套业务的发起点、流转过程，进而弄清楚自己接收的单个需求点在整个业务流程中的位置和作用。久而久之，程序员在实现业务需求的过程中逐渐对业务有了一定的理解之后，开发过程则不再一味简单地跟从需求，而是可以参与讨论一些业务需求的合理性、正确性，并及时与业务、需求沟通，从而保证了最终的实现也正是业务真正需要的内容。

近些年的一些研究也已经表明，软件项目失败的一大主因，正是软件项目在最终交付的时候才发现，软件交付的内容其实并不是业务真正需要的、甚至远远偏离了业务的真正诉求。其实，这也正是近些年敏捷开发备受推崇的一个原因：敏捷开发正是通过加强开发与业务、需求之间的沟通、反馈，让开发与业务、需求之间的不一致在日常开发过程中就被及时发现，以避免到最终交付的时候才暴露这种不一致性，也就是从开发流程上尽可能地保证了软件的实现与业务需求之间的一致。而程序员在对基本的业务流程有一定的了解之后，在实际的开发过程中就可以及时地与业务、需求进行沟通、反馈，从实际操作层面上保证了软件实现与业务需求的一致性，也就是给软件项目可以最终成功交付提供了又一重的保障。