在开发中，我们将分层架构和设计模式作为编码高效开发的套路，但你也知道，编码并不是开发的全部。一个完整的开发过程用面向对象的思想来概括，分为OOA（面向对象分析）、OOD（面向对象设计）、OOP（面向对象编程）。良好的代码结构需要需求分析和架构设计作为辅助。Stay试图向您描述一个理想且高效的工作流程。有了这个例程，你不仅可以缩短你的编码时间，还可以获得团队的认可。关于高效开发，大多数人的第一反应是成熟的分层架构、设计模式、第三方库。这些为我们提供了设计指南和方便的工具，可以更快地实现需求。高效开发还有另外一层含义。讲的是一个团队如何一步步提高团队的整体开发效率，缩短开发周期，实现更快的产品迭代。的设计。今天的话题是跟技术无关，聊聊高效开发的一些套路和实践。如何提高个人开发效率如何提高开发效率？我们先粗略的对比一下，不同的角色会如何实现同样的需求，再看看差距在哪里？我想每个人都能看懂这张图。一个需求是如何处理的，从初级开发工程师到中级到高级，再到架构师，他们处理的方式是不一样的。比如你是新人，刚到一个公司，分配给你一个任务，那么你可以直接搜索。因为分配给你的任务是拆分出一个比较具体、比较小的功能，所以你不需要做任何架构分析，只需要做具体的实现即可。对于一个实现者来说，他只需要搜索或找到他以前写过的代码。最笨的办法就是自己写。然而，并不是所有的实现都可以为谷歌编程。单纯的复制粘贴会增加你代码中的隐患，你知道这是相当危险的，也不会有技术沉淀。当你工作一两年，熟悉了一些工作流程后，你拿到任务的时候就会想怎么解决这个问题。当然这时候你的任务也从一个小函数变成了一个模块。这个业务长什么样子，怎么去分析，拆成小功能，然后有针对性的去搜索。虽然搜索到的不能完全满足你的需求，但你需要一个解题思路。稍微适应一下就可以实现。对于高级开发工程师或者架构师来说，他们拿到的任务是一个比较大的、系统的模块或者系统。因此，除了初级或中级之外，还有更多的事情需要考虑。这个时候你要做需求分析，架构设计，设计的时候你要考虑怎么解耦，怎么把高层抽象和低层实现分开，因为具体的实现是要拆分出来交给团队其他人的。当不同的角色面对同一个任务时，他们的侧重点不同，从而导致工作方式不同。初级和高级的差距在哪里？既然我们已经明确了，不同需求的人实现起来是不同的，那么区别在哪里呢？我们需要挖掘出那个特定的因素，这样我们才能知道如何做出调整。现在我们的问题是找出初级和高级的差距在哪里，缺少了哪些环节？先把视角抬高，再来看看面向对象（Object-Oriented），可以把OO分为OOA、OOD、OOP，即面向对象分析（Analysis）、面向对象设计（Design）、而面向对象程序设计（Programming），初级和高级的差距在哪里呢？只有这三个部分。资深开发工程师会有一个具体步骤：通过OOA分析业务流程输出模型，然后基于模型做面向对象设计OOD，用UML描述一个业务需求的整体流程，用OOD总结使用案例图、序列图、类图作为蓝图，指导OOP设计的高层抽象，将整个业务流程以伪代码的形式串联起来。一些独立的任务被拆分并交给其他人执行。在面向对象编程的过程中，经典的设计模式、设计原则来提高系统的稳定性，使代码具有可测试性和可扩展性。相对于初级和中级，他们的关注点更多在OOP上，在具体的代码实现上。这样就很难看到整体业务的流程和边界，也无法预见未来可能出现的需求变化。仅仅做一些重复劳动，无助于提高开发效率。跳出低级能很好的实现这一点，但是初级和中级像高级一样去做OOA和OOD是不现实的。如果对业务不是很熟悉，有些流程没有想清楚，或者没有考虑如何提升用户体验。如果不站在产品的角度考虑问题，设计的架构可能比较死板，漏洞百出。这不是自相矛盾吗？没有经验积累，你不可能像高级工程师那样思考。如果你做不到，你只能做低级的实现。这种沉淀太慢了，就像一个死循环，那我们要如何跳出这个循环呢？什么？然后从更好的OOP开始。其实写一段代码还是有点难度的。关键在于你想写的代码能打多少分。及格分数为60分，刚好适合跑步偶尔会有一些小bug；100分是通过设计模式设计原则写出来的好代码，可以很好的测试和扩展，稳定性也很强。怎样才能拿到高分？有句古话说得非常好。读万卷，写得有精神，准备得越多，知识越多，写代码就越流畅。首先，你首先要考虑的是这个产品提出的需求是否得到了你的认可，你认为什么样的方式才能让利益最大化。你可以给产品一些建议或者改进，因为你要做一个产品，要做好，你必须要参与，哪怕你做的是比较小的需求，功能，模块。当你看到一个有趣的或有挑战性的任务时，你要为这块的整体设计和实现而努力，不要被动地接受一个任务。因为接到的任务都是别人尝过的，规矩已经给你定好了。你只需要填写并实现它们。那些都是没有技术含量的。同时，不要急于表示这个做不到，那个做不到，Android很难做，等等。不要逃避责任，至少先做一些实实在在的研究和尝试，或者选择一些灵活、妥协的方案，给对方选择题，而不是直接拒绝。技术选型确定后，下一步就是由谁来主导哪些任务。接任务时，不要总是拿自己擅长的。每个人都应该变得多样化，而不是只有一种手艺（以后只有安卓不行）。擅长UI的人应该尝试去处理它。复杂的业务，能处理复杂业务的也要思考一些动画自定义UI如何处理。Stay在做代码实现的时候，比较喜欢先实现业务，再考虑UI上的实现。因为用户体验是个没完没了的东西，你可以设计的很花哨，也可以设计的很简单，产品经理都得背锅。至于业务，变化不会那么频繁。业务梳理好之后，你还要担心无法响应UI动作。还有一个好处就是业务是可测试的，可以在没有View层的情况下进行测试。如果开始画UI，十有八九会把UI和业务耦合起来，分离复用都很难，更别说写测试用例了。一天写八个小时代码是不可能的，也不可能说一天就可以把整个业务写完。如何可持续发展，最重要的是要有蓝图，要有清晰的高层抽象结构。有了高层定义，就可以一一填写具体的实现了。（可以参考装修留白房的全过程。）如果实在总结不出适合自己的套路，那就用‘书读百遍，意出’的妙招，但是读书是不够的。代码你要写，写完了还要想怎么改进。重新理解开发流程WhatStay刚刚给大家描述的是一个抽象的实现方法。接下来给大家演示一下：高效开发Stay认为应该分为OOA、OOD、OOP，这和我们刚才讲的是一样的。首先要有需求分析，然后是流程设计，最后是代码实现。本来想写一个完整的案例，但是精力有限，以后有空再来补充：）开发过程中的角色扮演从OOA、OOD到高层抽象架构和底层实现.不同角色的职责是不同的。请看图说话：很多工作两三年的同学都会焦虑，‘焦虑的是技术不能长久。30岁以后，我们去管理吧。有这样的焦虑并没有错。不对的可能是你对管理的概念不是很清晰。你知道如何成为一名合格的管理者吗？他的职责是什么？与其他角色相比，他在哪些能力上脱颖而出？关于这一点，Stay想分享一下自己的一些看法（仅限于技术管理层面）：刚才Stay一直强调OOA、OOD、OOP是因为在管理层面，如果要稳步迭代产品，你需要让每一个环节都可控。试想一下，如果需求分析不正确，将不得不重写大量的业务代码，这是一个潜在的风险。试想一下，如果业务设计不够清晰，没有事先设定规则和约束，那么大量的代码会是一次性的，从而导致冗余和低效。这是技术债，迟早要还的。试想一下，如果代码解耦不够，以后的修改会牵一发而动全身，重构难度大，无法满足产品的快速迭代。正是因为这些不可控的因素，才出现了责任的分解。有项目经理、售前、架构师、技术负责人、开发人员。当然，在小公司，责任就没有那么明确了。也许一个技术负责人可以涵盖所有的责任。如果你作为开发人员，经常加班，进度慢，可以反思一下你的leader是哪些环节做得不够好导致Inefficiency，能不能分享一些。从职业发展来看，大家都是从d1、d2、d3等小角色自下而上慢慢往上走。除了需要不断深化技术，未来转管理还需要抽象思维、业务能力、沟通协作，这些并不比写代码简单多少。不要认为自己目前只是一个小角色，只能给大boss擦鞋。不要这样想，每个人都应该更好地表达自己，更好地体现自己在一个团队中的价值。如果你做不到这一点，你很可能会被替换掉。所以多做一些事情，不要怕犯错，多和其他部门沟通，把自己耦合到各个部门。重构最怕强耦合。要解雇你，球队会有一段痛苦期吧？虽然整篇文章没有谈技术，但并不代表我认为技术没有用。支撑产品的是技术，推销产品的也有技术的功劳。我只是觉得这个角度很有意思。你可以再考虑一下。为什么要有面向对象的语言？是业务驱动技术，还是技术革新业务？单纯的讲方法论就像鸡汤。喝完说好，第二天就忘了。这不是方法论的错，更多是因为我没有能力去组合梳理出适合自己的方法论。同时，也是因为眼界不够，太在意眼前的细节。对于那些入行两年，处处跟人说自己迷茫，遇到瓶颈的同学，有没有想过自己的眼光不够？他们是否简单地将技术开发理解为一堆代码？
