我的技术管理感悟(架构篇)

天下之至柔，驰骋天下之至坚，无有入无间，吾是以知无为之有益。不言之教，无为之益，天下希及之。

做技术管理，一定会接触到项目的架构设计，那么架构到底要如何设计呢？有没有什么规律和方法可循？今天谈谈自己在架构方面的感悟。

1. 什么是架构？做架构设计有什么用处？

架构是一个很宽泛的概念，实际上，生活中到处都充斥着架构，公司的组织架构，房屋的结构，机械的结构等等，都是架构，架构不是本身就有的，是为了实现某种目的进行设计而产生的。做架构的目的是为了使我们想实现的目标更加具体，易于实现，便于分工合作，放在软件行业，就是让我们的代码耦合降低，开发bug数降低，易于维护，部署简单等等。

架构是否必须要做？答案是不一定。按照我们系统的复杂程度来确定，系统越复杂，我们在架构设计上耗费的时间应当越久一些。架构设计属于软件流程的设计阶段，在软件流程相对靠前的位置，发现问题后修改和调整的成本相对较低，而且能够站在全局的角度对系统各个方面进行考量，对于保证系统的概念一致性具有重要的作用。架构设计会选择技术，考量风险点，所以对后续项目的推进也有积极作用。所以，复杂的系统，我们虽然在设计阶段想不到所有的问题，但是我们应当发现尽可能多的问题，使用一定的手段和方式给出问题的解决方案和思路，这样就能缓解后期的项目风险。

2. 架构设计到什么程度？

在瀑布流程中，架构设计应当万无一失再进行后续步骤。但是人的认识能力是有限的，随着现在的系统越来越大，越来越复杂，我们仅能靠经验评估到一部分问题，更多的问题是处在变化中的。我现行的做法是，架构设计考虑40%的问题，之后要跟随开发团队，时刻关注开发中的代码问题，提出整改意见，同时对于不合理的设计和没有考虑到的问题，要及时积极地迭代设计，所以，架构设计要在整个软件流程中全程迭代，考量各软件相关方的意见，尽可能完善设计。

设计不一定在一次开发中全部实现，随着版本迭代，可以分版本实现，但是应当区分核心设计和非核心设计，对核心设计，应该尽早开发，这样有利于整个项目结构的稳定，而非核心设计，可以看具体情况之后再进行开发。架构设计应该尽可能包含大量的隐喻，限制开发者天马行空的代码，比如某个接口应当返回常量，结合编程语言，就应该使用const限定。接口和类设计要尽可能富有意义，同时权衡好泛化和具体，比如有一个电插锁，我们是应该把类名定为电插锁吗？可能更好的是定义为门禁，这样可以包含更多种类的锁。

所以，架构到底涉及到什么程度，没有确定的要求，保持适度就好。

3. 如何评价架构设计的好坏？

能够让需求得到满足，能够让开发轻松实现并进行自测，能够让测试简单实施测试，能够让运维轻松部署和维护，架构不过于复杂，这样的架构就是好的架构。不应该按照架构的复杂程度来评定架构好坏，真正好的架构是以最简单的设计解决复杂问题的。过度推崇架构复杂性，会导致代码的学习和维护成本增加，做架构设计应当时刻权衡架构的复杂性和解决问题带来的收益之间的性价比。做架构设计最核心的思想就是封装和迭代，封装表现为提高代码复用性和减小耦合，迭代体现在设计的迭代更新和代码的不断重构。

4. 如何提高架构设计能力？

架构设计是需要实践锻炼的，作为新手程序员，不要小瞧自己的每一段代码，就是写一个函数的工作，有架构思想的和完成任务型的程序员，写出来就会是两种风格。抓住每一次实践机会，多练，多想，多总结。逐渐丰富自己的经验库和风险库，能够很快地从需求中识别出风险点和难点，并能很快地想到相应的手段和方法解决问题。多写代码，多回头看看自己以前的代码，尝试改进代码结构，从中总结经验。

没有写不好代码的架构师，但是有做不好架构设计的程序员，对于程序员，有架构意识和没有架构意识是两个完全不同的境界，随着程序员工作年限的增加，逐渐加强自己的架构设计能力，你会发现，自己写代码的能力也会进一步提高，写出的代码质量也会更高，有效代码的生产率就会提高。