【阅读笔记】四月
五. 画蛇添足
系统的架构师都会有一种诱惑,设计一个完美的系统,这个系统会覆盖到需求的方方面面,并且这个系统要没有任何的bug。
但是呢,这个诱惑通常会在需求的变更,进度的压力,团队的其他成员无法准确理解,或者甚至是新手程序员经验不足的各种情况下,逐渐陷入一个没完没了的焦油坑中。所以架构师经常要在范围,质量,进度中作出妥协。
在前面《贵族专制,民主政治》这一章节中,提到了架构师和实现人员,也就是程序员之间的关系。但是具体他们之间是怎么样的一种配合关系呢?又是怎么样去在项目中实操呢?又怎么样的去协调系统架构师完美的设计和过高的开发成本?
书中的《画蛇添足》章节中提到:
- 牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配;
- 时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法;
- 对上述的建议保持低调和不公开;
- 准备放弃坚持所作的改进建议。
一般开发人员会反对体系结构上的修改建议。通常他是对的——当实现产品时,某些次要特性的修改会造成意料不到的成本开销。
也就是说,架构师和程序员之间的责任界面是代码(这里提的是两个角色,而不是具体的人员,当前的实际操作过程中,架构师往往也是核心代码的编写者)。而架构师需要将这种创造性放手给程序员,这样能充分调动团队的积极性和参与人员的成就感,对整个团队的共同前进是非常有益的。
书中我自己理解的一个就是完美性和成本的协调:
在开发第一个系统时,结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解,所以会谨慎、仔细地工作。在设计第一个项目时,他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边,作为“下一个”项目的内容。第一个项目迟早会结束,而此时的结构师,对这类系统充满了十足的信心,其精通这一级别系统,并且时刻准备开发第二个系统。
第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时,先前的经验会相互验证,得到对此类系统通用特性的判断,而且系统之间的差异会帮助他识别出经验中不够通用的部分。
实际上,现在在产品研发里经常提到的“mvp”概念,也就是minimum viable product—最简可实现产品。第一个产品或者第一版的产品通常是会被设计成精简的。而陷阱往往出现在第二个产品,在第一版产品获得成功之后,控制不住完美系统或者是市场的诱惑,高估开发能力或者是低估开发成本,提出大量可有可无,性价比较低的功能需求,从而在第二版系统上折戟。在后续的版本中吸取经验反而会进行准确的评估。书中提到了对结构师的要求—自律,或者说对工作量谨慎的评估。
六. 贯彻执行
在確定好团队结构,团队之间责任界面之后,剩下的工作就是执行了。书中在这一章里主要提到以下几个方面:
1. 文档化的规格说明—手册
文档的重要性不需要过多强调,书中描述的已经非常清楚了。
手册或者书面规格说明,是一个非常必要的工具,仅有文档是不够的。手册是产品的外部规格说明,它描述和规定了用户所见的每一细节;同样地,它也是结构师主要的工作产物。
随着用户和实现人员反馈的增加,规格说明中难以使用和难以构建实现的地方不断被指出,规格说明也不断地被重复准备和修改。然而对实现人员而言,修改的阶段化是很重要的—在进度表上应该有带日期的版本信息。
手册不仅要描述包括所有界面在内的用户可见的一切,还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴,而其设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明必须重复所有的基本要素,所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。
上面提到的是面向用户的,实际上需要将团队的下游团队也考虑成用户,也就是团队内部的文档也必须满足上述要求。
2. 形式化定义:实际上,对这一点有较深的理解,我们的自然语言往往存在着一些歧义,特别又是以灵活见长的中文,在不同的语言环境中可以有这不一样的含义。这里原没有一些形式化定义的严谨,比如公式之类。不过往往很多需求不太可能完全使用公式或者严谨的形式化定义。个人觉得一种折中的方式,是对自然语言在团队内做内部的统一,也就是术语库。保证团队内部对关键的术语和概念无歧义。
3. 直接整合:实际上我理解就是统一规划的全局变量,接口以及代码风格。
4. 会议:会议是必要的。一般来说,技术人员往往对会议比较排斥,认为是浪费时间。实际上是项目经理或者管理层必须严格的控制会议数量,会议范围和时长。做到高效的会议。
- 晨会,一般采用站立晨会,非常有必要,可以在一个课题小组之间召开,时长控制在10-15分钟。
- 技术讨论会,有必要,提升团队能力和成员的团队感。
- 预计超过1个小时以上的会议,必须提前做好工作,将会议内容和材料提前知会参会人员,并督促参会人员熟知(督促是有必要的,程序员往往专注于代码而忽略邮件)
- 会议纪要,不要使得会议没有结论,没有结论和记录的会议是低效的。