相较起2018年，2019与之前多有不一样。2018年的年末我突然意识了一件事情，看这么多书，如果没有用的话，那岂不是没有用出。而且我看的大多数，都不能实际转化为我写代码的能力。那我看哪些书有什么用处呢，难道只是为了口嗨，我今年看了什么什么书，陷入一种自我欺骗之中。于是，我打算在2019年，多写代码，多看代码，多看一些能在日常打代码之中用上的东西。
从2018年年底开始，开始做企业相关的东西，这一部分主要涉及到一个权限系统。权限系统，说简单，可以做得很简单，在做某一个动作之前，查询用户是否拥有这一权限，也就是selectbyid即可。但是做企业系统就涉及到，企业之间部门之间的关系，资产之间的关系。企业A的员工甲拥有权限α，那能否对企业B的员工B执行动作α法？那当然是不能的。那么这块就涉及到权限检查的升级抽象。我这一块我自己想的是设计模式来做的，也就因此买了一本Head first设计模式。里面介绍了一些常用的设计模式，其中就包括了大名鼎鼎的mvc模式。但是有些时候，解决问题的思路并不只是只有一种，因为数据源和公司开发职能的问题，权限并不需要尽善尽美，所以这一套系统设计被推翻了。换成了之前的所说的简单查表，而其他权限检查并不需要权限系统过问。
之后陆陆续续地看了其他项目组的一些项目，像是渲染组和一些中台组的代码接受了一些其他组的代码思想。也有一些自己的想法：代码怎么写才算写得好？其实这个问题我一直又在思考，毕竟我是想写出好代码的，那必须要知道什么代码才能算是好代码，总不能说我虽然并不知道我想去哪，但我也要先朝着目标出发，这种铁憨憨发言。。。。。。我之前有想过，代码写得越高级，复杂度小还是代码写得快好（不要问我写Bug怎么算），这是一个质量理念还是数量理念问题，以我现在的眼界和身处的职位来看，代码还是写得越快越好，写得越快，你越能省下来时间去做别的事情，毕竟精力有限。至于怎么算写的快，就在于高度自动化。以我们组的项目来看，复杂的系统大多都不会是一个独轮车，而是一组精密的齿轮组，这种系统的特点就在于会一处配置，多处使用。举一个最简单的例子来说，我开了一家餐厅，看人上菜叠。如果是普通人就给他上家常炒菜的菜单，如果是有钱人就给宫廷酒席的菜单，总而言之，根据不同的 customer type返回不同的菜单，也就是不同的数据。那么我就可以在后台数据库直接配上一套customer type将他和菜单关联起来。当然在第一次遇到的时候，可能并不知道在这里需要，假设当然我的餐馆需要服务的客户只有普通人，那么我写死才是最好的选择。这里我的想法是，如果同样的事情，碰上了两次，那么这里有应该被自动化改造。
除此之外，大部分时间在做Kubernetes和Istio的配置， 这两个框架也算是云原生框架中比较出名的了。这对我而言有种考古的意思在其中。这部分代码是我一个学长离职交接给我的，所以在没有文档和注解的帮助下，只能生啃文档，并结合实际上环境上的配置一点点试出来。不过，这一方面我一直没有想明白其中的业务价值所在，所以一直有些不明所以。按照我现在理解，我们可以用Kubernetes和Istio做一些除开发之外的事情，算是另一种解法，比如说，进行灰发测试，进行路由管理，但在我的印象当中，没有这两样东西的时候，也有其他方案可以解决。所以说，应该是两大框架的存在对我说的东西进行了一定程度上的检验。同时，因为源码的关系，进行Go语言的学习，并尝试用Go语言的框架进行一个网站的搭建，以起到练手作用。
其实我自己仔细想想，感觉2019年过得有些失败，好像没有什么拿得出，可以值得称道的成长或者成就，说好听一点，算是稳扎稳打了一年。在自己所负责的事情领域，大概知道如果有新的需求应该怎么做，上下游同事的处理，与一些紧急情况的处理方法。写到最后，又仔细思索了一下，也勉勉强强算是有一点成长，大概知道2020的发展方向有什么，要把一些什么事情解决，这一点上算是比去年强。去年的这个时候，还在摸索在公司里求生的边界。嗯，勉勉强强吧。
