实现系统的一些经验

最近几个月在实现规模比较大的底层系统（这也是一直没有论文阅读更新的原因）。

记录下反思中的点点滴滴（后面会有更新）。

---

 

挑战：

大型系统的最大挑战的根源在于其规模，以及规模带来的复杂度，它会在几个方面带来挑战：

• 它不能一下在在脑袋里全部浮现出来，也就是说一次只能关照一个部分（包括树状结构的至上而下的思考）
• 对于体力和意志力也是一个挑战，尤其是有deadline的情况下容易出现受迫性失误（没有按照完美的方法去实现）

---

目标：

 

“平衡”

往常我们会说是“完美”才是目标，实现一个功能效率俱佳的系统，但是在实际项目中，这种目标会带来实现时间过长，尤其是在有系统依赖性的情况，耽误了其他同事的工作，这显然是不完美的。

在有限时间里呈现出能达到的最好水平，才是目标。

实现这个目标的关键是“取舍”。

所以很多时候就是要留下很多不完美的实现，但是这个却是最完美的选择。

 

“控制”

选择了合适的火候之后，剩下的工作量仍旧是巨大的，在开始的兴奋的热恋期过去之后就是长期的僵持。

不停地大量的coding之后，进入身心的疲倦期，这才是考验的真正阶段。

这里就是需要控制力。

kratos似得的嗜血和彪悍大于一切技巧。

---

 

点滴：

 

尽早的可运行系统：

• 这对于思考改动在整个系统中的影响是一个非常有力的辅助，注意是辅助，本身全面的思考是不可取代的，但是总有你想不到的地方，可运行的系统测试可以很大程度上做辅助。
• 节省脑力：这对于效率至关重要，有时候做的太狠会造成一段时间的萎靡。
• 精神：会在屏幕上看见feature更加全面了，log里看见效率大幅度提高，这对于自己的鼓舞是非常强劲的。
• 炮灰代码：为了让系统尽快运行，我也写了一些后面被干掉的代码，这个是很不错的选择，早期快速的实现却换来了可以运行的测试系统，然后后期的合理的实现都是在系统测试下经过考验。
• 维护一个最小的运行（测试型）系统，这样改变重构都更快（否则就会很大程度上拖慢迭代速度），等功能模块禁得住考验了，再进行扩充。

习惯与状态：

• 尽可能多的设计是非常好的习惯，我也在引导自己在从多coding到多思考转变，有时候因为一点点的懒惰和侥幸心理就急于coding，到了中后期才发现设计的错误，其实要是自己在纸上完整的画下来，再多挑战自己几下就不必这样无谓的浪费了
• “空与无”的状态要好于非常兴奋的状态，把一切会分散注意力的东西都关掉，听比较容易进入这种状态的音乐（如果办公室安静的话不听音乐是最好的）
• 没完成一个模块去做refactor和写好注释，
• 把垃圾代码都清掉，我就是在升级其他模块的时候结果在忘了的情况下继续维护垃圾代码，这真悲剧
• 写好注释是最好的反思，理清条理是最高优先级
• 有几种情况还是适合立即动手：
• 设计的很烦，想coding痛快一下
• 犹豫不决应该这样还是那样，那就做吧
• 小的改动也上传：可以有效避免把已经做好的部分改坏，又没法恢复的情况，“步子太大容易扯到蛋”这个真是有道理的，实现过程中碰见过好多次这种情况，一直到后面自己老实了。
• 重构作为相对休闲的工作可以当作“休闲”分着进行。

专注：

所谓的前瞻性是一个很泛的词汇，重在火候的把握，通常意义上我们做项目都是时间严重不足的，所以一个实现的火候要好好把握。

• 对于发生频率非常大的未来才会出现的部分，只要做出不与之冲突的设计即可
• 对于没法去测试维护的部分，不要去做，节省时间去做更加有意义的事情