读程序员的制胜技笔记01_入门.png

1. 在实战中，什么最重要

1.1. 工作产出相当重要

1.1.1. 通常没有人会真的关注你的那些优雅设计、精妙算法，或者是高质量代码

1.1.2. 你的同事才不想优化、维护你的代码，只盼着你的代码能够运行，并且容易理解、维护简单

1.1.3. 他们关心的只是你能在规定的时间里出多少活

1.1.4. 团队的总产出要比团队中的任何一个人的产出都重要

1.2. 设计非常重要

1.2.1. 首先要有一个粗略的想法，其次是设计

1.2.2. 好的设计不一定非得摆在台面上，也可以保存在你的脑海里

1.2.3. 好设计模式或好算法能提升你的产出

1.2.3.1. 不能提升产出的东西就是没用的东西

1.2.3.2. 几乎一切都可以被赋予货币价值，所以你的一切行为都能够用产出来衡量其价值

1.2.4. 可以用糟糕代码来获得高产出，但仅限于项目不需要进行产品迭代的情况

1.2.4.1. “屎山”（糟糕的代码）

2. 实战程序员

2.1. 行规，即某个行业里最重要的知识精华

2.2. 微软在招聘时通常招两种人

2.2.1. 计算机科学专业的应届毕业生

2.2.2. 软件开发领域拥有丰富经验的业界专家

2.2.3. 如何处理模糊性，是微软招聘人员时面试的核心问题之一

2.3. 非科班出身的程序员

2.3.1. 缺少理论学习和理论在日常编程工作中的正确运用经验

2.3.2. 经过长时间的积累学会了有用的算法

2.4. 科班大学毕业生

2.4.1. 理论知识丰富，但是缺乏实践

2.4.2. 有时也缺乏对自己所学知识的质疑态度

2.4.3. 在学校里，你不是根据知识的重要性来学习，而是跟着人家设计的路径来学习

2.4.4. 你不会知道，某些知识在竞争激烈的行业中会有多大用处

2.4.5. 时间不等人，按部就班地顺着时间线学习是不现实的

2.4.6. 经过长时间的积累体会到再好的理论在实践中也常常会有不管用的情况

2.5. 实战程序员

2.5.1. 他们所拥有的那些业界经验

2.5.2. 被提出无理要求的老板“折磨”出来的

3. 杰出实战程序员

3.1. 善于沟通，能够提出有建设性的反馈，同时也能虚心接受别人的意见

3.2. 懂得质疑

3.2.1. 常常会自省，并质疑那些被广为接受的观点

3.2.2. 对这些观点的解构能够让你看得更清楚

3.2.3. 批评一门技术并不代表这门技术没有用处

3.2.4. 技术批评能扩大你的眼界，让你能够鉴别出在某些应用场景中更合用的技术

3.3. 结果驱动

3.3.1. 结果导向

3.3.2. 为了得到结果可能意味着牺牲代码的质量、优雅性和技术追求

3.3.3. 你要时刻反思自己在做什么，为了谁在做

3.3.4. 牺牲代码的质量并不意味着牺牲产品的质量

3.3.4.1. 如果你测试得当，并且需求写得非常明确，你甚至可以用PHP去写

3.4. 高产出

3.4.1. 有些技术是可以从别人的经验和“血泪史”当中学到的

3.4.2. 你学到的那些本领能让你写出更简练的代码，更快做出决定，这会尽可能让你少背一些“技术债”，并且会避免你以后花好多天来努力搞明白半年前你写的代码到底是一堆什么东西

3.5. 接受复杂性和模糊性

3.5.1. 复杂性是可怕的，但是模糊性更可怕

3.5.1.1. 因为它甚至会让你不知道该怕到什么程度，于是就更害怕了

3.5.2. 可以将那些看起来复杂到无法入手的问题，分解为一个个更便于管理、复杂度更低、更简单的小问题

3.5.3. 你的思路越清晰，就越能解决未知的问题

4. 现代软件开发存在的问题

4.1. 软件开发世界中充满了你不愿意看到的意外

4.2. 凡事要质疑、反思，这是有价值的

4.3. 技术繁多

4.3.1. “left-pad”的库，其作用仅仅是给字符串末尾添加空白字符

4.3.2. 由于“银弹”谬论，我们总在不断追求最佳技术

4.3.3. 大多数技术都是权衡利弊，找出折中的方案，而不是生产力的助推火箭

4.3.4. 提高效率靠的是你对这项技术的熟悉程度和应用技巧，而不是你使用的技术本身

4.4. 现代软件开发由范式驱动

4.4.1. 导致了软件开发的保守主义

4.4.2. 面向过程编程

4.4.3. 结构化编程

4.4.4. 面向对象编程

4.4.5. 多层架构的应用(n-tier application)

4.4.6. 胖客户端，瘦客户端，泛型，MVC、MWM和MVP

4.4.7. 响应式编程(reactive programming)

4.4.8. 异步编程

4.4.9. LINQ那样拥有模式匹配和不变性概念的函数式编程语言

4.5. 科技黑箱

4.5.1. 就像汽车，之前人们还可以靠自己来修理，如今发动机越来越高级，引擎的金属盖如同盖在法老坟墓之上，谁要打开它，就会被诅咒

4.5.2. 如今的技术比二进制代码的逆向工程还要难懂

4.5.3. 无条件信任某个包及其生态或者各类框架是很容易出现大问题的

4.5.4. 焦虑是因为不了解，而不是不能够

4.5.4.1. 勇于“开盒”，了解其中的细节，对于你怎样使用“盒子”也是一样的

4.5.4.2. 你真的没有必要阅读全部代码，或者浏览厚达千页的理论书，但至少应当明白某部分的功用，以及它如何影响你的项目

4.6. 代码开销

4.6.1. 框架和库是有用的抽象，通常能帮我们减少开销

4.6.2. 不能把所有决策都推给框架来定

4.7. 自扫门前雪

4.7.1. 程序员只关注自己的技术栈，对支撑这些技术栈的知识漠不关心

4.7.1.1. 饭都吃不上，哪有时间去学习呢？

4.7.1.1.1. 开发者的吃饭难题

4.7.2. 了解特定技术、库的工作原理，依赖关系是如何工作和连接的，可以让我们在写代码的时候做出更好的决策

4.8. 憎恶重复

4.8.1. 你的工作时间越少越好，避免重复的、无脑的工作

4.8.1.1. 比如复制、粘贴，或是为了做一些小更改而从头编写只有少部分不同的代码

4.8.2. 不是所有的“打杂”都没用

4.8.2.1. 复制、粘贴有时是有用的，虽然很多人对它有很深的成见，但是在某些方面，将它们运用好了，甚至会比你之前学到的最佳实践更加有用