读书笔记之《代码大全2》

1.软件构建很重要，直接决定了项目的成败，一般占据项目成本的65%，降低风险，亡羊补牢，为时晚矣。
2.鼓励重用，改变，但是不仅仅是抄袭
3.相对于试错式编程必定是不如经过用心仔细的规划和设计的编程，但是也不是意味着过度计划。
4.见多学广活学活用
5.Java更适用于web项目。c++和c#更适用窗口应用程序
6.优秀的程序员是紧缺的
7.发现错误的时间越接近引入的时间，带来的危害越小，当然不引入错误才是最好的，不过不现实。
8.迭代可以减轻前期准备不足的负面影响
9.对系统要解决的问题有清楚的陈述
10.需求变更往往是无法避免的
11. “深入一种语言去编程“的程序员首先决定他要表达的思想是什么， 然后再决定如何使用特定语言提供的工具来表达这些思想。
12. 设计犯错时无可厚非的，在此基础上进行修改可以避免更大的损失。设计是一个迭代的过程。
13. 软件首要技术就是管理复杂度。让每个人在同一时间需要处理的本质复杂度减到最少。
14. 面向接口编程并尽量少的暴露内部工作机制，封装实现细节。信息隐藏强调的是隐藏复杂度。
15. 养成问自己”我该隐藏些什么？“的习惯。
16. 把感觉比较容易变化的部分限制在一个区域内。
17. 学会熟练使用访问器子程序。取代直接使用全局变量。增加隐藏
18. 《设计模式》是本值得仔细研读的书，不能为了模式而模式。
19. 做重复的事情却期待着不同的结果
20. 熟练运用ADTs（抽象数据类型）。类的接口应该展现一致的抽象层次。
21. 包含：has a …继承：is…a(LSP:任何基类可以出现的地方，子类一定可以出现。)，派生类必须能通过基类的接口而被使用，且使用者无须了解两者的差异。多用多态.
22. 正确的给予函数和变量有意义的名字。按照团队规范命名方式进行命名。
23. 函数应该只有一个返回值，永远以它的返回的值命名。过程可以根据需要接受任意的输入、修改和输出参数。
24. 防御式编程：承认程序都会有问题，都需要被修改，应该根据这点来编程。
25. 活用assert 断言
26. 使用版本控制工具
27. 写好伪代码并依照它去生成代码，同时把伪代码变成编程语言中的注释
28. 想要提高带阿姆的质量和生产率，有一个重要的途径就是重用好的代码
29. bug的原因是由于编写代码的人，要为自己写的代码负责。单步调试。
30. 尽量减少作用域
31. 递归能做到的用栈和循环也可以做到，递归中至少有一条非递归的路径。只在需要的地方使用goto。
32. 表驱动法可以很好的化简复杂的逻辑和结构，表数据存在程序外可以方便修改
33. 软件质量的不同目标是有冲突的，不可能所有方面都做的很好
34. 阅读代码比测试检测的缺陷高80%，而且成本更小。所以要在早期阶段就要强调质量保证的工作，贯彻整个项目。
35. 提高生产效率和改善质量的最佳途径就是减少代码返工的时间，即改善产品的质量。
36. 提前写测试用例，将迫使你在开始写代码之前至少会思考一下需求和设计，而这往往会催生更高质量的代码。提高软件质量能够减少开发成本
37. 测试是寻找错误，调试是纠正错误的过程，理解程序本身而不能仅仅理解问题
38. 重构：在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改。重构不能代替重写，当处于大规模的重构之中时，应该考虑重写代码
39. Pareto法则：用20%的努力取得80%的成效。
40. 撰写文档的目的并不在于文档本身，先写计划的关键在于迫使你仔细思考配置管理，并把你的计划向每个人解释。文档只是你在计划并构建软件系统过程中所做的那些真实工作的一种有形的副产品。
41. 配置管理：系统化的定义项目工件和处理变化，以使项目一直保持其完整性的实践活动
42. 优秀的程序员还是少的，为其支付更高的报酬理所当然。–好的程序员倾向于聚到一起
43. Daily Build和冒烟测试是很好的集成方式。
44. 程序很大程度是写给人看的。好的布局和良好的可读性（注释，好的命名习惯）很有必要，为人写代码，没必要写富有玄机的代码，除非有必要
45. 注释应表达代码的意图，注重为何做而不是怎么做
46. 有些懒惰是科学生产力的来源。
47. 软件行业学要不断的学习，工作十年，是得到10年的经验还是1年的经验的10次重复？发展才是硬道理。。。。
48. 让好习惯的形成来影响生活
49. 降低复杂度是软件开发的核心
50. 借助规范集中注意力
51. 软件设计是一个逐步精华的过程
–第一遍通读代码大全的简单摘录
2017/07/07