糟糕的是代码规范一直没有被严格地执行，导致编码风格各种的不一致，要命的是我还有强迫症，看到不同的编码风格特别别扭。见过一个函数近1000行代码，一行注释也没有。算法类的代码没有注释没有文档，读起来那是相当费劲。就像根据别人的呕吐物去猜别人吃了什么。
Leader必须清楚每个人写的代码的算法、流程，加强代码审查，防止员工离职带来的代码维护问题，必要的文档还是要有的，特别是算法性比较强的代码一定要有文档。
修改代码时要保持代码和注释、变量名或参数名保持一致。比如曾经遇到过，半径改成了直径，代码中是按直径使用的，但是变量名还是叫radius，函数名还是getRadius。
有的任务不适合拆分，人越多效率越低。关于这一点，《人月神话》中貌似讨论过。
有些特性需要尽早考虑，后期再加入会影响已有的架构，造成不必要的麻烦。
数据库由专人专门负责设计和维护，以免造成混乱。
生成文件中包含闭源项目时，生成文件加入版本管理，以便同步更新。比如老大有个DLL模块未开放，手动拷贝最新的DLL太麻烦了。
软件效率问题很可能是因为读数据库、网络通信。
资源文件比如VS的.rc，最好不要多人修改，可由专人专门负责资源文件的修改，或者定好规则必须独占式修改，配合好。
最好使用Git，它的优势就不多说了，或者SVN，在TortoiseGit、TortoiseSvn中通过关键字搜索提交记录会很方便，相反，微软的TFS我目前没有发现搜索的方法，就连按提交人排序也不知道如何实现。在查找以前的提交记录时会很麻烦。
代码提交时，必须保证可编译通过，不能影响其他人的编译。
为开发人员提供可用的、够用的电脑配置，别卡得要死。
代码提交时，如果修改的是多个问题，可以分几次提交，便于后期通过版本控制软件搜索，提交注释要写清楚。
修改代码时，旧代码要直接删除不要注释起来，也不要署名，一切交给版本控制软件。删掉旧代码是因为保持代码清洁，否则后期代码会越来越乱。
源代码开头不要署个人名字，只署公司版权，因为一个文件不可能只有一个人去维护，而且利用版本控制软件可以查询修改历史。
删除占位符注释，比如MFC的// Todo。
代码提交说明要写清楚，比如修改Bug，到底是什么Bug。提交说明对于后期搜索很重要。
规范：头文件必须加在文件开头，不能在文件中间加。
提需求或Bug最好形成文字描述，口头表达容易遗忘，或者漏听细节。
如果函数有多个参数最好不要重载，否则通过VS定位函数很困难，体验过就会知道，VS下拉列表框列出两个函数，都是一堆参数，如果不仔细观察，无法快速定位到要找的函数。
协作聊天软件需要设置右下角弹出，增强快速回馈。
变量名问题：bool isHeaderOrFooter; true表示是Header还是Footer呢？bool isHeader; 会更好。
命名规范：除了公认的缩写外不要使用自创的奇怪的缩写，避免单词拼写错误，公司一定要有代码规范，并强制严格执行，控制单个函数的长度。
删除过时代码，保持代码清洁。
使用单元测试，每次改Bug要确保所有单元测试都通过。因为改一个Bug可能会影响其他功能。
团队内的知识分享。
代码提交之前先自己审阅一下，避免将临时的测试代码提交。
程序员的当前任务不应被打断，新任务需要排队。断了思路会比较麻烦。优先级高的新任务可以例外。
std::pair不容易区分first、second代表什么意思，如果有必要请自定义数据结构。