我的2009年工作经验小结(php程序员)

转眼又是一年过去了，似乎，最近五六年来，一直都过得不那么顺利，今年还算是不错，至少，在客户、老板和同事的帮助下，一年的工作，终于在年前收尾了。在此小结一下，吸取一些教训，以免来年重犯相同的错误。

1、做了一个最正确的选择：挂靠一家软件公司做程序。做程序和做业务，是不应该同一个人进行的，就算客户是主动上门的，沟通同样要花费精力，说不定这也是性格上的问题，比如，当我专心地写代码的时候，我把每个电话和QQ留言都当成是一个麻烦，一个一分钟的电话很可能让我一小时都静不下心来，不知别的程序员是不是这样，这或许是一个需要改变的坏习惯。

2、做美工和做程序，其实也不应该同时进行，前些年单打独斗成了习惯，什么都自己来，明明现在单位有美工了，还是习惯自己做，或是总是不由自主地去考虑本该由美工考虑的问题。在很多客户眼里，美工就是负责怎么把页面做得好看，所以如果自己对这方面要求不高的话，总是希望只交给一个人完成以降低成本。但事实上，网页美工和平面美工在技术上还是有很大的区别，出完平面效果图后，让其完整地表现在网页上，所需要的时间和精力，都比出一张效果图要多得多。同事小夏的页面都是div+css架构的，而且对不同浏览器的兼容性做得相当完美，看过之后，table架构页面都不想再看了，于是浪费更多时间跟着去写div，然后又要为该死的浏览器兼容性和不同的显示器分辨率伤神，而当页面问题解决后，往往就会发现，原本的程序思路已经被打断了，又要花更多时间会过神来想程序。以后，我只管页面输入输出，美工的事情，还是交给专业的美工去考虑吧。

3、做项目规划，其实应该以客户的想法为主，很久以前我就已经在对客户说，做项目，其实是客户自己做项目，我只是在技术上帮助客户实现。可是实际操作起来，又关起门来自己做自己的一套想法，做完之后才发现，自己的想法和客户的有很大的不同，或是不符合客户的实际需求，比如最近这个项目，辛辛苦苦做得差不多了，却发现和客户原有的系统没法结合。可能沟通方面确实是我的一个大问题，不愿意与客户联系的主要原因大概有两个：一个是工作进度比自己原来估算的慢了，或是碰到问题卡住了，怕没面子，不好意思去联系；另一个是问题比较琐碎，问得太细了，怕人觉得我太笨或是太懒不愿动脑筋。说到底，还是太内向，顾虑太多，以后要拉下脸来，想到什么就先问个明白，每个细节，客户说怎么做就怎么做，老板说怎么做就怎么做，完全没必要自己去做太多的设想。

4、Zend Framework并不适合所有项目，面向对象和设计模式也是同样。页面和程序分开就好了，include就可以，没必要去炫耀哪个是controller,哪个是view，为每个数据表建一个类，也不一定要那么学术地称之为model并坚持去符合model的标准，把对表的操作实现了就行。技术上的事情，具体的我另外开个帖子讨论，总之，一个项目上手，关键是怎么在最短时间内达成客户的需求，所有的技术都只是手段而不是目的。不适当地炫耀技术是我所犯下的严重错误之一。

5、注意休息，劳逸结合。程序写不进去的时候，坐在电脑面前发呆是徒劳的，做一个项目的关键时刻，一两个晚上的通宵加班起到了很好的效果，但加班成为常态，就起到反效果了。体力从来都不是我的强项，以前学校跑 3000米考试，总在中途放弃，说我累了，跑不动了，可是现在脑子累了，却不知道自己需要休息，一个通宵不行就两个通宵，两个通宵不行就三个通宵，三个通宵之后还不行就白天睡觉，晚上对着电脑发呆，终于由硬撑转为死撑，由死撑转为崩溃。以后，安排工作计划的时候，绝不在把晚上的时间安排在内，晚上就是休息时间，上网看看小说，写写博客，学点新的技术，锻炼一下身体，出去和朋友小聚，项目吃紧时加几个班......总之我只不过是个平凡的人类，就算真是super man，除了工作之外，也还是需要生活的。一直以为为了未来努力工作是正确，但认真想想，让每一天都过得幸福而又充实，似乎更加正确。不会休息的人就不会工作，十几年前就听到过这句话，终于真正地理解了。

6、不要怕重复劳动，项目是不可能在一开始就规划得清楚和完善的，回想一下项目开发的教程，什么敏捷开发，极限编程，甚至是UML，都是贯穿整个项目始终的，从来都没有哪种方法，可以在一开始写好大纲，然后照着大纲，按部就班，就能完成整个程序的。一开始就做很多设想，花费很多时间去构思一种“完美”的方案，然后面面俱到地去完成所有代码和页面，最后发现行不通的时候，付出的代价就实在太大了，倒不如有一个基本的思路，做一个UML用例图（也不见得就要中规中矩地打印出来，在本子上画个草图，也是一样），自己理一下思路，找一个用例开始写，写之前先和用户确认一下，写完再给客户看一下，哪些要补充要修改的马上改好，然后写下一个用例，写后面的用例时，往往会想起前面的用例不周全，事先要有心理准备，发现了就根据客户需求改动一下，其实也并没有多大的工作量，所有用例写完，上架之前最后整理测试一下，这么做，比自己蒙头做完然后去找客户验收要有效得多。

7、对老项目的升级，功能方面一定要吃透，数据库无论怎么不合理，绝对不能改，原来用GB2312的，也别改成UTF-8，比如最近这个项目，2003年的系统，中间经过了N个程序员的改动，二十多个子系统，光是数据库就有十几个（注意是数据库，不是数据表），我看着代码头晕决定重写，一上手就重写了数据库，最后发现四处都有牵扯，最典型的，一个用户项目列表，原来的程序竟然是这么写的：

• 根据用户登录的id号，从hr库中的人员表中读出他的所在部门编号
• 根据所在部门编号，从hr库中的部门列表中读出所在部门名称
• 把部门名称（中文）通过页面地址连接传递给下一个页面
• 在下一个页面中，根据部门名称从oa库（这是另一个数据库了）中的部门表中读出部门ID（这个部门表和hr中的部门表字段和部门条目基本相同但是部门id顺序是不一样的，估计是某个程序员增加功能时不敢碰原来的表而另外新建了一个表）
• 根据这个新的ID，取到了部门的项目

类似这种代码，到处都是，而且，原来的程序，页面和程序都没有分开，别说类了，连函数都难得见到一个，我对当年完成这个项目的程序员佩服得五体投地，他们竟然能仅靠任何一个非计算机专业必修课都要学到的分支和循环语句，到处是一个页面include另一个页面，就完成了一个20多个子系统构成的大项目。但这种钦佩并不能弥补我阅读程序时的痛苦，所以，当我发现我辛苦写完代码之后，和原有系统挂接出现了一箩筐的问题时，简直恨不得把家里的墙壁挠出个窟窿来了。

8、采用完整的注释代码和统一的命名方式，这个算是我的优点所在了，和很多人的习惯不同，我很愿意写注释，并且是按照phpdocument规范来写注释。这样，无论一个项目写了多少个类和函数，只要采用zend studio 或是netbeans之类的专业编辑器编程，总能轻易地找到自己以前写的东西，只要输入一个起始字母，我自己写的类和函数就会自动出现，并包含详细的功能和参数注解，这样，无论是我自己，还是有什么别的程序员接手，都能迅速读懂代码，继续开发，如果接手的每个程序员都能坚持采用类和函数为主的编程方式，并做好注释的话，那么，一个项目，就会逐年完善，越做越强，而不是东一个补丁，西一个补丁，打到最后，最终补无可补。关于这点，我也打算另外开个技术贴详细讨论。

差不多就这样8点吧，对的坚持住，错的坚决改正，2010年又是新的一年，相信一年会比一年好，年年有进步，年年有发展。

小广告：我的网站：www.10000j.com，刚刚起步，积累PR中，哪位愿意帮忙的请给个链接或是引用本文时保留此链接，谢谢。