以下列出的是写程序容易犯的错误：
1. 缩写
（1）不利于新手理解
（2）系统中可能有多个词的缩写相同，这会让人迷惑
（3）只有众所周知的缩写词才应该被使用，但这通常不容易区分
（4）不应该有多余的缩写，比如数据库里字段名，不需要加表名前缀
2. 命名需要有意义，且结构清晰
主要存在于页面和CSS文件中，我觉得我有必要介入，重新定义CSS及页面结构，“Html结构对比.txt”里有一个对比，每个人都应该学习一下“web-standards.pdf”，最重要的是还Html标签以原来的意义。
微软帮助里有“类库开发的设计准则”，里面有很全面的命名规则说明。
3. 不应该以完成功能为最高目标，应该以程序易读性为最高目标
比如完成功能之后，还应该把综合，空格，换行等过一遍，用Ctrl+KD排一下版。
过长的程序代码要换行，不要用匈牙利命名法，而应该用有含义的名称，而不是表明类型的名称。
4. 最重要的是程序是否是精心设计过的
有2种程序中经常出现的臭味，一种是缺乏设计，一种是设计过度。
现在主要的问题是缺乏设计，比如对于这样一个大项目，多语言应该独立出来一个新项目，页面查找、编辑的操作，分页存储过程，分页的页码列表，有更优的实现方案。
我们要让写程序成为脑力劳动，而非体力劳动，这就要努力追求程序简单性，不应该以完成任务为最高目标。
5. 对程序的质量的要求
我们这是一个大项目，就像一座高楼大厦。如果建一座小平房，我们选材不需要太严格，达标就可以了。但高楼大厦的材料必须高标准，严要求。我维护过很多项目，这些项目符合80/20原则，即80%的项目代码都很烂，20%的项目设计比较好，但也越来越烂，原因有2个，开发时成员的水平普遍较高，设计的很好，代码也很优秀，但随着时间的流逝，优秀人员也会流失，再加上需求的变化，原来的设计慢慢变的不能适应新需求，这就是代码会腐化的特性，也叫程序里的臭味。如何解决这些问题，我觉得七嘴八舌的讨论太肤浅，不能解决实际问题。而需要建立一种代码审查机制，即当任务完成一部分后，要考查每个人写过的代码，这个人在自己的电脑前，向其他人讲解自己如何实现某一功能，现在已经做到什么程度了，未来准备怎么做。其他人不光能听到他的解释，还能看到他写的代码，这样就能彻底的了解他的状态和看清程序里的问题。这个过程其实是个挑毛病的过程，一个优秀的程序应该是经得起推敲的，但要注意的是，路要一步一步的走，不能简单的因为现在的代码不能覆盖未来的需求而否定它，敏捷开发反对为未来做设计，就是因为未来不可知，我们推测的未来往往是错误的，而只有当前能够运行的代码才是最实在的，毕竟任何功能都要有实际的代码来实现，写完代码才意味着软件完成了，不应该为未来的需求花太多的时间。敏捷开发的过程是迭代式，渐进式的，先实现一部分需求，并使代码最优化，再在此基础上实现多一点的需求，同时发现以前的设计有不合理的地方，立即做一个小的重构，再次使代码最优化，这样不断实现下去，到最后就可以实现所有需求，并使代码最优化。在写代码的过程中，你才能知道什么是最佳的设计，而不是什么都没写就去做设计，设计出来的八成都会有问题。用《敏捷软件开发：原则、模式与实践》的作者Robert C. Martin的话说就是：代码就是设计，设计就是代码。
6. 敢于否定自我
人类就是在否定自我的过程中进步的，MSF中有定期反省的原则，敏捷开发中有重构的原则，软件工程中有错误发现的越早，改正的越早，付出的代价就越小的论断。所以当我们发现一个错误或一种更好的实现方法时，应该毫不犹豫的实施它。一个团队不应只是以完成任务为最高目标，应该以提高开发效率为最高目标，这种开发效率不是计较一时得失的效率，是着眼于长远发展的效率。实际上，提高开发效率意味着不断追求最佳的设计和最优的性能，使代码量越少越好，越容易实现越好，越容易维护越好。当达到这些目标时，团队成员不会麻木的拷贝着代码，不会丧失工作的乐趣，因为工作很容易完成。要让所有团队成员都具有这种精神是不太现实的，能够做的就是选出一个技术尖兵，当前面的路不明晰的时候，派他去探路，探明白之后，其他人跟着走。
需要说明的是，创新是需要代价的，这种代价就是用新事物代替旧事物需要做的努力，和新事物也可能有缺点的风险。但这不应成为否定新事物的理由，世界上没有什么是一尘不染的，但这不影响我们向最优化靠的更近一点，我们仍然应该去追求局部的完美，虽然整体的完美是不存在的。
肯定或否定一件事物时，需要客观分析它的各个方面，而不应主观臆断，应该用矩阵来分析此事物与彼事物的优劣，然后做出抉择，最好用数字来对比，它们之间的区别是同一数量级的还是上升一个数量级的。当综合指标提高一个数量级时，就应该毫不犹豫的去实施，而不是束之高阁。
用新事物代替旧事物的代价不能凭空想像，最准确的测量方法是实践，改一个试试，看是不是真的代价很大，实践是检验真理的唯一标准。
7. 异常处理
永远不要吞掉异常，帮助里有异常的最佳实践。因为异常发生时会严重影响性能，所以要竭力避免不必要的异常，一种好的习惯是在做实际操作时事先验证数据。当异常发生时，必须做记录，并把用户引到错误页面。Web.config里有错误页面的配置，开发时设置为Off，发布时设为On。
我在写程序中经常做自我否定，也欢迎别人来否定我，但需要客观的态度和充分的理由。
根据我的编程经验，我制定出了一套评判程序优劣的标准，我希望这个标准能够在工作中应用，使我们的决策更客观，并提高工作效率。
评判方案优劣的：（现代软件工程把性能的考虑放的很次要，只有少数情况需要专门追求性能，软件的简单性才是最重要的）
1. 代码量：权重10
2. 耦合度：8
3. 性能：4
评判人员态度的：
1. 程序编写规范：空格与换行是否整齐，命名是否有层次和有意义
2. 注释：不求规范的长篇大论，只求适当和必要。比如当交接任务时，已完成的和未完成的不单要有简明扼要的文档，在代码里也需要标出来。
3. 无效代码：即被注释掉的代码，是很影响视线的。我的习惯是在重构时将过时的代码注释掉，当重构完成时，删掉其中的大部分，只留极少数有参考价值的代码。然后每次看到漏删的完全没用的无效代码时，彻底删除之。
每个人都有自己的价值观和生活方式，所以我们不能做到让所有人的思想重心都集中到编程上来，但有必要在力所能及的情况下提高团队的编程素养，使他们有积极的工作态度和适当的压力。我们需要采取一些措施，设定一些机制来提高团队的战斗力。
我建议：
1. 上午的站立会议要缩短。不要提出一个问题，其它人听的半懂不懂的时候就七嘴八舌的展开讨论，这样并不能解决实际问题，有问题可以提出来，但在会后专门解决。站立会议的主要任务是报告开发进度，总结昨天做的，明了今天需要做的。
2. 每周五下午做代码审查，把本周所做的代码都过一遍，形式是一个一个过，过的时候所有其他人都在这个人的电脑旁，有任何问题，现场立马改，需要大改的可以先做记录，在下周改动。这样做的好处在于，每个人都对整个项目有清晰的认识，而不仅仅是自己所做过的功能，而且这促进了知识的传播，一段代码胜过千言万语，有时会使人感到“原来代码还可以这样写”。这是发现错误，纠正错误的过程，这个过程最能提高程序员的开发水平。
1. 缩写
（1）不利于新手理解
（2）系统中可能有多个词的缩写相同，这会让人迷惑
（3）只有众所周知的缩写词才应该被使用，但这通常不容易区分
（4）不应该有多余的缩写，比如数据库里字段名，不需要加表名前缀
2. 命名需要有意义，且结构清晰
主要存在于页面和CSS文件中，我觉得我有必要介入，重新定义CSS及页面结构，“Html结构对比.txt”里有一个对比，每个人都应该学习一下“web-standards.pdf”，最重要的是还Html标签以原来的意义。
微软帮助里有“类库开发的设计准则”，里面有很全面的命名规则说明。
3. 不应该以完成功能为最高目标，应该以程序易读性为最高目标
比如完成功能之后，还应该把综合，空格，换行等过一遍，用Ctrl+KD排一下版。
过长的程序代码要换行，不要用匈牙利命名法，而应该用有含义的名称，而不是表明类型的名称。
4. 最重要的是程序是否是精心设计过的
有2种程序中经常出现的臭味，一种是缺乏设计，一种是设计过度。
现在主要的问题是缺乏设计，比如对于这样一个大项目，多语言应该独立出来一个新项目，页面查找、编辑的操作，分页存储过程，分页的页码列表，有更优的实现方案。
我们要让写程序成为脑力劳动，而非体力劳动，这就要努力追求程序简单性，不应该以完成任务为最高目标。
5. 对程序的质量的要求
我们这是一个大项目，就像一座高楼大厦。如果建一座小平房，我们选材不需要太严格，达标就可以了。但高楼大厦的材料必须高标准，严要求。我维护过很多项目，这些项目符合80/20原则，即80%的项目代码都很烂，20%的项目设计比较好，但也越来越烂，原因有2个，开发时成员的水平普遍较高，设计的很好，代码也很优秀，但随着时间的流逝，优秀人员也会流失，再加上需求的变化，原来的设计慢慢变的不能适应新需求，这就是代码会腐化的特性，也叫程序里的臭味。如何解决这些问题，我觉得七嘴八舌的讨论太肤浅，不能解决实际问题。而需要建立一种代码审查机制，即当任务完成一部分后，要考查每个人写过的代码，这个人在自己的电脑前，向其他人讲解自己如何实现某一功能，现在已经做到什么程度了，未来准备怎么做。其他人不光能听到他的解释，还能看到他写的代码，这样就能彻底的了解他的状态和看清程序里的问题。这个过程其实是个挑毛病的过程，一个优秀的程序应该是经得起推敲的，但要注意的是，路要一步一步的走，不能简单的因为现在的代码不能覆盖未来的需求而否定它，敏捷开发反对为未来做设计，就是因为未来不可知，我们推测的未来往往是错误的，而只有当前能够运行的代码才是最实在的，毕竟任何功能都要有实际的代码来实现，写完代码才意味着软件完成了，不应该为未来的需求花太多的时间。敏捷开发的过程是迭代式，渐进式的，先实现一部分需求，并使代码最优化，再在此基础上实现多一点的需求，同时发现以前的设计有不合理的地方，立即做一个小的重构，再次使代码最优化，这样不断实现下去，到最后就可以实现所有需求，并使代码最优化。在写代码的过程中，你才能知道什么是最佳的设计，而不是什么都没写就去做设计，设计出来的八成都会有问题。用《敏捷软件开发：原则、模式与实践》的作者Robert C. Martin的话说就是：代码就是设计，设计就是代码。
6. 敢于否定自我
人类就是在否定自我的过程中进步的，MSF中有定期反省的原则，敏捷开发中有重构的原则，软件工程中有错误发现的越早，改正的越早，付出的代价就越小的论断。所以当我们发现一个错误或一种更好的实现方法时，应该毫不犹豫的实施它。一个团队不应只是以完成任务为最高目标，应该以提高开发效率为最高目标，这种开发效率不是计较一时得失的效率，是着眼于长远发展的效率。实际上，提高开发效率意味着不断追求最佳的设计和最优的性能，使代码量越少越好，越容易实现越好，越容易维护越好。当达到这些目标时，团队成员不会麻木的拷贝着代码，不会丧失工作的乐趣，因为工作很容易完成。要让所有团队成员都具有这种精神是不太现实的，能够做的就是选出一个技术尖兵，当前面的路不明晰的时候，派他去探路，探明白之后，其他人跟着走。
需要说明的是，创新是需要代价的，这种代价就是用新事物代替旧事物需要做的努力，和新事物也可能有缺点的风险。但这不应成为否定新事物的理由，世界上没有什么是一尘不染的，但这不影响我们向最优化靠的更近一点，我们仍然应该去追求局部的完美，虽然整体的完美是不存在的。
肯定或否定一件事物时，需要客观分析它的各个方面，而不应主观臆断，应该用矩阵来分析此事物与彼事物的优劣，然后做出抉择，最好用数字来对比，它们之间的区别是同一数量级的还是上升一个数量级的。当综合指标提高一个数量级时，就应该毫不犹豫的去实施，而不是束之高阁。
用新事物代替旧事物的代价不能凭空想像，最准确的测量方法是实践，改一个试试，看是不是真的代价很大，实践是检验真理的唯一标准。
7. 异常处理
永远不要吞掉异常，帮助里有异常的最佳实践。因为异常发生时会严重影响性能，所以要竭力避免不必要的异常，一种好的习惯是在做实际操作时事先验证数据。当异常发生时，必须做记录，并把用户引到错误页面。Web.config里有错误页面的配置，开发时设置为Off，发布时设为On。
我在写程序中经常做自我否定，也欢迎别人来否定我，但需要客观的态度和充分的理由。
根据我的编程经验，我制定出了一套评判程序优劣的标准，我希望这个标准能够在工作中应用，使我们的决策更客观，并提高工作效率。
评判方案优劣的：（现代软件工程把性能的考虑放的很次要，只有少数情况需要专门追求性能，软件的简单性才是最重要的）
1. 代码量：权重10
2. 耦合度：8
3. 性能：4
评判人员态度的：
1. 程序编写规范：空格与换行是否整齐，命名是否有层次和有意义
2. 注释：不求规范的长篇大论，只求适当和必要。比如当交接任务时，已完成的和未完成的不单要有简明扼要的文档，在代码里也需要标出来。
3. 无效代码：即被注释掉的代码，是很影响视线的。我的习惯是在重构时将过时的代码注释掉，当重构完成时，删掉其中的大部分，只留极少数有参考价值的代码。然后每次看到漏删的完全没用的无效代码时，彻底删除之。
每个人都有自己的价值观和生活方式，所以我们不能做到让所有人的思想重心都集中到编程上来，但有必要在力所能及的情况下提高团队的编程素养，使他们有积极的工作态度和适当的压力。我们需要采取一些措施，设定一些机制来提高团队的战斗力。
我建议：
1. 上午的站立会议要缩短。不要提出一个问题，其它人听的半懂不懂的时候就七嘴八舌的展开讨论，这样并不能解决实际问题，有问题可以提出来，但在会后专门解决。站立会议的主要任务是报告开发进度，总结昨天做的，明了今天需要做的。
2. 每周五下午做代码审查，把本周所做的代码都过一遍，形式是一个一个过，过的时候所有其他人都在这个人的电脑旁，有任何问题，现场立马改，需要大改的可以先做记录，在下周改动。这样做的好处在于，每个人都对整个项目有清晰的认识，而不仅仅是自己所做过的功能，而且这促进了知识的传播，一段代码胜过千言万语，有时会使人感到“原来代码还可以这样写”。这是发现错误，纠正错误的过程，这个过程最能提高程序员的开发水平。
扫一扫
2184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
