开发实践思考（四）

本篇接上一篇《开发实践思考（三）》，继续汇总思考点，每篇10个。

1. 使用引用来捕获异常

通过引用捕获异常，不会有对象删除问题，也不会发生slicing异常对象问题，异常对象只拷贝一次。

2. 数据绑定思想

将UI展示信息和实际关联数据绑定在一起，而不要人为拆分开。

举个例子：

假设有一个下拉输入框，里面有：苹果、香蕉、全部等三种选项。对应入参为1、2、空。那么按照上面的思路，是将文字，例如苹果和"1"建立关联关系。当需要获取对应的入参时，可以直接获得“1”，而不是先获取“苹果”这种字符串，再通过各种if推导出数值"1"，后面这种硬推导的方式，笔者称为硬编码。

且不说硬编码中转换函数归属问题，这种实现方式在扩展性和使用上都不方便，很容易遗漏，不建议使用。

更进一步思考，这种数据绑定思想，可以用在多语言、多颜色、多风格等场景。将绑定关系写在配置文件中，使用配置中的key初始化界面数据，绑定对应的value进去。系统初始化时，根据不同环境加载不同配置文件，得到不同的效果。

基于上可以更进一步，配置文件增加版本信息以及校验信息，启动时由后台推送，达到配置实时升级的效果。

3. 总结复盘

任何工作都需要回顾总结，大到系统项目，小到具体需求，如果在完成后缺乏总结，那么从某种程度上来说是失败的，有以下可总结的方向：

1. 通过这个项目/需求，是否吃透了某一块的业务，搞懂了来龙去脉？
2. 通过这个项目/需求，是否充分理解了公司某个技术框架/基础组件的用法？
3. 整个项目的设计上，有哪些做的不好的地方？
4. 在整个项目的开发上，是否踩了坑，犯了低级的错误？
5. 在整个项目的进度把控、人员安排、上下游协调上，是否存在不足之处？
6. 遇到突发事件，是否快速有效的进行解决，缺乏哪些东西阻碍了问题的快速解决？

通过充分的总结，之前犯过的错误我们不会再犯，理清楚技术和业务的来龙去脉，对自己是一种提升，总结沉淀下来的文档，对别人也有很大帮助。

4. 理解消防

消防，消指的是消除问题，防指的是预防类似问题再次发生。在平时的处理Bug以及线上问题上，也是同样道理，先及时解决问题，然后深挖问题根源，对问题进行复盘。

不仅仅要解决已出现的问题，更重要地是挖掘隐藏的同类问题，一起解决。

通过分析同类问题，分析出现该问题的根源，从最佳实践、规范用法等方面向团队成员讲解，防止后续犯同样的错误。

5. 海恩法则

海恩法则是航空界关于飞行安全的法则，它指出，每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。据此分析，

当发生一件重大事故后，我们在处理事故本身的同时，还要及时对同类问题的“事故征兆”和“事故苗头”进行排查处理，以此防止类似问题的重复出现，及时消除再次发生重大事故的隐患，把问题解决在萌芽状态。

海恩法则强调两点：

1. 事故的发生是量的积累结果
   2 再好的技术，再完美的规章，在实际操作层面，也无法取代人的素质和责任心

6. 发布注意

新功能上线发布时，要有平滑过渡机制、应急处理机制、旧方式下线方案等辅助措施。

每发布一项新功能，都需要有后台开关来控制，一些有可能会更改的参数，不要在前端写死，而是通过从后台获取的方式来进行。这样，当出现问题后，不至于没有控制手段，眼睁睁的看着问题扩大。如果涉及到的业务较多，那么开关控制粒度要细，包含功能总开关和各级子功能开关。

对于每个线上发布版本，要进行分支封板操作，在该分支上，除非有线上紧急Bug，否则不能有任何提交，保证线上版本和源码版本的一致性。当该版本线上有问题时，取出该版本分支进行处理。

7. 开发目录和发布目录

不要从开发目录中直接打包程序，因为开发目录会频繁改动，贸然打包，可能会导致以下问题：

1. 打包时，本地还有未提交到代码库中的代码，打包后输出给测试，后续继续在开发目录中修改后再提交，这会造成测试版本和开发分支版本不一致。
2. 如果本地尚未提交的代码被撤销了，而打包的是撤销前的代码，也会造成测试版本和开发版本不一致。

最佳实践：
发布目录需要独立出来，在该目录下，通过自动化构建脚本，从代码库中获取最新代码，编译成Release版本后再发布。该目录只做编译发布工作，禁止任何代码以及配置的修改。

8. 汇报工作

撰写工作汇报的作用：

1. 让领导看到你，不做职场小透明。

   你写了工作汇报，领导才知道你做了什么，才能看到你。

   对于你来说，只需要面对一个领导，但对一个领导来说，要面对多个下属，均摊到每个下属的注意力实在太少。而他了解员工工作情况最方便的方法，就是看工作汇报。因此，当你敷衍工作汇报时，实际上是在敷衍自己。

2. 及时调整工作方向，避免做无用功。

3. 在工作汇报中，不仅要写已经做过工作的结果，还要写中间遇到的困难，目前采取了哪些方法，需要什么样的资源来协助推进。让问题提前暴露，不要让问题烂在我这里。

   作为领导，最担心的是下属遇到了问题，却不告诉他，直到该问题带来的影响越来越大，最后兜不住了才爆发。
   领导就是你最大的资源，要好好利用。

一份优秀的工作汇报需要做到：

1. 描述工作背景: 在汇报工作前，要说清楚这件事的背景

2. 当前该项任务遇到了什么问题，当前采取了哪些措施，取得了哪些效果
   一方面体现解决问题的能力，另一方面体现总结能力。

3. 汇报工作结果并进行小结。
   当前该项任务进行到哪一步，有没有阶段性的成果输出，输出数字跟过往相比，是增加还是减少了？简要分析下原因。
   实事求是，不要担心业绩降低就不汇报，报喜不报忧在这里是不适合的。
   只要你尝试解决过问题，就要写出来，让领导看到你是在推动问题解决，而不是坐等问题在自己这里烂掉。

4. 未来的打算和计划
   汇报完过往之后，接下来要说未来的计划和打算，让领导审核下，未来计划的可行性，未来大方向下的继续前行的必要性？
   无论是过去的工作遇到了问题，还是在新的计划需要领导帮助，都要及时提出来，让领导知道你的难处，解决你遇到的麻烦，需要什么样的资源来推动该问题的解决。

在撰写工作总结时，有以下套路可参考：
* 业务功能开发（其实是做需求）
* 业务功能优化（其实是改Bug）
在写解决Bug，不管解决过程多么惊心动魄，解决方案多么合情合理，这都是建立Bug的基础上。在写的时候，可以着重的地方。换一个视角去看待这个问题，比如，从功能优化的角度来看待，是不是觉的，之前写的不是问题，现在做的是在改善程序效率？
* 即使是手头上的项目没有进展，也要提到。XX项目：跟进中。

在工作汇报中，可从这样的时间结构上去划分：过去、现在、未来。

• 过去可重点描述近期业务进展回顾，重点梳理不同时间点的异同之处以及推动的地方
• 现在主要包括当前工作进展
• 未来包括下一阶段工作安排

9. 工作周报撰写

工作周报主要写上周的主要工作内容，具体细节无需写，最后提一下结果。

本周预备完成的工作：

• 越具体越好，例如，整理优化的话，具体到后台哪一个模块上面的整理和优化
• 本周准备解决的问题，具体到尝试解决的功能模块，讲解清楚明白。

不建议写的太笼统， 例如解决Bug之类的，不利于读者了解具体事项。

10. 接受自己的不完美

我们不应该过度着眼于我们还不够完美这一客观、不可改变的事实。

没有人是十全十美的，学习、工作、生活上都不可能十全十美。

承认这一点，可以缓解一些焦虑，但也不要心里承认了这一点，就放弃追求完美的路。

不完美的常态根本不会影响完美学习更多更深入的内容，不要固执地认为"不要完美主义"和"认真学习"是相互冲突的。

不要因为一点点没做好，遭受到一点点挫折，就放弃后续整个计划。

不要过度依赖学习路径，与其把准备知识都给掌握了再去学习核心内容，不如直接上手，哪里不会学哪里，这样的针对性以及学习效果会更强。

每一本教材都有适用人群，你不属于哪个人群，就不要强求看懂。