糟糕的是代码规范一直没有被严格地执行,导致编码风格各种的不一致,要命的是我还有强迫症,看到不同的编码风格特别别扭。见过一个函数近1000行代码,一行注释也没有。算法类的代码没有注释没有文档,读起来那是相当费劲。就像根据别人的呕吐物去猜别人吃了什么。

Leader必须明白每个人写的代码的算法、流程,加强代码审查,防止员工离职带来的代码维护问题,必要的文档还是要有的,特别是算法性比较强的代码一定要有文档。

修改代码时要保持代码和注释、变量名或参数名保持一致。比如曾经遇到过,半径改成了直径,代码中是按直径使用的,但是变量名还是叫radius,函数名还是getRadius。

有的任务不适合拆分,人越多效率越低。关于这一点,《人月神话》中貌似讨论过。

有些特性需要尽早考虑,后期再加入会影响已有的架构,造成不必要的麻烦。

数据库由专人专门负责设计和维护,以免造成混乱。

生成文件中包含闭源项目时,生成文件加入版本管理,以便同步更新。比如老大有个DLL模块未开放,手动拷贝最新的DLL太麻烦了。

软件效率问题很可能是因为读数据库、网络通信。

资源文件比如VS的.rc,最好不要多人修改,可由专人专门负责资源文件的修改,或者定好规则必须独占式修改,配合好。

最好使用Git,它的优势就不多说了,或者SVN,在TortoiseGit、TortoiseSvn中通过关键字搜索提交记录会很方便,相反,微软的TFS我目前没有发现搜索的方法,就连按提交人排序也不知道如何实现。在查找以前的提交记录时会很麻烦。

代码提交时,必须保证可编译通过,不能影响其他人的编译。

为程序员提供可用的、够用的电脑配置,别卡得要死。

代码提交时,如果修改的是多个问题,分几次提交,便于后期搜索,提交注释要写清楚。

修改代码时,旧代码要直接删除不要注释起来,也不要署名,一切交给版本管理软件。删掉旧代码是因为保持代码清洁,否则后期代码会越来越乱。

源代码开头不要署个人名字,只署公司版权,因为一个文件不可能只有一个人去维护,而且利用版本管理软件可以查询修改历史。

删除占位符注释,比如MFC的// Todo。

代码提交说明要写清楚,比如修改Bug,到底是什么Bug。提交说明对于后期搜索很重要。

规范:头文件必须加在文件开头,不能在文件中间加。

提需求或Bug最好形成文字描述,口头表达容易遗忘,或者漏听细节。

如果函数有多个参数最好不要重载,否则通过IDE定位函数很困难,体验过就会知道,IDE列出两个函数,都是一堆参数,如果不仔细观察,无法快速定位到要找的函数。

协作聊天软件需要设置右下角弹出,增强快速回馈。

变量名问题:bool isHeaderOrFooter; true表示是Header还是Footer呢?bool isHeader; 会更好。

命名规范:除了公认的缩写外不要使用自创的奇怪的缩写,避免单词拼写错误,公司一定要有代码规范,并强制严格执行,控制单个函数的长度。

删除过时代码,保持代码清洁。

使用单元测试,每次改Bug要确保所有单元测试都通过。因为改一个Bug可能会影响其他功能。

团队内的知识分享。

代码提交之前先自己审阅一下,避免将临时的测试代码提交。

程序员的当前任务不应被打断,新任务需要排队。断了思路会比较麻烦。优先级高的新任务可以例外。

std::pair不容易区分first、second代表什么意思,如果有必要请自定义数据结构。

标签: none

评论已关闭