读codelife有感

春节在家闲暇无事的时候看看书，翻到以前读的codelife，决定记录一下看后的心得（俗称读后感）

1. 技术是为业务服务的，要深刻理解这一点。

程序员的迷茫不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于软件世界的浩大分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术，业务的关系所致。

这句话我深有体会，写代码写的多了，难免会烦躁，觉得自己写的代码没有创造出价值，没有成就感。这是由于我们仅仅处于一个生产链条的一环，我们只关注自身，并没有把握整个生产链条，从而不能知道我们这一环在整个链条中占有一个什么样的位置，我们就像一只没有头的鸟，一只在扇动翅膀，却不知道飞向何处。
试想一下，如果我是公司的老板。我的目的很简单，就是盈利，为了达到盈利，我需要开发软件，实现业务。真正实现盈利的是业务，只要软件能很好的实现业务，呈现在客户面前，就能实现盈利，就这么简单。
所以，接下来，进入到软件开发，当然软件开发是一个系统的工程。我需要产品经理理解业务，整理出需求，设计出原型；把原型交给ui来设计出好看的界面；再把前后台开发叫到一起开会讨论开发具体事宜。我们往往需要思考，为什么要有这些功能，这些功能为什么要这么去设计，肯定是有其道理的。

要深刻理解业务，要明白，自己的每一行代码，都是在实现业务，优化用户体验。

2. 想要工作出业绩，必须认清系统背后的业务价值

leader问我对接下来的团队有什么计划？我当时说了一堆什么改进代码质量，每天晨会，任务透明化，建立迭代机制等等，然后被各种批驳一通。

这一点我也有体会。去年在九度网络担任前端开发经理，公司的软件已经上线，处于空档期，老板叫我写架构文档，接下来的计划等等。我当时也是说了很对泛泛而谈的东西，什么code review，小组会议，代码规范什么的，结果老板也是不满意。当时有一个技术难题，把公司的业务模块化，通过后台实现业务的组装，这个问题我当时想了很久没有拿出好的解决方法，这一点上老板非常失望。其实什么代码规范的东西，老板根本不关心，他只关心业务能不能满足，功能能不能实现，因为这才是赚钱的根本。

业务当然要理解，但是也没必要深入研究，那是老板的事，除非你要自己创业。作为一个技术人员，技术才是第一位的，你理解了公司的业务，也要学会用最合适的技术去实现这些业务，甚至用多种技术去实现这些业务，技术学到了是你自己的，而业务如果你不能用来创业赚钱，再深入也没有用。试想一下，你换了一家公司呢？新的公司有新的业务，你之前公司的业务不是没用了嘛。

3. 分工导致软件开发效率的提升，同时也会导致人与人之间的矛盾从而增加软件开发成本

比如开发人员负责开发周期负责完成软件研发，测试人员负责对开发人员交付的 成果进行测试等，于是就形成了分工。一旦分工形成，每一个分工组织都会有自己的 价值追求，架构师关注的顶层的价值即软件系统能否支撑业务增长被分工的形式打 碎到各个组织中。分工是有其价值的，他使得复杂昂贵的任务可以被简单、并行、 可替换的流水线方式解决。但久而久之，价值碎片化的问题就出现了，比如测试人 员只关注找出更多问题，开发人员只关注快速开发更多的系统，运维人员只关注保障系统稳定。

这似乎是一个矛盾体，人与人之间的协作，是非常讲究人员素质的。并且人与人之间的矛盾是无法避免的，怎么让一个团队发挥出最高效的状态，是一个管理上的难题。

4. 作为team leader 需要本身的思考之外，还需要外交能力

• 识别业务痛点，向上管理与老板对焦
• 与下属进行业务梳理，共同完成业务开发
• 与其他部门进行协作，如测试部门，运维部门

向上管理是拔赤老师比较强调的内容，如果你的老板不是前端，向上管理特别有 必要，你需要消除“语言差”、做必要的前端核心概念“科普”。
一般业务 / 产品老板的关注点是:流量、转化、跳失、体量、用户体验、规模化、 模式 / 产品创新等，要了解清楚现阶段老板的关注点是什么，从自己团队的维度思考 试图给出到达路径，这是非常重要的规划线索。
向上管理不是有事没事找老板唠嗑，而是注意沟通的有效与质量，提问题最好带 着初步的解决方案，业务 / 产品老板的时间有限，又存在“语言差”，相对复杂的内容 务必准备 PPT。

特别是理解业务，进行向上管理。有时候领导的想法没有准确的传达到自己这边，或者自己意识到一些问题，这时候要主动找到领导，说出自己的想法，领导了解了你的想法后，如果合理会采纳，不合理也没关系，至少领导更加了解你了，也会更加信任你。