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