工作中的感悟

吐槽加感悟。

现在的代码感觉好混乱,维护起来好困难,都怀疑自己是否适合这个行业了。:(

软件工程方面的东西看过不少,从软件工程的角度讲,按理说项目早就该失控了。没有需求文档,没有完善的整体架构,在“照着这个软件做”的指导方针下,Leader简单分一下谁谁谁做哪一块,然后大家就开始动手做了,更糟糕的是代码规范一直没有被严格地执行,导致编码风格各种的不一致,要命的是我还有强迫症,看到不同的编码风格特别扭。见过一个函数近1000行代码,一行注释也没有。我智商比较低,真的看不懂。项目规模已达到近90万行,哇哦。

下面是工作中的感悟,在此记录一下:

Leader必须明白每个人写的代码的算法、流程,防止员工离职带来的代码维护问题,算法性比较强的代码最好形成文档。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

团队内的知识分享。

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

程序员的当前任务不应被打断,新任务需要排队。断了思路会很麻烦。

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

吐槽大会结束。