我的软件架构之初路的杂谈（二）

2020-10-06，更新：

        在持续地学习也了解软件架构师和系统设计师的过程中，发现之前自己的理解和总结并不正确；或者说，是没有完全理解软件架构师和系统设计师，这些角色的工作职责和工作内容。 最近看到Simon Brown写的《程序员必读之-软件架构》后，发现这两者其实就是同一角色，之前自己错误地把架构师的职责人为的分成了两个层面，从而自己的结构体系中抽象成为了两个角色。

        之前理解的系统设计师的职责应该对应于书中的软件架构师。之前理解的软件架构师的职责，现在看起来，应该是对应书中软件架构师应有职责中的两部分：设计软件和编写代码。

        之前总结的版本，目前暂不进行修改。因为，我现有的理论和观念还并不成熟。之前的总结，也算是自己转变过程中的总结。这种自己的后续知识体系推翻自己之前的理论，也是存在过的。其实，出现这种偏差的情况我仍旧认为是正常的，它是学习成长的过程。

        总的来说，成为软件架构师，需要大量的技术积累和实践经验，是一个长期过程。很认同《程序员必读之-软件架构》中提到的，软件架构师是一个角色，而不是一个头衔。后续实际工作中，需要深入观察工作中的现象，获取软件架构师的实践经念。

===========================================================================================

2020-02-25，最初版本：

       在没有实际负责软件系统设计的工作之前，我一直认为软件架构师和系统设计师的角色和职责是一样的，只是不同语境下的不同叫法。在向系统设计这个角色扩展时，才感觉到或者说发现到两个角色是有差别的。软件架构师应该是偏向于软件的设计开发；系统设计师相对软件架构师而言在软件整个体系结构中应该更上层一点，关注的范围相对要宽广一点。

        工作以来的岗位一直是软件开发工程师。多年工作过程中，大部分时间是基于需求来设计和实现软件产品。所以在能力的扩展方面，更多地关注在软件架构师这个层面，初期是借鉴前人的代码，再慢慢地尝试抉择运用合适的设计模式，再到后来的软件架构。这一系列动作，都是为了实现软件源码的复用，让软件结构的层次分明，易于后续的功能扩展和产品维护。可以看出，使用软件架构主要从一个开发者的角度，让自己的源码（注意，还不是最终产品）看起来优美：没有冗余代码，结构层面分明；舒心：个人觉得，使用了良好的架构/设计模式，自身能力价值呈现了出来；质量高：结构的分明便于后期问题的排查、后来人的学习，以及新功能的扩展。这一系列动作，映射到项目上的价值是，复用已有源码和设计模式，可以降低产品的开发周期；基于好的架构/设计模式，提高了产品的性能，可修改性等；好的源码质量，也降低了产品后期的维护成本。

        基于上面的总结和工作体验，个人对软件架构师的理解和实际运用，更多地是在整个产品生命周期的中的实现和维护阶段，没有涉及整个产品的生命周期。

        在向系统设计师扩展的这三、四个月里，总体感觉就是，系统设计需要用比软件架构更高的层面去看待整个产品，是大而广的，但不会太精细地去关注具体的细节。就如软件实现阶段的实现细节，系统设计师不应该去关注这些细节的，软件架构师却更多的关注在上面。

        两个角色的主要职责是不一样的，有时候还会出现对立和冲突的情况，由于各自处于的出发点不一样。系统设计师，可能为了满足客户的时间需求和快速占领市场的期望，希望较快地生产出产品，所以产品能满足基本功能就符合期望了，不一定是一个完善的优美的产品；而软件架构师，当得到功能需求时，更多地考虑是软件如何实现地比较完善，对原有产品代码复用或不产生不利影响，考虑到后期可能会有的新需求和功能扩展，这样必然需要更多的时间去分析，设计和实现。这种冲突，经常会发生，最后只有两者相互妥协，看似双赢，但问题还是可能在某个时候暴露出来。

        理想状态下，需要两者相互理解对方的痛点，减少冲突。但大家都知道，站在自己的角度去理解对立面是比较困难的，所以最好的方法是，让两者相互学习，融合成一个角色；但两个角色有各自的特点和侧重点，软件架构师并不能被系统设计师代替。或者说，当一个人从软件架构师转变成为系统设计师之后，其软件架构师的能力会慢慢被实际工作所弱化。在实际工作中，相互学习的最后，基本都转变成了系统设计师，也许这就是软件架构师到系统设计师的成长过程。