人月神话
加入新的成员不一定意味着生产效率的提高
当团队的生产力下降的时候，当deadline逐渐来临的时候。我们能做的是两条道路，一条是增加个人工作时间，另一条是增加人手。
增加个人工作时间，意味着加班，在中国的大环境下，这样的选择是不可避免的。
当然如果你的领导愿意为你分配人手，你也可能会觉得这并不是一个好的决策。
因为Fresh Man往往会拖累你的工作，让你不经感叹到，还不如自己加班好了。无论是沟通的成本，还是培训的成本，当然这也依赖于任务是否易于分解(要求设计上的松耦合)。
编程的乐趣与苦恼
编程为何有趣？创建事物的纯粹快乐，并且事物总是按照预期一样完美(理想是骨感的)进行！事物对他人有用的被需要感！学习其带来的非重复性乐趣！ 编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。
编程为何苦恼？必须追求完美！对他人的依赖，理论上他人的程序应该是完整的，但是现实中往往设计的并不合理，甚至是拙劣的！Bug的寻找，绵绵无绝期！。
这就是编程，一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
对于许多人而言，其中的乐趣远大于苦恼。 respect!👯👯
当然如果你是一个更有追求的程序员，那你应该知道，编写整洁的代码的程序员就像是艺术家，他能用一系列变换把一个白板变成一副优雅的绘画，而不是一团混乱的鬼画符。
当别人读到你的作品的时候，他们会像见过精美的工艺品或者设计精良的汽车一般，漏出会心一笑。
需要什么样的文档
1.目的。主要的功能是什么？开发程序的原因是什么？架构图？ 2.环境。程序运行在什么样的机器、软硬件和操作系统上？ 3.范围。使用的范围？面向的目标群体？ 4.实现功能和使用的算法。精确的描述系统做了什么？流程图？数据流的流转？ 5.测试用例和使用文档。
贵族专制统治
程序员与架构师，他们之间的关系是一种无需任何歉意的贵族制度。
一位Leader的团体架构提供了一种方法-既能获得少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，并且最大程度的降低了沟通的成本。
程序员的数学-基础
0 和 1
0 虽然没有实际的数量，但是却起了占位的作用，有了占位符才会产生模式，有了模式才会生成简单的规则。而规则就是我们一直探寻的东西。
简单的例子是：
- 没有计划的计划(0 计划)
- 没有药效的药(0 药)
逻辑 true and false
逻辑是消除歧义的工具，良好的逻辑意味着，兼顾完整性和排他性。
完整性要求没有遗漏，排他性要求不重复。这就要求我们注意研究边界值。
找到规律，使用余数
除法是分组，余数是确定它属于哪个组。
- 判断奇偶 8/2=4 — 0 (0 是偶数组) 9/2=4 — 1 (1 是奇数组) 2.今天是星期天，100 天之后是星期几？ 100/7=14 — 2 (2 表示星期 2)
当我们想要“详细的研究”事物时，我们往往容易陷入“想正确把握所有细节”的思维。但是较之“正确的把我”，有时“准确的分类”则更为有效。
只要发现了周期性和奇偶性们就可以将大问题转换为小问题，其中余数是一个重要的武器。
对于难以处理的庞大数值，只要发现了其周期性，就可以利用余数，简化问题。
奇偶校验
数据为 8 位，传输方加入一个校验位，使其中的1为偶数个或者奇数个。
接收方根据与传输方协定的1的个数偶数或者奇数，对其进行校验，校验1为偶数个或者奇数个，若一致，则数据未受到干扰。
数学归纳法
1.若P(0)成立 2.若P(K)成立 则P(K+1)成立 1.2满足，可推出P(n)成立
通过基底和归纳2个步骤，就能进行有关无穷的证明。
排列组合
数数，就是不遗漏、不重复的去计数。
对于无法直接计数的庞大数据，先缩小规模找到问题的本质，再将其抽象化，就能得到答案。
递归
递归，是一种奇妙的思考方法，它 使用自己来定义自己。这在编程和数学中都是非常常见的。
我们在遇到递归的时候，我们一定会有这样的一个想法，“在重复做相似的事情”。之所以会产生这种感觉是因为我们有 “发现规律的能力”。
观察内部是否存在相同结构的小规模问题。
指数爆炸
如果问题中包含指数爆炸，就不能简单的采用“一个不漏”的方法来解决问题。
二分法就是合理有效的利用了指数爆炸的方法。
对于指数或许我们是无法直接处理，但是我们对其进行取对数的操作之后，就方便处理了。
不可解问题-不可解的数、无法编写的程序
我们能用计算机来解决的问题是无穷的。但是，这个无穷也只是可数的。所有问题的集合是比可数更多的无穷，那里是我们无法企及的世界。
何为解决问题
在思考解决问题时，我们经常会使用 “先用较小的规模进行试算” 的方法。用较小的规模进行尝试，可以发现规律、性质、结构、循环以及一致性等，从而认清隐含在问题中的模式。否则，及时解决了问题，也只是知其然不知其所以然。
在一般的编程中，程序员通常不需要掌握很深奥的数学知识。不过，认清并简化问题结构，总结出具有一致性的规则等，对于程序员来说就是家常便饭。 不要觉得“不擅长数学”就漠然处之，而要想到“数学妙趣横生”，给每天的编程都注入数学的思维方式。
概率是面积
矩阵就是映射
代码整洁之道
如果每个例程都让你感到深合己意，那就是整洁的代码。
糟糕的代码就像是沼泽(wading),灌木丛生、暗布陷阱的沼泽地。我们拼命像寻找出路，但是目光所及，只是越来越多的死气沉沉的代码。
这样我们要不是被其牢牢束缚，最终崩溃。要不是狠下决心，从头再来。不论哪一种，都将使我们付出大量的精力。
那么为什么 要写糟糕的代码呢？为了赶进度？水平不够？期待早早结束？这些事情我们都做过，我们都知道自己创造了一片混乱，但是我们大多数人都决定弃之不理，走向新的一天，我们暗自给自己下定决心，下一次！下一次，我们绝不会写出这样糟糕的代码。然而如果我们这次不回头，next equals never。
丑陋的代码是为什么产生的？
程序员态度的缺失！！！！
我们抱怨需求变化背离了初期设计；我们抱怨进度太紧张，没法好好干活；我们抱怨他人的代码不整洁，我们把问题归咎于了愚蠢的经理，苛求的用户，难堪的队友。
不过，亲爱的，We Derserve It。我们就像是医生，病人提的要求，病人家属提的要求，确实我们是应该参考的，但是如果我们全部follow了他们的要求，那么这就是一种不专业的态度
整洁代码来此开始
@author
当我们在javadoc中为自己署下名字后，我们就要意识到 我们有责任与读者做良好的沟通。
童子军规则
让营地比你来时更干净
每次入，都比每次出更干净，那么代码就会越来越干净。清理并不一定要太大，也许只是改变一个变量名，拆分一个过长的代码，换一个更确切的函数名，清理一个嵌套if语句。
命名
命名之处，随处可见，我们给变量、函数、参数、类和package命令。
我们给目录命令，我们给jar、war命名，我们不断命名，不断命名。
哈哈，var1,var2,var3,每次看到源码中有这样的命名方式，我总是感慨，原来大牛和我一样，受困于命名。那么我们有办法，为自己的代码取一个好名字吗？
- 名副其实
- 避免误导
- 读的出来的名称
- 别乱定义数字，字符串，对应的常量更容易寻找
函数
一个函数只完成一件事情(单一权责原则)，但是这个事情里面所有的语句又必须是在同一个抽象层。 当面临的情况发生改变的时候，函数内部不能出现改变，引入抽象工厂是一个非常的手段(新类型的增加，导致函数内部机械的添加，违背了开放闭合原则)。 没有参数>1个参数>2个参数>3个参数>可变长参数，所以当你参数过多的时候，请使用参数对象，因为多个参数往往是某个概念的一部分。 重复是软件中一切邪恶的根源。许多的原则与实践规则都是为了控制与消除重复而创建的。无论是面向对象的将代码集中到基类，还是面向方面编程、面向组件编程多少都是消除重复的一种策略。 函数不是一出生就是完美的，并不是一开始就是按照规则写函数的，我们的初稿或许是简陋无序的，太多的缩进和嵌套循环，过长的参数列表，名称的肆意，重复的代码等等，它需要人去斟酌推敲，分解函数、修改名称、消除重复等，直至达到自身满意的程序。
注释
哇哦，这样定义注释真的是🔥.
注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败，注释并没有办法优化你的代码。
注释总是一种失败，我们总无法找到不用注释就能表达自我的办法， 所以注释出来了，这并不值得庆祝。当发现自己需要写注释的时候，再仔细想想是否可以不用注释，用代码来表达。当你无奈写注释的时候，你都应该清楚地认识到自己表达能力上的不足。
注释掉的代码也是令人抓狂的东西，我不知道他有多旧，不知道他是否还有意义，没有人敢删除它，因为大家都假设它是存在价值的。由此这些腐朽的代码，随着时间的流逝，成为了代码里面的孤岛，它调用不存在的函数，它使用已经改名的变量。如果你看到了注释掉的代码，请直接删除它，当别人需要它的时候，告诉别人去代码控制系统中去找他。
格式
代码格式关乎沟通，沟通是开发人员的头等大事。 统一的代码格式约束人的行为，从而建立了人与人之间能够准确沟通的局限。 每个程序员都有自己喜欢的格式风格，但如果是一个团队的话，那么听老大的话就是最好的选择，以让软件具有一以贯之的风格。
错误处理
别让你的异常、错误的处理，搞乱了你的代码逻辑。要学会优雅的处理错误、异常代码。
码农翻身
通俗易懂，生动形象的将整个计算机世界以一个一个的故事展现在你眼前，或许有那么一点不够严谨，但却足够的有趣。