杂谈:开发人员如何进行复杂业务的学习?让boss刮目相看
一点小拙见,欢迎指正
一、概述
大型复杂的软件系统,是有许多人共同协作完成的,有些产品的业务是很复杂的,其在需求文档,及开发规范上都做得很好,不然维护的人越多,没有文档和规范去限制,岂不更加乱套。
如果文档不健全,或者代码也不规范,软件业务还复杂,那这样的公司也没必要继续干下去(ps:这样的公司很少)。
我目前所在的公司,维护的系统业务上比较复杂,其技术上不是很难。所以,更比较偏向于业务上的掌握。我是一个把技术当成兴趣爱好的人,让我学习业务,无疑是赶鸭子上架--难为人。但迫于我需要拿薪水养家糊口,还是避免不了去学习业务。
技术是为业务服务的,两者相辅相成。要想技术实现上更饱满,开发人员需要对业务熟练掌握。所以,这个坎我们也必须要过。
结合我对复杂业务的学习,做一个总结,希望对有困惑的读者能尽一点绵薄之力。
首先,我从身边的同事和朋友,了解到开发人员对学习业务的常见误区:
-
- 提需求的才应该负责业务,开发人员只负责实现需求功能。
-
- 让开发人员学习业务的时候,下意识就认为从看代码开始学习,代码经手人太多,代码不规范和注释不健全,导致怨声载道。
-
- 业务文档不全,学习起来特别困难,不知从何处入手。
基于以上的误区和自己最近学习业务的理解,下面谈谈几个学习建议。
二、八个学习建议
-
准备一个空白word文件,和一个可运行的系统debug环境。
-
写下如下几个问题?有助于去寻找答案,帮助理清思路。
问题1:xx业务的概念,背景,特点分别是什么?
问题2:xx业务是如何落地到我们软件系统中,涉及哪些改动?
问题3:xx业务在系统中,有哪些相关需求涉及到,是否能找到对应的需求文档及代码详细设计文档?罗列出来
问题4:xx业务在系统中,涉及的数据库表有哪些,是新增表还是修改表?
-
根据相关问题,查阅资料或请教同事,收集资料,并将答案写到word中。
-
根据需求文档的需求编号,idea全局查找,大致浏览一下项目代码,找到基础数据的来源入口。
5. 转换角色,把自己当成一个用户,从界面上去操作相关功能,对有一些不清楚概念的选项参数名词,查阅资料,理清概念。结合数据库的表字段,来理解含义,并记录到word中。
名词解释:重点把业务名词的概念搞清楚,并记录下来。这点蛮体现大家的专业和细心。把不清楚的概念搞明白,我蛮喜欢这样的。
-
记录下每一个操作所涉及的页面,后端接口,表。
-
debug调试技巧要牢靠。那这里主要说一下,debug时,常用的技巧。
- 浏览器端chrome的开发者工具,查看每一个操作是否有涉及与后台交互,有哪些数据传输。
- idea的全局查找和断点跟踪调试。
- 绘制一些图表,方便直观阅读。
三、后记
这是我最近对学习复杂业务,领悟出一点小小的心得体会。
如果把技术比作是我的左手(我是个左撇子),属于惯用的,处在舒适区,代表着硬实力;那业务就是我的右手(拿笔杆子的),属于不惯用的(使不上什么劲,除了拿笔,和拿筷子),则体现出的是软实力。
一点小拙见,欢迎指正
喜欢的读者,可以关注我➕,以免迷路。分享我奔走在技术道路上的点点滴滴。