程序员的度
我这里想说的度，并不是程序员的气度，而是在项目开发过程中，去完成自己所所需完成的每项任务的度。
很多概念都有个最高目标，但未必最高目标就是最合适的。最切实际的目标，是要综合考虑实际情况，可能包括资源，时间，成本，效率等等，做到有度。这个世界是个多维的，充满矛盾的。程序员们要学会在各个矛盾体之间找到平衡点。
编码的度
我想很多公司都会有自己的编码规范，要求在编码过程中，你的文件命名，函数定义，变量命名，代码注释等都要按照规定的格式进行编写。我们公司的编码规范是我写的，但我自己其实也无法全部做到。
作为公司的规章制度，可能需要一个很完善，很全面的考虑。而作为我对个人的要求，对程序员编码的度的理解，是每个程序员自己心中要有一个基本编码规范，也就是你自己编写的代码要有自己的风格。简单来说就是二个要点，一是自己写的代码，以后自己要能够看懂；二是自己写的代码，要有自己的风格。很多程序员的代码，过了一段时间，甚至是几天后，连自己都看不懂了，一是内容看不懂，因为没有恰当的注释说明，二是都搞不清是不是自己写的代码，因为代码中没有自己的风格。
程序员是有个性的群体，所以我并不强求所有人都一致，但每个人自己要有自己的度，别人可以看懂的度。
模块封装的度
高内聚低耦合是模块封装的理想目标。但又未必是最佳的方案。就好比数据库设计中的范式。如果实际应用中把数据库设计到最高范式，那么这个数据库往往未必适用，因为查询的效率可能会大大降低。适当的增加冗余，往往能在空间和时间上找到平衡。模块的封装也是如此，不要盲目的追求高内聚低耦合，导致过度的封装。这会增加很多的开发时间和成本，而你过度封装的内容其实很多是没有必要的，将来根本就没有扩展的可能。
我有个同事，C++水平不错，喜欢做些模块封装，特别喜欢用一些开源的东西，可能觉得比较有成就感。有一次让他写一个数据文件的处理模块。这个数据文件的名称是有一定的格式和含义的，比如包含时间信息和数据项识别信息。这部分模块比较独立，牵涉面小，数据文件来自于官方的数据服务，文件名称规则变化的概率很低。本来这样的模块，最多写个配置文件，使得文件名称有一定的适应性，不至于写死。结果他直接将一个正则表达式引了进来，自己编写了成百上千行代码，还引进来一堆的动态库和文件。最糟糕的是，在他离职后，还发现他写的正则表达式在判断某些数据文件名称时，还有判断不正确的情况。由于他引入了别人不怎么熟悉的东西，其他人都难以接手。
功能设计的度
在进行面向对象设计时，也要考虑度的问题，不是设计的颗粒度越细就越好。综合考虑各个功能的要求，功能未来的扩展的可能等。对于有扩展可能的功能，或者影响面较大的功能，要保留一定的扩展空间，保持一定的弹性。当用户对功能进行增加或改变时，可以降低开发成本，防止前功尽弃的重新来过；对于基本上没有扩展可能的情况，而且影响面很小，比较独立的功能，不考虑以后的扩展也是可以的，即使出现万一，那么重新开发的成本也是能够接收的。
总之，必须在时间、进度和成本之间掌握度。才能实现即能按时完成用户的功能，又能节约成本的设计。
程序员要掌握的度还有很多，比如测试的度，沟通的度等。这里不再一一细说，大家从上面所讨论的几个度，也可以推敲在其它方面如何去掌握这个度。世界是多维的，每一维都会有它的极致，也许在某一方面，我们会要追求这个极致，比如航空航天的算法，你就不能考虑中庸之策了。但对于很多程序员开发的项目来说，往往不需要追求某一维度的极致，而是要在多维度之间掌握平衡。这个平衡点的把握能力，也可以代表一个程序员的水平。