我们平时把软件编码叫做写代码，让外行人听起来像是在写文章，就是把你心里的想法一点一点的有条理的写出来，在这一点上，编码和写文章确实有相似之处，但写文章一般是你自己写，编码则需要和别人合作。还有在软件设计的时候，我们经常拿盖房子来比喻，盖房子之前要先画好蓝图，整体结构，考虑好水、电的布局等，盖一个小狗窝和盖一栋大楼的过程也是不一样的，做一个小软件和一个超大型的软件的过程也是不一样的。如果你能很好把软件的开发过程想象成某些生活中具体的例子，找到他们的相似之处和不同之处，你就能更好的理解软件开发，以及利用这些隐喻来与人更好的沟通。你脑子里如果有很多这样的隐喻，在你做软件设计时就会不经意的想起来，成为你思考和权衡不同方案的工具。做任何事情都需要前期准备，在软件开发中更是如此，尽管如此，还是有很多程序员接到任务后就是想着尽快编码，很多老板不重视软件开发的前期准备。要想保证一个软件的质量，在前期准备，需求分析，架构设计，编码，测试，维护等每一个环节都要重视质量。具体程序员接到任务的时候要检查一下在你之前的那些软件活动有没有准备好，如果需求中有好多没有说明的地方，架构设计也不明确，你不知道需要和其它模块之间如何通信，基础组件啥也没有，这种情况下进行详细设计和编码会很受罪。和同事老板达成前期准备重要性的共识之后，就是如何做前期准备以及如何判断前期准备已经做好的技巧，这些是更实用的地方。如何做前期准备基本上是需求分析人员，产品经理和架构师的关心的问题，而判断前期准备是否已准备好则是具体程序员也需要具备的能力。首先要判断你做的软件的类型和规模，如果你做的是一个长期的项目，一期一期的做，就更适合敏捷开发和迭代式开发，做一些基本的前期准备就可以开工了，先把最核心的功能实现，每隔一段时间把一些新需求加入设计和编码中来，设计和编码可以结合起来，需求也不用一下子就写的特别全面，先写出最基本的需求。如果你要做一个性命攸关的系统，如航天软件，医疗软件等，前期准备就应该更严格，需求规格说明书要尽量详细，设计也要花很长时间来做，尽量防止以后改动。根据你的项目的性质来选择更迭代化还是更瀑布式的开发。
