人月神话 -- 读书笔记一
焦油坑
每个单独的问题都容易解决,当他们相互纠缠和累积,团队就会越来越慢,这就是焦油坑理论。
什么是产出
除了可运行的程序之外,有上图两种途径可以将程序转变成更有用但成本更高的产物。编程产品和编程系统比程序都是 3 倍的成本,编程系统产品则是 9 倍的成本。
职业的乐趣
内心期望劳动成果被他人使用
精妙的程序运行达到预期效果的成就感
持续学习的快乐
在易于驾驭的介质上工作
乐观主义
程序员们都是乐观主义的,错误的假设是:一切都将运作良好,每一项任务仅花费它应该花费的时间。
人数和时间可以互换的情况只在某个任务可以分解给参与人员,并且他们不需要相互的交流。
建议将编码时间只分配 1/6 的时间,其他在计划,设计,构件测试和系统测试中。
盲目要求项目按期完成的就像是煎蛋—加大火只能是一面焦了,而另一面还是生的。
保证概念完整性
系统设计中,概念完整性是最应该考虑的重要因素。
系统的概念完整性决定了使用的难易程度,不能与系统基本概念整合的良好有特色的想法,最好放到一边。
但是如果出现了很多重要单不兼容的构想,应该抛弃原有设计,对不同概念进行合并,然后重新开始。
想要得到系统完整性,结构师必须控制那些核心概念,他们负责的工作产物的生命周期比实现人员的产物要长。
实现人员和结构师的工作都是富有创造性的,产品的成本性能依赖于实现人员,正如易用性依赖于结构师。
没有规矩,不成方圆,外部的体系结构的规定实际上是增强,而不是限制创造性。限制能将注意力集中,更关注在具体问题。
就像 react 一样,限制了生命流程,将工程师的注意力集中在各个位置。
创造性活动包括 3 个阶段:
体系结构
设计实现
物理实现
##画蛇添足
估算过高
面对估算时间过高。结构师要:
牢记开发人员承担创造性和发明性的实现责任,只能建议
时刻准备为指定的说明建议一种实现方式,同时准备接受任何的方法
对建议保持低调和不公开
准备放弃所做的建议,通常开发人员的反对是对的,次要特性的修改会造成意料不到的成本开销。
自律-开发第二个迭代的后果
开发第一个系统的时候,装饰和润色功能会被搁置,结构师倾向于精炼和简洁。
第二个迭代是最危险的,因为第三个和第四个的时候会相互验证经验。
一个倾向是过分设计第二个系统。导致第一个系统被搁置的功能全部用上去,用户只用到了极少的功能。
一个是第二个系统存在某些技术进行细化,精炼的趋势,由于系统设想发生变化,技术显得落后。
要自我约束,避免功能的过于修饰,基于系统基本里面以及目的变更,舍弃一些功能。面对诱惑的警觉,不断提出正确的问题,确保概念和目标在详细设计中的完整体现。
贯彻执行
如何让每个人理解结构师的决策?
文档化的规格说明-手册:规格说明修改的阶段化也很重要,进度表上应该有带日期的版本信息。规格说明要完备。
将定义书写成文字的过程会对很多最初不是非常重要的问题进行判断。
在整个设计里,保证很多看似琐碎的东西处理原则上的一致性,绝不是无关紧要的事情
不要带两个时钟出海,带 1 个或 3 个。如果同时具有两种方式,必须一种作为标准,一种最为辅助描述。
我们的 prd 和视觉稿感觉是一个道理~
还有就是会议,结构师和大家一起探讨系统存在的问题。来让大家更多的理解和参与。
程序和手册往往会不一致,并且手册会被忽视。当存在多重实现的时候,情况就不一样了。从手册更新到机器造成的成本消耗比根据机器调整手册要低。并且当有两种以上的实现的时候,定义会更加整洁和规范。
这些的第三方组件开发有点这种感觉,某个接口的修改,先更新手册,再更新代码会好一些。
当有问题的时候,建议直接咨询结构师,并且结构师应该保存这份纪要,整理分发给用户和开发。
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 981909093@qq.com
文章标题:人月神话 -- 读书笔记一
文章字数:1.3k
本文作者:泽鹿
发布时间:2019-08-28, 16:45:23
最后更新:2019-08-28, 16:45:23
原始链接:http://panyifei.github.io/2019/08/28/读书笔记/人月神话/1/版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。