《软件开发的201个原则》是一本富有实用价值的书籍，作者精心总结了软件开发过程中的201条原则。通过阅读该书，我深刻理解到了软件开发的复杂性和重要性。这本书对于提高软件开发人员的技能和效率具有重要的指导作用，是一本不可多得的好书。
《软件开发的201个原则》读后感(一)
Blockchain is an advanced Internet underlying technology, which does not only belong to a certain industry. 什么是量化交易机器人？ 量化交易软件特征： 1、纪律性
量化交易要求严格按照既定的逻辑进行投资决策，每个操作都是有数据和模型支持的，这样可以克服人工交易带来的情绪波动、主观臆断、恐惧和侥幸心理。比如一个每五分钟执行一次下单逻辑运算的策略，到第五分钟时，不应该出现模棱两可的情况。 2、系统性
在制定量化交易策略的时候，需要从全方位考虑交易品种、交易频率、投资周期、对冲机制、异常处理、资金容量、市场流动性、冲击成本等一系列策略系统元素，另外，需要从海量的历史数据和实时行情中捕捉到统计上大概率盈利的模型，这整个过程，是一个系统性的工程。 3、及时性
正是因为量化交易的系统性，人脑在处理这些系统元素的速度上，是比不上计算机的。信息技术的使用，使得量化策略的执行在速度上是大大优于手动交易的。 4、投资视角广
凭借计算机高效、准确地对海量信息进行处理，在所有市场里去寻找更广泛的投资机会。 5、概率取胜
1)是定量投资不断从历史数据中挖掘有望重复的规律并加以利用； 2)是依靠组合资产取胜，而不是单个资产取胜。
Many fields have begun to use this technology and apply it. Blockchain is an advanced Internet underlying technology, which does not only belong to a certain industry. Many fields have begun to use this technology and apply it
《软件开发的201个原则》读后感(二)
我是做车载软件的，有一次因为软件交付问题客户投诉到了销售老大，销售老大发了个全员邮件意思是说他对外标榜的工程能力已经被狠狠的打脸。那是我第一次听到工程能力这个词儿，但未深入探究。后来项目上陆续又出了几次质量问题，我才开始想去了解到底什么是工程能力。于是在豆瓣找了一本相关的书《代码的艺术》，那本书里提到了《软件开发的201个原则》，于是又买来读，后来发现竟是同一个作者章淼（后者是译者）。章淼察觉到了一个事情，根本上保证质量的是人，只有开发者有了工程意识，有了质量意识，才能交付高质量的软件。我粗鄙理解，一个人如果不用心做事，不管拥有什么学历，掌握什么技术，熟悉什么方法，他在工作中的表现都可能都不会很好。所以在提升工业软件的综合能力上，培养一种工程意识，培养对工程能力的理解和尊重，似乎才是我们缺少的东西。 下面对我印象深刻的原则做了摘录和注解。 ◆一般原则 原则1：质量第一。 想办法提升质量是没有错的，质量第一。 原则3：开发效率和质量密不可分。 同样的条件下，高质量的产品必然需要更多的投入，效率也必然有所下降。 原则15：看到越多，需求越多。 给客户提供的式样书，写的越细节，客户提出的要求就会更多更细节，这会让自己很被动。所以在提供式样书的时候需要把握好平衡。 原则18：让软件只需要简短的用户手册。 不要指望通过用户手册让软件变得好用，好的软件不需要繁杂的用户手册来指导使用。 原则20：记录你的假设。 所有的事情都是建立在假设的基础上的，需要记录自己的假设。 ◆需求工程原则 原则43：记录需求为什么被引入 需要记录需求被引入的原因和背景，项目时间跨度较长的话，项目后期可能会忘记需求对应的原因。如果因为某些原因需要进行变更时，引入原因将是考虑因素之一。 原则46：避免在需求分析时进行系统设计 需求分析是分析需求的合理性和必要性等。如果这个需求是好的，才考虑如何实现。而不是难就不做，容易才做。 原则59：自毁的待定项 为了防止一些TBD的事项后续无人跟进，每个TBD都要有负责人以及问题解决的时间。 ◆设计原则 原则64：没有文档的设计不是设计 设计描述的是思考过程，思考过程是在人的大脑中完成的，如果设计没有落入文档，那无法证明思考过，也无法证明设计的合理性。 原则65：封装 封装不但可以使使用更加便捷，只要调用一下外部接口就可以，无需理会内部逻辑。它还能降低发生错误的概率，因为内部的处理已经被封装不可见，所以很难影响其内部动作。 原则66：不要重复造轮子 某些功能如果之前已经设计过，那最好直接复用，不需要重新开发，任何的变动都有可能引入问题。 原则67：保持简单 要不简单到没有明显的问题，要不复杂到没有明显的问题。这句话说得可太好了。 原则68：避免大量的特殊案例 如果一个设计有很多的特殊按理，那说明设计的并不好。 原则69：缩小智力差距 软件的设计要尽量与现实世界一致，让所有人都好理解。其实万事万物的道理和逻辑都是共通的。 原则73：使用耦合和内聚 设计需要尽量做到低耦合、高内聚。 ◆编码原则 原则88：避免使用全局变量 全局变量意味着所有模块都可能影响该变量，减少了全局变量的使用，也就减少了不确定性。 原则97：代码审查 代码检查发现的错误大概占所有被发现错误的85%，对于发现错误，代码审查比测试要好得多，如果这都不能激励你进行代码审查，我不知道还能做什么。 ◆测试原则 原则111：测试只能揭示缺陷的存在 测试只能揭示缺陷的存在，并不能提升开发的质量。不要寄望通过测试来提升软件质量。在我看来，越是水平低的公司越把质量保证寄托在测试身上。 原则113：成功的测试应当发现错误 测试没有发现缺陷并不是什么好事，如果软件没有问题也就不需要测试了，测试的目的就是为了找出缺陷。所以，有的公司会把验证出的bug数量作为测试人员的KPI。 原则114：半数的错误出现在15%的模块中 Bug的分布也有二八法则，分析Bug分布对管理Bug来说很重要。 原则117：测试不正确的输入 不要只测试正确的输入，因为我们无法控制软件会被如何使用，需要测试不正确的输入。 原则119：大爆炸理论不适用 不要存在侥幸心里，认为可以跳过某些环节，即节省时间还能保证质量。不信你可以试试，跳过单元测试直接集成测试，临时性的时间会节省，但后面擦屁股成本恐怕高的离谱。 ◆管理原则 原则142：你可以优化任何你想要优化的。 发现问题不难，想到解决方案似乎也不难，但是执行很难。很多事情只要你想做都能做成，且不说“完美解决“吧，起码的”得到优化“是完全可能的。 原则147：不要设定不切实际的截止日期 一次两次还行，如果经常设定神仙来了都完成不了的deadline，项目成员就会麻木，失去紧张感。当截至日期失去了严肃性，那它基本也就形同虚设了。 原则153：相信排期。上接原则147，相信排期就是保持排期的严肃性，设定了就必须完成。排期如果是合理的，相应人员是认可的，那我们必须相信它，而且要严格要求和监控它。 原则167：管理偏差。 项目管理就是在管理偏差，无论是对项目控制还是对外报告，问题的着眼点都应放在偏差上。进度、成本、质量的偏差自不必说，在某种程度上，沟通不顺畅，对风险预估的不准确，都是一种偏差，是一种客观现实或者主观期望上的偏差。 ◆产品保证原则 原则176：组织配置管理独立于项目管理。 配置管理是个比较繁琐和需要细致操作的工作，这也就意味着它是耗时的。很多时候，配置工作做的不好都是因为屈服了其他项目指标，比如项目经理要求当天对外发布一个版本，版本发布也许是可行的，但配置工作不一定能完成，如果配置管理员是项目组的一部分，那配置工作必然会有所让步。所以，如果配置工作可以独立于项目管理，不受项目经理的控制，是可以起到第三方的质量监控的作用的。 原则178：给所有中间产品一个名称和版本。 这个原则不单适用于配置管理，日常的项目工作中所有的文件都应该有版本号的概念，最简单的版本号就是日期，比如20231229，如果当天有多次更新可以用20231229a，20231229b等。这是一种好的习惯，对于自己和对方管理文件都有好处。 原则179：控制基线 过CCB的目的是决定是否执行式样变更，如果执行了就会修改式样和代码等一些列内容，也就是导致了基线的变更。 原则180：保存所有内容。 说白了就是所有的东西都要有记录，特别是对外的东西，比如，设计考虑/针对修改内容的测试Case和测试结果/针对影响范围的测试Case和测试结果等。那一天出了问题需要追溯或者挖坟的时候，可以拿出这些东西确认哪个环节出了问题，是设计考虑不健全，还是测试Case不足，甚至是没有测试，这些东西对于内部反省和防止问题再次发生很有作用。 ◆演变原则 原则195：维护阶段比开发阶段产生的错误更多。 维护阶段意味着项目已经量产，用我们总经理的话来说，量产后所有的动作都像是悬崖边跳舞。维护阶段的错误不一定更多，但是如果发生，一定比开发阶段更严重，所以维护阶段的所有变更一定要更严格的控制，开发阶段执行的流程一点都不能省略，甚至要更严格，也应该更加切实的执行。 原则196：每次变更后都要进行回归测试。 回归测试被定义为一种软件测试，以确认程序或代码更改没有对现有功能产生不利影响。针对修改部分做验证是必须的，但是我们通常无法肯定改动不会对其他功能产生影响，所以回归测试也是必须的。 这本书英文版出版与1995年，距今28年，而其中绝大部分原则现在依然适用。忘了第几个原则了，书中说要对硬件的发展保持乐观，对软件的发展保持悲观，我想时间给了这两条原则充分的佐证。
《软件开发的201个原则》读后感(三)
走近用户
1、软件开发的目的是解决真正的问题，了解真实需求唯一途径就是和真正有需求的人沟通
2、理解用户的优先级：
a、找到真正需要的那20%核心功能，确保建立正确的优先级
b、降低需求工程成本最简单的方法是不做，但前提是你要能知道客户是否可以接受
3、有问题及早暴露：建立联系，及时汇报风险，讨论应对的可能方式；
开发模式
一次性：关键需求不明确的时候，甚至可以考虑投20%的研发资源（一页纸PRD，不考虑任何设计、扩展性、维护性）产出一个粗糙版：原型是低风险高回报的最佳方式
演进式：关键需求明确，先把明确的部分实现；
关于需求
1、PRD：用自然语言描述，再通过形式化语言翻译，最后回到自然语言（自然语言和形式化语言相互结合，对开的分页对比）
2、需求分析要有针对性的方法（可组合）：数据密集型-->ER（实体关系图）； 实时系统-->有限状态机或状态图； 有同步难题的（存在异步并发事件的离散事件系统）-->Petri网； 决策密集型（条件相互组合、有多种决策方案）-->决策表
3、需求分析的时候不要做系统设计
4、明确超出预期时系统的行为（比如流量超过XXX，会被限流）
关于设计
1、避免拆分过渡：一个人很难理解超过7（±2）个事物
2、设计形式：模块如何向调用方通知错误，系统如何提示用户错误，如何组织数据结构，模块间的通信机制，文档标准等等；
3、上线后最大的成本是维护：可维护性对架构选择来说比算法和代码结构更重要
4、算法基础：算法复杂度理论基础是优秀设计师的基础课
5、至少包括：打包方案（什么是什么的一部分）、依赖层次（谁依赖谁）、调用关系（谁调用谁）、进程组织；
6、灵活复用：a、先问下团队的同学，“有没有实现过XX功能的模块（接口）”；b、找开源的
关于编码
1、设计和需求未达成一致前，要坚定地拒绝写代码：方案的变化总是比重构系统的成本要低
2、程序首先是写给人看的，互联网中最贵的资源是人力
a、避免使用特殊技巧：1、向世界展示自己的聪明；2、维护者看懂觉得写的人厉害，自己也厉害；3、职业安全感
b、避免多层嵌套：嵌套只要超过3层就会降低可理解性
c、先写文档后写代码，写代码的时候记得要有注释
3、先确保正确，再提升性能：多数项目在早期不会有很大的流量和性能压力，重要的是解决问题，对性能优化要有信心；
4、代码Review：好的Review能发现80%问题，花15%的研发资源，整体成本减少25%-30%
5、不只是理解语法语义：好的coder能很快学会一门语言，因为他很好的理解什么是高质量编程
6、会用只是基础，只有知道什么时候用，你的技术才是进步了
关于测试
1、开发不要给自己的系统做测试计划和具体测试：开发时候犯的错，测试时候会再来一次
2、方法约定：
a、黑盒测试和白盒测试互补且缺一不可；
b、不要在单元测试之前集成：一旦集成有问题反而更加难查
c、压测不要漏：系统是不能控制所处的环境的，但你也不想软件因此崩溃
2、覆盖率和通过率缺一不可：除非你确定测试用例很好的覆盖了需求，否则测试用例通过百分比没有意义
关于管理
1、不能完全依赖“少数优秀的人”，如果人走了？所以不能完全极端，要适中配比人员
2、员工觉得要跟你汇报的事情，至少是他认为重要，否则他不会告诉你；
3、对症下药：通过倾听+试验，搞清楚激励个人的时候哪里用萝卜哪里用大棒；
4、团队效率至上：个人效率都提高不意味着团队效率提升
项目管理
1、项目的定义是有限的资源下达成目标：过程中一定会有所选择权衡并加以取舍，这是PM要决策的
2、给项目选择指标时，请确保你要观察（测量）的和你要实现的目标有关；
3、排期问题：a、让开发制订排期（现实中不太可能）；b、开发在功能进度和放弃之间做抉择（很难）
4、必须有项目计划：如果你不知道要去哪里，那你也无法到达那里
整体：a、项目的关键里程碑；b、文档和代码的交付标准；c、人员分配的情况
分维度：b、任务之间依赖关系：PERT表；每项任务起止时间：甘特图；
5、降低需求工程成本最简单的方法：不做；前提是你要知道客户是否可以接受
6、进行中的项目的进度报告：“各项都按计划进行，除了…”，重点关注问题
7、软件开发项目的风险
资源类：人员、时间
需求设计：关键需求不对齐、用户界面不受认可、需求变化应对不及时、徒增用户并不想要的功能
架构开发：组件无法复用、性能不足、远超团队的技术能力（极端的：超过当前的IT技术）
关于维护
1、如果能正常运行，不要尝试“修理”：很有可能你其实引入了一个问题
2、最好不要花钱填坑：废弃、替换、从头创建任何有不良历史记录的组件
3、程序迭代越久，每次改动，整个系统中需要被修改的组件比例会越来越高
4、权衡重构：扪心自问，如果你编撰了设计文档，维护者们真的会使用他们吗？
5、先翻新最差的：重写一个800行的模块，可能能减少30%运维成本
6、保持熟悉：开发人员对产品的心理熟悉程度随着版本迭代会逐渐降低（出现问题，能知道哪个应用哪个模块甚至哪个方法）
7、将这个系统引入它要解决的问题的环境时，本身就改变了环境，也就会引发新问题；
综合性的
1、复盘很重要：PM、PD、开发、测试、业务做好自己领域的复盘（关注不符合预期和相应action），沉淀有效的组织资产
2、问题分析：要找到根因，且不仅仅只是技术问题，还有管理问题（制订规则、红线，增加管控措施）
3、PRD的设计是为了让用户行为能被很好理解，架构的设计是为了支撑前者，选其优者（QPS，RT，拓展性，复制性，安全，可用性）
4、正视标准：几乎所有标准都提供了组织和内容方面的指导
5、业界和学界：用业界的环境作为萌发想法并验证效果的实验室，而不是先不切实际构思然后做技术转化
6、二八法则：80%的bug会在20%的代码，80%的CPU被20%的代码消耗，优秀的程序员写代码时间在20%之内，抓住并满足客户必须的20%功能（有时候剩下的80%甚至可以）
7、变更控制：a、所有变更从变更请求开始，业务、测试、客户、产品都一样；b、SCM要独立于项目管理，规则一旦能绕开，存在就没意义了
8、复用的极致：只要可能，购买而非开发
