关闭

第十四章: 程序员的度

9555人阅读 评论(36) 收藏 举报

    我这里想说的度,并不是程序员的气度,而是在项目开发过程中,去完成自己所所需完成的每项任务的度。

很多概念都有个最高目标,但未必最高目标就是最合适的。最切实际的目标,是要综合考虑实际情况,可能包括资源,时间,成本,效率等等,做到有度。这个世界是个多维的,充满矛盾的。程序员们要学会在各个矛盾体之间找到平衡点。

   编码的度

    我想很多公司都会有自己的编码规范,要求在编码过程中,你的文件命名,函数定义,变量命名,代码注释等都要按照规定的格式进行编写。我们公司的编码规范是我写的,但我自己其实也无法全部做到。

作为公司的规章制度,可能需要一个很完善,很全面的考虑。而作为我对个人的要求,对程序员编码的度的理解,是每个程序员自己心中要有一个基本编码规范,也就是你自己编写的代码要有自己的风格。简单来说就是二个要点,一是自己写的代码,以后自己要能够看懂;二是自己写的代码,要有自己的风格。很多程序员的代码,过了一段时间,甚至是几天后,连自己都看不懂了,一是内容看不懂,因为没有恰当的注释说明,二是都搞不清是不是自己写的代码,因为代码中没有自己的风格。

程序员是有个性的群体,所以我并不强求所有人都一致,但每个人自己要有自己的度,别人可以看懂的度。

   模块封装的度

高内聚低耦合是模块封装的理想目标。但又未必是最佳的方案。就好比数据库设计中的范式。如果实际应用中把数据库设计到最高范式,那么这个数据库往往未必适用,因为查询的效率可能会大大降低。适当的增加冗余,往往能在空间和时间上找到平衡。模块的封装也是如此,不要盲目的追求高内聚低耦合,导致过度的封装。这会增加很多的开发时间和成本,而你过度封装的内容其实很多是没有必要的,将来根本就没有扩展的可能。

    我有个同事,C++水平不错,喜欢做些模块封装,特别喜欢用一些开源的东西,可能觉得比较有成就感。有一次让他写一个数据文件的处理模块。这个数据文件的名称是有一定的格式和含义的,比如包含时间信息和数据项识别信息。这部分模块比较独立,牵涉面小,数据文件来自于官方的数据服务,文件名称规则变化的概率很低。本来这样的模块,最多写个配置文件,使得文件名称有一定的适应性,不至于写死。结果他直接将一个正则表达式引了进来,自己编写了成百上千行代码,还引进来一堆的动态库和文件。最糟糕的是,在他离职后,还发现他写的正则表达式在判断某些数据文件名称时,还有判断不正确的情况。由于他引入了别人不怎么熟悉的东西,其他人都难以接手。

功能设计的度

    在进行面向对象设计时,也要考虑度的问题,不是设计的颗粒度越细就越好。综合考虑各个功能的要求,功能未来的扩展的可能等。对于有扩展可能的功能,或者影响面较大的功能,要保留一定的扩展空间,保持一定的弹性。当用户对功能进行增加或改变时,可以降低开发成本,防止前功尽弃的重新来过;对于基本上没有扩展可能的情况,而且影响面很小,比较独立的功能,不考虑以后的扩展也是可以的,即使出现万一,那么重新开发的成本也是能够接收的。

总之,必须在时间、进度和成本之间掌握度。才能实现即能按时完成用户的功能,又能节约成本的设计。

程序员要掌握的度还有很多,比如测试的度,沟通的度等。这里不再一一细说,大家从上面所讨论的几个度,也可以推敲在其它方面如何去掌握这个度。世界是多维的,每一维都会有它的极致,也许在某一方面,我们会要追求这个极致,比如航空航天的算法,你就不能考虑中庸之策了。但对于很多程序员开发的项目来说,往往不需要追求某一维度的极致,而是要在多维度之间掌握平衡。这个平衡点的把握能力,也可以代表一个程序员的水平。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:540454次
    • 积分:8242
    • 等级:
    • 排名:第2520名
    • 原创:125篇
    • 转载:18篇
    • 译文:1篇
    • 评论:1618条
    最新评论
    资源网站