标签：
1.要适当解耦，但不是要全部解耦，要学会划分好模块
2.查找问题的根源，而不是着眼于解决当前问题
3.先思考，再写代码
4.不要用原始的数组，而是使用boost::array
5.尽量使用shared_ptr
6.如果界面框架提供MVC模型，一定要使用MVC的方式来编写
7.不要滥用继承，继承一定要有逻辑关系，is-a的模型，不要为了方便一些操作就把所有东西都放在基类，然后继承下来，如果是为了方便操作，复用代码，应该将代码封装成一个函数
8.C++里面如果使用coroutine，一定要记得清理资源
9.利用BOOST_SCOPE_EXIT在资源申请的地方顺便写下资源清理的代码，类似于go的defer
10.与人交流，如果超过一定的复杂度，最好带上设计图或者框架图
11.熟悉团队的英文水平，在使用英文命名变量或者类的时候，记得带上注释，如果是缩写，也要带上中文注释
12.在使用map的时候，key如果是int，string这种基础类型，最好使用typedef，便于让人看出这个key是干什么的，list，vector同理
13.如果程序需要处理特殊处理，应该要写注释，比如在一个const的类函数里面，如果需要const_cast<T*>(this),那么要写上注释，告诉用户为什么要这样做
14.统一变量，函数的名词命名，比如评分，有的用score，有的用judging ，整个项目里面应该统一使用一种名词,防止混乱
15.即时沟通，不要闷头做事
16.即时审查代码
17.利用MVC模型来进行数据和界面分离，然后通过数据来做测试
18.项目确定的时候，需求没确定，做一步看一步的时候，如果不知道数据要归谁管理，统一放在global里面，然后定时整理代码
19.一个项目里面最好要有一个可以统一放置全局变量的地方
20.如果对性能，内存要求不是很严格，使用vector而不是list，因为你永远不会预料到需求是否会有随机读取的操作，那到时候只能用std::advance来获取
21.善于利用stl algorithm,如果遇到stl的数据处理先看下有没有对应的stl算法
22.由于STL的代码编写可能很长，所有可以建一个文件放置全局宏定义，类似QtGlobal文件
23.不要越级去分配任务，否则会让下属只做更上层的事情
24.过分宣传个人责任与惩罚，这是某种形式的管理懒惰,进而导致的是多做多错，少做少错，尽量不做
25.管理工程师要从技术上管理，在准备对一个工程师进行管理的时候要让他承认你的技术
26.要培养下属较真的能力
27.工程目录要制定好
28.要有一个地方保存改进记录
29.产品跟技术，不能偏向，两者需要争论，然后才能让大家理解两边的想法
30.做事要懂得互惠
31.绩效考核主要面对管理者，避免量化技术
32.弱化测试和开发的边界，引导技能互通
33.测试的出现并不是为了给开发推卸责任，而是要帮程序员找到问题的所在，从而更好的解决问题
34.定期整理问题 反思 记住 是反思 不是找谁负责 而是找怎么避免问题
标签：
原文地址：http://www.cnblogs.com/linyilong3/p/5464667.html
