小灰笔记

这里提到的一切看上去似乎都是奢侈或者奢靡，但是从我个人的期望来说我是希望有这样的环境的。而现在，能够从互联网上看到的微软都是超级人性化的“可恶的资本主义”的模样。那么，基于现在的计算机的性能，哪怕是个人计算机的性能，理论上来说我们的创造具备了无限的可能。这里再次提到了增量式的开发，其实对于开发者来说，尤其是小型的开发团队，我觉得这是最好也是最稳妥的软件开发模型。快速原型只能够作为一个中间过程中的版本存在，由此，其实这上面的一些可行性的结论也许不一定能够在最终的设计中得到确认或者继承。继续上一篇的一些思考。

软件或者硬件的发展根本的目的还是要去符合用户的基本诉求，既然经过了一路的历史洗礼依然能够存活，说明至少曾经的主流技术路线还是让人们所接受的。那就是，其实在软件开发中有很多对立的观点但是彼此却都是正确的，只是在不同的场景或者条件之下彼此各有各的有点。其实，在实际的进程中，很多推翻了重来的方案。结合后面的实际的例子说明，书中描述的部分如今是已经实现了的。但是，这又不得不引起我的好奇，之前的这个版本的word究竟提供了什么样的功能呢？这一次的阅读还是很有启发思考的作用的，也可以让我对过去的一些工作进行总结。

全部学习汇总： GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month. (github.com)前面总结了没有银弹的章节，多少还是让我想到了一些其他的方面：全新的技术模式、新的开发语言、新的开发工具、新的技术思想以及原有技术上可能存在的重用性改造。在这些方面上必须得时刻保持着自己对于相应方法的敏锐程度，因为随时出现的新方法都可能颠覆整个行业。这一个章节，其实是上一个章节话题的延伸。开篇的这个照片，我觉得多多少

因为，相应的高级语言的出现解决的通常来说是一个特殊的领域或者专用的领域的问题，对于整个大的软件开发环境来说没有大的变化。我再次想到了微软，虽然我没有去体验过，但是从网络上的各种信息来看，至少我看到的信息描述了一个我非常欣赏的成长氛围。一切设计的源头其实还得追溯到人，很多时候，一个功能会因为一个人的思想而发生重大的改进。关于设计的共享，GNU的出现极大的推进了这方面的发展。继续前面没有结束的没有银弹的章节的学习笔记整理，前面一半抛出来了一系列的问题，而这一半则是一些对应的方法性的讨论。

典型的例子是现在的操作系统的开发，有很多新的处理器的匹配还得保证一系列设备的兼容性。其实是驱动的设计，因为我们需要用开发的方法来实现对各种各样的芯片本身的描述，而这是一个很大的集合。人狼是非常可怕的，可以变换成各种可怕的怪物。软件本身是复杂的，而且随着硬件升级以及客户需求的升级，软件如果是一个持续维护的产品，它将会更加复杂庞大。银弹其实是被翻译成了多种不同的叫法，这样虽然没有对整体的理解造成太大的影响，但是还是给读者一种不连贯的感觉。在所有的工作中，明确即将设计的产品是什么，什么样子其实是最重要的。

前面我的批注多少是有点对我曾经工作的一点抱怨了，这里有我自己的私人想法，不见得适应市场的风格。但是，把一些标准化了的软件封装修改成非标准化的软件，很多时候工程师的工作少了创造性的乐趣，而这个过程也是一个让正确的设计理念不断扭曲的过程。而这里提到的计算机存储资源的限制早就已经让工业技术的革新给颠覆掉了，如今的存储早已经不是什么稀缺的资源了。但是在嵌入式控制的领域这个有所不同，然而，如果用户采用的是你开发的模块驱动来进行二次开发，这样还是有一定的相似之处的。关于自文档化的代码，有一些推荐的技巧：1，命名规范；

这本书的翻译，充斥了大量的类似问题，我估计可能会是老师带着几个学生翻译出来的。尤其是，很多团队的项目管理人员对此认识不够，而结构师又没有足够多的经验，就很可能只是放一个框架的说法在这里，实质上还是工程师信马由缰。我觉得这个也是没有绝对的答案的，从开发者的角度考虑，至少局部开发的时间阶段逐步增加是好的。但是，不管如何处理，只要是有多人合作的开发的团队这种模块之间的交互耦合问题的产生以及面对是迟早的事情。其实，我觉得现在流行的linus的评价也可以用来作为一个替代的回答：说都可以说，给我看看你的代码！

但是现在我接触的工程师似乎很少有人再有这样的东西，或许这也是技术时代进步的结果吧，而我碰巧接触了一些古老的知识与思想。资源的分配不能够只是考虑各方面的使用的公平性，不能够一刀切采用雨露均沾的模式。涉及到软硬件两方面的问题通常是技术上难以解决的问题，而软件开发的前提假如有一个可靠运行的硬件将会是一个幸运的事情。工具的使用我觉得应该是自由的，只是在用于与人交流的时候尽量采用标准化的文件，不然因为工具带来的隔阂就很难打破。在项目推进的过程中，有些公共的资源在使用需求是重叠的，这个可能会是很常见的问题。

看完了整个章节的内容之后，我觉得未雨绸缪的说法虽然也能够表达一定的表述意图，但是似乎也不能够直接让人联想到真正想要做的事情。其实，这个章节最主要的讲解内容就是如何去应对开发过程中的临时版本，而这种临时版本很多时候只是一个阶段性的临时品，最终废弃。否则，会出现很多的权力对立。但是，正是这样的现状催生了很多新的技术与新的产品设计以革新当前的凌乱。引入这样的插图，可能是想说这个工程的设计少了一个中间的原型做验证，因此导致了严重的后果。原型到产品有时候会有一道难以实现的障碍，因此，产品化的过程有时候是阶段性的。

我觉得一个合理的项目推进应该是这样子的，有相应的交付物沉淀也会让项目的成果能够积累复用。现在的软件开发人员真是幸福，看看之前的项目实施能够死磕到这样的程度，工作的难度不可想象！项目经理有时候的工作体现并不在于技术或者决断，项目的管理本身或许是一种沟通的艺术。资金的预算对于技术来说有时候会是一个非常重要的约束项，很多时候，开发工具以及商用的实施方案是否可以选择都是受限于资金预算的约束。看及此，不禁好奇：如果我随便找一个我接触过的项目经理，按照这样的准则进行复盘，他们的表现能够达到基本的及格线吗？

有这样的方式，我们可以在表达的时候以词句的方式来表达，如果没有，或许我们所说的都是单个字符了。但是，还是我前面所说的成长阶段问题，目前我所见的工程师没有这方面的能力也暂时接触到不到这样的诉求。但是，对于有能力的工程师来说，这样的能力会是一个工程师基本素质的一个很重要的能力评估点。我查了一下这个开篇的标题的机器翻译，的确是有削足适履的意思。然而，从实际的处理效果来看，目前的技术领域没有那么严谨的态度以及精益求精的精神。这里应该是讽刺故事的作者了，其实存储空间的使用是一个很难的事情，或许远超我们想象。

开发语言对于开发效率的影响是巨大的，现在我接触的汽车电子软件开发中基于模型的开发模式，也就是MBD模式算是一个很典型的例子。但是，在这样的效率模式诱惑前我们也得冷静分析权衡，毕竟这样的开发可能会有更高的资源消耗以及较低的优化水平。有一个没有提及的则是最后的这一个标注：那就是交互的接口数量有时候也会影响开发的效率，其实这样的交互不仅仅是上面说的系统，也包括人员的交流。开篇的标题是胸有成竹，但是从内容看是没有什么这方面的体现的。其实，这个引入语跟章节的内容是契合的，整个章节的谈论点其实就是经验数据。

或许，这里能够表达出来的不仅仅有一个组织的概念，也有安排的意思。再次想到了高德纳提出来的文学编程，很多工作中需要考虑的问题在这样的工作模式中得到了很好的解决。这本书出版的时候已经是几十年前了，当时的技术条件还是有一些古老，如今的技术以及计算机服务产品太多，我们面临的环境已经比之前好太多。沟通配合的有效和高效也是很重要的一方面，因此在高效的团队中出现的应该更多的适合做而不是冲突。关于产品责任人以及技术主管的职责分工，可能有多重模式，随着工作内容的不同、团队大小的变化等会有不同的组合方式。

如果MCU的开发也算是这个机器的范畴的话，其实这里提到的问题有些还是从现实中看到一些端倪的。但是，跟文中描述多少有些不同，我看到的其实是对于勘误表的了解不够。但是，其实从原文的表达来看，也有可能是词不达意导致别人无法理解而无法推进的意思。这里的几个措施很难糅合到我的工作流中，但是从这里可以学习到两点：书面资料以及找一个可以拥有决策权的人来推进项目的落实。电话日志在现在的环境之下已经不适用了，但是也出现了一些其他的可替代的手段。产品的说明书有时候会有一定的模糊性，采用两种描述方式是很好的实施方式。

然而，等团队的成长到了一定的程度之后，第二个系统的设计迟早是需要面对的。有时候，推进项目进展的或许不会直接的技术而是管理的艺术以及沟通的技巧。因为，大的项目可能有很多人协同工作，而单兵作战决定一切的可能性不大，毕竟我们不是每个人都可以成为RMS的。否则，提升了效率可能也丧失了团队的凝聚力。产品的设计有时候是非常依赖于团队成员的经验的，有时候，他们提供的或许不是如何去实现，而是让我们避免掉很多失败的可能。最近的几次笔记整理，我保留了章节的第一页封面以及图片，这些内容比较醒目以后或许可以作为提醒我回忆的信息。

这里其实是介绍了大教堂的故事，看了后面的内容后我知道了，这个章节所需要讲述的其实不是承前启后而是如何从一个整体的角度来做好把握融合各方面的设计成就伟大的作品。概念复杂度在设计上需要考虑一定的权衡，概念的复杂度会涉及到设计，而功能与设计的比值其实是一个很好的性价比参数，可以作为最后的衡量标准。优秀的产品设计中，系统的架构师甚至说是需求的定制人员应该从客户的角度来思考整个项目的进行。后面的一段描述，从意思上是跟前面有一页的内容相反的，我觉得这个翻译是对的，前面应该是翻译除了一点问题。

在之前看过的RMS的故事中可以看得出来RMS的战斗力，兴许别人眼中的优秀人员是一个10X的程序员，而他则是一个100X的高手。但是，对于这种精干的小分队来说，可能开发大型的项目的时候会出现效率低下的问题。首先得有一个外科医生，这个是这个团队的灵魂人物，需要比较高的天分、丰富的经验以及广博的只是。语言专家我觉得可能是实力雄厚的团队才会拥有的，但是有这样的角色存在肯定会让这个团队的整体能力有一定的提升。如果解决大型项目中，精干小组不适用的问题，还可以采用另外的方式：那就是把大型的项目进行一定程度的拆分。

其实，我前面从开发者的角度提到了一个聪明人和智者的概念，从项目经理的角度也应该有这样的思考。客户的紧急催促以及不合理的进度现在看起来会是大多数，如何面对并处理这样的问题会是一门很有意思的艺术性手段。人月其实是一个工作量的单位，而错误的认为人月可以互换，这个也的确是存在的。缺乏合理的安排是导致问题产生的主要原因，但是合理的安排背后的原因可能是很多的，这个值得我们去仔细总结。而后面的信息，也是我前面提到的恶果的具体表现了。这个，在我前面提到的典型的6人干一件事情的例子上就凸显的格外明显。这个，最为常见不过。

没有任何有效联想的内容，在学习的时候很难进行有效的二次加工，通常在学习的时候也会遗漏一些有价值的信息。针对第一点，讲得很正确，但是我觉得unix思想有一种思考的方法是非常值得我们去参考使用的：我们尽量花10%的时间来找一个解决90%问题的解决方案，剩下的问题再作为特殊情况专门对待或者干脆不处理。SICP还是对我思考问题的方式有了很大的影响的，而视频课程中老师讲过一句话，大意是：“我们所接触的其实是魔法，我们使用咒语来召唤计算机的灵魂”！但是，或许这样的团队生产的是我没见过的优秀代码。

这不是我第一次看到这本书，而且我也曾经粗略翻看过几页，但是之前看的时候或许根本没用心，因此脑袋里空落落的没有深刻的印象留下。我觉得，原文使用的单词或许是power，而想要表达的概念可能是计算机的性能越来越强。这是我们读书选择翻译版的时候需要付出的一些代价，或许我们获取到的不是第一手的资料。这在我现在所从业的嵌入式行业其实应该更容易出现，时至今日，所有的软件行业中恐怕很少有什么具体的业务面中的硬件工程师能够比嵌入式中的硬件工程师更加贴近于软件实施了。我可以多读几遍，每次都以不同的人员的视角来理解。