架构师必备的37项技能清单( 三 ) _架构师

1）矫正解决方案：通过对解决方案的矫正，有助于你发现最简单的那个方案，通过从不同的角度和位置去看，往往会得到不错的效果。你可以从上到下的想一遍，然后再从下到上的想一遍。如果你有一个数据流（data flow）或流程，那么你可以先从左往右想一遍，然后从右往左想一遍。与此同时问自己一个问题：“在理想的世界里，你的解决方案会发生什么？” 或：“公司或指定人员会做什么？” 这两个问题会强迫你把解决方案减少到如Occam’s Razor建议的那样。
2）退一步海阔天空: 经过了激烈而漫长的讨论，通常会得出一个高度复杂的涂鸦。但千万也永远都不应将这个视为最终结果。这时候，你需要后退一步：再次查看全局（抽象级别）。回到最初的本心，还是有意义吗？然后再次在抽象级别上进行遍历并进行重构。做这一步有时候让结论更加清晰，而不至于第二天继续进行方案的讨论。至少我的大脑需要一些时间来处理并提出更好，更优雅，更简单的解决方案。人的脑子是需要时间来思考的。
3）分解成一个个小问题（Divide and Conquer）: 简化问题的一个好办法就是把问题切分成多个小问题然后挨个解决。这让我想起了自己小时候打扫院落的场景，看着偌大一个院子，看着就烦，于是我决定把院子划分成三个小块，然后一个个去打扫，这让我的心理负担减轻了不少。一个个小块打扫完了，最后再整体查看下整个院子还有没有边边角角的地方需要打扫。总览一下全局，然后整个院子就打扫完了。再枯燥的生活，都可以发现一些乐趣。
4）重构并不可耻: 有时候，你可能一时半会想不到更简单的方案，你不妨就从一个复杂的方案开始做起，先做着，等到之后再进行重构，这时候再去重新思考解决方案。重构并不可耻，但重构之前要注意一件事情：足够的自动化测试以确保你所重构的地方的功能正确和满足利益相关者的需求。学习更多重构的知识，我建议你可以读读《重构、改善既有代码的设计》 “Refactoring. Improving the Design of Existing Code”，这本书是 Martin Fowler写的。
4、代码
即使你是一个企业级别的架构师，就最顶层的那种架构，你依然应该知道开发人员在他们每天的工作中主要做些什么。如果你不能明白某个东西如何实现的，你可能会面临两个主要问题：

开发人员有可能不会接受你说的。
你也不会明白开发人员要什么和面临的挑战。

1）有个辅助项目（Have a side project）: 跟进一个辅助项目，可以让你了解到新的技术和工具，以了解到当今和未来的开发方式。Kurt Schneider写的“Experience and Knowledge Management in Software Engineering”（软件工程中经验和知识管理）一书中说经验是所见、情感和假设的结合。看书固然是好事，但这只是书本知识（book knowledge）。只有当你自己尝试去做事情本身，然后你感受到情感和发生情绪，然后有了对事物好坏的判断。你使用技术的时间越长越能做出正确的评判。这有助于你在日常的工作中做出正确的判断。当前有大量的语言和框架，只有你对这些有一定的经验和了解后才能做出正确的决策，从而引导开发人员朝着正确的方向迈进。还是那句话，记住经验的定义：所见、情感和假设。要想有经验就要去动手！
2）找到正确的事去尝试：你不可能去尝试所有事情。这是不可能的。你需要一个更加结构化的方法。有一个来自ThoughtWorks不错的方法是技术雷达（Technology Radar）。他们把技术、工具、平台、语言和框架分为四类：Adopt，Trial ， Assess 和 Hold 。Adopt（采用）意思是 “强烈的感觉到已经可投入到生产中使用了”，Trial（试用）意思是 “可以先在某个项目中做尝试，在这个项目中做到风险可控”，Assess（调研）意思是“可以探索下对公司有哪些影响”，Hold（保留）意思是 “谨慎使用” 。通过这种分类，更容易获得新技术的整体情况及其准备情况，以更好地评估下一步要干什么。
5、文档
架构文档有时候很重要，但有时候又不重要。重要的文档比如架构决策或编码指导手册。编码开始之前通常需要初始文档，并且需要不断完善。其他文档可以自动生成，因为代码也可以是文档，例如UML类图。
1）Clean Code：代码是最好的文档，如果你写得足够好。一个好的架构师要有能力分辨出好代码和烂代码。著名的书：“Clean Code” 。