StreamSparkAI

speaker 1: 大家好，这里是原子能。 前些天在粉丝群里面有一个大学生很焦虑，他说自己简历上的项目一边写一边踩坑，设计一直在改，一直在优化，每样都要慢慢摸索。 现在快毕业了，这个项目还没有完整做出来。 对他这个情况。
speaker 2: 我引用了一句名言来回复，make it work, make it right and make it.
speaker 1: 这个著名的软件开发原则的字面意思就是把它做出来，把它做对，然后把它做快。 但这句话的重点不在于work right and fast，而是他们的先后顺序。 所以它真正准确的表达应。
speaker 2: 该是make it work first，就make it right，and finally make it fast.
speaker 1: 不然可能听过这个原则，甚至也照着这个来做，但是没有去深究他为什么这么说。 就像第20期视频的核心观点，No Why之后才是no how。 所以我们今天就来剖析这个，我认为是软件开发的最重要的原则。 群里这个小哥这一这一半改了，那一做一半又改了。 永远都在重构，在优化。 表面上来说，你的架构设计，你的代码质量，从专业水平的角度来说确实会变得更好。 但实际上你这个软件没有因此更接近终点，反而是越走越远了。 我看到过很多简历里面列出来那些炫酷的项目，对此我的提问都会是，他做完了吗？ 上线了吗？ 被谁用过了吗？ 而回答往往也都是做完了还没上线，没有用户，这种都不能够算是真的做完了。 因为一个没有实际被使用过的软件，他压根就没有活过。 在整一个让编程再次伟大系列的第一个视频的第一个话题，就是软件的生命周期。 里面有提到软件在设计开发的阶段，这是前期只有在它上线那刻才是它生命的开始。 所以一个没有做完的软件，它的架构有多好，它的代码写的多美，它的性能有多强大，都是空谈，毫无意义。 如果你的主要目的只是为了在简历里面多列出来一些技术名词，那我建议你还不如直接去背诵八股文算了。 因为你压根没有让他运行起来。 所以某某技术在某某软件里面发挥了什么作用？ 它的优点，它的缺点，你都没有真正在实战中体验到。 当面试官问起来的时候，你能回答的也只能是八股文的范畴。 那你这个项目还做来干嘛呢？ 浪费时间。 所以说make it work是一切软件开发的第一原则。 只有在这个基础上，我们才有资格去讨论后面的make it right和make it fast。 有聪明人就会说了，那我为什么不开始就直接make it right呢？ 一步直达终点，这一集就跟第七个包子的故事一个道理，既然吃七个包子就能饱，为什么不直接吃第七个呢？ 当然我不是在说人不可能在一开始就知道怎么做是正确的，理论上确实能做到，但实际上很难。 因为正确的做法从来都不是一个constant，它不是一个常量，而是一个变量。 他的取值取决于三个因素，一是你的认知范围。 就像群里这位小哥，他在不断的学习中会接触到新的理论，新的思路。 在数据读取这件事上，他先是用了直连数据库，然后他又认识了connection pool连接池，然后又接触了o后面，还学到了用read进行缓存的优化，这些新的知识隔三差5就会刷新他所了解的正确做法。 二就是行业的发展，我们常常用state of the 2来指代当前的正确做法，但这个东西也不是在一夜之间忽然就怎么样通过全世界的程序员投票决定的，它是一个渐变的过程，就像我们说不出来Linus是在什么时候成为state of the 2的操作系统。 因为不同的社区，比如说学术界、开源界和业界，他们各自的需求不同，对Linus的接纳过程自然也不同。 更别说有些竞争激烈的领域，比如说前端生态，同一个时代都会有好几个不相上下的技术，某个大企业的背书或者是某一个大版本的功能发布，都有可能完全扭转整一个局势。 而第三个因素就是正确的相对性。 软件开发不存在绝对正确或绝对错误的解决方案。 当然那些完全跑不动的情况除外啊。
speaker 2: 从这个角度来说，我们都不应该用right and wrong这个词啊，应该用better和bro这里，不用best and wor是.
speaker 1: 因为在现实中我们不会盲目的追求完美的答案，而是一个足够好的就行了。 因为我们往往有很多事情要做，你在一个地方去纠结完美只会拖累我们解决其他问题的进度。 所以总的来说，正确是在一个时间和空间上的相对概念。 那么它自然要有一个参照系才成立，而这个参照系就是要有一个原点，这个原点就是前面提到的make it work。 然后你会发现你人生中开发的大多数软件都不会走到make it fast这一步。 首先是因为高频、高速、高并发为核心卖点的软件，无非是大家天天开发的东西。 所以在大多数的软件应用场景里面，对于响应速度、运行效率的感知，尤其是从用户的体验的这个角度来说，其实是很微妙的。 你要说从10秒钟到1秒钟的前进时间，大家都能够感受得到。 但是从一秒钟优化到900毫秒，一般人就不会有很明显的感觉。 只要你没有整出什么指数级时间复杂度的代码，通常情况下你的优化就是在1秒到900毫秒这个区间上。 而且在很多场景里面，代码上做优化远远不如在代码外的安排。 比如说在互联网场景，一个好的C D N服务商，一个符合用户的分布规律的一个部署策略，对于用户体验的优化效果远远高出代码层面的优化。 而更常见的情况是在软件项目的不断推进过程中，会持续的有更多更高优先等级的任务被插进来。 比如bug的修复，新功能的开发，为了能够开发某些新功能，而而需要对某些旧功能进行改造。 那从一开始就存在了这个性能优化这个任务，很容易就一直被压在箱底。 如果你开发了这个软件，排除万难，终于来到了make key fast这一步，那么恭喜你可以开始探索计算机技术更多更深层次的奥妙了。 比如在第五期视频里面，我们探索了链表这个数据结构的性能局限，以及相对而言数组结构的优点。 或者在第六期视频里面，我们探索了技术框架带来的额外抽象层所造成的额外负担。 来减少抽象层的价值。 或者第十期视频里我们探索了怎么往底层原理走，从而获得高出几个数量级的优化效果。 或者第13期视频里面我们探索了如何通过砍掉服务间的交流成本，将一切逻辑纳入数据库的高速架构。 或者15期视频里我们探索的正则表达式这种日常工具的性能缺陷，以及不同场景的替换方案。 后者第18集视频里面我们探索了文本作为数据结构的缺点和一些二进制格式的应用场景。 这些探索在这个阶段才有价值。 在你的软件真正运行起来之后，在你给它打造一个足够优秀的架构基础之后，在这之上的优化才能真正的有所发挥。 如果你的根基是千疮百孔的那在上面研究哪个数据结构能够更好的击中cpu缓存，就有点像是在研究回字的4种写法。 这个道理有点像马斯洛需求理论，先满足生存需求，再满足生活需求，最后才有余地去考虑人生的升华。 那么make it work就是生存，make it right是生活，make it fast是升华。 在我的这些视频的评论区里面，也经常会看到有些人对内容嗤之以鼻，不屑一顾。 我想可能就是因为他们误把这些内容当做是软件开发的生存需求了。 所以就会觉得说写个软件而已，还要搞了这么多花里胡哨的，你这是在误人子弟。 回过头来，我觉得整一个原则的最大价值在于把软件开发是一种具有阶段性，是一个动态过程的这个特性给很好的展现了出来。 大多数的理论都是在追求某一个最好的结局，比如某某东西要怎么样做才最好，某某问题的最好的答案是什么等等。 看多了这些理论，就会容易陷入一个错觉，觉得软件开发就是一锤子买卖，要做就做到最好才能拿出手，结果呢永远都出不了手。 所以希望这次讨论能够让大家打开一点思路，让你的编程再次伟大。 我们下期见，拜拜。