读codelife有感

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

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

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

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

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

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

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

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

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

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

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

这彷佛是一个矛盾体，人与人之间的协做，是很是讲究人员素质的。而且人与人之间的矛盾是没法避免的，怎么让一个团队发挥出最高效的状态，是一个管理上的难题。

4. 做为team leader 须要自己的思考以外，还须要外交能力

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

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

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