工作这东西，还得经常回顾。理理自己做对的事、做错的事，保持大脑清洁。
软件开发过程中，从需求到实现到维护，应该表现出来的素质：
1. 充分理解业务需求
我们不仅仅是实施者，也是设计者。
动手前，先理解业务逻辑；从用户和产品经理的角度想，每个功能点为什么要这样做。
为什么要理解业务？因为要提高开发效率。原因如下：
产品经理画的原型只是产品的输出形式，内核是代码逻辑。就像一个人，与外界交互的媒介是皮肤、衣服，支撑人的生命的身体内部机理。
界面上一个按钮，背后可能牵连很多工作。例如，一个融资放款，需要记录放款，同时要扣减授信额度。
这跟开发效率有什么关系？因为可以避免代码逻辑错误。
在理解业务需求的过程中，你可能有疑问，你需要跟leader或者直接找产品经理讨论。讨论的过程中，要么是你对了，产品设计需要修改；要么你错了，但是获得及时更正；要么你们的意见互补，使产品设计更加完善。
总之，在动手之前，将要实现的功能理清，可以避免推倒重来。
2. 能想到的尽量做好
对于前端，能限制用户行为的、帮助用户理解功能、引导操作的等等，都做好。操作简单很重要，输入限制做好很重要：一是提高用户操作成功率，二是避免后端校验，提高效率。
对于后端，先结构化代码。事先想好结构，避免代码混乱，责任不清。结构清晰的代码，使得自己的思路也清晰，容易扩展、容易修改。
3. 会用也要懂原理
框架加速了开发速度，但是应用不当就很难发现问题。不可简单模仿，更要懂原理。例如，Spring的方法注解，在这个方法作为这个类第一个被调用的时候才生效。
4. 自查自测
第一遍写完的代码很大很大概率上是有bug的。写完一个方法，重读一遍，可能发现逻辑错误。
像考试一样，检查完之后，要对答案，也就是自测。运行一下，看看结果是否是预期的。
把自己能力范围内能发现的错误尽早解决，一是为了消除潜在问题，二是避免打脸。
5. 正确的合作方式
首先自己写好注释，帮助别人正确调用你的方法，避免出现问题，减少沟通成本。
其次仔细阅读对接文档，别人写的注释，不要浪费同事的时间。
工作对事不对人，不带情绪。理解同事的想法，不带个人感情色彩。每个人的想法不一样，在充分理解对方的想法之后再下结论。
6. 重构代码，提高可维护性
没有完美的代码，尤其是项目紧急，匆匆忙忙写完的代码，简直不堪入目。重构代码的目的就是让代码更好维护，当然要回测，避免重构引入了新问题。
这个月做一个项目，昨天初步验收，暂告一段落。昨天本来可以早点放假。但是在验收过程中频频出问题，其中也有我的贡献，很惭愧。这件事促使我写这篇小结。
我要我们的团队因为我的存在实力更强～
