架构师训练营总结 -20200614

在这周的架构师训练营中，我们简要回顾了UML的使用场景，李老师也分享了一个他自己刚开始工作的时候，对于工作中技术点与上级的主动交流、反馈，之后承担项目中关键代码的架构，最终达到“其它开发人员依赖自己的代码”这一目标的经历。



个人认为通过老师分享的这个经历，首先说明了是不是有一个架构师的title不是最重要的，最重要的是实际在做架构设计的事情，是不是让其他人依赖于自己写的代码。只要上述目的达到了，那么不需要任命，自己本身就已经是架构师了。



其次个人认识到UML在实际工程中的作用，是用来表达自己的设计思路，并与其它相关方进行沟通的。UML在大学的软件工程中就学过，但是平时使用的机会不多，或者说自己并不重视对UML的使用。通过本周的学习个人意识到，UML图的成本比起实际的代码开发来说要低的多，也便于提前发现问题并进行修改；另一方面可以通过图向相关方表达自己的思考结果，提高和相关方沟通的效率，使得相关方可以更好的理解自己的意图，评估方案的可行性，并争取到相关方的支持。反思自己在工作过程中，只有遇到较大的项目，需求方提供了一定的前期调研时间的情况下，才会考虑通过UML对数个关键功能点进行建模，并且大多数情况下可能只有一张时序图或ER图，不足以说明自己的设计意图，剩下的大部分内容还需要在会议上进行口头表达。基于之前课程中提到的4+1视图，个人考虑在之后的工作中逐步引入UML工具辅助自己进行思考，也尽量在会议上通过UML表达自己的设计意图。



周六开始的课程中我们学习的软件设计的原则，并通过数个设计模式和安利对具体的软件设计原则进行了说明。和UML类似，我在之前的工作中一直认为软件设计原则和设计模式离我们的日常工作很远，通常是因为要换工作要面试而去突击复习强化记忆，找到新工作之后就逐步淡忘了。而通过本周课程的学习，我开始认识到不同软件设计原则和设计模式带来的稳定性、灵活性上的提高，最大的收获在于弄清了“为什么我们需要学习软件设计模式”和“软件设计模式是用来解决什么的”这两个最重要的问题。随着现代社会越来越高速，人们对软件开发的周期要求也在不断的缩短。现在的软件需求恨不得提出后一两个小时就可以开发测试完毕并发布上线，因此之前我在工作中常常省略了设计过程，按照流程说明直接进行开发，虽然可以满足一时的上线需求，但是当需求变更过几次之后，常常会发现自己开发的代码变得难以维护，并且进入到“测试时间更长-加班保证开发进度-代码更难以维护-加班时间更长”的恶心循环。通过本周的学习对个人在工作方式上有了新的启发，一个良好的软件结构设计应该可以使我们更轻松的实现新的功能，同时不影响已有的功能。因此接下来个人打算对一些实际工作过程中的非重点功能进行重构，看看实际效果如何。