Eric Evans曾在书里提到过的经历：架构师不能脱离一线，将设计文档丢出去不做持续跟踪和看护。开发工程师不是工具人，不是纯粹的做代码翻译工作，要有自己的软件开发专业性，加上自己的思考和创造。总之，是一个既紧密协作又独立职责独立创造的过程。
前面写过文章架构设计和编码实现的关联性和独立性和架构设计与实现一致性：保持思维、策略和技术的无缝对接，以及最近的先架构设计再编码vs不做架构设计直接编码？其实，这么多篇文章围绕软件设计和软件实现这个主题，主要还是遇到了一些工作中的实际挑战，因为我发现有个很大的矛盾点，就是大多数人对软件方案设计和软件开发实现之间混淆视听、混乱不清的理解，甚至出现对应职责人员相互吐槽的情况，当然后者是幼稚的表现。
说白了，究其本质，如同大Boss所说，不专业，大多数（据不完全统计80%非专业）都是业余人员和没有工匠精神的“差不多”先生/女士，仅仅是入了个门，拿到敲门砖就止步了，殊不知那只是招聘的门，根本不是操作系统/计算机网络/编译原理/软件工程/OOD/UML的门，实际上所做的工作都是后者。
而20%的专业人士大部分时间在面对“管理流程要求”和“管理胡萝卜”的方向上一路狂奔，就是为了好绩效所做的努力视图领导喜欢或者管理要求喜欢，或者在被动救火和生产疑难问题攻关，偶尔有点时间小范围布道一下，比如一个勤学好问的同事在午饭的时候想起来上午遇到的一个问题。ps.这个比例某种程度上可能跟视野有关，不过粗略估计了下，还是蛮符合我们这里的团队的比例的。
方案评审本来是一个极佳的布道场合，但是基本上都是在澄清需求功能概念以及询问这个功能有没有考虑可靠性、那个模块出故障了有没有告警和应急方案，当然评委们凭借极其丰富的经验给出一些实用建议，都是为了避坑，而不是辅导软件设计，或许他们并没有这个义务，他们的职责还是聚焦在保障现网稳定和避免客户投诉。
上面浅析了一些人员、管理、工作现状。ps.只是一些个人视角。
软件既然是一门学科，还是有学科的专业性。这让我想到了谷歌和奈飞的招聘策略，“博士军团/10倍程序员”和“只招成年人”。
反观我们的招聘策略，前段时间跟一名同事交流，突然问到“合作方真的适合合作么？”，因为合作方这个事情还出现过一名骨干出走事件，领导勃然大怒。这里有点复杂，已经超出了技术讨论范围，比如大企业还有负责消化就业率的社会责任。
想到zhuzige以前像鲁迅一样呐喊，一腔热血打算改变目前内部软件设计的现状，还有很多像zhizige一样优秀的前辈，现在发现只能做一个牧师，不断的输出分享案例，静水潜流，然后响应老板的号召学习美国职业人员，要求先建模/设计再编码，贡献一份自己的力量。
革命尚未成功，同志仍需努力。同在一艘大船，既然目标一致，还是要齐心协力。接下来还是回到软件设计和开发实现这条主线。
软件设计应该设计到什么程度？
比如某负责开发实现的同学吐槽说“方案设计太粗糙了”，这种同学现在看毫不客气的说就是偷懒的或者是没有摆正自身定位的，只是图一种情绪释放，一时口嗨。为什么这样说呢？因为这种情况往往是别人设计的方案自己负责实现，当他本人负责方案设计的时候一样的粗糙，甚至更粗糙，这就是我真实观察到的。
代码开发不是一项拿着设计文档进行的代码翻译工作，有的架构师已经明确说了“如果传递只是让下一层翻译代码，那我还不如自己就把代码写了呢”。
还有另外一个角度，比如负责方案设计或者方案评审的同学走完“管理要求的流程”就不再跟踪实现了，除非负责开发的同学比较主动也积极思考，这个时候才会有交流有互补有完善，这样的做法也是不对的，这样就是面向“管理流程”的设计，而不是面向“软件实现”的设计，只是有一个设计模板，在做“设计”的样子，不是在“设计”什么东西。
当然，软件设计不能一次性做对，受到几个因素制约：
1、系统过于复杂
由于现代大型分布式软件系统复杂度高，有些需要编码验证才能肯定概念成立，才能完成一个设计的闭环。
举一个很真实的例子，你要发布一个客户端软件，客户使用的操作系统有Suse、Centos、Ubuntu等，还有不同的内核版本，后期还要再加上客户端软件不同的版本管理、客户操作系统如何兼容升级等，在设计阶段如何确定范围？
2、需求不断变化
需求本来就是不断变化的，而且随着你的进展在变化。这也是敏捷提出来的缘由。
举一个真实的例子，某个功能客户一开始说不要求商用能跑起来基本功能就行，先保证交付POC即可，后来突然变卦说公司战略计划提前，要上生产业务，要达到商用能力。这个变化会引发什么呢？会导致开发测试工作量膨胀、需求计划时间节点变动，进而影响其他需求要做调整或者裁剪，一连串的事情和人员都要跟着变动。往往导致某个需求方案设计完了进行搁置，或者某个需求开发到一半进行搁置，搁置的需求对应的用户怎么办呢？还得去沟通延期。并且搁置的需求什么时候完成呢？还得做好需求的跟踪管理。
3、交互的系统不断变化
和其他系统的交互，其他系统在不断的变动。
以上这些，已经成了现在软件设计的常态。软件系统越来越复杂，需求变化越来越快。
解决方法就是架构师不确定的地方，前面和需求分析人员配合，后面和开发人员配合，交叉确认。
每一层，做的事情，越薄越好，逻辑恰到好处，不多不少，准确全面而不冗余，这，才是每一层最大的专业性。专业，尽量做薄。
架构设计的主要工作是“提取主要矛盾和矛盾的主要方面”。架构师要聚焦理清思路和主线，确定边界，保证不偏离航道。
不可能那么详细，主要是最低成本传递需求内涵，不然字段长度都事无巨细的定下来，就不叫设计了，“直扑代码”就好了（不做架构设计直接编码，直扑代码的架构师），能省很多事，但不是人人都既能软件设计又能软件实现。
软件开发人员应该负责什么事情？
有反哺软件方案设计的意识，并积极主动的与架构师沟通互动。
具有抽象、面向对象思维，精通设计模式，分层架构思想，强大的软件建模能力。
不是对着软件设计文档，无脑的、机械的翻译成代码，这也是文档设计不能太严格界定，反而会严重制约开发人员该有的创造力。现代软件系统或者软件产品，是一个集体智慧的共创过程。
最后才是软件编码实现、单元测试、功能验证和自动化用例。
现实工作中，大多数人（符合前文统计的80%，没有无缘无故的结果）只会编码，按部就班的工作，到处散落的函数，能跑通就行，用着面向对象的语言写着面向过程的代码。
随着时间的推移，代码结构腐化，逻辑混乱，一堆代码“屎山”，一地鸡毛，一塌糊涂，出了问题难以定位，定位完了难以修复，修复的时候容易引入新的问题，修复了一个引入了两个。
极其难以维护，甚至更可怕的是，自己负责的功能、编写的代码，开发完了还没过多久呢，就啥也不知道啦，容易引发“失忆症”，这怎么能快速支撑客户、快速响应定界定位问题呢？！因为系统本身已经很复杂，编写的代码都是任意堆砌的，所谓的软件实现竟然可以乱到“没有规律”可言，需要记忆的细节太多的时候，信息量过大，都是零碎的、碎片的，甚至需要再次追踪代码，而且一个人看大半天代码看不出所以然来，还要多个人一起分析、多次走读代码，才能找出线索。
这样一个专业的学科，竟然可以运转到“没有规律”，怎么才能有高效率？怎么才能总结经验？何谈可维护性和软件稳定性？到最后大多数人的能力不仅没有得到成长，心态还被迫养成了走到哪里是哪里，哪里出问题修哪里，组织AAR回溯复盘改进点也一样是“没有规律”可言，项目如沼泽，人员如行走在泥潭。
软件开发到“没有规律”，“流程”依然在高速运转，不停的拉通、对齐、推动、压强，下面熊猫眼，上面喜笑颜，开个庆功会，又能战斗了。
奇妙的是，这，并不影响商业成功。
为什么都这么奇怪了，还能一个胜利接着一个胜利？
因为基础软件的架构在那里，操作系统的架构在那里，数据库的架构在那里，消息队列的架构在那里，甚至芯片的架构、GPU的架构在那里，软件二进制的架构在那里，一个软件子系统内部编码再乱其运行时也乱不出这些基础软件架构，这，可能是唯一能解释得通的地方吧。
无论如何，在专业的道路上，要严肃严谨，要认真对待，要有所追求，要工匠精神，要求真去伪，要能立得住，形成影响力，对外交流并输出贡献。
不然怎么跟专业的人士交流，怎么学习先进呢？怎么进步呢？
至今让我难以忘怀的是，当年18摸的一位band10的前辈，给我留下了深深地技术气质的印象，嗯，我用了“技术气质”这个词儿，这是给我留下的最真实最深刻的印象。
一元或在看都是莫大的鼓励，一起成长。
