一些编程和管理的经验

一些编程和管理的经验

这些年的一些编程经验，以及在管理上的一些东西

1. 要适当解耦，但不是要全部解耦，要学会划分好模块

2. 查找问题的根源，而不是着眼于解决当前问题

3. 先思考，再写代码

4. 不要用原始的数组，而是使用boost::array

5. 尽量使用shared_ptr,如果有效率需求使用unique_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. 定期整理问题 反思 记住是 反思 不是找谁负责 而是找怎么避免问题,如果是技术水平管理者有必要帮助下属提升技术水平，这就是 30条 的做事要懂得互惠

35. 管理者不仅要懂人，还需要懂业务和技术

36. 给每一段代码编写注释，不管代码多简单，都打上几段的注释

37. 测试的好处只有在项目足够大得时候，越进行到越后面，需要更改的需求越多才会显示出来，刚开始是会让大家感觉到厌烦的东西

38. 测试人员及早介入项目，针对功能建立测试用例，开发人员进行查看测试用例，然后考虑是否可以针对这些功能进行自动化测试，然后建立自动化测试的文档，后面写代码的时候需要针对这部分进行制作

39. 测试驱动开发的关键在于在编写测试的时候理解需求，思考代码的组织和架构， 而非为了测试而测试

40. 与其依赖于测试员寻找bug，不如靠整个团队自己产生没有bug的代码

41. 技术的老大应该随时紧跟潮流，而不是仰赖自己的技术出身管理整个技术团队，但是用的却是几十年前的那一套技术

42. 变量函数名等不要吝啬单词

43. 程序员要从测试的角度思考代码

44. 测试驱动开发是为了将软件开发分成一个个粒度比较小的开发任务

45. 将一个bug转换成一个测试用例

46. 敏捷开发的重点在于自动化测试和持续发布，而不是每天开会