我觉得架构这个词太高大上，设计也是，每次遇到要自己设计的工单，脑袋都发胀，但是我现在也有了自己的一点理解，所谓架构和设计其实都是为了一个目的，那就是避免以后遇到麻烦。作为一个初级工程师，在工作能接触到的麻烦有代码难以理解，这个是刚入团队的时候会经历的，还有代码可以理解但是它实现的功能和它写的是不一样的，这个也是个揪心的问题，每次都要把代码从上到下理一遍，不然以后就是一个坑，还有代码的概念很多，理不出一个大致的框架，这个也是个问题，但是一般影响最大的是团队的leader，因为他经常要考虑代码的结构是不是简单。
想一下解决的方法，其实就是要写的时候多考虑，代码多了以后要考虑重构，避免太难读的方法有，一个名字不能超过三个单词，如果超过可能就需要重构，不要自己创造概念，毕竟别人不懂你的概念，使用已有的框架，因为他们有成熟的文档，并且不用你维护，更别提还有社区的力量帮你解决问题，请把一个包下的东西都起一个后缀，表示他们是一个东西，我因为这个问题花了三天的时间看代码才理清了功能，如果有可能请写和业务无关的代码，比如找到一个购物车里最近添加的一个商品，正常的思路是先按时间排序，然后取第一个或最后一个，熟悉java 集合stream的观众已经想到了，用一条stream就可以做到了，但是我觉得可以更好，因为我经常遇到掉别人接口的事情，如果他已经写好了某个小功能，我能直接调来用的话，我会非常高兴，而且写代码要花的时间真是超出你想象的长，能避免当然就避免好了，所以可以写成一个排序方法，和一个取最大值的方法，功德无量。
代码结构的问题，我觉得如果leader能够画个图来解释一下，应该会很好，因为好懂，而且成员有一个共识，review的时候负担可能不是那么重。
最近我的leader要离职了，团队里出现没有一个人能够清楚的知道整个项目内容的人，所以如果当leader的话，文档写的好还是很重要的，另外双leader的模式是否可行呢。