近期的感悟

1、先要观察，然后才能"采取行动"。

这个采取行动是指你接下来做事的方式，因为新公司的项目比较大，然后协作开发的人特别多，同时开发之间的水平也是参差不齐的，每个人的代码风格也是一样，有的时候有些特别有问题的代码我最开始是会直接指出来的，因为作为一个整体，大家以后维护这种代码是特别麻烦的，尤其的写内存泄露的代码和无脑堆砌代码，但是奈何说了没用，这种东西估计要领导重视去主动推才行，后面我也感觉其他人 好像并不喜欢这种直接指出来代码内存泄露或者非线程安全这种。其实想想也是，这主要是我的问题，不能以自己的想法去套在其他人那，我觉得项目代码设计得好一点后面好维护，当然这是指我们在时间和能力范围之内，但是经过一段时间的观察，我感觉很多人其实只是想着场面上过的去的心态，准确的说应该非常多人都这样想的，其实这种想法才是真实的大多数，应该很少有人会想着把项目当做作品去打磨，在最开始我和同组内另一个安卓同事会积极去指出其他不对的地方，但是遗憾的是并没有同事愿意加入其中并修改讨论不对的代码，我也不反对别人指出我的代码漏洞，相反这是好事，因为至少我知道了这是错误的或者低效率的代码，作为技术人员来说，专业能力是不进则退的，因为别人都在成长而你原地踏步，时刻保持敏锐的危机感还是有一定必要的。

2、先要观察你需要做的是什么以及公司需要你做的

这个 比较抽象，简单的说我目前的公司是乙方，甲方是各种银行，我们做的项目就根据需求文档和客户各种讨论，这种项目不像做自家产品所有的逻辑都有产品经理预先设想好了，大部分的逻辑是需要看文档的，这就需要你有一定耐心，然后你在写的过程中会发现文字能表达的东西是有所局限性的，客户写在文档上的和你理解的不是一个东西，或许你会问了，为什么不第一时间问客户呢，我个人感觉这是一个开发流程上的 bug，做这个项目很多模块了，我们在最开始编码阶段是接触不到客户的，你说扯淡不扯淡，等我们编码完毕，自家公司测试通过后才开始和客户测试，这个时候又开始大改，因为理解有误也有可能是客户就是要改或者要加其他的东西，这个时候整个的逻辑你要全盘记住，因为一个口述的逻辑的新增会影响到其他之前的逻辑，但是客户是不会帮你预判到这些问题的，当我们在写的过程中发现的逻辑漏洞也是需要我们去总结跟客户反馈，然后客户再给出他们想要的方案，简单的说就是搬砖，其实毫无技术含量，只是需要你的耐心、细心和记忆力，无需高超的技术能力。

2、不要忘记持续学习

很多时候，我们整天忙于业务代码，忙于加班自我感觉很充实，时间每天都很紧没有浪费，但是其实并没有长进，这个时候我们需要看别人的代码学习，看博客学习，看开源框架学习，首先要先补足自己基础上的不足，然后再去学那些术层面的，因为基础属于道，这些东西的"保质期"长到比一个人的一生还长，但是像 RxJava、OkHttp等等这种第三方框架是更新淘汰非常快的，尤其是前端的框架。