编码之旅——预备篇

做为一个合格的程序员应该做到哪些事呢？熟悉编程语言，掌握框架结构以及相关技术，了解需求，了解程序运行机制……还有呢？

作为一个程序员，你可能会遇到以下这种情况：你接到了来自你的客户的需求（不管你的客户是谁，有可能是你的产品的客户，有可能是你小组的其他成员，有可能是QA人员），你思考了一下这些需求，然后你毫不犹豫的开始编码了，但是写到某个部分你忽然发现有些地方不对劲，你目前这种做法是错误的，然后你又删掉或大量修改已写好的代码，这样反复若干次，终于算是做好了，或者说是你以为做好了，然后你感叹的说“做程序员真累啊！”，然后你开始做一些简单的功能测试，结果发现居然有bug，“天那，怎么会有bug？”接下来自然是修改代码，然后回测。“终于修改好了”，你感叹的说，但事实并非如此，很快你又接二连三的发现了若干个bug，然后自然又是一通修改，气人的是你修改的代码竟然会带来更多的bug，这使你很怕自己的代码，很怕再修改代码了，很怕再找到bug，于是如果稍微有人提出一点对你写的代码的问题你就会毫不犹豫的将问题转推给别人说明如果别人怎么怎么改的话就会没有问题了，让别人去改他自己的代码，而不是你的代码，因为你已经害怕了自己的代码！如果若干天或一个月后你的客户要求你添加几项或改动一些功能的话你会愁死，而且你会去尽力阻止你的客户的这种想法，希望他老老实实的使用现有的系统，不要再“瞎闹”了，因为已经够乱的了！这一切的结果是什么呢？你很恨自己的行业，“为什么当初我选择了做程序员呢？真想转行！”，当然这只是结果之一！相信你自己或是你身边一定有这样的人存在。

现在的问题是，做程序员真的要这么累吗？回答自然是不用！上面所描述的场景是非常常见的，其中提到了两个关键问题：

1. 程序员没有做预先的设计工作，所以后期出现多种问题需要修改大量代码。拿来就写的工作模式显然是需要避免的！请注意设计工作不单单是架构师与设计师的工作（架构实际上就是一种设计，只是更泛化）。许多程序员当你问他是否用UML的时候他会说用过，但只是来走走样式，上面要设计图纸的时候现做一个拿来敷衍一下，有的干脆直接反向一个出来，改都不改一下就当作设计图来用了。这是不对的，UML的宗旨是帮助你设计，理清思路的，如果你系统都做好了，那还要UML干吗？！

2. 程序员没有计划好的编码流程，这样会在编码阶段丢掉一定的效率，这无非是一个时间资源与人力的浪费。如果一开始就有一个流程计划的话那么只要按照流程走就可以了，不需要程序员去随时浪费脑力考虑何时应该做什么。另外一个经过周详设计的流程是可以应付大部分编码工作而又可以帮助评估项目时间的好东东。

我们在《编码之旅》系列中要讨论的也正是这两大部分。值得一提的是关于问题一中讲到的设计工作，实际上需要通过了解并掌握设计模式才能做到，这一部分很广，同时也比较复杂，当你熟悉它的时候才会了解什么是真正的面向对象编程！你也许会觉得有点夸张，“我早就学会OOP了”，真的吗？！我会在以后挤出一些时间来总结一下设计模式以及OOD（Object Oriented Design ）的一些原则，欢迎读者有时间来讨论一下！也就是说，在《编码之旅》中将不会讲解设计模式，而只是简略的告诉你首先你应该有一个自己的设计，然后在去按照设计好的去编码，而不是盲目的去写代码。

那么，闲话少说，起航吧，接下来让我们来讨论一下编码流程，Let's go！