Open rooobot opened 4 years ago
第二周的第二次课，感受还是挺深的，其实第一周的课，老师提出的一些实际中发生的问题，以前也碰到了不少，可能因为太习惯了，所以感受不太深吧。
周六的课感受还是比较深的，有两点吧：
首先是第一点，关于面向对象设计的原则，可能基本上大家都知道SOLID，但是，估计没有多少人对这几点原则有足够深刻的认识。从老师的授课能感受到，老师身为一线顶级架构师，对这些基本的原则的理解足够的深刻（这是从真实的架构师身上感受到的）；
SOLID
另外，再看Spring框架的源码、Dubbo框架的源码，这些优秀的框架的实现者，将这些基本原则发挥得淋漓尽致，刚入行的那几年，看着Spring的源码都头大，太多的接口、太多的类，从接口到具体的实现类中间又隔离很多层实现，有abstract的，也有具体的，这样的设计，在当时的我看来除了头大，是没办法深刻理解的，时致今日，我已经能明白这种设计的重要性：接口需要隔离变化，从接口到具体的实现类中间有多层分层是因为框架的整体设计上有不同的分层实现，不同的层有不同的职责，这就涉及到高层与低层之间调用关系的问题，所以框架的主体设计定下之后，每个模块的实现也会遵循框架主体的设计原则，这样做的目的，无非都是为了可扩展性和可维护性。
Spring
Dubbo
abstract
面向对象设计的原则这几点只是冰山一角，其实落到实处的时候，太多太多的细节会依赖于我们对一些基本原则、基本原理的理解，如果对这些层底的原则原理理解不够深刻，我们是无法变得更优秀的。但矛盾的是，平时的工作或是学习中，大多数时候，我们无视这些底层的理论，一方面可能是因为从字面上或是别人举的一些简单的示例来看，感觉挺简单的，所以不在意，另一方面可能因为我们自身所经历的业务或是经验不够，所以没办法从更宏观或是多种不同的角度去深刻理解这些底层的理论知识吧，从而导致我们无法快速成长到下一个阶段。
其实，本质上还是一样的，学技术应该重视基础、重视基本原理，具体技术层面有技术层面的基础和原理，理论也一样，理论也有理论的基础和原理原则，很多行业内大师级的人物写过一些经典的杰作，以前读不懂，当到了一定的阶段，应该反复的去多读几遍，这个过程是锤炼自己思维思想的过程，这个过程是痛苦的，但收获是不言而喻的。道与术相辅相成，二者不可或缺。我想或许我找到了一直以来，自己总感觉缺点儿什么的那个部分了吧。
一个人摸索的道路上挺迷茫的，无法构建知识体系，不知道想法是否正确，不知道如何触及下一阶段的门槛等等，只有与优秀的人放在一起一比较，才能让自己显出原形，看到自己的不足，这也是我想参加这个训练营的初衷。
李老师周六的课已经可以把周四课后大家的疑虑全部打消了，至少对我而言是的，并且给我建立了充分的信心，现在更加的期待下次的课。
另外一点就是老师说到的和产品经理合作的问题，我感受挺深的，因为最近几年，我自己本身就经过过作为开发人员和架构师不同的角色与产品经理合作的过程（虽然最终因为其他原因没有被定岗为架构师，但不影响我作为架构师的角色所做的事情）。
我个人的感受是，作为开发人员，和产品经理合作的过程，需要足够的去关注业务本身，这一点老师在课上也有说，产品经理是直接面向需求方的，所以他对需求的理解从某种程序上说是会比开发人员深刻的。作为开发者应该多去与产品经理沟通需求，不要放过任何一个有疑问的点，充分理解需求之后，结合自己所要实现的模块去从技术层面考虑有没有什么问题，有没有不合理的功能（所谓的不合理需要结合业务场景来看，有时候需求本身是一回事，产品经理的理解又是另一回事，所以碰到有疑问的需求时，尽量去和产品经理对一对需求方最原始的需求，避免产品经理二手的理解导致开发实现的问题），同时，作为开发者也有责任和义务向产品经理解释清楚（要让产品经理真的理解为什么不合理），产品经理也是人，你向他解释了，如果是真的不行，大多数情况下他是能接受的，就事论事，就算他不认同，你向他解释清楚了这么做的后果，他愿意接受，大家书面上确认了也没问题，但这不是解决问题最好的方式，大家都需要站在公司的立场去考虑。
作为架构师和产品经理合作需要架构师站在更大和更高的角度去考虑需求。因为关注点不一样，开发人员更聚焦于业务功能本身，而架构师要全盘整体考虑，从系统层次的角度来看：整体架构、需求边界切分、服务拆分、系统部署等整个流程的各个点都要考虑到，而且这只是高层的切分，具体到每个部分，又有很多细节的地方要考虑；从开发的角度来看：系统的分层、技术的造型、业务的难点如何实现等，同时还要在和产品经理的沟通过程中，把握住潜在可能变化的需求点，在设计时做好松散的设计，为将来的变化预留好可扩展性。有些时候，因为一些不太合理的需求或是交互，还要和产品经理去沟通，说服对方也做出一些修改变化，基本上这种情况下，都需要架构师给产品经理解释为什么不可行，有什么变通的方案，前后的区别在哪里，为什么。
其实，我个人觉得当你觉得工作中的某相关方很强势时，多数情况下是因为你的能力没有让对方信服，所以对方表现出强势和自信，如果对方是对的，那就不用多言，如果不对，你就需要用你的专业来以德服人。
以上是第二周课后的一点随想和感受。
第二周的第二次课，感受还是挺深的，其实第一周的课，老师提出的一些实际中发生的问题，以前也碰到了不少，可能因为太习惯了，所以感受不太深吧。
周六的课感受还是比较深的，有两点吧：
首先是第一点，关于面向对象设计的原则，可能基本上大家都知道
SOLID，但是，估计没有多少人对这几点原则有足够深刻的认识。从老师的授课能感受到，老师身为一线顶级架构师，对这些基本的原则的理解足够的深刻（这是从真实的架构师身上感受到的）；另外，再看
Spring框架的源码、Dubbo框架的源码，这些优秀的框架的实现者，将这些基本原则发挥得淋漓尽致，刚入行的那几年，看着Spring的源码都头大，太多的接口、太多的类，从接口到具体的实现类中间又隔离很多层实现，有abstract的，也有具体的，这样的设计，在当时的我看来除了头大，是没办法深刻理解的，时致今日，我已经能明白这种设计的重要性：接口需要隔离变化，从接口到具体的实现类中间有多层分层是因为框架的整体设计上有不同的分层实现，不同的层有不同的职责，这就涉及到高层与低层之间调用关系的问题，所以框架的主体设计定下之后，每个模块的实现也会遵循框架主体的设计原则，这样做的目的，无非都是为了可扩展性和可维护性。面向对象设计的原则这几点只是冰山一角，其实落到实处的时候，太多太多的细节会依赖于我们对一些基本原则、基本原理的理解，如果对这些层底的原则原理理解不够深刻，我们是无法变得更优秀的。但矛盾的是，平时的工作或是学习中，大多数时候，我们无视这些底层的理论，一方面可能是因为从字面上或是别人举的一些简单的示例来看，感觉挺简单的，所以不在意，另一方面可能因为我们自身所经历的业务或是经验不够，所以没办法从更宏观或是多种不同的角度去深刻理解这些底层的理论知识吧，从而导致我们无法快速成长到下一个阶段。
其实，本质上还是一样的，学技术应该重视基础、重视基本原理，具体技术层面有技术层面的基础和原理，理论也一样，理论也有理论的基础和原理原则，很多行业内大师级的人物写过一些经典的杰作，以前读不懂，当到了一定的阶段，应该反复的去多读几遍，这个过程是锤炼自己思维思想的过程，这个过程是痛苦的，但收获是不言而喻的。道与术相辅相成，二者不可或缺。我想或许我找到了一直以来，自己总感觉缺点儿什么的那个部分了吧。
一个人摸索的道路上挺迷茫的，无法构建知识体系，不知道想法是否正确，不知道如何触及下一阶段的门槛等等，只有与优秀的人放在一起一比较，才能让自己显出原形，看到自己的不足，这也是我想参加这个训练营的初衷。
李老师周六的课已经可以把周四课后大家的疑虑全部打消了，至少对我而言是的，并且给我建立了充分的信心，现在更加的期待下次的课。
另外一点就是老师说到的和产品经理合作的问题，我感受挺深的，因为最近几年，我自己本身就经过过作为开发人员和架构师不同的角色与产品经理合作的过程（虽然最终因为其他原因没有被定岗为架构师，但不影响我作为架构师的角色所做的事情）。
我个人的感受是，作为开发人员，和产品经理合作的过程，需要足够的去关注业务本身，这一点老师在课上也有说，产品经理是直接面向需求方的，所以他对需求的理解从某种程序上说是会比开发人员深刻的。作为开发者应该多去与产品经理沟通需求，不要放过任何一个有疑问的点，充分理解需求之后，结合自己所要实现的模块去从技术层面考虑有没有什么问题，有没有不合理的功能（所谓的不合理需要结合业务场景来看，有时候需求本身是一回事，产品经理的理解又是另一回事，所以碰到有疑问的需求时，尽量去和产品经理对一对需求方最原始的需求，避免产品经理二手的理解导致开发实现的问题），同时，作为开发者也有责任和义务向产品经理解释清楚（要让产品经理真的理解为什么不合理），产品经理也是人，你向他解释了，如果是真的不行，大多数情况下他是能接受的，就事论事，就算他不认同，你向他解释清楚了这么做的后果，他愿意接受，大家书面上确认了也没问题，但这不是解决问题最好的方式，大家都需要站在公司的立场去考虑。
作为架构师和产品经理合作需要架构师站在更大和更高的角度去考虑需求。因为关注点不一样，开发人员更聚焦于业务功能本身，而架构师要全盘整体考虑，从系统层次的角度来看：整体架构、需求边界切分、服务拆分、系统部署等整个流程的各个点都要考虑到，而且这只是高层的切分，具体到每个部分，又有很多细节的地方要考虑；从开发的角度来看：系统的分层、技术的造型、业务的难点如何实现等，同时还要在和产品经理的沟通过程中，把握住潜在可能变化的需求点，在设计时做好松散的设计，为将来的变化预留好可扩展性。有些时候，因为一些不太合理的需求或是交互，还要和产品经理去沟通，说服对方也做出一些修改变化，基本上这种情况下，都需要架构师给产品经理解释为什么不可行，有什么变通的方案，前后的区别在哪里，为什么。
其实，我个人觉得当你觉得工作中的某相关方很强势时，多数情况下是因为你的能力没有让对方信服，所以对方表现出强势和自信，如果对方是对的，那就不用多言，如果不对，你就需要用你的专业来以德服人。
以上是第二周课后的一点随想和感受。