mod

极客时间专栏/软件工程之美/课前必读/学习攻略 | 怎样学好软件工程？.md

@@ -0,0 +1,121 @@
+<audio id="audio" title="学习攻略 | 怎样学好软件工程？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3b/85/3bbbd7987ac77ad25aceeef4fcd9b785.mp3"></audio>
+
+你好，我是宝玉。
+
+关于“什么是软件工程”和“为什么要学软件工程”，我在开篇词中已经简单介绍过了。总结来说：软件工程是软件行业知识体系的内核。无论你想走技术路线，还是转向做管理，想要走的更快更稳，那就绕不开软件工程。
+
+在正式开始学习前，我们先来聊聊应该如何学习软件工程。你要先知道，软件工程学科的“知识树”结构是什么样的，才能更好地理解每个知识点和彼此间的联系。
+
+## 软件工程知识架构全景图
+
+首先你要明确，当我们谈软件工程学时，究竟在讲些什么呢？
+
+在《软件工程——实践者的研究方法》这本经典软件工程教材中，作者Roger S.Pressman画了一张图，高度概括了整个软件工程的核心知识。
+
+<img src="https://static001.geekbang.org/resource/image/5b/dc/5b3yy6642bace3928782e978de576fdc.jpg" alt="">
+
+由图可见，“质量焦点”在最底层，这不难理解软件工程是为了应对软件危机诞生的学科，其目标就是为了要**聚焦于质量，构建和维护高质量的软件。**可以说，聚焦于质量就是软件工程的基石。
+
+**那“过程”指的是什么呢？**
+
+要构建高质量软件，则要解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动有效地组织起来。而软件过程，就是在软件项目的生命周期内，也就是软件从诞生到结束这期间，在开发与构建系统时要遵循的步骤。
+
+有两种过程框架你一定经常听到，那就是瀑布模型和敏捷开发。这是在软件工程多年的发展中，逐步形成的两种主流的软件过程指导框架。
+
+**那么，何为“方法”？**
+
+方法是指在整个过程中，如何构建系统的方法学。比如说，如何分析用户需求；如何对产品进行测试验收；如何进行系统架构设计等。
+
+**知道了过程，掌握了方法，那么具体落到操作层面，就会涉及到工具的使用。**
+
+我们需要工具来辅助方法的执行，提高效率。通过工具，可以把一些手动的工作自动化，比如自动化测试工具，自动构建部署工具；通过工具，可以帮助把一些流程规范起来，比如Bug跟踪、源代码管理；还可以通过工具，帮助提高编码效率，比如各种编辑器IDE、各种高级语言。
+
+如果现在再回头总结一下，软件工程的核心知识点，**就是围绕软件开发过程，产生的方法学和工具。**
+
+你可以用一个简单的公式来理解软件工程，那就是：**软件工程=工具+方法+过程。**
+
+根据这个公式，我将软件工程的知识结构做成了思维导图，方便你对知识点有更好地理解，高效学习。
+
+<img src="https://static001.geekbang.org/resource/image/99/99/9926b79ecc91a4e664933c587f630199.jpg" alt="">
+
+## 如何学习软件工程？
+
+我给了你软件工程学的公式，也对软件工程有了更为全面的了解，看起来软件工程学很简单，但这些内容一下子要吃透也不容易。在开篇词中，我介绍了会从“道、术和器”三个维度去讲这个专栏，这其实对应了学习软件工程的四重境界。
+
+**学习软件工程的四重境界**
+
+**第一重：用器**
+
+“器”就是工具，工具规则简单，上手就可以用，也很快就能看到效果。比如，原型设计工具可以帮助你确定需求，持续集成工具可以帮助你简化测试和部署的流程。对工具的学习是最为简单的，也是最基础的。
+
+**第二重：学术**
+
+“术”就是方法，学会方法，你就能应用方法去完成一个任务，例如用需求分析的方法，你去搞清楚用户想要什么，用Scrum去组织项目开发过程。
+
+掌握了术，甚至是可以脱离器的，例如你没用原型设计工具，你用纸和笔，用白板，一样可以去沟通确认需求。
+
+**第三重：悟道**
+
+“道”就是本源，软件工程知识的核心思想和本质规律。就像敏捷开发，本身并不是一种方法，而是一套价值观和原则，领悟了这个道，就可以成为你在处理项目过程中各种问题决策的依据。道是可以产生术的，你掌握了敏捷开发的道，你就可以领悟出Scrum、极限编程这样的术。
+
+**第四重： 传道**
+
+当你能把复杂的知识通过浅显易懂的方式传授给别人，那就说明你对知识的领悟已经到了更高的境界。同时，教学也是最好的学习方式，通过传授别人知识，可以让你对知识本身有更深入的理解。
+
+## 做中学和教中学
+
+你可能会问，怎样学，才能到达以上这四重境界？我在做技术管理的工作中，经常要做一些培训的工作，在这过程中我总结了两套行之有效的方法：“做中学”和“教中学”。
+
+<img src="https://static001.geekbang.org/resource/image/38/19/38203f9726c63858c230e1947768f019.jpg" alt="">
+
+**“做中学”，是一种自下而上的学习方法，**通过实践，从使用工具到学习方法，再从方法中提炼出道。
+
+在学习本专栏的时候，你可以采用“做中学”的方式，把专栏中的知识应用起来，在实践的过程中去巩固你学到的知识，去思考背后的道。把已经积累的项目经验和软件工程的知识点关联起来，这样才能加深你的理解，学以致用，把经验和知识转化为能力。
+
+**“教中学”，是一种自上而下的学习方法，**通过教学，去进一步深入领会别人总结出来的道，去模仿推导方法，去学习如何使用工具。
+
+比如，你学习完一篇专栏文章后，把学到的知识进行输出，写成微博或博客分享出去；在公司内部讲给你的同事们听等。在教学分享的过程中，去进一步深化吸收知识内容，构建你的知识体系。
+
+**“做中学”和“教中学”，**这两种方法你可以配合起来使用。
+
+## 参考书目
+
+另外，在学习软件工程的过程中，我看过一些不错的相关书籍，在这里列个书单，供大家参考。
+
+- 《构建之法》
+
+作者邹欣是微软的研发总监，同时在多所高校进行了软件工程的教学实践，在此基础上对软件工程的各个知识点和技能要求进行了系统性整理，形成教材。也是对本专栏知识很好的补充。
+
+- 《人月神话》
+
+这是软件工程历史上的经典著作，内容发人深省，40年来一直畅销不衰，里面的观点即使到现在也不过时。这本书即使你以前看过，隔一段时间再翻看一遍，可能都会有新的感悟。
+
+- 《人件》
+
+如果说《人月神话》关注“软件开发”本身，《人件》则关注软件开发中的“人”。作者指出知识型企业的核心是人，而不是技术。
+
+- 《知行合一： 实现价值驱动的敏捷和精益开发》
+
+作者丛斌有二十多年从事软件工程教学、咨询和研究的经验，所以书写的特别接地气，文章有很多真实案例，对敏捷开发和CMMI都有很深入描述。
+
+- 《软件工程——实践者的研究方法》
+
+这是大部分高校采用的软件工程标准教材，可以作为一个参考。
+
+- 《持续交付》
+
+讲述如何实现更快、更可靠、低成本的自动化软件交付，描述了如何通过增加反馈，并改进开发人员、测试人员、运维人员和项目经理之间的协作来达到这个目标。
+
+- 《走出软件作坊》
+
+这本书生动的描述了国内小型IT企业在发展过程中遇到的一系列项目管理问题，以及作者是如何去解决这些问题的。
+
+## 总结
+
+今天，我带你浏览了软件工程的全景图，也为你讲解了学习软件工程的四重境界。同时，我也介绍了“做中学”和“教中学”这两套行之有效，并且特别适合软件工程学科的学习方法，所以希望你在后面的学习中，可以付诸行动。
+
+- **分享你学到的知识。**将你从专栏学习到的知识写成微博或博客等，分享给大家。写作是一种特别好的总结和学习方式，在你写的过程中，很多不清楚的问题就想明白了。
+- **做几次内部分享或培训。**如果你从来没做过公司内部的分享或培训，不妨迈出第一步，把你学到的知识，写成PPT，小范围地讲给你的同事或朋友。如果你已经做过类似的分享，那么就再做几次软件工程相关的。准备PPT的过程，就是你最好的学习过程。
+- **把你学习的知识应用起来。**学到的知识只有用起来才能变成你自己的经验，尝试着把在专栏中学到的知识应用到你的项目中去。多问多思考。有疑问就提出来；看到其他人问的问题，也可以去思考为什么，一起探讨问题的答案。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/课前必读/开篇词 | 你为什么应该学好软件工程？.md

@@ -0,0 +1,114 @@
+<audio id="audio" title="开篇词 | 你为什么应该学好软件工程？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9b/c4/9b920f87ea5d9968057159e4068c18c4.mp3"></audio>
+
+你好，我是宝玉，欢迎加入我的专栏，和我一起开始软件工程的学习之旅。
+
+和很多人一样，我的职业生涯是从一个自学编程的“野路子”程序员开始的。1999年，我考入西北工业大学工程力学专业，但是却对编程很感兴趣。大一的时候自学网页编程，大二开始去学校网络中心兼职，同时在外面接了很多做网站的私活。
+
+那时，虽然我的编程水平提升特别快，但是因为完全是自学，跟其他计算机科班的程序员一比，多少有点自卑感，觉得好像差点啥！在实际工作中，遇到具体的问题，我只能见招拆招，一个一个地解决。
+
+当然，因为一开始我无法从系统层面整体看事情，所以虽然问题解决了，但也总有一种疲于奔命的感觉。我曾经遇到的问题，你肯定也不陌生，比如：
+
+- 开发时没有分析没有设计，上手就写，后期难维护，加班熬夜去填“坑”；
+- 缺少理论指导，遇到新项目不能举一反三，工作很平庸；
+- 遇到需求变更这种事，除了抱怨两句客户，只能闷头做，无力反抗；
+- 做项目没计划性，想到哪做到哪，总是延期，比其他同事做的慢；
+- 不知道如何与团队协作，职业发展遇到瓶颈，无法得到晋升。
+
+那时候我不知道啥是正规做法，主要靠自己摸索。也特别困惑：科班出身的程序员是否与我有同样问题？像微软、阿里等这些大厂的程序员，他们又是怎样协调完成好那么庞大的项目？我这个“野路子”程序员面临的问题，他们又是怎么分工协作解决的？
+
+2002年初，我有幸转了专业，成为了中国第一批软件工程专业的学生，有机会系统地学习软件工程的理论知识，这解开了我的很多困惑。
+
+**软件工程学让我知道，软件项目的开发其实是一个工程，整个开发过程是可以有效组织起来的；对于开发过程的各个阶段，已经有很多解决问题的最佳实践，有很多方法来帮助我们高效完成任务；我们还可以借助工具来协助管理，提升开发效率。**
+
+如果说以前自学编程时，我还是停留在学习各种编程方法（术）上面，那软件工程开始让我主动去思考这些“术”后面的“道”，去思考软件项目中各种问题背后的原因，以及各种方法后面的理论指导。
+
+这种对“道”的思考，逐步影响了我思维方式，让我从单一的程序思维上升到系统的工程思维去看日常的问题；同时让我形成了一套自己对于软件开发和项目管理的方法论，能举一反三，指导我去灵活运用各种方法，或者根据项目特点创造合适的解决方法。
+
+当然，软件工程学的价值不仅于此。有人说程序员是吃青春饭的，因为计算机技术更新太快，年纪大了学习能力下降，就很难跟得上了。于是就有人很焦虑，会关心未来技术发展趋势如何？我怎么才能跟得上这些技术变化？
+
+亚马逊的创始人杰夫·贝索斯（Jeff Bezos）曾经在一次演讲中说：“人们经常问我，未来10年什么会被改变？我觉得这个问题很有意思，但也很普通。从来没有人问我，未来10年，什么不会变？”
+
+这个回答同样适用于软件开发领域。在软件开发领域，有哪些知识十年前很重要，现在仍然重要，未来可能同样重要？
+
+其实仔细分析，这些知识不外乎：**数据结构、算法、面向对象思想、设计模式、软件工程。**如果范围不局限于程序开发，还要算上测试、产品设计、项目管理、运维这些岗位。
+
+**你会发现，无论你是什么岗位，只要你从事软件开发相关领域，都绕不开“软件工程”，因为现代软件项目开发，多多少少都离不开软件工程知识的应用。**
+
+想象下在日常工作中，不管你用什么开发语言，不管是前端和后端：
+
+- 你接到一个开发任务，如果想开发出客户想要的功能，你是不是先要做需求分析；
+- 你接手一个复杂的、大的功能模块，是不是先要做设计，才能把复杂的拆成简单的，才能让大家一起分工去开发；
+- 你完成一个功能模块，如果要保证质量，是不是需要写一些测试代码，还要做一些功能测试；
+- 还有日常用的那些工具，像源代码管理、Bug跟踪。
+
+而这些内容，都是软件工程相关的知识，和你用什么语言无关。十几年前我开始工作时就在用这些知识，现在还是在用这些知识，未来这些知识还不会过时。
+
+换言之，这就是经典的价值，为什么说我们要学经典，因为经典就是这个行业最为本质的东西。你顺着这个逻辑想，就知道为什么大学的计算机专业要设计数据结构、算法、操作系统、软件工程这样的课程了。
+
+技术更新迭代速度确实很快，难以把握，更难以预测，但是软件开发背后的逻辑却万变不离其宗。
+
+**你只有掌握了这些逻辑，才能步步为营，不被快速发展的软件开发行业所淘汰。因为你脑袋里装有软件开发的战略，相对于赤手空拳、盲打莽撞的人来说，你更能在未来获得先机。**
+
+我经常会跟身边的朋友“安利”软件工程的重要性，但是往往都没有下文。究其原因，主要是传统的软件工程教学方法出了问题，各个知识点过于偏理论，难以和实际项目的应用联系起来，理解起来生涩乏味。导致有人误以为软件工程是枯燥、无用的。
+
+回想当初我在学习软件工程课程时，并没有觉得特别枯燥，主要归功于三点：
+
+1. 我学习前已经有项目实践经验，所以学习时，很容易能将理论和项目经历串起来；
+1. 我在以前项目中有很多困惑，带着问题再去学习，这样效率更高；
+1. 即学即用，获得正反馈。我不仅会把软件工程的知识应用在工作中，还会把日常生活中的问题当成一个项目去思考，不停练习和获得正反馈。
+
+我一直在思索，怎么让软件工程的学习，既不那么枯燥无味，同时，也具有实用性，即学即用，可以用来指引帮助我们来解决问题。
+
+这样一直到2015年，我到美国攻读计算机的硕士学位，发现美国的计算机教育确实有可取之处，例如学校会聘请企业的专家作为兼职讲师，让学生有机会了解业界最前沿的技术趋势。
+
+这些有丰富项目经验的企业专家讲师在讲课时，总能把一些知识点和鲜活的案例结合起来，和学生一起探讨这些知识点背后的历史和逻辑，让软件工程学变得易学、实用。
+
+在美国读书的经历给了我很大启发，软件工程的学习，也可以不那么枯燥。恰好我的经历也比较特殊：
+
+> 
+从自学编程的程序员到软件工程专业科班毕业；从技术开发到在微软飞信做项目管理；从程序员到技术总监；从几个人小团队到几千人的大厂；从国内公司到美国公司；从个人小项目到几千万用户的大项目；从传统瀑布模型到最新的敏捷开发。
+
+
+这些丰富的经历，帮助我更好地理解了软件工程的知识，也知道如何应用它，可以发挥最大的效用。
+
+因此，在这个专栏中，我会结合自身在软件开发中的经历，**将软件工程中的知识点和我所看到的国内外前沿的、典型的项目案例结合起来讲解，也会和你一起分享我对这些知识背后的思考。**和你一起去软件工程学中，寻找软件项目中问题的答案。
+
+我希望最终，你能把软件工程知识和项目经验有机地结合起来，转换成你自身能力的一部分。
+
+另外，在实际软件项目开发中，离不开各种工具的使用，像源代码管理、持续集成、看板、监控报警等，帮助我们更好地协作、规范项目流程、上线维护。
+
+在本专栏，我也会在穿插着介绍各种工具的用法，有哪些价值，让你在了解后能很快应用到项目中，达到即学即用的效果，提高项目开发效率、规范项目流程。
+
+我们的专栏会从**“道、术、器”**三个维度来讲解软件工程的知识内容。
+
+- “器”就是软件工程中的各种工具。
+- “术”就是软件工程中的各种方法。例如如何做需求分析？如何对需求变更做变更管理？
+- “道”就是软件工程知识的核心思想、本质规律。例如为什么要有需求分析？需求变更产生的深层次原因是什么？项目中决策的依据是什么？
+
+在专栏的模块设置上，我将它分成了三大部分。
+
+#### 1. 基础理论
+
+从宏观的角度建立起软件工程的知识结构，展现软件工程学的全景图，让你掌握从软件工程的基础概念到主流的软件过程方法论。我会帮你开始思维上的转变，去尝试用工程化的思维模式，去分析和解决工作和生活中的问题。
+
+#### 2. 项目过程
+
+我会按照软件生命周期，把知识点拆成：**规划、需求分析、设计、编码、测试、运行维护**这六个阶段，然后带着你一起去了解每个阶段要侧重做哪些事；分析每个阶段常见的问题，找到解决方法；了解各个阶段有哪些工具可以对项目有帮助，从而学会应用它们。
+
+#### 3. 案例分析
+
+在这个模块中，我会带你一起去看看这些大公司是怎么应用软件工程的。之前你可能会有疑惑，认为软件工程学很虚，我们小公司用不着，或者不知道怎么在实际项目中应用软件工程。
+
+其实软件工程的思想是润物细无声，包括微软、谷歌、华为、阿里巴巴这样的大公司早已经深得其精髓，把它用得炉火纯青了。
+
+你的公司，你遇到的大部分项目问题，都可以回到软件工程的逻辑里来解决。我会给你分享我看到的经典的软件工程案例，让你能够通过综合案例，把前面的知识融会贯通，并逐步内化为自己的基础能力。
+
+简单来说，我希望通过这个专栏，你可以从知到行，打好基本功，掌握软件工程学中涉及的方法和工具，学会举一反三，在软件项目的开发和管理过程中，能运用自如；也希望软件工程的思维，可以让你脱离技术的拘泥，有更高的格局和视角去看待工作和生活中的问题。
+
+最后，也希望软件工程学这门基础学科，真正成为武装你职业上升的盔甲。无论你想走技术路线，还是转向做管理，都能从赤身肉搏、苦钻技术却不得法的“野路子”，变得行有章法，在未来软件的快速革新稳步前行。
+
+如果你在专栏的学习过程中，遇到任何问题，或者有什么想法，欢迎留言与我交流。相信这段学习之旅，你我都将收获满满。
+
+好，那就让我们开始吧！
+
+

极客时间专栏/软件工程之美/课前必读/特别放送 | 从软件工程的角度解读任正非的新年公开信.md

@@ -0,0 +1,242 @@
+<audio id="audio" title="特别放送 | 从软件工程的角度解读任正非的新年公开信" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/13/4d45a5f63e8d483605d0562ab6fb6813.mp3"></audio>
+
+你好，我是宝玉。
+
+2019年1月，任正非的那封[《全面提升软件工程能力与实践，打造可信的高质量产品》](http://xinsheng.huawei.com/cn/index.php?app=forum&amp;mod=Detail&amp;act=index&amp;id=4134815)公开信在朋友圈刷屏了。作为软件工程专业出身的程序员，这封公开信自然是引起了我的好奇，仔细阅读之下，确实让我大吃一惊。
+
+于是，我从软件工程的角度对这封公开信进行了解读。**在我们专栏内容正式更新前，我将它作为特别放送分享给你，希望可以帮助你更好地理解软件工程。**
+
+这封信看似像八股文一般，但细看之下，可以发现作者对于软件工程的理解确实非常深刻，各种专业术语信手拈来，比喻恰到好处。
+
+我对华为的研发其实一直挺好奇的，从传统的硬件公司，到现在软硬件齐头并进，华为手机销量都已经超过了苹果，可见华为的软硬件研发实力早已处于全球领先水平。信中提到：
+
+> 
+二十年前的IPD变革，重构了我们的研发模式，实现了从依赖个人、偶然性推出成功产品，到制度化、持续地推出高质量产品的转变。
+
+
+这一句话，也揭示了华为的软件研发能做到全球领先水平的原因。
+
+华为是在1999年开始从IBM引进IPD的，到今年2019年正好20年，在过去的20年里，IPD帮助华为从游击队变成了正规军，研发队伍从几千人到几万人，软件产品也覆盖到手机操作系统、应用、云服务。
+
+我对IPD是不甚了解的，只知道IPD（Integrated Product Development，集成产品开发）是一种产品开发方法，但如果说软件产品的开发方法，我是比较熟悉的，那就是软件工程。
+
+任正非发出的这封信的大背景也很特殊，2018年中美贸易战开始，中兴、华为首当其冲成为美国开刀的对象，跟风站队的澳大利亚、新西兰、英国也跳出来抵制华为，说华为不安全，可能含有间谍软件，窃听国家机密。这帽子一扣是很难扯清的，这就是为什么整封信从标题开始，一共17次提到两个关键字：可信。
+
+只有让客户觉得华为的产品“可信”，华为才能尽快走出这场危机，那么怎么才能做到可信呢？
+
+如果你是餐厅老板，有人造谣你的厨房脏乱差，员工上完厕所不洗手，你怎么办？最好的办法自然是用先进的管理流程，并且让整个做菜的过程尽可能公开透明。
+
+所以信中有这样一句话：
+
+> 
+我们要转变观念，追求打造可信的高质量产品，不仅仅是功能、特性的高质量，也包括产品开发到交付过程的高质量。
+
+
+要转变观念，不再只认结果的质量，还要追求过程质量了！而如何追求过程质量呢？那就是要“全面提升软件工程能力和实践”。
+
+如果信到此为止，也就是个普通官方“八股文”。领导们嘛，可不就是喜欢指个大方向，说你们要用软件工程，要实施软件工程，至于怎么用，那是你们的事情，毕竟做领导的哪有几个真的懂软件工程，难得的是这封信居然有很多具体怎么做的细节内容。
+
+以下，我带你看看这封信都提到了哪些具体到操作层面的问题。
+
+## 1. 软件项目管理金三角
+
+先看这一句：
+
+> 
+我们各级管理者和全体员工都不得以进度、功能、特性等为理由来降低可信的要求，确保可信的要求在执行过程中不变形。
+
+
+振聋发聩呀同志们，热泪盈眶呀！生活中有多少次这样的情况发生：三个月的项目，老板说你一个月就要给我做完；做到一半的项目，PM说这个功能很重要，我们要加上去。最终怎么办？牺牲质量呗！又想要马儿跑得快，又想要马儿不吃草，天底下哪有那么好的事情。
+
+软件工程里面早就告诉我们了：时间（多久可以完成）、范围（需要实现多少功能）、成本（花多少钱）这三个要素直接决定了产品的质量（产品的质量，客户的满意度）。
+
+<img src="https://static001.geekbang.org/resource/image/7f/f7/7fa5c8351b4590a2bc8a482955c133f7.jpg" alt="">
+
+希望各位老板别光学乔布斯，也学学任正非！想要员工天天加班，还想着少发工资，还要产品质量好，做得快，这不现实呀！
+
+<img src="https://static001.geekbang.org/resource/image/f5/cf/f5bb522b7fd25d6d7738642e4c922ccf.jpg" alt="">
+
+首先得明白一个最浅显的道理：想要“多、快、好、省”都占着，这是不存在的，你只能选两样。想要便宜还想要质量好，那就得等；想要快还想要质量好，那就得多花钱；要想便宜做的又快，那就得接受质量差！
+
+## 2. 自我精进
+
+2018年底，程序员被企业裁掉的不少，很多程序员开始担忧起前景来。关于这一点，这封信中也提到了一些指导意见，如果你能达到以下要求，应该是不必担心裁员的。
+
+> 
+我们要从最基础的编码质量做起，视高质量代码为尊严和个人声誉。代码就像是高楼大厦的一砖一瓦，没有高质量的代码，可信的产品就是空中楼阁。我们要优化并遵循公司各种编程规范，遵从架构与设计原则，熟练使用各种编程库和API，编写出简洁、规范、可读性强、健壮安全的代码。
+
+
+这一段是说给我们程序员看的，这其实也是对程序员的基本要求，大家看看自己，看看身边，真能做到的有多少？像我一样觉得自己还做的不够好的，咱还是努力学习吧，多练练，多用点心肯定更没问题的。
+
+## 3. 关于架构
+
+讲完了程序员的自我精进，信中又开始说架构师了：
+
+> 
+我们要深刻理解架构的核心要素，基于可信导向来进行架构与设计。
+
+
+看到没有，又提到可信了，架构设计的时候，别再天马行空，啥新酷用啥，啥流行用啥，一定要有“可信导向”，架构设计目标先搞清楚。
+
+然后是细节：
+
+> 
+在确保可信的前提下，要在性能、功能、扩展性等方面做好权衡；慎重地定义我们的模块与接口，真正做到高内聚与低耦合；我们要遵循权限和攻击面最小化等安全设计原则，科学设计模块之间的隔离与接口，提升安全性；低阶架构与设计要遵循高阶的架构与设计原则，在充分理解原有架构与设计的情况下，持续优化；我们要熟悉各种设计模式，重用公共成熟组件和服务，避免重复劳动。
+
+
+- “高内聚与低耦合”，这是讲架构设计时，让模块之间做到高内聚与低耦合。
+- “权限和攻击面最小化”，这是讲架构设计时，要注意对安全的防范，权限要控制好，暴露出来的入口要小，做好防范。
+- “重用公共成熟组件和服务”，不要浪费时间在造轮子上了，多重用现有的组件和服务，甚至要提取公共的组件和服务。减少重复劳动，提高效率。
+
+你看，多么浅显的道理，一看就明白，但要做到可不容易！
+
+## 4. 技术债务
+
+华为这些年高速发展，早些年为了追求速度肯定也没少走捷径，这些年下来，也肯定没少欠技术债务，现在也是一个从追求速度到追求质量转型的契机。
+
+所以信中说完架构开始讲技术债务了：
+
+> 
+我们要重构腐化的架构及不符合软件工程规范和质量要求的历史代码。我们知道，再好的架构，其生命力也是有限的。随着时间的推移、环境的变化以及新技术、新功能特性的引入，架构也会腐化。面对腐化了的架构，要毫不犹豫地去重构它。同时主动以可信设计原则为导向，去重构不符合软件工程规范和质量要求的历史代码，提升软件架构的生命力。
+
+
+我们都知道，没有万能的架构，只有适合当时需求、当时技术条件和人员的架构。时间推移了，很多架构就满足不了要求了，就需要重构。
+
+作为80后，小时候其实生活挺艰苦的，那时候我们穿衣服都讲究的是：“新三年，旧三年，缝缝补补又三年。”架构也一样嘛，不满足需求，我们先修修补补，真要重构挑战还是不小的，但是不去做的话，它会一直成为发展的障碍。
+
+这封信也算是推了一把：“面对腐化了的架构，要毫不犹豫地去重构它。”当然你重构，也不要忘记“可信”这个根本目标，“同时主动以可信设计原则为导向。”
+
+其实Google在这方面已经走在前面了，一直鼓励重写代码，任何软件每隔几年就重写一遍，这样可以优化代码，采用最新技术，去掉一些没有价值的功能，最重要的是让新员工得到锻炼，保持高昂的斗志。不知道关于这点，华为是不是在向Google学习。
+
+## 5. 安全性
+
+这些年，互联网发展很快，但是安全事故却层出不穷：开房记录被泄露、密码被泄露、比特币被盗……这暴露出业界的普遍问题，对安全的重视度不够。
+
+所以信中也不止一次提到安全问题：
+
+> 
+公司已经明确，把网络安全和隐私保护作为公司的最高纲领。
+
+
+> 
+我们要深入钻研软件技术，尤其是安全技术。
+
+
+> 
+我们要遵循权限和攻击面最小化等安全设计原则，科学设计模块之间的隔离与接口，提升安全性
+
+
+> 
+“编写出简洁、规范、可读性强、健壮安全的代码。
+
+
+要打造一个安全的软件，就是首先要有安全意识，然后要懂安全技术，在整个开发过程中要从架构设计、代码等方方面面去注意。
+
+## 6. 技术是工具
+
+这些年，开发界一直有些不好的风气，就是都认为自己的技术是最牛的，写后端的看不上前端的，用Angular的看不上Vue，写PHP的认为自己的语言是全世界最好的，做开发的还看不上做测试的。
+
+但是这封信中有一句话，大家不要忽视，“软件技术是我们打造产品的基本工具”，技术只是工具，只是我们用来打造产品的工具！
+
+> 
+技术是否先进，技术选择是否合理，将决定我们软件的高度。
+
+
+技术的选型，不仅要看技术是不是先进，还要看它是不是适合当前的产品项目。并不是什么技术很新酷，就用什么！
+
+> 
+我们要深入学习架构与设计、编码、测试、安全、可用性、性能、维护性、体验等技术，并科学运用这些技术。
+
+
+既然技术只是工具，那么我们就没必要给自己设置各种技术壁垒障碍。
+
+如果开发就只学编码，测试就只学测试，认为安全问题，那应该是搞安全的人的事，这样的话是非常不利于团体协作的。
+
+每个人都能在一个领域深入地钻研，同时对其他领域有一定了解，对个人、对团队都是非常有利的一件事。这样的话，也不需要DevOps这种为了兼顾开发、测试、运维三种角色而存在的工种。
+
+## 7. 一致性
+
+我们做软件开发工作的人都知道，一致性很重要，然而现实中这样不一致的例子却比比皆是：
+
+- 从客户的需求，到最终的实现，总是差别很大；
+- 我们良好的设计，在编码实现的时候，因为赶进度、开发人员偷懒等各种原因绕开设计，抄近路，最后设计和编码无法一致；
+- 我们在项目初始的时候制定了很多规范，却总是不了了之，难以执行；
+- ……
+
+通常是一步错步步错，就像下面的秋千图：客户想要一个给三个孩子玩的秋千；产品经理以为就是一个板子加两绳子就行；架构师发现除非把树截开，否则秋千没法荡起来的；程序员以为用绳子和板子连一起就完事了；而真正满足客户需求的，也就只要在绳子上挂个轮胎而已！
+
+<img src="https://static001.geekbang.org/resource/image/2a/70/2a196741845cc6533716f7ff66fa3c70.jpg" alt="">
+
+一致性在软件开发领域，一直都是理想美好而现实却很残酷，信中也提到：
+
+> 
+我们要遵守过程的一致性。遵守适用的法律法规、遵循业界共识的标准、规范，确保规范到实现的一致性、代码到二进制的一致性。架构要符合架构原则，设计要遵循设计模式，代码要符合编程规范，最终做到需求与实现一致，达成各项对客户的承诺。我们只有脚踏实地做好每一步，才能真正打造出可信的高质量产品。
+
+
+无论这个目标有多难，但是从“遵守过程的一致性”开始，在每个阶段都去做到一致性，“脚踏实地做好每一步”，还是有希望能做到“真正打造出可信的高质量产品”。
+
+## 8. 改变习惯
+
+在实施软件工程的过程中，有两个难题，一个就是转变思想，另一个就是改变习惯了，这种改变的过程也一定是很痛苦的。
+
+> 
+为此，我们要改变行为习惯，追求精品。我们要开放透明、积极和勇于揭示问题并主动推动改进。软件开发是一种创造性和艺术性的工作，需要充分发挥我们的聪明才智和潜力。我们要改变只重视功能结果、不重视代码质量的行为习惯，要严格遵守软件工程规范；改变被动的修修补补；改变碎片化知识获取，主动去学习提升并贡献经验、代码，形成共享知识库。我们需要改变的行为和习惯还有很多，对绝大多数人来讲都将是一个痛苦的转变过程，会脱一层皮，但我相信大家能够迎接这种挑战。
+
+
+从事软件开发工作越久，恐怕养成的坏习惯就越多，信中列的几条都很有代表性：
+
+- “只重视功能结果、不重视代码质量。”
+
+功能实现完了就完事了，质量那是 QA 的事。这种坏习惯不改,质量是很难有保障的。
+
+- “不遵守软件工程规范。”
+
+软件工程的各种规范不是约束，也不是摆设，而是实实在在为了团队整体更好地协作。对于定好的规范，要严格执行，不合理的规范，也要提出来一起改进。
+
+- “被动的修修补补。”
+
+为了能继续凑合，继续修修补补，而没有考虑重构改进，也是一个不好的习惯。
+
+- “碎片化知识获取，不主动去学习提升。”
+
+在现在的信息时代，碎片化的知识获取是容易的，但是像软件工程这种知识，仅仅通过碎片化的学习还是不够的，必须主动的，系统的去学习，虽然这个过程会很辛苦，但是非常有必要。
+
+- “不愿意贡献经验、代码，不去形成共享知识库。”
+
+很多人不愿意去分享知识和经验，有的是因为太懒，有的是觉得没什么好处。但是分享本身就是学习和提升的最好手段。知识库这种事不仅是对别人有帮助，对自己也是一个特别好的学习精进的过程。
+
+想象下你新加入一个团队，如果这个团队有很好的知识库，你可以通过知识库，很快上手工作。同样的，如果你把你的经验写到知识库，后面的新人也可以从你的分享中受益。
+
+## 9. “软件工程”和“质量工程”需要依靠架构技术
+
+> 
+“软件工程”和“质量工程”需要依靠架构技术，而不是依靠CMM和QA管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。
+
+
+所有的涉及到的管理问题，最终都要归结到人管理还是制度管理的问题上，软件项目管理也不例外。如果过多的依赖于人的管理，那么项目经理的职责就太重了，优秀的项目经理本身就是稀缺资源，最终会变成瓶颈。
+
+所以通过架构技术和工具，把管理流程落实下来是一个非常好的方式。有两个例子可以很好地说明这点。
+
+早些年软件服务规模庞大、模块耦合度紧密，所以需要一个庞大的开发团队，团队一大，沟通成本就高，进而管理成本很高。后来微服务这种架构提出后，将大的服务拆成小的服务，整个组织也从大项目部门拆分成各个小组，各小组可以独立更新维护。
+
+另一个例子是，以前单元测试和代码审查还有自动部署很难执行，后来借助源代码管理工具和CI（Continuous integration，持续集成）工具，就可以很容易地进行代码审查，并且可以确保单元测试跑通过后才进行部署。
+
+这一点其实信中也有体现：
+
+> 
+我们将全面强化以Committer角色为核心的代码审核和提交机制，代码经过更加严格和系统的审核才能合入版本。为此我们将建立一支更高水平的Committer角色群体，负责软件架构的看护、代码的审核和提交，整体保障合入代码的高质量。我们要变革考核机制，要让架构设计好、代码写得好的人脱颖而出，对编程能力不满足要求的人给予帮助和培训。但任何人如果编写的代码长时间不能合入版本，将会被团队抛弃。
+
+
+## 10. 软件工程就像一个国家的农业
+
+> 
+软件工程就像一个国家的农业，是最基础的设施！（出自：蓝血题记）
+
+
+看到这句时，我很感动。这些年软件工程被提起的其实不多，大家关注更多的是各种新酷的技术，而对于这种软件开发最基础的理论视而不见。
+
+还有人一提到软件工程，就马上说软件工程不是银弹。软件工程从来不说自己是银弹，就像现代医学，也不会号称自己包治百病，它只会不断改进，对症下药。
+
+好，这就是我对这封信的全部解读，我希望它能帮助你更好地理解软件工程，认识到软件工程的重要性。
+
+如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。