初来乍到
入职第一天，领了本破烂ThinkPad（和自己的同模具..），战战兢兢，对着新人文档从jdk1.8开始配置环境。
- 打开项目满目飘红，依赖下不来，找公司的老同志要了份公司内部的maven配置文件，解决。
- 花了一会儿功夫理解了DEV、QA和PRD的区别，被告知可以在DEV随便乱搞（bushi）。
- 注册公司产品，下载内部测试版APP，学习使用内部的抓包工具。
- 在内网乱逛，熟悉各种平台，包括WIKI，工单系统，配置中心，监控平台，造数平台...
搞完这些去找mentor要活儿干，妄想接个需求做做，mentor太忙，反手丢了两个项目给我看，找人要权限（实习生什么权限也没有，悲），拉代码，一番折腾。
几乎没有文档，屎山代码看得我头昏脑胀。
总体感受是，代码比较规范，也比较简单，但我不知道它们有什么用。
业务不是通用的，这一点和技术不一样。
在这段实习中，怎样才能在业务以外的地方学到通用的东西带走呢？
屎山遨游
下午leader找，模块重构，直接把公司的核心屎山丢给实习生梳理。
起初我觉得用屎山形容各位老同志们的代码是大不敬，在看了一下午之后我只觉得很贴切。
平心而论，老同志们写的代码挺整洁也比较规范，各种新特性（新但不是完全新）比如Stream API满天飞，拆开成一个个方法看，都没什么问题。
主要的问题包括，随着迭代项目结构逐渐混乱，不同技术混用，过期代码没有下线，代码冗余。
对照设计模式的六大法则
- 单一职责
- 开闭
- 面向接口
- 接口隔离
- 迪米特
- 里氏替换
做得比较好的只有单一职责和与面向接口。
从历史代码来看，最初的架构是比较合理的。各种设计模式，工厂、外观、代理、建造者、适配器等等都有很合理的实践。
但随着需求不断变化，新增需求越来越多，最崩坏的是接口隔离原则，若干个长达好几百行的类给我留下了深刻的映像（其实都是if-else）。
AOP也没有很好地运用起来，多处重复的前置处理与后置处理并没有被抽离出来。
其次，技术的混用也是比较常见的问题，部分自研的中间件或框架与原生API共存。
此外，居然出现了（应该是由于交流的问题）不同的开发为了同一个需求创造了两个结构一样的不同名bean的现象...
一个架构很不错的项目是怎样一步步沦为屎山的呢？这个过程大概是不可避免的，所以才需要不断重构吧。
打卡下班。