尽管我是第一次从大学校园走入公司开始设计代码，但是我仍然相信，不少程序员，无论是类似我这样的初次进入公司开发环境的菜鸟，还是有着几年工作经验的老鸟，在开发网站或者软件的时候都会存在如下的问题：

1. 对项目中其他成员开发的可重用控件视而不见，又编写了一个实现类似功能的控件，或者，他看到了这个可以重用的控件，但认为与自己的需求差了那么一点点，于是他copy了这个可重用控件的代码，并稍做修改，让他完成自己的工作。于是，这个项目中诞生了两个几乎一样的控件，产生了代码冗余，为以后的项目维护留下了隐患。
   我认为最好的方法是：首先问下项目组长是否存在能够完成你这个功能的控件，如果没有，就自己写一个，如果有（或者有类似）的话，尽量利用已有代码，如果想实现特别的功能，为这个控件新增一些属性和方法（记得写好注释），或者干脆继承它！
2. 认为自己的代码或者控件只在当前的需求下运行，于是他把属性写死，完全不考虑代码的可扩展性。比如某个程序员被告知，他所做的网站的首页需要放置一个flv播放器，于是他编写了一个控件，控件中包含了一个flash播放器，他认为这个播放器将只在首页要使用，于是他直接在html里面把播放器的宽度和高度写死，并且不在控制代码里面留下任何可以修改该宽高的接口，于是问题来了，另外一个程序员需要在别的页面中调用flv播放器，他不存在笔者说的第一个问题，他知道代码重用，可是，他发现，原来的这个flv播放器控件居然无法调配宽高，他不得不花一些时间来扩展这个控件，而且他几乎是在抱怨中完成这个工作的，项目如果多次存在这样的问题，无疑会加大时间的浪费，并且项目组的成员的快乐感也会逐渐降低。
   因此，程序员需要注意：您开发的控件要尽量能够“放之四海为皆准”，也就是要考虑可扩展性，不然别人维护你的代码将是一场噩梦！
3. 轻视“举手之劳”，比如接受url参数的时候直接使用Request，而没有使用更加安全的可以过滤危险字符的封装类（如DntRequest），尽管甚至只需要多输入2、3个字符而已；不对数字输入进行判断，尽管只需要调用IsNumbr而已，即使项目中没有这个函数，也只是一句“Regex.IsMatch(src,@"^\d+$")”而已；不使用Dispose，尽管在vs中只是输入变量名再加一个点而已。
   以上的不作为轻则导致程序偶然运行出错，重则导致被黑客抓住尾巴，其实在项目中注意细节，项目的稳定性和安全性会提高一个档次，就好比多关房门可以减少50%的被盗率一样。

项目中如果有程序员出现以上问题，当然最主要的原因是该程序员的主观原因，如果说程序员写出高效快捷且性能优越可扩展性好的程序是技术问题，那么出现以上描述的问题则是一个态度问题，或者说是“责任感”，试想，如果一个程序员在设计代码的时候能够设身处地的把项目组其他成员今后在维护自己代码时的感受考虑进去，能够想一下“我能做到的尽量做到，减少别人不必要的工作量”，能够把项目当作是自己的，而不只是完成自己工作时间赚取薪金的一个工具，那么他当然会为项目贡献出最优质的代码。

 

如果一个程序员认为自己很有责任感，但是他却出现了以上描述的问题，那么除了在代码编写中尽量强迫自己客服懒惰以外，需要多读书以及阅读优秀代码来提高自己的修养。

 

如果项目组中经常出现以上描述的一些问题，而且不只是一个当事人，那么项目组长是到了有必要反思自己是否渎职的时候了，项目组长需要反思如下问题：

1. 我是否招到了一批素质低劣的程序员，看来我当初对他们的测试有很大的漏洞
2. 我知道里面存在一些菜鸟，但是我没有对他们进行代码质量之类的培训
3. 项目组成员之间是否缺乏沟通？
4. 我难道不对低劣代码做出任何批评？或者我根本就不注意这些?
5. 上级给我的时间以及我给他们的时间是否过于紧迫，以致他们没有心思对代码进行修饰？

以下方法有助于让项目组长反思之后采取行动：

1. 在招聘环节，加入代码可读性以及其他细节指标，我想，能够注意细节的程序员比那些能够编写“高深莫测”的代码的程序员更优秀
2. 尽量每周抽出时间对程序员进行讲座或者座谈会，会议的主题应该是如何编写简洁有效的代码
3. 多组织活动让项目组成员进行沟通，如果项目组成员之间关系融洽，那么他们会彼此监督对方的代码，互相学习，成员之间的监督和学习比你一个人监督和授课好
4. 加强代码监管
5. 如果时间确实紧迫，那么就尽量做前面四条吧！