在开发中，编码我们有分层架构、设计模式做为套路来高效开发，但你也知道编码不是开发的全部，一个完全的开发流程用面向对象思想来概括，它分为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这样的小角色慢慢往上走的，除了技术需要不断深入，未来转管理还需要有抽象思维、业务能力、沟通协作，这些并不比写代码简单多少。
也不要觉得目前自己只是一个小角色，只能替大佬擦擦鞋。不要这么想，每个人都应该更好的表达自己，更好的去体现自己在一个团队的价值。如果你做不到这点的话，你就很有可能被替换掉。所以多做一些事情，不要怕犯错，多去和其他部门沟通交流，要把自己耦合到每一个部门中去。重构最怕强耦合，想要开掉你，团队还要有一个阵痛期呢，对不（奸笑😈）
来个收尾
虽然通篇没讲技术，但不代表我觉得技术没用哈，支撑产品的是技术，推动产品的也有技术的功劳，只是觉得这个角度很有趣，大家可以再深思下，为什么要有面向对象语言？是业务推动了技术，还是技术革新了业务？
单纯的讲方法论就和鸡汤一样，喝了都说好，第二天就忘记了。这不是方法论的锅，更多的还是自己无法结合整理出适合自己的方法论，同时也是因为眼界不够，过于关注眼前的细节。
那些入行两年就到处和人说自己迷茫，遇到瓶颈的同学，有没有想过是自己的眼界不够呢，是不是把技术开发单纯的理解为堆代码了呢？
在过去五年中，我一直做Android相关的工作。在这期间，我与不同背景，不同水平的工程师进行过合作。有些工程师有非常丰富的经验，有些是刚走出校园的应届生，它们拥有的只是学校学习到的知识并利用业余时间进行App的开发。还有些工程师甚至不是CS专业，仅仅是自学的。在合作过程中，我目睹了不同类型工程师的工作交付内容和方式。
所以，如果你是一个Android软件工程师，可以尝试读一下这篇文章。首先，很多人误认为移动开发非常简单，移动应用就是把根据后端的设计把一些界面组合在一起。真的是这样吗，其实这与实际情况差的很远。实际上，如果你看一下PlayStore上的应用，你就会发现app的质量分布其实是一个高斯分布，低质量的app很少，同时高质量的app也很少。
这里我定义一下平庸的App是什么
在一个非常基本的层面上， 一个平庸的app 与操作系统不能很好地兼容。首先，不遵循平台要求的设计语言，这会使得用户感到困惑。第二，不考虑运行环境（内存、cpu、带宽、电量）实际上是有限制的。第三，在某些条件下不能工作（比如在弱网环境下）。现在的大部分软件都存在最后一个问题。
简而言之，以上三点就是构建一个好的移动应用的挑战。此外，App需要与公司的基础需求合理地整合，适应不断变化的业务需求。
所以如果我要寻找可以处理以上三个挑战的软件工程师，以下几点是我关注的：
较好的软件工程和技术水平 这包括：SOLID（面向对象设计）原则，clean code，应用架构和测试。数据结构和算法也很重要。但是我不在意面试者是否可以平衡二叉排序树。我关注面试者是否理解基本的数据结构（Lists, queues, trees, hash maps），是否理解 O 是什么，可以讨论时间和空间的交换，就是最基本的技能。
熟悉java语言（如果面试者非常熟悉其他的语言，我也不会拒绝）。
理解并发 因为App是响应式的，所以不可以在主线程中执行耗时任务。很多事情需要在其他线程执行，如果面试者不能处理并发编程，他们需要在工作和项目中学习。
理解分布式系统 随着移动应用变得越来越灵敏，需要设计为可以离线使用。这意味着如果网络有故障，相同的用户可能会面对不同的状态。因此，面试者需要了解CAP（Consistency，Availability，Partition Tolerance theorem）理论和分布式系统的共识模型。
分析解决问题的能力 面试者需要对事物的工作原理保持好奇，并且有大局观。
较好的口头和书面表达能力 在技术上，沟通交流非常重要。面试者清晰地表达自己的想法，同时合理的文档说明是非常重要的。其实，是否擅长写文档一定程度上也代表了代码能力。
理解当前的技术环境和对设计与工程的影响
我并不担心面试者是否对SDK本身理解多少。如果面试者理解以上的几点，即使他只是一个Android的用户，也可以快速地学习。也就是说，面试者同时拥有好的CS背景，了解android生态环境，还要知道以下的一些基本概念：
可以画出Android的基本架构
可以描述在点击Android studio的一个按钮之后具体发生了什么逻辑
理解基本的Dalvik和ART 虚拟机
Android进程间通信原理
app的沙箱机制以及为什么要用沙箱
权限系统（权限在底层是如果实现的）
进程和应用生命周期
还有一点是可以和面试者聊他擅长的话题，如果他擅长ui，就可以和他聊UI。
可以发现重要的是判断面试者是否知道核心的基础和概念，从而较好地处理分给他们的任务。一定不要雇佣只会使用一两个library的员工。工程师不仅在必要时会使用library，而且可以在提供解决问题的方法之前可以分析使用情景，预见可能的问题。
再次强调，一定不要雇佣只会使用一两个library的工程师。
当然，我这里描述的条件适用于senior 工程师。同样也需要雇佣一些junior工程师。但是一定要控制好两种工程师的比例。如果团队中有太多初级工程师，那么开发过程非常艰难，需要修改一个接一个的线上问题，直到可以代码达到维护性和测试性良好的程度。
如果你是一个Android工程师，你可以看一下以下的文章以提高自己的技术水平：
软件工程技术
Clean Code — by Uncle Bob Martin
The Pragmatic Programmer — by Andy Hunt and Dave Thomas
Refactoring — by Martin Fowler
Head First Design Patterns— by Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra
Patterns of Enterprise Application Architecture — by Martin Fowler (his blog is also worth following)
java
Effective Java, Second Edition — by Joshua Bloch
并发
Java Concurrency In Practice— by Brian Goetz
数据结构和算法
Introduction to Algorithms (a.k.a The Cormen book) — by Charles E. Leiserson, Clifford Stein, Ronald Rivest and Thomas H. Cormen.orThe Algorithm Design Manual — by Steven Skienna
计算机文化
Subscribe to ACM Queue
Love the Papers
Listen to Software Engineering Radio and/orSoftware Engineering Daily
问题解决技巧
How To Solve It — by G. Polya and John H. Conway
写作技巧
On Writing Well— by William Zinsser
值得follow的一些blog
Chet Haas’s blog ： Specifically These series of articles he (Chet) wrote about Android development
Dan Lew’s blog
Jake Wharton’s blog
Jesse Wilson’ blog
Cyril Mottier’s blog
Chris Bane’s and Roman Nurik’s blogs for UI related subjects.
Listen to Android Backstage and The Fragmented Podcast.
And finally do subscribe to Android Weekly, to read about the latest stuff in the Android development world.
此文为译文，原文地址https://hackernoon.com/what-makes-a-good-android-software-engineer-206562e1fdb6\#.g108jtz8i