贵族专制、民主政治和系统设计
接上一章：短小精干的队伍带来了新的问题，如何对大项目进行合理的分割？这依赖于一个很重要的前提：概念的完整性，具体而言是指在项目的开发过程中，应该有一个一以贯之的明确的目标和清晰界定的范围，否则随着人员的变动和时间的变迁，这个项目可能会逐渐演变成四不像(我最近在参与的一个项目就是如此，人员的变动导致了项目功能、技术栈的变迁，项目的周期被极大地拉长)。而如何产生概念的完整性呢？答案是贵族专制，少数人决定一个概念并厘清边界，然后据此分割执行，否则人多嘴杂，必然会导致项目在讨论中变成奇怪的样子。
画蛇添足
这一章主要是告诫系统设计师们，不要过度设计，尤其是在第二个系统(第一个系统完成后开发的第二个系统)中，不要过度自信，保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主。(是不是可以说是保持初心？)
贯彻执行
概念的完整性不仅仅要在专制的贵族和系统设计师这一层面上充分传达并理解，在系统的实现人员中，也要充分传达。在不理解业务背景的情况下，开发者也很难写出优秀的代码。作者在这一章介绍了很多方法以达到这一目的，包括规格说明手册、形式化定义(我的理解是 Web 开发中的原型图一样的存在)、会议和大会、多重实现(举例：假如JavaScript只有 V8 一个引擎，那如果引擎实现与 ES 标准不一致时，改标准比改引擎实现要容易得多，但是有多个引擎时，与标准不一致的引擎就必须修改自己的实现，从而保证了标准文档的贯彻执行)、电话日志、产品测试。
当然这些方法在如今可能已经过时了，但是通过种种方式保证软件开发的进度不偏离最初的概念和目标，是实现项目成功的重要保障。实际上在当代的软件开发流程中也有一些措施来实现这一目标，如敏捷开发中每天的站会。
为什么巴比伦塔会失败
我们都知道巴比伦塔的失败是因为上帝给了人类不同的语言导致的沟通失效。那么在大型项目中如何保证沟通的顺畅呢？作者详细介绍了项目工作手册的内容、发布方式、更新方式等等，但是当年他们仍然是纸质文档，后来才进化成微缩胶片，现如今我们有了更方便的字处理工具和文档协作工作，因而这部分的建议就用不上了，但是保持文档的更新和有效获取仍然很重要，否则不同的人对需求的记忆和理解可能出现偏差、进度可能会出现错位等等，导致项目的开发进度被拖慢。
相应的，外科手术队伍也可以有效地降低交流的难度，毕竟人越少，沟通越便捷，这样一来，整个项目通过合理的人力划分和职责限定，就会自上而下形成一个树状结构。作者特地论述了团队中技术负责人和产品负责人的分工与关系，但是我很难将作者的观点映射到当代的开发团队中来，只好略过。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 25岁的心里话
· 闲置电脑爆改个人服务器（超详细） #公网映射 #Vmware虚拟网络编辑器
· 基于 Docker 搭建 FRP 内网穿透开源项目（很简单哒）
· 零经验选手，Compose 一天开发一款小游戏！
· 一起来玩mcp_server_sqlite，让AI帮你做增删改查！！
2023-05-23 每日打卡-30
2023-05-23 每日打卡-29