[答疑]把“一线”等同于编码的CTO

​​软件方法（下）分析和设计第8章分析 之 分析类图——知识篇（20211227更新）​​

​​软件方法（下）分析和设计第9章分析 之 分析类图——案例篇（20211228更新）​​

（匿） 2022-2-20 13:51

我们CTO开发经验很丰富，但是对建模很不感冒。我推荐您的软件方法，他说这些都是虚的，一线开发人员的技术才是实实在在的，实在无语。

UMLChina潘加宇

这位CTO怕是把“一线”等同于“编码”，把“开发”等同于“编码”，把“技术”等同于“某种实现方式”了。

涉众那里才是“一线”的战场，而编码人员和涉众的接触恐怕是最少的，很多编码人员一开始像温室里的花朵，经过许多痛苦后才“知道柴米油盐贵”。

如果做了很多年程序员还是这样的思想，如果不做CTO安心走格子，不对自己知识范围之外的事情指手画脚污染团队风气，危害还不大——这比较难做到的，不认真学习进步仗着自己老资格散播自己半对半错的朦胧经验的，可不少。

如果担任CTO画格子，不知道会把研发团队带向何方，给整个公司带来什么危害。

一些推崇“敏捷”、“工程师文化”的人可能会嚷嚷“干嘛要人来画格子，程序员喜欢做什么就做什么，这样做出来的东西才是精品”，顺便再扯上微信和张小龙为证据。这样的论调会受欢迎，因为它让程序员安心呆在舒适区——可以仔细观察广受欢迎的各种“敏捷”、“DDD”论调，看看有没有这个特点。

以下文字摘自《软件方法》第8章：

在分析工作流不断提出性能问题的人，您可以尝试让他整理一下领域逻辑，也去看看他之前写的代码，大概率会发现其中逻辑的组织是很糟糕的。

这是人的本性中急于回到自己的舒适区的一种表现，不只是在分析工作流如此，其他工作流也会有类似现象。

例如，开发人员没有掌握需求技能，也不愿意学习，即使给他时间去做需求，他也不知道应该怎么做。只好随便找人问问，开个会，走走过场，然后就着急回到编码的舒适区，甚至在讨论需求的时候都已经在不由自主地思考实现小细节。

为什么“现场客户”之类的东西会吸引开发人员，就是迎合人的这些本性，让开发人员可以安然坐在电脑前面，呆在自己的舒适区里。

呆在舒适区并不一定是错的。

如果出于个人爱好和天赋，专精某方面的技能，在某个领域深入挖掘，解决该领域各种难题，这是非常好的选择。不注意自己的爱好和天赋，什么都想学习，很可能什么都浅尝即止，以“学习新知识”来逃避碰到的各种难题。

错的是自欺欺人。

当形势需要人走出舒适区来应对困难的时候，如果说“我只擅长我手上的东西，这个我对付不了，我也没有兴趣和勇气去对付，还是让我解决我擅长的问题吧”，这个可以理解；如果说“这个只需要用我擅长的东西对付就足够了”，那就属于自欺欺人了。

以下文字摘自《软件方法》第1章：

软件开发人员如果缺乏软件工程方面的训练，对以上工作流没有概念，就会把这些工作产生的工件通通称为“设计”或者“文档”。例如问开发人员在做什么，回答“我在做设计”、“我在写文档”，其实他的大脑可能正在思考组织的流程（业务建模），或者在思考系统有什么功能性能（需求），或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答成“在做设计”、“在写文档”。后来又有牛人说了：代码就是设计。本来“设计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码就是一切？

很多大谈“编码的艺术”的书籍和文章，其实探讨的根本不是编码的技能，而是分析技能甚至是业务建模技能，只是作者的大脑里没有建立起这些概念而已。编码确实有编码的技能，就像医院里护士给患者输液也需要经过训练，但如果患者输液后死亡，更应该反思的是护士的输液手法不过关，还是医生的检查诊断技能不过关？