对于程序员来说，写代码思路是最关键的。如果采用的技术平台、框架、网站建设开发时间等已经确定了，那么在开始写之前，花三分之一以上的开发时间去把所有的数据结构及其相互关系考虑清楚。比如需要定义几个类，类和类之间的关系是怎样的，每个类里有什么属性，每个类提供一些什么样的方法等等，这些是最核心的。这些数据结构要考虑得尽可能细，比如功能实现可能没问题，但是性能上不理想，这就说明你的数据结构设计还需改进。这些细节要反复考虑，交叉检验，直到自己觉得很周到满意了为止。在这个基础上，再注意实现的细节、代码可读性等，就能写出让自己满意的代码。具体说明如下：
一、数据结构和核心算法
低水平程序员总在考虑代码，高水平程序员总在考虑数据结构及其之间的关系。数据结构考虑清楚了，核心的算法自然也就出来了，这就是关于每个类的每个方法如何实现的问题。比如需要实现一个中位数查询方法，如果你前面确定了数据保存的格式是一个列表，那么你可以考虑采用插入排序法;如果数据格式是自平衡二叉排序树(AVL)，则只需直接返回根节点就可以。
数据结构决定算法，所以你在考虑数据结构的时候，一定要尽可能地使数据的结构和它的自然属性相匹配，不然后面的实现就会是一场噩梦。比如，你把一个多层级的结构定义成二维数组，看上去也靠谱，相当于在一个表格里维护一个组织结构图，可是当你做到部门增减的时候，本层级的数组元素移动自不必说，下面各个层级的元素移动就很容易乱套，而且性能很差，可能你写了2000行代码还有很多边界条件会出错。相反，如果用一个孩子兄弟链表来表示这个树型结构，操作起来就非常容易，可能100行都足够了。
二、功能实现
思路确定后，实现过程同样也需要大量构思活动。碰到比较熟悉的领域，自然可以轻车熟路，但难免会有一些你不太熟悉的技术需要尝试。有的同学比较排斥这种领域，比如我好不容易才掌握了Struts 2，领导又让我去学习Grails框架，我就会觉得很不爽，大概看了看就挑出它的一堆问题，然后能躲多远就躲多远。可是我要说，这样的心态会阻碍自己提高技术水平。作为一个程序员，最大的挑战和乐趣就是不断学习新的技术，没有这样的心态，很快就会落后。
好，那么遇到不熟悉的技术怎么办?我的体会是，先不要急着实现项目中的代码，自己另外维护一个测试项目，在里边边查文档边学习，边做一个小功能，把所有需要在项目中实现的功能先在测试项目里跑通，然后再写项目里的代码。这样做的好处是把单个技术问题和其他潜在的bug隔离开来，便于快速学习新技术。
三、测试
测试很重要，设计测试用例就像开发时设计数据结构一样，也是很关键的。在设计测试用例的时候，要把当时自己设计数据结构的思路全部忘掉，或者找别人来设计测试用例，不然会不由自主地测试那些你已经考虑到了的地方。这样测试是跑通了，用户一用起来可能各种边界条件会到处出问题。
有人会推崇TDD的方法，先设计好测试用例，然后在开发过程中确保所有测试通过。我个人不喜欢这种方法，虽然承认从开发质量管理和长期维护的角度来说TDD是很有必要的，但我个人尝试的结果是，设计完测试用例后，想到开发的目标不是实现功能，而是为了跑通测试，就感到毫无乐趣可言。这一点我自己也觉得很矛盾。
四、代码可读性
要想自己满意，代码的可读性一定要好。要做到一年后甚至几年后你拿到自己写的代码，还能很容易看明白当时的思路和实现。这就涉及到命名和注释的问题。
命名就像超市里的商品标签一样，要让人一看就知道这是什么东西，比如你在员工类里定义了两个属性是到岗日期和离职日期，定义成date1和date2就没多少可读性，定义成dateOnBoard和dateQuit就比较清晰一些。
注释也是很重要的，它可以用来说明一段代码的作用，算法的设计思想，或者是方法调用的参数格式要求等。有人觉得命名就是注释，代码本身就为自己代言了。其实这种说法用来强调命名规范的重要性是很好的，但是因此说不需要注释则有失偏颇。试想，如果Dijkstra首次发明最短路径算法的时候，他给出的代码里没一行注释，即使所有的变量命名都定义得准确而严谨，又有几个人能看懂他的算法呢?所以，在重要或者复杂的地方，都需要详细地写一些注释，便于看代码的人清晰地了解你的思路。
最后总结一下：要想写出自己满意的代码，不要急于动手，要先仔细想清楚思路性的东西，尤其是数据结构，然后在实现过程中大胆尝试小心验证。设计好测试用例，确保代码的可读性，就可以在代码中表现出自己的最高水平。但毕竟各人水平是有差异的，自己满意并不等于其他人欣赏。我对此的看法是，不求尽如人意，但求无愧我心，足矣。
更新时间：2017-05-25
