问题汇总

1. 代码追溯困难，在代码向上追溯的过程当中，如果是遇到 configuration 的管理，如果没有在当前代码中定义，则很难梳理当前代码的逻辑。
   工作中难免需要阅读源码。我个人的习惯是，首先按照调用链，梳理调用逻辑，其次，对每一个类进行归类整理，形成一个调用的基本思路，进而，对代码进行代码进行分层结构，初始化/配置/调度/执行，层次要清楚，对软件设计者才会又一个相对完整的理解。
   然而在这种进度当中，有一些代码的可读性比较差，值得以后在工作中要避免。
   在 Configuration 这一层，如果引用了一些东西，尽量声明出来，并且保证可读性。
   比如说，产品引用了一些环境变量，那就把如何取的环境变量放到一起，如果到处找的话，会很困扰。
   configuration 这类东西，本身就是一种状态，尽量的需要放在数据库当中，这样，在使用的时候，程序本身管理逻辑即可。

想到哪里讲到哪里，以上

1. cli 好用，但是仅限于在交互环境中，如果是一些项目当中，代码里面使用 cli， 会造成困扰。而且 cli 的颗粒度实在是太大。用语言调用api 的方式，可以更好的进行复用。

工作习惯

1. 在 Jenkins 的 dev 习惯当中，如果要引用 sdk ，可以去看一下是否有相关的 plugin，如果有，就避免在 job build 过程当中引用第三方包，造成时间上的浪费。
2. Map 固然好用，传参的时候，如果里面的参数是有固定的内容，可以考虑定义再 model 里面的 class 里，这样能够提升一定的可读性。
3. 变量传参后，如果是一个变量传参到多层的类当中，变量尽量保持一致，以提高可读性。

吐槽

1. 这个领域工作时间久了，你动一下脚尖，距离你十米的一根棍子到了，你会觉得这个可能和你动脚尖的行为存在关系，并且确实会思考为什么。