鸟菜的短期小结

本章不想谈技术，谈谈一些思考，一些想法，一些感觉。最近听了几次培训，手头也有项目在做。忙碌是有的，思考也有一些，但终究还是忙，得停下来歇歇，看看为什么这么忙。

我记得有人说过：如果一个游戏让你觉得玩的很累，就说明你没有掌握游戏规则。那么学习提高的规则是什么，迭代开发的规则是什么，业务需求规则又是什么？

   答案需要慢慢找。几个思考和大家分享：

1. 最近越来越发现，业务的复杂性远远超过语言的复杂性。

    或许这并不难理解，当业务需求灵活多变的时候，寻找一种开发成本适中的语言或许更符合要求。

    当然，这不排除语言本身的特性，比如C就适合于底层的基础开发/复杂的计算。

    但是业务仍然是核心驱动力，这句话在实际中的表现形式，就是运营的同学给开发的同学提各种需求，算是驱动吧。

    像淘宝这样以运营为驱动的公司，这种趋势就越发明显。

    运营规则的制定，流程的安排，多个系统之间的交互，就是代码的模板。 因此，业务的掌握是代码编写的基础。

    因为几乎不涉及复杂的计算，更多的是系统之间的数据传递，因此notify/hsf/tair这些中间件承担着非常重要的角色，对于稳定性要求很高。这些中间件的诞生，同样是业务驱动的结果。

2.  业务的复杂使得代码逻辑复杂，但是，好的设计原则可以更清晰的表达业务逻辑。

     因此，代码重构总是必要的。有时时间紧迫，可能首要任务是先让代码跑起来，之后一定要去优化。

     重构所需要的时间的时间，绝对比在糟糕的设计上添东西花费的成本要少。

     在我自己看来，重构是一件很好的学习过程，让你对系统有更合理的抽象，更易于扩展。

3. 软件设计属于“道” 的层面，编码就是“术” 。学习语言不是难事，如果有具体的实践学的的更快。

    这让我想起了曾经背单词的经历，拿着厚厚的单词书，每天看几页，一段时间就看完了。可是这样的效果等同于没看。

    没有应用背景，过于广泛的阅读等于没有阅读。

    所以我也在思考，当我写博客的时候，应该是同自己的实际应用联系在一起的。

    或者遇到某个问题，或者对某个点感兴趣，这些的前提是可以用到，可以快速解决问题。

    所以，让博客内容更集中，更有针对性，有实用性，这是以后的方向。

4. 这周的开发有点累。后来几天都是11点多到家。早上上班都是一边骑车一边睡觉，觉得状态很差。  

    当时在估算时间的时候，可能有些细节并没有想象中的那么明确，导致自己开发时间变长。我所在的关键节点的滞后，导致整个开发周期变长。

    不过还好主要节点都已经开发完毕，自测也可以通过，下周需要把整个流程穿起来。

    需要的仍然是重构。代码评审的时候就发现，可以改进的地方有很多。

    当我自己在工程中翻看其他的代码时，也曾因为没有注释，奇怪的引用/继承关系和多个看起来好像相同的方法之间徘徊。

    重构。提高。