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

[Oscar.Ken]

    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
> http://codingnow.com/mailman/listinfo/cpp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codingnow.com/pipermail/cpp/attachments/20060326/c1cf2c4d/attachment.html