没有见过好的代码，也许就比较难去写出好的代码；没有遇见糟糕的产品，就不知道原来的产品有多好。
    很多时候，我们局限于我们的视野，作出的判断往往不够准确。
    所以永远不要把你生命某一时刻的感悟，当做真理。因为当你接触更多的信息，你有可能不断否定原先的判断。

    来到新公司两个月，除了一些对人对事的感悟，还有一些对整体组织结构的感悟。

    曾经：
    【以业务来划分团队，业务内有各个职能的人，大家都是搞同一个业务的】小作坊式的开发？10人业务小团队，产品比较简单，虽然有与外部能力的交互，但是比较少。感觉主要的优点应该是：小范围的效率提升。

    • 由于没有把同一个职能的人，日常性地聚集在一起，实际上技术共同进步的可能性变小了
    • 易于小范围沟通，沟通的内容相对简单，主要的原因还是业务复杂度简单（并不是大公司说有多难，而是杂）
    • 团队的凝聚力要更高。客观上由于大家负责同一个业务，实际上会更加熟络。
    • 业务的熟悉成本较低，主要是获取业务知识的来源问题（你几乎可以从每一个人那里得知业务内容），可以说是自动的业务人员备份。

      也许是意识到专精技术无法交流进步的缺陷，往往这种模式会有各类分享会，以让各类型码农碰头。

    现在：
    【以职能划分团队，大家负责不同的业务线——比如都是前端，搞对应的不同业务】分工、流水线式开发。当体量较大，产品较多，也许这种更加合适？？主要的优点应该是，易于管理。

    • 代码管理更加方便，利于技术发展。
    • 人员管理更加灵活？
    • 成本降低？这种模式最少只需要1个人。比如A产品、B产品、C产品，都要增加某个下架提示，如果通过业务来划分，可能就要通知A团队、B团队、C团队；而通过职能划分团队，则只需要通知【前端团队】
    • 沟通的重要性被放大了。主要还是因为沟通的双方、甚至多方，未必能够清楚对方的需求。当某一方发生变动后，需要通知所有方！！！
    • 当有人离职的时候，造成的打击实际上是巨大的。（如果不做好人员的备份，实际上极其容易导致产品、功能的断代）

    【曾经觉得有些公司7个人负责42个产品很酷，现在看来有利有弊；他要求每个人的实力都是非常强大的。】

    同时能够做到互相备份。