另一个观点是作者没有提到的，我认为架构师可以由专门的个人或者团队组成，他们承担新技术、框架的调研工作，负责对用户提出的需求进行评估，采用新的技术做出产品原型、技术调研报告，供产品部门在技术选型和技术架构选型时作为参考，这也可以体现架构师的水平和贡献。

作者：技术本身是没有好坏的。比如最早的计算机软件是单机运行的，逐渐发生了架构拆分，形成了 C/S 的架构。随着互联网技术的发展，变成了 B/S。其实是换汤不换药，Browser 还是一个 Client。但是因为 Browser 的普适性，其实就是又做了一个架构拆分，成了一个通用的 Client，做到了很多 C/S 时代做不到的事情。互联网时代的技术人员对 C/S 架构鄙视得一塌糊涂。到了 App 时代，又回到了 C/S 时代的做法，因为 HTML5 响应慢，无法适应手机客户端。所以说，随着人们问题的不断变化，会有不同的技术周期的出现，会有不同的技术周期出现，技术有自己的生命周期。没有永远最好的技术，也没有永远最差的技术，而问题总是在不断发生变化的，对于这一点，架构师要有清醒的认识。

我：其实我不太喜欢面试培训班出来的技术人员，他们可以滔滔不绝地和你描述各种框架的使用，细微到某一个参数，每遇到这种场景，我真想用英语说“I don’t care”。并不是有偏见，而是我真的不在乎你懂不懂参数的配置，我要问的是计算机科学基础知识，聊算法、聊数据结构、聊设计模式、聊你参与过的系统架构设计、聊内存管理机制和垃圾回收机制、聊你对于技术的情怀。框架的选择，实质上是对于技术可行性的选择，这又需要符合当前的业务形态，所以，正如作者所说，没有哪一个技术或者框架是最好的，只有最适合你的产品需求的，才是最好的。

作者：对于开源者来说，开源是把自己的理念介绍给外部的一个手段，和写一本书是一样的。区别之处在于，写一本书是在读者大脑里运行的，而代码是在计算机中运行的。相同之处在于，要想让代码在计算机里运行好，读者仍然需要理解作者遇到困难时，为何这样思考，找到作者解决问题的独特思路。也就是说，代码最终还是要和书一样在读者的大脑里运行起来，才能够把代码所产生的软件运用好。

我：认同作者观点。很多公司都在内部讨论是否应该开源，看看 Google 就知道你的答案了，人家一天到晚在开源，依然保持引领全世界的技术发展，并没有被看懂开源代码的对手超越。这里作者提到了写书，同为作者，我知道其实写书不能赚多少钱，但是我有一个梦想，这一生出版超过 60 本书，一本一本脚踏实地写起来，梦想还是要有的，万一实现了呢。

作者：很多软件工程师学了大量的算法和计算机基础，然而在工作中发现派不上用场。这是非常正常的，因为这些内容是为了在科学领域做研究准备的。而在业务领域，大多是如何把现有的业务在软件中模拟出来的问题，并没有太多高深的数学问题。并且现在的计算机硬件，比如 CPU、内存、存储等都非常便宜，也不需要斤斤计较地去扣时间和空间复杂度。这些都导致所学不能致用。反而如何能够高效地把业务用软件表达出来，并能够随着业务的增长，让软件也快速地长大，则变成了一个更重要的问题。这一点可能是当前计算机软件教育需要思考的问题。

我：Absolutely。

作者：单元指的是代码调用的最小单位，实际上指的是一个功能块或者方法。所以单元测试指的就是对这些代码调用单元的测试。单元测试是一种白盒测试，相对而言，集成测试基本都是黑盒测试。有人会问，如果方法就是单元，一个软件包含那么多方法，那单元测试会成倍数增加程序员工作量，这个问题确实存在，但是有了单元测试，每天能够看到自己的单元测试运行结果全部是绿色，或者正在逐渐把红色的变成绿色，心理的成就感是非常强的。由于形成了代码编写的反馈环，所写的每个代码都能够快速的从单元测试中看到变化，软件工程师会对写代码保持极大的兴趣，每天都能够有强大的动力去修改代码，而且心理也会感到更安全。在与人沟通时，心里也会更有底气。