答复: Re: Re: Re[2]: [cpp]感谢大家解决了我的困惑

[Jack]

这篇文章我双手双脚赞成！
 
写代码已经有16个年头了，个人的习惯风格早就已经形成，见过的代码风格也是林林总
总，其实好坏之处都同样的明显，没有哪一种是普适的。
 
对于公司或者项目来说，重要的就是规范每个人的行为。可以保持个人的习惯，但是要
有协调的规范，规范可以是先进规定的，也可以是项目组内的人员彼此协调的。
 
为了做到项目组内人员协调，超大型的项目（或者中型但是时间压力明显的项目），人
员肯定很多，那就需要硬性规范；中小型项目或者时间压力不大的项目，其实可以通过
减少开发人员，来帮助达到人员协调（人多不好办事啊）。
 
上面的都是事后辅助的部分，下面就是事前要做的事情了。
 
项目初期规划明显，最能够帮助人员保持清醒头脑，知道自己在干什么，否则再好的程
序员，也会因为反复的调整和修改，加上时间压力，彻底的放弃一切规范和条例，写了
等于没写。
 
归根到底，能够维持整艘大船前进，是大的原则。好的船长能够避开激流险滩暗礁，能
够找到目的地；好的大副能够尽量让船开得不是那么摇；好的船员能够明白长官在说什
么，并且快速简洁的完成相关的指令。
 
也不知道说清楚了问题没有。大家随便批
 
 


  _____  

发件人: cpp-bounces at codingnow.com [mailto:cpp-bounces at codingnow.com] 代表
Oscar.Ken
发送时间: 2006年3月26日 11:14
收件人: C++ Discuss Group
主题: [Norton AntiSpam] Re: Re: Re[2]: [cpp]感谢大家解决了我的困惑


    DarkSpy兄所言有理，若豆子大般项目，一个人足矣，个人约定也就随时可定。
 
    然而项目人数越增加，口头协定越难保障代码的可读性，尤其是编码风格的混乱，
会让阅读代码的人不断地切换思维(类似OS中切换进程)，如此让人头痛。没有良好编码
风格的代码，就如没有良好排版风格的书籍，让人望而却步。
 
　namespace用与不用各有千秋，Unreal的代码也从来不用namespace，各个包之间也不
会有命名冲突，但其命名都加以U、A、E之类前辍，变向使用了namespace的功用（也可
说namespace或许是从这些前辍演化过来的），NDL也不使用，Qt也不完全使用，但我们
会看到NiXXX, QXXX之类的命名，所以，用法上各有千秋，至于如何取舍，还看各家所
好了。
 
    所以一般的大项目中，都"应该"有若干规范来定义这些细节条款，话说到此，或有
兄台想驳斥为教条主义，我想劝兄换个角度来看这些"规范"，可以把它看成"导航图"，
我们开发项目就如在一片大海中前行，如果大家都有按着一张预先制作好的导航图上的
路线前行，就更容易不偏离行向。并且，有一个事实就是，一个人所写的代码，不可能
永远都由他(她)本人来维护，别人总有要阅读其代码时，如果没有良好的一致约定，或
许就一个变量或某个magic number让人费解。 
    
    在此举最近的一例，最早在我们的一个项目中，有一条协议OnPing()，我大概记得
当时是为了响应server的测试网络延迟所加，大概记得要回发一个-1作为响应，然事隔
近半年后，有人问我为何发-1，因在server端处理此消息的代码中是遇到-1就不作处理
了(我在工作中几乎完全信任团队成员，也很少怀疑别人的代码)，那么也就是说，按现
在的理解，这条协议一直以来做无用功。在工作繁忙的状态下，半年时间一个人要写多
少变量，多少常量？时间一长，谁能100%保证能将记忆的碎片接成完整的画面？所以，
在遇到类似的情况下时，我们只能"推测"，说得偏激一点就是"猜"。然而最早理应用
const value或是macro define来或是enum代替这个magic number -1，或许今天也就不
再迷惑了，这也是我自己的错误，所以，有些条款中不是也说了绝对不要用magic
number吗？此例可验之。 
 
    在我们公司，也曾有程序员在试用期被扫地出门的，其中有一个就是，光看Demo运
行表现尚佳，略去代码省查一关，后于试用过程中发现其编码风格极度混乱，而且并不
像其所表象的那样对C++所有掌握。若当初就省查其Demo源代码，那么必然可知若干细
节，也无须枉费此周折，不欢而散。人是很奇怪的动物，伤身易补，伤心难补。
    
    每个人从一开始接触计算机到现在，所经历的过程及环境必然有所不同，在此过程
中形成的思维也固然有所差异。我曾一再迷惑项目开发为何如此难以达到完全稳合预定
计划，后静心思索，参阅典籍，终略有收获，然天资愚钝，未能找到标本兼治之解决方
案。项目开发中，最难管理的就是人，别无其它。从《人月神话》、《微软研发－致胜
策略》、《微软项目－求生法则》《微软团队－成功秘诀》、《程序开发心理学》等典
籍中可找到许多相似观点。曾认为管理人就是在管理人的心的我也突然感觉到力不从
心，或许我现在才真正明白人心（人的思维）是多么不可量化，以致于无从下手。人心
会变，需求会变，设计会变，实现会变，进度时间会变，最后的计划也就不如变化了，
哈哈哈哈。 
 
    所有的function都是由code实现的，所有的bug也都是由code造成的，而这所有的
code也都是由人完成的。一个项目中，最难管理的就是人，不是其它的规范的一致等因
素。
 
    也许最根本的要从我们的教育上改进才能标本兼治。课堂上老师讲基础，讲理论，
讲技巧，讲应用心得，然而极少有老师能注重培养学生的编程习惯。冰冻三尺非一日之
寒，好的习惯需长年累月略有所获，而陋习之为，稍纵即成。
 
    过犹不及，物极必反，任何事物要想利用得当，必须要把握好一个度。反思国内现
在软件开发的现状(游戏软件首先是软件，再是游戏)，似乎大部分太过于自由，或许需
要那么一点点"导航图"来指引。 
　　
　自从接触编程（学习机上的GBASIC）到现在，一晃11年过去了，然还觉自身境界不
高，或是天资愚钝，尚未能有所大成，然从未放松从各方面提高自己，自谓一个优秀的
程序员，应该是有很好的习惯及技术造诣，从各方面都有很好的修养，或此方能修成正
果。
 
　滴水穿石，绳锯木断，共勉，呵呵。
     
    所言字辞，如有偏激，望各位大侠海涵：)
    
    致，
礼!
 
 
-- 
［宁静致远］ 

 
在06-3-26，DarkSpy <coneos at 21cn.com> 写道： 

Oscar.Ken，您好！ 
 
    项目大,编写人多,可以用 namespace 来清爽一下.
    豆子大的项目,几个程序员, 可以做到口头约定的话, namespace 就素那浮云.
　　想用的时候就用喽,不想用就不用喽.设计开始之前就说好喽......
 
    任何东西都不能过度,写个代码要 n 个 :: 和 n 个名空间的话, 那是得不偿失.
偶尔来个一两个就会看起来很舒服的样子.像云风以前的设计, 啊都有namespace的啊,
啊看起来也没什么不舒服的. 云风现在的设计啊, 也没多少namespace,啊看起来也很舒
服啊. :-)
 
    很多都要看设计和框架以及代码质量,什么style....俺是free style. 项目怎么需
要怎么做.怎么做怎么设计...
 
 
 
　　　　　　　致
礼！

　　　　　　　　　　　　　　DarkSpy
                            coneos at 21cn.com
　　　　　　　　　　　　　　　　　2006-03-26
 

_______________________________________________
Cpp mailing list
Cpp at codingnow.com  <mailto:Cpp at codingnow.com> 
http://codingnow.com/mailman/listinfo/cpp




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codingnow.com/pipermail/cpp/attachments/20060326/2bee35f9/attachment-0001.html