软件行业的利润
《软件工程最佳实践》是我2021年度最推崇的书籍之一，即使50%的内容我还没看-因为它具体执行措施写的太详细了。我认为这本书最重要的观点在于，以软件工程的角度阐述了软件行业利润的来源。
有些人认为利润来自于拿下垄断的订单，或来自于成本和销售的差价，或来自于持有的技术，甚至来自于对员工的剥削，这些角度都不算错。不过从软件工程的角度来讲，软件行业的利润来自于可交付价值的可复制性。
我只能想到一些不成熟的例子。比如面包，如果10个人来消费，那就要生产10份。而对于软件，如果你为公司内部开发了工具，那就服务了一个公司的人；如果你为工厂写了一套代码，你服务了一个行业的人；如果你写了个通用购物软件，那你就可以服务几乎市场上所有的人，而你的成本并不像实体产业那样按份递增。
当然这是最理想情况下的设想，实际上一样会有需求多变，产品细分，成本控制等问题需要处理。如果软件行业要想被认可为一个工程学科而不是一门手艺，就必须采用稳固可靠的工程实践方法，经济高效地交付可接受的软件产品。这本书从头到尾都在不厌其烦的强调影响软件真实经济价值的各个因素，以及如何去处理这些因素。
当然这些对于我这种小卒级别的人来说，远远达不到干预项目利润的程度。不过可以借用这种思想，指导我们的编程思路。
就像网上说的那样，如果有时间，去深入学数据库，设计模式，数据结构，网络原理等长时间内不会过时的知识，而不是跟风又去追了最新的前后端框架；针对特定网站和App解析类的工作，就像给10个人做10个不同面包一样，还要追踪他们的口味变化，其代码基本毫无可复制性，性价比低的令人发指。
年轻人经常面临抉择，到底要不要加班呢？趁年轻多奋斗提升自己听起来很有道理，但是也害怕又忙又累又毫无收获。其实这种局面下就要考虑这种工作是不是对自己有积累的工作。那怎么才算有积累呢？参照上文，那就是评价可复用的知识库的积累程度。那种工作量大且代码高度定制化的外包，工作起来更像是消耗而非积累，我朋友评价饿死也不能去，我过了好几年才有这意识，何等的迟钝。而那种十天赶出一个电子商城或内容管理系统的外包，恰恰是因为构建了某一方面的代码积累，其利润来自于外包业务部分需求的可复制性，饶是如此，往往也被后续的需求变更弄得焦头烂额。
同样常见的"紧急"和"重要"之争，同时紧急且重要的任务最优先，这没什么争议。但是单纯"紧急"和单纯"重要"怎么选择呢？我只能说，讲理论的时候大家都知道优先去做利在长远的事情，真动手的时候，尤其是编代码的时候往往又忘的一干二净，或单纯顶不住进度的压力。代码整洁之道和设计模式这类旨在增加代码可读性和可复用性的书大行其道，本质上还是因为能增加利润。
前几年面对总是无疾而终的软件管理制度，就有同事说领导们肯定也不傻，现在这样赶工能有一定利润，推行那些标准啥的，慢工细活，没准利润反而没那么高了。我当时难以反驳，直到看了这本书之后才大致能明白，真正的利润运算要贯穿多年，包括人员更迭，代码维护，需求蔓延等等因素需要处理，可复用的材料积累也是投资回报比评价的重要一环。而很多时候我们估算利润只考虑了眼下一刻。
或许有人会说，在这个风云变幻的年代，谁又能考虑到未知的多年以后的情况呢。但是这本书就是在08年金融危机之际出版的，尤其强调了投入缩紧情况下可复用积累的重要性。
补充一句书里的观点：可重用材料不仅包含编码，还包含体系构架、需求、设计、测试材料、使用指南以及其他一些必要的组成部分。
书里还有一句：认为集中办公对软件开发有益，这一情况表明，软件工程仍是门手艺（craft）或者一种艺术形式（artform）而不是一个真正的工程领域。原书提到这里的背景是软件具有可远程组装性，凭借远程开发、虚拟开发环境和标准可重用组件的组合，将很好地把软件工程变成一个真正的工程领域，并显著降低软件开发和维护成本。不过，联想到疫情泛滥的当下，这句话有了新的用途–若是有公司或团队认为远程办公会影响软件开发效率，那就说明其软件工程管理水平不够格。