擅长某种抽象思考

　　刚才看了一篇博文，写自己开发遇到的bug。第一个bug就没看下去，因为主要是异常自己没处理导致没有发现更底层的错误上报。

　　这些东西在我看来，根本可以避免。开发环境里，有时候遇到一些api没有封装好权限，一直查看如何把这些权限封装好，老板却说没有必要。后来受到攻击，整个行业都受到攻击同行也没设置权限。本来这些都可以避免。可能是公司没有足够大的原因。

　　有很多问题在开发的时候能推测出来会造成一些漏洞，因为技术的原因或者开发进度的原因没有及时补好这些漏洞。如果随着时间回来补好就可以。经常看到一些比较违背直觉的做法，可是也说不出来为什么，等很久之后才想明白有什么不好。最开始就知道不去那样做，只是不知道为什么于是没办法告诉别人。

　　经常看别人说设计模式复用，我看设计模式看一会儿就睡着了。都是一些很普通的思考，项目里很多封装都需要临时的灵活变动，和那些多少个设计模式没有什么关系或者说根本不用理会这些名词，用该做的聚合以及分包解耦把逻辑写好就可以。

　　在不清楚怎么写的时候往往是变动的需求，未来走向不可知。这时候用最简单的方式实现就可以了，然后等未来发生变化的时候根据已经确定的方向做调整。可以增加开发速度并且维持高度可扩展性，同时需要不断轮回开发。做好现有功能的同时根据当前状况对以前的一些功能做调整。

　　写代码的时候业务逻辑的实现，像是做数学题的解题。我的解题能力，比作扛哑铃的话，力气还相对比较小。没有得到很好的锻炼。可是在分包和整合，让程序怎么写容易维护，优化业务这些方面，思维相对来说有些异常的灵敏。写代码的时候经常考虑用最小的力气直接实现目标。有些因为本来就是“力气小”，也有些因为比较擅编排周围资源，直抵完成目标任务。