关于高效开发的一些套路与实践

开发
一个好的代码结构是需要需求分析,架构设计做为辅助的,Stay尝试向你描述一个理想高效的工作流程,有了这个套路,不仅能让你缩短编码时间,还能得到团队的认可。

在开发中,编码我们有分层架构、设计模式做为套路来高效开发,但你也知道编码不是开发的全部,一个完全的开发流程用面向对象思想来概括,它分为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这样的小角色慢慢往上走的,除了技术需要不断深入,未来转管理还需要有抽象思维、业务能力、沟通协作,这些并不比写代码简单多少。

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

来个收尾

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

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

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

责任编辑:未丽燕 来源: Stay's Notes
相关推荐

2018-06-29 14:51:41

Java健壮性实践

2017-10-23 12:22:58

Android编程基础总结

2021-02-06 14:25:29

Java延迟加载代码

2010-11-02 14:11:15

SilverlightWPF微软开发

2021-10-21 06:52:17

Vue3组件 API

2011-07-13 09:13:56

Android设计

2013-07-18 16:16:51

2013-08-21 13:47:29

PhoneUDIDUUID

2020-09-21 06:58:56

TS 代码建议

2009-06-18 09:51:25

Java继承

2013-04-07 10:40:55

前端框架前端

2012-09-25 10:03:56

JavaJava封面Java开发

2018-01-03 10:32:21

面试经验套路

2010-01-15 10:34:59

Linux命令行操作

2022-05-19 07:52:39

MLOps云计算实机器学习

2011-03-11 09:27:11

Java性能监控

2017-12-21 07:54:07

2012-04-19 10:06:55

微软Windows 8 E

2009-06-04 16:28:43

EJB常见问题

2015-12-04 10:04:53

点赞
收藏

51CTO技术栈公众号