前言

在开发中，编码我们有分层架构、设计模式做为套路来高效开发，但你也知道编码不是开发的全部，一个完全的开发流程用面向对象思想来概括，它分为OOA（面向对象分析）、OOD（面向对象设计）、OOP（面向对象编程）。一个好的代码结构是需要需求分析，架构设计做为辅助的，Stay尝试向你描述一个理想高效的工作流程，有了这个套路，不仅能让你缩短编码时间，还能得到团队的认可。

关于高效开发，大多数人的第一反应就是成熟的分层架构、设计模式以及第三方lib。这些给了我们设计准则还有便利的工具更快的去做需求实现。

高效开发还有另外一层含义，关于一个团队他要如何去提升团队的整体开发效率、缩短开发周期，能够一步一步去更快速的产品迭代，在这个过程中你要做好需求分析，架构上的设计。

1. 如何提升个人开发效率？

同样一个需求，不同的角色会如何来着手实现，然后我们再来看差距在哪里？

一个需求如何被处理，从初级开发工程师到中级再到高级、架构师他们处理的方式流程是不一样的。

例如你是一个新人，刚到了一家公司，被委派了一个任务，可能直接就去搜索了。因为分配给你的任务是拆分出来一个比较具体、比较小的功能，所以不需要去做什么架构上的分析，只需要去做具体的实现。对于一个实现者而言，他只需要去搜索或者去找以前自己写过代码，最笨的方式才是自己去手写。不过呢，不是所有实现都是可以面向 Google 编程的，单纯的复制粘贴会让你的代码增加隐患，而你也知道，这是相当危险的，而且也不会有技术沉淀。

当你工作一两年，对一些工作流程比较熟悉后，再拿到一个任务就会想应该如何去解决这个问题，当然这个时候你的任务也从小功能变成了一个模块。这个业务是什么样子的，应该如何去做分析，拆分成一个个小功能，然后有针对性的去搜索，虽然搜来的不能完全满足你的需求，但你只是要个解题思路，借鉴下稍微做下适配就可以实现啦。

而对于高级开发工程师或架构师来说，拿到的任务就是一个比较庞大的、成体系的一个模块或者一个系统。所以要考虑的事情要比初级或中级要多的多，这时候就得做需求分析，架构上的设计，并且在设计的时候，还得去考虑应该如何解耦，如何分离高层抽象和低层实现，因为具体的实现是要拆分出来交给 Team 中其他人去做的。

2. 初级和高级的差距在哪里？

我们来看看面向对象(Object-Oriented)，你可以把OO分为，OOA、OOD、OOP，也就是面向对象的分析(Analysis)，面向对象的设计(Design)，以及面向对象编程(Programming)

高级开发工程师他会有一个具体的步骤：

1. 通过OOA来分析业务流程输出模型

2. 基于模型再做面向对象的设计OOD，借助UML来描述整体的一个业务需求的流程

3. 以OOD归纳的用例图、时序图、类图做为蓝图来指导OOP

4. 设计高层抽象，以伪代码的方式串联起整个业务流程

5. 拆分出一些独立任务交给其他人实现

在面向对象编程的过程中，还可以套用经典的设计模式、设计原则来提升系统的稳定性，让代码变得可测试，可扩展。

3. 如何跳出’低层实现’这口井？

没有经验沉淀，就无法像高级工程师那样思考，做不到那样就只能做低层实现，这样沉淀的太慢了，就像死循环啊，那么我们该如何 break 出这个 loop 呢？

那就先从更好的做 OOP 开始，其实想把一段代码写好，还是有点困难的，关键在于你想写出来的代码能打多少分，及格分是 60 分，它刚好处于可以跑的状态，偶尔会出点小 bug ；100 分就是通过设计模式设计原则写出的良好代码，它能很好的去做测试、做扩展，那它的稳定性也很强。

如何才能得高分？有一句古话说的很好，读书破万卷，下笔如有神，你做的准备工作越多，底蕴越足，写代码就会越顺畅。

首先第一个是你要考虑的是，这个产品提出的需求有没有得到你的认可，你觉得什么的方式来实现会使得效益最大化。你可以给产品提些建议或者改进，因为你想做一个产品把它做好，你必须要参与进去，即使你做的是比较小的需求，功能，模块。

当你看到感兴趣或者有挑战的任务，得自己去争取这一块的整体的设计和实现，不要被动的去接受一个任务。因为接收来的任务都是别人咀嚼好的，给你定好了条条框框，你只用往里面填实现就可以的，那些都是没有技术含量的。

同时也不要急着去表达这个做不了，那个做不了，安卓做这个很难实现的等等。不要去逃避责任，至少要先做一些真实的调研和尝试，或者选取一些可变通的、折中的解决方案，给对方做选择题，而不是直接拒绝。

在确定了技术选型之后，那么接下来就是哪些人来领哪些任务。领任务的时候，大家不要总是去领那些自己擅长的，每个人都要变得多元化，不仅仅是只会一门手艺（以后只会安卓也不行了）擅长做UI的要去尝试处理复杂业务、能处理复杂业务的也要想想如何处理一些动画自定义UI。

在做代码实现的时候，比较偏向于先实现业务，再去考虑UI上的实现。因为用户体验是一个没完没了的事，你可以把它设计得很好花哨也可以把它设计得很简单，这锅得产品经理去背。而对于业务来说，改动就不会那么频繁了，业务梳理清楚了，还愁不能响应UI的action嘛，并且还有另外一个好处就是业务是testable的，不需要View层也可以测试。假如你上手就画UI，十有八九你就把UI和业务耦合在一起，连剥离复用都很难做到，更别提写测试用例啦。

写代码不可能一天写满八小时，也不可能说一天就能把整体的业务全部写完。如何可持续地做开发，最最重要的是，得有一个蓝图、一个清晰的高层抽象结构，有了高层定义再一个一个往里面填具体实现就可以了。

4. 如何理解开发流程？

先得有需求分析，再做流程设计，最后才是代码实现。

5. 你开发环节中的角色扮演？

从OOA、OOD再到高层抽象架构和低层实现，不同角色的职责是不一样的。

很多工作两三年的同学都会焦虑，焦虑的是技术不能走的长久，30岁以后就走管理吧。有这样的焦虑不是什么错，错的可能是你对管理没有一个非常明确的概念。你知道如何做一个合格的管理吗？他的职责是什么？他比起其他角色，突出在哪些能力？

站在一个管理的层面，想要产品稳步迭代，需要让每个环节变得可控。

• 想象下，如果需求分析不对，大量的业务代码要重写，这是潜在风险。

• 想象下，如果业务设计不够明确，没有提前定好规则与约束，大量的代码都会是一次性的，也就导致了冗余和低效，这是技术债务，迟早要还的。

• 想象下，如果代码不够解耦，未来修改会导致牵一发而动全身，使得重构困难，又无法满足产品快速迭代。

正因为要避免这些不可控的因素，才会有了职责的细分。有了项目经理、售前、架构师、技术负责人、开发人员。当然在小公司，职责没那么清晰，可能一个技术负责人就 cover 所有职责了，如果你做为开发人员经常加班，进度缓慢，可以反思下，你的leader是在哪些环节做的不够好而导致低效，你能否分担一些。

从职业发展的角度来说，大家都是自下而上从d1、d2、d3这样的小角色慢慢往上走的，除了技术需要不断深入，未来转管理还需要有抽象思维、业务能力、沟通协作，这些并不比写代码简单多少。

也不要觉得目前自己只是一个小角色，只能替大佬擦擦鞋。不要这么想，每个人都应该更好的表达自己，更好的去体现自己在一个团队的价值。如果你做不到这点的话，你就很有可能被替换掉。所以多做一些事情，不要怕犯错，多去和其他部门沟通交流，要把自己耦合到每一个部门中去。

小结

支撑产品的是技术，推动产品的也有技术的功劳，只是觉得这个角度很有趣，大家可以再深思下，为什么要有面向对象语言？是业务推动了技术，还是技术革新了业务？