软件开发201个原则笔记，持续更新中...
- 软件交付时第一个要求就是质量，不存在降低质量按时交付的情况。
- 高质量的定义有很多种，对那些压力环境中工作的用户而言，高质量意味着响应时间或高容量，对于成本敏感的项目，高质量代表低开发成本，对客户而言，高质量意味着满足他们所有的需求以及尚未感知到的需求，但是，以上是不可能同时兼容的，我们要按照。
- 生产力和质量成反比，生产力高越高，质量越低，质量越高，生产力越低，
- 要想要质量的软件就要高价钱，IBM给NASAS开发的软件每行代码1000美元，万行bug少于1个，开发人员想要提高软件质量是可行的，原则8、11、12、13、67、98、130、131。
- 项目开始的时候不去建立质量，希望先随便开发一版，然后翻新改进来提高质量是不可行的。
- 低可靠性比低效率更可怕，一段消耗大部分执行时间的程序是低可靠性的，但是可能要到系统部署很久之后才会发现，等发现的时候开发人员早就不在了，很难排查它的原因。
- 软件交付的时候，先花费20%的资源做出一个快速且肮脏的原型，交付给客户收集反馈，然后再编写需求规范来开发，可以尽早得知用户想要的是什么，以防做出来的不是客户想要的，避免资源的浪费。
- 多与用户沟通，了解真正的需求，解决真正的问题，这样的系统，用户才会使用。
- 项目为什么经常失败，因为客户和开发人员有不同的目标，比如，客户想要的是在特定的时间内完成，可以让客户对功能的优先级做排序，对于开发者，优先级高的必须完成，中级的内容完成了予以奖励，低级需求奖励非常小，延期予以处罚。
- 计划扔掉一个，反正你早晚会扔掉，说的是如果做一个全新的系统，最好花一部分资源做成第一版，维护一段时间稳定之后，再重新做出第二版替代版。
- 原型分两种，一次性原型和进化型原型，当核心功能不了解的时候做一个一次性原型，给到用户得到反馈，当了解了核心功能之后再构建进化型原型。
- 构建一次性原型，应该构建你不了解的功能，一次性原型就是为了掌握核心功能而构建的。当构建进化型原型，你应该构建已经很理解的特性，如果构建不清除需求的进化行原型，那你就错了，你离高质量的软件越来越远了。
- 如果是构建一次性原型，要越快越好，不用担心质量。
- 一个有效的低风险的软件开发方式是增量扩展型，开始的时候功能尽量简单，后面一点一点去扩展，如果一开始就是一个复杂的系统，后面增加功能的时候肯定会重构，那将会是噩梦。
- 用户看到的越多，想要的就会越多，交付给用户之前应该预想到，客户肯定会提出更多的需求，最后提前准备应对策略。
- 在软件开发的过程中，需求的改变是必然的，而且是贯穿开始与结束的，最好在排期时多加点时间来应对需求的变更，毕竟，因为需求的变更导致系统的延期是属于灰色地带，很难抽身。
- 如果有条件，尽量购买现成的软件，而不是自己从头开发，毕竟现成的软件是经过市场检验验证的，如果从头开发，不仅预算容易超值，最后为了赶进度还会砍掉功能，最后实现出来的功能跟现成的功能都差不多。
- 构建好的软件，用户手册尽量简短，越简短说明软件设计的越好，没有那种快捷功能的小花招，用户其实不想花费大量的时间去学习那些小花招，还是尽量做成简单通用规范的软件吧。仅仅因为软件开发人员喜欢一种用户界面，并不意味着你的客户就会知道怎么使用，许多软件开发人员喜欢带有内置技巧的用户界面，这些技巧可以作为捷径。通常，用户需要简单，干净，清晰的用户界面，而不是小花招。
- 每一个复杂的问题，都有一个简单的解决方案，这是错误的。对说这句话的人保持高度怀疑。
- 没看懂。
- 在不同的场景使用不同的语言，比如前端用前端用vue，react，后端用java，go，设计时，设计界面用sketch，设计美图用ps。因为每一种语言或工具都有它的相对于某个领域的优势。
- 构建一个自动化场景的时候要先手动操作一次。一名无纪律的工程师配上绝好的工具，会变成一个危险的无纪律的工程师，使用一个工具时一定要有基本的纪律，理解并遵循这个工具的恰当使用。不要无纪律的使用，以免发成过载现象。
- CASE工具（能够自动覆盖软件开 发生命周期各个阶段的集成的、减少劳动力的工具）可以提高10%-20%的开发效率，可以尽情使用，但是要注意，也许会发生买来的工具没人使用的情况，这并不是工具不好，而是没有使用好。
- CASE工具可以让优秀的工程师更高效，平庸的工程师最多只是减少一些质量差的软件，不会让平庸的工程师变得优秀。
- CASE工具是很贵的，应将他们做成业务成本的一部分，如果不够买，就要考虑后果，比如更低的成产力，更高概率客户不买账，更好的人员流动性。
- 知道何时使用跟知道如何使用同样重要，知道如何使用一项技术不会让你成为一个优秀的工程师，但是知道何时使用，才是一个好的工程师。不要为了使用而使用一项技术。
- 只要需求目标实现了，就可以停止下来，不要做更多无用的开发。每一个例子都由一系列步骤组成，当完成步骤的一半，发现问题解决了，就可以停止了，后续步骤的执行是不必须的，可能会对后续使用带来危害。
- 没看懂。
- 自己写出bug不用害怕，也不用表现出攻击性和藏着掖着，应该广而告之，避免其它同时犯同样的错误，和调整下次翻错误时的心态。
- 新技术的出现肯定会鼓吹和夸大它的性能，请保持警惕，不要太相信，要仔细阅读，充分实验之后再考虑是否采用新技术，避免做小白鼠。
- 时刻了解新技术，多看杂志周刊，参加重要会议，那些看似没用的PPT和与参会人员交流，其实是非常重要的。
- 不要排斥领导或者客户让你写文档，要求越高越好。
