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

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

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

今天的主题是撇开技术和大家聊聊高效开发的一些套路与实践。

如何提升个人开发效率

如何来提升开发效率?我们先来粗暴的对比一下，同样一个需求，不同的角色会如何来着手实现，然后我们再来看差距在哪里?

这个图我想大家应该都能看懂。

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

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

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

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

不同的角色面对同一个任务时，他们的关注点是不一样的，也就使得工作方式不那么一样。

初级和高级的差距在哪里?

既然我们已经清楚了一个需求不同的人来实现它是不一样的，那么不一样到底在哪里，我们要挖掘那个具体的因素，这样才能知道应该如何做调整。

现在我们的问题就是找出初级与高级的差距到底在哪里，少了哪些环节?

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

那初级与高级的差距到底在哪里呢?就差在这三部上。

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

• 通过OOA来分析业务流程输出模型
• 基于模型再做面向对象的设计OOD，借助UML来描述整体的一个业务需求的流程
• 以OOD归纳的用例图、时序图、类图做为蓝图来指导OOP
• 设计高层抽象，以伪代码的方式串联起整个业务流程
• 拆分出一些独立任务交给其他人实现

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

对比下初中级呢，他们的关注点更多的放在OOP上，在具体代码实现上。这样就不太能全观整体业务的流转和边界，无法预见需求未来可能发生的变化，仅仅做些重复劳动力对提升开发效率是没有任何帮助的。

跳出低层实现这口井

但是啊，让初中级去像高级那样去做OOA、OOD也不现实啊，如果对业务不是很熟悉，一些流程上想得不够清楚，或者没有考虑如何去提升用户体验，没有站在产品角度考虑问题，那么设计出来的架构可能会比较死板，同时也漏洞百出。

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

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

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

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

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

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

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

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

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

如果实在是总结不出适合自己的套路，那就用‘书读百遍其义自现’这一招好了，但读是远远不够的，还得写代码，写完了还要想如何去改良。

重新理解开发流程

刚才Stay给大家描述的是一种抽象的实施方式。接下来给大家做个示范：

高效开发Stay觉得应该分为，OOA、OOD、OOP，跟我们刚才讲的那个是一样的。先得有需求分析，再做流程设计，最后才是代码实现。

本想写个完整的案例，奈何精力有限，后续有时间再补上：)

开发环节中的角色扮演

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

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

就这一点，Stay想分享点自己的观点(仅局限于技术管理层面)：

刚才Stay一直在强调OOA、OOD、OOP，是因为站在一个管理的层面，想要产品稳步迭代，需要让每个环节变得可控。

• 想象下，如果需求分析不对，大量的业务代码要重写，这是潜在风险。
• 想象下，如果业务设计不够明确，没有提前定好规则与约束，大量的代码都会是一次性的，也就导致了冗余和低效，这是技术债务，迟早要还的。
• 想象下，如果代码不够解耦，未来修改会导致牵一发而动全身，使得重构困难，又无法满足产品快速迭代。

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

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

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

来个收尾

虽然通篇没讲技术，但不代表我觉得技术没用哈，支撑产品的是技术，推动产品的也有技术的功劳，只是觉得这个角度很有趣，大家可以再深思下，为什么要有面向对象语言?是业务推动了技术，还是技术革新了业务?

单纯的讲方法论就和鸡汤一样，喝了都说好，第二天就忘记了。这不是方法论的锅，更多的还是自己无法结合整理出适合自己的方法论，同时也是因为眼界不够，过于关注眼前的细节。

那些入行两年就到处和人说自己迷茫，遇到瓶颈的同学，有没有想过是自己的眼界不够呢，是不是把技术开发单纯的理解为堆代码了呢?

作者：佚名

来源：51CTO