科班也好，野路子也罢，对于进入职场工作的程序员而言，在一个相对固定领域深度工作几年后，一定会接触到更大的工作范围，比如说项目管理、架构决策、业务规划等，工作方式与工作内容都会发生变化，需要的思维方式也会发生不同。
同样的，我在工作三五年后也接触到了更广阔的工作领域，回过头看，现在以一个初级架构师的要求回溯下成长历程，并持续思考架构设计所需要的能力养成。
如果有什么主题贯穿始终，那就是：
Everything is a project, everything needs to be designed.
我想这应该是工程师的基本素养，把软件领域的事情都看做项目管理，用工程思维纠正偏差保证落地执行。
另一方面，拥有独立思考能力与思辨能力，不经过设计的系统就是更有可能出问题的。两者都很重要，这个文章专栏更侧重后者就将专栏名称定为架构方法，探讨架构师的成长路径。
第一篇就先谈一下从程序员到架构师的转变所必须的思维方式切换。
1、从解决问题到提出问题
我们都知道爱因斯坦讲过，提出问题比解决问题更重要。那是因为我们解决一个问题的时候，常常只需要用到一些数学以及实验的能力就可以了，但提出一个新的问题，以一种新的角度去看待旧的问题，是需要用到我们的创造力才能够做到，而这恰恰是真正推动科学进步的一部分。
作为程序员，面对的是确定的问题，找到可解的方法；作为架构师，面对的往往是不确定的环境并提出合理的问题，再去寻求解法。工作的出发点是问题而不是技术，不能因为手里有了锤子（熟悉的技术栈）看哪里都是钉子。
程序员的工作大部分都在编码实现上，将明确的编码任务找到合适的方法实现。架构师可能只有一部分精力在编码上，还有用户调研、可行分析、解决方案、产品设计、架构设计等，端到端（End-to-End）将软件产品交付给用户使用，让用户使用产品后变得更卓越。
摆脱面相实现的思维习惯，就是要求架构师离用户更近一些，思考如何解决用户的痛点，亲临用户现场接触领域知识。架构师与产品经理往往是产品的一体两面，一面用户市场，一面研发团队，他们就是其中的桥梁，支撑起产品的组织构架。按照康威定律，产品的架构设计也会同构于组织架构。
诚如《人月神话》作者 Brooks 所言：
The hardest part of design is deciding what to design.
找到恰如其分的切入点，植入软件架构设计考量，再去投入产研，可以由架构师的决策能力决定的。否则常常看到的结局就是一将无能，累死三军。
2、始终 trade-off
身在其位谋其职，跨入架构师门槛后，将会面对铺天盖地的需求。引用乔布斯的话就是：
Deciding what not to do is as important as deciding what to do.
也就是我们常说的 trade-off，考验专业能力也考验心力。
可以讲 trade-off 是软件架构的核心，因为几乎不可能有项目能按照业务要求满足所有的成本、资源、范围、质量、风险等要求。在有限的条件下，只能优先满足其中一部分，扩展到极限情况下，只有一种要素是第一优先级的。
同样的，在架构设计理论中，CAP 最多只能达成两条边。功能需求与非功能需求都是有条件达成的，不可能既要又要还要。Keep it simple 是更困难的事情。
尤其注意非功能性需求往往决定架构，实现功能性需求有许多种方案，但是方案选择取决于非功能性需求，以及团队技术储备，基础设施完备程度，合规要求等研发管理能力。
定契约，有思考，能落地，展现的是架构师的架构决策能力。否则，按照用户或者业务方的要求，或者迫于上级的压力，那就是功能一个不能少，优先级一个不能低。今天立项，恨不得明天就能上线，架构师的职业前景就堪忧了。
至于该取哪个该舍哪个，就要在架构设计之前定下设计原则，比如数据一致性优先级最高，尽早发布基础功能版本的优先级大于延迟发布完善功能产品等。当出现矛盾的时候，利用这些原则来进行取舍。
大多数场景适用的是，分阶段交付产品并快速迭代，一个不太好用的产品胜过一个不能用的，而快速发布可以弥补产品的问题。
3、跳出疯狂的忙碌
标题来自 37signals 的联合创始人 Jason Fried 的同名书名。
这本书对 10x 程序员做了一种阐释，生产力是用来形容机器的，不是用来形容人的。
如果用生产力来形容人就会导致不断填满又不断膨胀的任务栏，追求更高的产品产出，也就是做更多的工作或花费更少的时间，机器可以 7x24 工作，但是人不能。强调生产力就意味着强调忙碌，没有闲暇也就没有思考，缺少创造性程序员就沦为了重复制造的机器。
对于程序员而言，真正追求的应该是有效性（effective），确认目标并高效完成，善于做减法，腾出的时间可以思考与休息，从而可持续发展。对于架构师而言，更应该如此。
但是架构师的外部环境是，码而优则仕是国内 IT 行业的普遍现状。做架构师尤其要提醒自己不要被 title 所麻痹。选择架构师就要不断精进技术，软件工程到底还是一门手艺活，手艺活就要持续磨炼。常常脱离编码容易做出不切实际的设计，Java 之父高司令在亚马逊依然保持每年至少 10 万行代码提交量。再优秀的架构设计最终也要通过代码实现，再厉害的工程师也要扎实自己的基础知识，这是立足之本。
架构师要避免过度繁忙，不断确定目标，正确做事，也让正确的事持续发生，持续提供增量价值。知识储备不更新，个人价值就会缩水；反过来，知识深入完善，需要更复杂的场景验证指导所学。学习与实践反复验证保证持续成长，换取职业生涯不断上台阶的可能。
