好记性不如烂笔头，《代码大全》看了等于没用，要留点笔记，最好亲自动手

软件构建是重要的过程
用隐喻来理解软件
前期准备很重要
指定编程约定，不要依赖某种技术，明白自己所处的浪潮
软件设计方法，分层/分模块，自定向上/自定向下
抽象的意义在于对细节的隐藏，而这种隐藏是非常有用的
子程序要小，可以降低脑力复杂度，因为优点太多了
防御式编程也是很有用的技术，其中断言是指用户级绝对不能出的错误，而异常是系统级意想不到的错误
伪代码是非常重要，便于理解，写程序是要先打草稿的，比如划分职责非常有用
变量关注减少作用域，减少生命周期，减少代码跨度（尽量挨在一起），灵活选取变量与值的绑定事件，还有一个命名不要后来又有两种意思，进而方便了重构？难怪啊最近觉得重构的阻力很大，是这些因素导致的，全局变量虽然方便，但是增加了脑力复杂度，因为你要搞懂这个变量意义，就需要查看所有引用其变量的引用到底对其做了什么呢
变量可读性的重要性比如bear_age,IsXX不如XX肯定好，好的命名重要尽量不要i，j，而且变量也不要太长，也不能太短，g_xx全局变量的标识
创建需要自己的类型，然后注意溢出等情况
对于结构灵活使用，可以对变量进行组织，结构对于减少智力管理复杂度是类不能比拟的哦，全局变量尽量别用，哪怕使用也得用获得器封装起来
顺序执行的函数，可能通过一些特别的设置（比如返回同一个对象），阐明是顺序执行的关系，而不是在方法名做手脚
条件语句Case中用Default做错误抛出非常好的技巧，对else对详细注解说明，对常见的语句应该排在更前面
循环控制，要合理的给Index命名，不要i,j什么的，还有就是设计一个循环，从内向外扩散设计，每次设计都只需要关注到一个点。高手程序员和低级程序员区别在于，高级程序员在脑中设想好代码，再设计，低级程序员拿着直接设计并且修修补补
多返回值增加管理复杂度，递归要设置计数器，因为担心内存占用太多，而不是计算的问题，一个递归函数步骤是多个，要分解成小函数方便理解。goto是结构化编程利器，可以让不支持类的编程语言，同样好维护，但是要注意不能滥用
表驱动法对众多数据对解析，和bool变量的简化，起到了巨大的作用，用一个解析函数完成了非常棒的效果，甚至比面向对象还要好用。不支持类的语言更应该用，表驱动还有阶梯等一些优化技术。。找一个解决问题又不引发方案等解决方案，而不是寻找最佳的解决方案。
用dowhile改善嵌套if，把bool弄成子函数，结构化编程降低复杂度，顺序，选择，循环其他谨慎，复杂度高的可能不是好的设计，需要重新来，改善阅读性和可理解性，比如把范围符合轴区间的形式
用多种检测方式才能有多缺陷检查率，保证软件质量是省钱省时间的做法，即时前期感觉不明显也应该观测在整个生命周期。代码复查比测试更省钱。。保证软件质量的代码不一定比没作保证的代码编写更慢
结对编程比个人开发效率还要高你敢信，协同开发的一些技术可以运用在非编程上面，非编程的工种也会导致缺陷。
测试符合28原则，模块化的威力就是方便测试，测试要用随机数生成器生产数据，测试先行可能对需求严谨，测试的记录与总结经验，日志就是类似飞机黑匣子。
二分法调试，科学方法调试（收集稳定数据，假设xx，验证xx，改成xx，再验证），利用断点也可以形成分而治之的调试，对于修改代码而言如果不理解整个允许逻辑是非常可怕的，所以不提倡使用全局变量，如果调试太花时间不如重写。对于集成可以采用增量集成的技术。性能剖析器能发现调试错误。关注变量的心里距离（相识程度），不然的话怎么排查都以为自己没错，还有列出蛮力调试法。放松一下也不错。一次只做一次修改，并且修改后要测试是否造成了其他影响（模块化）
重构把int类型Money改成自定义类Money，Null对象模式，把判断嫁给自己，数据初始化干掉虚函数，异常和错误互换身份。重构涉及到修改代码，需要小步进行，大规模重构不如重新写。重构收益遵循28原则，也就是把20%最复杂的模块重构了就非常好了，如果全部都要重构追求完美，那就等于浪费时间，自取灭亡，成了教条主义
性能优化有时候是乘法级别的，所以说值得做，28原则，只优化很少一部分，即可让整个系统翻倍加快，忌过早优化可以放到最后来优化，这个重构不同，而且优化只需要部分核心代码，也和重构不同，重构最好一直持续，优化中警惕架构的不足。警惕性能大头：输入、系统调用、错误
警惕短路运算的陷阱，swich判断首先是最常用的case排在前面，使用惰性求值也可提高性能，for循环的if判断放在外面也是可以参考，合并思路，展开思路，哨兵值（数组尾部加哨兵），循环内部尽量少计算，浮点数性能低了，使用辅助索引，利用代数等方式消弱计算。比如用乘法模拟幂函数，单浮点比双浮点不仅小性能还更好，小心系统函数，用自己的函数粗略模拟性能更好，使用正确的常量，子程序小放在汇编语言还可能被读懂呢，用内联子程序重写代码

27，28，29没仔细看，29-35章节大致总结如下：

打造各种各样工具，不要怕功能重复，大剪刀和小剪刀都有用
程序员应该养成良好的习惯，比如一开始就用伪代码编程
诚实是难能可贵的品质
制定各种编码规范非常重要帮助你解脱
写代码要有良好的命名，站着问题这个抽象层思考并合适命名，最好不要计算机科学哪些命名
多阅读多思考，持续学习
良好的注释
注意砍需求
在开源项目上快速打造产品

27 程序规模对构建的影响

27.1 要点
随着项目规模的扩大，交流需要加以支持。大多数方法论的关键点都在于减少交流中的问题，而一项方法论的存亡关键也应取决于它能否促进交流
在其他条件都相等的时候，大项目的生产率会低于小项目
在其他条件都相等的时候，大项目的每千行代码错误率会高于小项目
在小项目里一些看起来“理当如此”的活动在大项目中必须仔细地计划。随着项目规模扩大，构建活动的主导地位逐渐降低
放大轻量级的方法论要好于缩小重量级的方法论。最有效的办法是使用“适量级”方法论

28 管理构建

28.1 核对表
28.1.1 核对表：配置管理
概要

你的软件配置管理计划是否用于帮助程序员，并能将额外负担降低至最低？
你的软件配置管理方法是否避免了对项目的过度控制？
你是否将一些变更请求聚成一组？无论采用非正式的方法（如创建一份未决更改的列表）还是更加系统的方法（如设立变更控制委员会）
你系统地评估了每一项提交的更改对成本、计划和质量的影响吗？
你是否把重大的变更看做是需求分析还不够完备的警报信号？
工具

你用版本控制软件来促进配置管理吗？
你用版本控制软件来减少团队工作中的协调问题吗？
备份

你定期地备份项目中的所有资料吗？
你定期把项目备份数据转移到off-site storage里了吗？
所有的资料，包括源代码、文档、图标和重要的笔记都得到备份了吗？
你测试过备份与恢复的过程吗？
28.2 要点
好的编码实践可以通过“贯彻标准”或者“使用更为灵活的方法”来达到
配置管理，如果应用得当，会使程序员的工作变得更加轻松。特别包括变更控制
好的软件评估是一项重大挑战。成功的关键包括采用多种方法、随着项目的开展而修缮评估结果，以及很好地利用数据来创建评估等
度量是构建管理成功的关键。你可以采取措施度量项目的任何方面，而这要比根本不度量好得多。准确的度量是制定准确的进度表、质量控制和改进开发过程的关键
程序员和管理人员都是人，在把他们当人看的时候工作得最好

29 集成

29.1 核对表
29.1.1 核对表：集成
集成策略

该策略是否指明了集成子系统、类、子程序时应该采用的最优顺序？
集成的顺序是否与构建顺序协调，以便在适当的时候准备好提供集成的类？
该策略是否易于诊断缺陷？
该策略是否使脚手架最少？
所选的策略是否好于其他方式？
组件之间的接口是否有明确定义？（定义接口不是集成的任务，但要验证这些接口的定义是否明确。）
Daily build与冒烟测试

项目是否经常build–理想情况下，每天build一次–以支持增量集成？
每次build后是否都运行冒烟测试，让你知道这个build能否工作？
你是否已使build和冒烟测试自动进行？
开发人员是否频繁地check in他们的代码–两次check in之间最多间隔一两天？
冒烟测试是否与代码同步更新，随代码发展而发展？
破坏build是罕见事件吗？
是否在有压力的情况下，也对软件进行build和冒烟测试？
29.2 要点

30 编程工具

30.1 核对表

30.1.1 核对表：编程工具

你有一套有效的IDE吗？
你的IDE集成了：源代码控制、build/测试/除错工具，以及其他有用的功能吗？
你有能自动进行常用的重构操作的工具吗？
你是否使用版本控制工具，对源代码、内容、需求、设计、项目计划及其他的项目构件进行管理？
如果你面对超大型的项目，你是否使用了数据字典或者其他“包含系统中使用的各个类的权威描述”的中央知识仓库？
当可以用到代码库时，你是否考虑用它来代替“编写定制代码”？
你是否充分利用了交互式除错器？
你是否使用make或其他“依赖关系控制软件”，用来高效并可靠地build程序？
你的测试环境包含有自动化的测试框架、自动测试生成器、覆盖率监视器、系统扰动器、diff工具，以及缺陷跟踪软件吗？
你有没有制造过定制工具–能满足特定项目的需求的那种，特别是能自动执行重复任务的工具？
总而言之，你的工作环境有没有从“充足的工具支援”中获益？

30.2 要点

程序员有时会在长达数年的时间里忽视某些最强大的工具，之后才发现并使用之
好的工具能让你的日子过得安逸的多
下面这些工具已经可用了：编辑、分析代码质量、重构、版本控制、除错、测试、代码调整
你能打造许多自己用的专用工具
好的工具能减少软件开发中最单调乏味的工作量，但它不能消除对“编程”的需要，虽然它会持续地重塑“编程”的含义

31 布局与风格

31.1 核对表

31.1.1 核对表：布局

一般问题

格式化主要是为了展现代码的逻辑结构吗？
你的布局方案能统一地运用吗？
你的布局方案能让代码易于维护吗？
你的布局方案是否有利于代码的可读性？
控制结构的布局

你的代码中避免begin-end对{}的双重缩进了吗？
相邻的块之间用空行分隔了吗？
对复杂表达式格式化时考虑到可读性吗？
对只有一条语句的块的布局始终如一吗？
case语句与其他控制结构的格式化保持一致了吗？
对goto语句的格式化是否让其显眼了呢？
单条语句的布局

为逻辑表达式、数组下标和子程序参数的可读性而使用空格了吗？
不完整的语句在行末是以明显有错的方式结束吗？
后续行按照标准数目缩进了吗？
每行顶多只有一条语句吗？
所写的每个语句都没有副作用吗？
每行顶多只声明一个数据吗？
注释的布局

注释与其所注释的代码的缩进量相同吗？
注释的风格便于维护吗？
子程序的布局

你对每个子程序参数的格式化方便于看懂、修改、注释吗？
采用空行分隔子程序的各部分了吗？
类、文件和程序的布局

多数类和文件之间是意义对应的关系吗？
如果文件内有多个类、各类中的子程序按类分组了吗？
各类都清楚标志了吗？
文件中的子程序用空行清楚地分开了吗？
在没有更好的组织形式的场合，所有子程序都按字母顺序排列了吗？

31.2 要点

可视化布局的首要任务是指明代码的逻辑组织。评估该任务是否实现的指标包括准确性、一致性、易读性和易维护性
外表悦目比起其他指标是最不重要的。然而，如果其他指标都达到了，代码又质量好，那么布局效果看上去也会不错
Visual Basic具有纯代码块风格，而Java的传统做法就是使用纯块风格，所以若用这些语言编程，就请使用纯代码块风格。C++中，模拟纯代码块或者begin-end块边界都行之有效
结构化代码有其自身目的。始终如一地沿用某个习惯而少来创新。不能持久的布局规范只会损害可读性
布局的很多方面设计信仰问题。应试着将客观需要和主观偏好区分开来。定出明确的指标，在此基础上再讨论风格参数的选择

32 自说明代码

32.1 核对表

32.1.1 核对表：自说明代码

类

你的类接口体现出某种一致的抽象吗？
你的类名有意义吗，能表明其中心意图吗？
你的类接口对于如何使用该类显而易见吗？
你的类接口能抽象到不需考虑其实现过程吗？能把类看成是黑盒吗？
子程序

你的每个子程序名都能准确地指示该子程序确切干些什么吗？
你的各个子程序的任务明确吗？
若各子程序中自成一体后更有用，你都将其各自独立出来了吗？
每个子程序的接口都清晰明了吗？
数据名

类型名描述有助于说明数据声明吗？
你的变量名有意义吗？
变量只用在其名字所代表意义的场合吗？
你的循环变量名能给出更多信息，而不是i、j、k之类的吗？
你用了名字有意义的枚举类型，而非临时拼凑的标识或布尔变量吗？
用具名常量代替神秘数值或字符串了吗？
你的命名规范能区分类型名、枚举类型、具名常量、局部变量、类变量以及全局变量吗？
数据组织

你根据编程清晰的需要，使用了额外变量来提高清晰度吗？
你对某变量的引用集中吗？
数据类型简化到最低复杂度吗？
你是通过抽象访问子程序（抽象数据类型）来访问复杂数据吗？
控制

代码中的正常执行路径很清晰吗？
相关语句放在一起了吗？
相对独立的语句打包为子程序了吗？
正常情况的处理位于if语句之后，而非在else子句中吗？
控制结构简单明了，以使复杂度最低吗？
每个循环完成且仅完成一个功能，是像定义良好的子程序那么做吗？
嵌套层次是最少的吗？
逻辑表达式通过额外添加布尔变量、布尔函数和功能表简化了吗？
布局

程序的布局能表现出其逻辑结构吗？
设计

代码直截了当吗？是不是避免了自作聪明或新花样？
实现细节尽可能隐藏了吗？
程序是尽可能采用问题领域的术语，而非按照计算机科学或者编程语言的术语编写的吗？

32.1.2 核对表：好的注释技术

一般问题

别人拿起你的代码就能立刻明白意思吗？
你的注释是在解释代码用意，或者概括代码在做什么，而非简单重复代码吗？
采用了伪代码编程法来减少注释时间吗？
你的注释能否同代码一起更新？
注释清楚正确吗？
你的注释风格便于修改注释吗？
语句和段落

代码避免用行尾注释了吗？
注释是着力说明为什么而非怎么样吗？
注释为将要阅读代码的人们做好准备了吗？
每个注释都有其用处吗？删掉抑或改进了多余的、无关紧要的或随意的注释没有？
是否注释了代码的非常规之处？
避免使用缩略语了吗？
主次注释区别明显吗？
含错代码和未公开的代码特性有注释吗？
数据声明

对数据声明的注释说明了数值单位吗？
数值数据的取值范围注释出来了吗？
注释出了编码含义吗？
对输入数据的限制有注释吗？
对位标志做注释了吗？
在各全局变量声明的地方对其做注释了吗？
各全局变量是通过命名规范、注释（或者两者兼用）来标识其意义吗？
神秘数值是否以具名常量或变量代替，而非只是标注之？
控制结构

控制语句都注释了吗？
冗长或者复杂的控制结构结尾处有注释吗？抑或可能的话，简化之从而省去注释了吗？
子程序

各子程序的意图都注释出了吗？
子程序的其他有关情况（诸如输入输出数据、接口假设、局限性、纠错、全局效果和算法来源）都注释出来了吗？
文件、类和程序

程序有简短的文档（就像在“以书本为范例”中说明的那样）给出程序组织的概述吗？
每个文件的用途都有说明吗？
作者姓名、email及电话号码在代码清单中都有吗？

32.2 要点

该不该注释是需要认真对待的问题。差劲的注释只会浪费时间，帮倒忙；好的注释才有价值
源代码应当含有程序大部分的关键信息。只要程序依然在用，源代码比其他资料都能保持更新，故而将重要信息融入代码是很有用处的
好代码本身就是最好的说明。如果代码太糟，需要大量注释，应先试着改进代码，直至无须过多注释为止
注释应说出代码无法说出的东西–例如概述或用意等信息
有的注释风格需要许多重复性劳动，应舍弃之，改用易于维护的注释风格

33 个人性格

33.1 要点

人的个性对编程能力有直接影响
最有关系的性格为：谦虚、求知欲、诚实、创造性和纪律，以及高明的偷懒
程序员高手的性格与天分无关，而任何事都与个人发展相关
出乎意料的是，小聪明、经验、坚持和疯狂既有助也有害
很多程序员不愿主动吸收新知识和技术，只依靠工作时偶尔接触的新的信息。如果你能抽出少量时间阅读和学习编程知识，要不了多久就能鹤立鸡群
好性格与培养正确的习惯关系甚大。要成为杰出的程序员，要先养成良好习惯，其他自然水到渠成

34 软件工艺的话题

34.1 要点

编程的主要目的之一是管理复杂性
编程过程对最终产品有深远影响
合作开发要求团队成员之间进行广泛沟通，甚于桶计算机的交互；而单人开发则是自我交流，其次才是与计算机
编程规范一旦滥用，只会雪上加霜；使用得当则能为开发环境带来良好机制，有助于管理复杂性和相互沟通
编程应基于问题域而非解决方案，这样便于复杂性管理
注意警告信息，将其作为编程的疑点，因为编程几乎是纯粹的智力活动
开发时迭代次数越多，产品的质量越好
墨守成规的方法有悖于高质量的软件开发。请将编程工具箱中填满各种编程工具，不断提高自己挑选合适工具的能力

35 参考

《代码大全2版》

《代码大全》个人总结相关推荐

evoc服务器长鸣报警显示正常,UPS电源故障灯亮，蜂鸣器长鸣报警怎么办
UPS电源故障灯亮,蜂鸣器长鸣报警怎么办一台迈普1KVA在线式UPS电源,开机后旁路输出正常,按ON键,能由旁路转入逆变器工作,但立即又跳转旁路,且故障灯亮,蜂鸣器长鸣报警,按OFF键,蜂鸣器停止报 ...
你的灯亮着吗读后感2
最近读了<你的灯亮着吗>的第三.四篇.对其有了一些感想. 真正的问题: 人容易被刮胡子的刀片划伤,是设计者的问题?还是使用者的问题?车祸经常发生,是因为政策对速度限制太高了?还是因为开车不 ...
《你的灯亮着吗》读书笔记3
终于读完了<你的灯亮着吗>,其实从总体来看,这本书给了我很大的启示. 在理解问题之前,至少要做好准备接受三种可能的出错情况:或许还可以改变问题的表述来获得不同的解决方法:当你沉迷于寻找问题 ...
《你的灯亮着吗》读书笔记1
你的灯亮着吗? 上帝说:"要有光."于是俺挑了这本只有50多页的书,在剩下的5天里,可以保证读完剩下的三章. 前几天我一口气看了三章,觉得这本书和<梦断代码>相比,上了 ...
华为服务器故障灯不开机_总有故障灯亮却不知道是怎么回事？详解这些你不认识的故障灯...
总有故障灯亮却不知道是怎么回事?详解这些你不认识的故障灯其实,所谓故障灯,就是用来提示车主,你的爱车究竟哪里出了问题.但由于很多故障灯很少见,别说新司机了,有的老司机都未必见到过.所以,这些故障灯到 ...
读后感：你的灯亮着吗
你的灯亮着吗书的内容就不介绍了,说说我读完这本书的感受吧. 首先,印象比较深刻的是书中对真正问题的追查方式. 大概是下面这样的步骤: 1.先把你认为出现的问题描述一下 2.想一下,可能是哪里出的问题 ...
你的灯亮着吗--随笔1
<你的灯亮着吗>是著名思想家温伯格的一本定义分析和解决问题的书籍.问题解决的第一步应该是描述问题. 我认为本书的一个重要的点就是告诉大家如何去正确的认识问题,去定义一个问题. 问题是你期望 ...
[书籍分享]0-003.你的灯亮着吗:发现问题的真正所在
封面内容简介本书是由唐纳德·高斯和杰拉尔德·温伯格著作.它主要是向读者阐述了一些关于问题定义和看待问题的方式方法,帮助读者解放自己的思维禁锢,多方面的去寻找问题的定义,并解决问题. 这本书分六篇列 ...
笔记本电脑关机后指示灯还亮_汽车仪表常见指示符号之清洗液指示灯，灯亮了怎么办？...
清洗液指示灯就是玻璃水指示灯,用来显示玻璃水的储存量的,平时为熄灭状态,当玻璃水不足时就会点亮提醒驾驶员该添加了. 添加后清洗液指示灯还亮的说明出现故障,检查玻璃水电机,相关线路保险丝等,行车中此灯亮 ...
《你的灯亮着吗》读后感1
<你的灯亮着吗>这本书主要讲了几个实际的问题,在还没读这本书时对这本书有一定的了解,所以在读这本书时也是有一定的目的,在这本书中可以学到好多的东西,在作者分析问题和解决问题中我们可以找到好 ...

《代码大全》个人总结