![]() 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和MVP4.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. 复制、粘贴有时是有用的,虽然很多人对它有很深的成见,但是在某些方面,将它们运用好了,甚至会比你之前学到的最佳实践更加有用 |
|