人机情不和的读后感：我与GPT聊《架构之道：软件构建的设计方法》
照例先公布上次的投票结果：
看来还真有要转行的。
近又是利用出差时间读了本书，高铁真是不错的自习室。
这本书对架构的理解挺有趣的，应该说快半本书都是项目管理方面的，因为作者把好的软件架构方式称为“元设计方法”，又分为系统设计和项目设计两部分，前者偏向我们常说的架构设计，而后者则包括了对项目的落地管理，在作者看来，后者远比前者重要。书的视角很完整，也是我们常说的，架构要管落地的。 “对于初级架构师来说，做任何事情都有很多选项，然而对于架构大师来说，好的选项非常有限，甚至只有一个”。章讲元设计方法时，上来就是这么一句来自“架构师之禅”的引言，总让人想起，“我们要对给领导写几个方案以供决策”这句话，其实每次都是有意识引导领导做某个选择，而不是真有多少选择自由，因为确实也没那么多选择。“真正掌握任何一门学科都是一次漫长的旅行”。的确，少说也得3年5载的，这句话我跟GPT聊了下，结果另有出处：
不过再往下问上下文就有了点误解：
它先跑去书中找上下文，又说书不对，然后才返回正确答案，也就是把在书中没找到当成了自己有“误导”。
回到书的内容上，所有架构方法的公共难题就是颗粒度问题，就是元设计也不例外，作者给出的佳选择是面向易变性封装，但也说“可悲的是，学会识别易变区域并不是通过观察别人来掌握的。不可能从书上学会骑自行车，我们得骑几次（然后摔倒）才能学会”。我自己做业务架构的感觉也是，要说讲授业架设计技术，东西也不多，但是没经过实践，光听是听不会的，或者说容易以为自己会了。
说到“元设计“这个词，GPT又为难了，其实GPT可能并没有真正掌握这本书的原文：
即便给出了明确的引文也还是如此，所以，我觉得是要真的喂原文并且有序诱导，而不是总考验它知不知道，毕竟它有时候提供的是答案库的东西，有时候可能是信息词条拼凑，但都未必是高度来自原文的内容。它对于我笔误的“原设计”和正确说法的“元设计”的反应也说明它掌握的并不是原文，估计有版权问题吧。
然后我还是继续自己写吧，“需求应该捕获行为，而不是所需的功能”，这一点与业架方法还是很一致的，业架也是以捕获行为为主，所以看到很多将功能布局的图放出来说是业务架构时，尽管有几分相似，但总是感觉有点儿怪怪的。
作者主张系统构造应该“迭代设计，增量构建”，也就是设计是完整的，且要经过多轮设计进行收敛，但构建可以是分步的，这个道理大家也都认，但是实际工作时很多时候走向了“增量设计，增量构建”，将增量造成的修改称为迭代，其实按道理说那个不能称之为迭代。。。
“软件开发行业是如此混乱，以至于对于大多数开发人员来说，常识性的基本实践可能很陌生。然而，忽视它们做再多的事情都不会加快进度。导致问题的行为不可能用来解决问题”。软件工程让人可惜的就是，只有研究它的人才会把它当工程看。
“需求与设计不应该有直接的映射”，这句话曾经让我困惑了一下，但是仔细阅读发现，作者这样说反对的是基于功能的设计，包括根据业务域切分，希望根据内聚性、易变性设计，从上到下，降低易变性、提升重用性，其实与业务架构主张的根据数据聚类行为的设计有近似之处，因为数据是根据业务关系聚类，而不是功能。企业级业务架构也是根据价值链和领域交叉切分数据域，再考虑行为的。其实思路是接近的，而作者后续主张的前瞻性设计，也就是“参与者网络”，就更加接近了。
这本书还是很有作者个人色彩的，作为被授予“软件传奇”称号的人，还是很有个性的，在文字中也有体现。书的后半部分跟项目管理关系较大，看的时候可以自行取舍。
“切忌根据需求进行设计”，很有道理哦，不妨一读。
后，考验下GPT吧：
还是要喂原文再聊比较好，那样才是训练，而不是考验它知不知道。
相关文章