读者提问：
飞哥你好，本人Java 已有一年半，到现在可以独立配合前端、app的开发任务，目前遇到的问题：碰见有点绕的业务逻辑代码就有些力不从心。
平常晚上也在看书刷题，目前想到的是晚上下班再在公司待一个多钟来学习提升。
请问下飞哥有没有此阶段的方法或建议呢？
大飞回复 :
这种情况应该是对业务逻辑不熟悉+自信心不足导致的。
应对业务逻辑不熟悉带来的压力和焦虑，最好的办法不是刷题和看书，而是花时间好好的去熟悉业务逻辑。
通过看业务代码，请教相关同事，看能找到的各种技术文档，不断加深对业务逻辑的理解。只要做到心中有数，一个需求过来，很快就能想到要怎么做，内心就会比较安定了，那种焦虑感自然就会消失了。
对工作的自信，来自日常工作中积累的点点滴滴的小成功。一个小需求的成功上线，一个方案的成功设计。。。 积累多了，对工作，对业务的自信自然就有了。有了自信，就不会出现恐惧感和无力感。
所以，你现在最好的方式应该是投入更多的时间去熟悉业务逻辑，熟悉业务代码，然后，把每个工作任务都尽力做好，争取积累更多的小成功。
再说多点。
看到上面这位读者的问题，我想起自己刚毕业的第一年，也遇到类似的情况。
遇到比较复杂的业务需求，心里就会担心，会焦虑，也会有无力感。有段时间，为了应对这个问题，我加大了我的学习时间投入，想通过更加努力的学习来缓解这个问题。
当时以为，只要不断提高自身的技术能力，这种对业务需求的焦虑感和无力感就会消失。
但后来，我发现自己错了。
毕业的第一年，我做的是QQ 的分布式后台系统，系统很庞大，有复杂的业务逻辑，也有难懂的技术逻辑，然后我当时有看linux 内核源码的习惯。
当时觉得， linux 内核那么复杂，而且内部的各种设计都是顶级的，那时想，如果能够搞懂内核里面的东西，再回过头来看业务系统的代码，那肯定是小事一桩了。
但后面的结果，不如所愿。
业务系统于我并没有变的小事一桩，反而因为我没有花更多的时间去了解业务逻辑，导致需求的完成时间和完成质量跟不上团队的整体进展。
后面我的 leader 还就这个事情，跟我长聊了一番，我才意识到我的努力方向错了。
其实业务逻辑跟技术是没有相关性的，无论你做题做的多好，基础知识掌握的多么深入，对业务逻辑理解几乎都是没有帮助的。
然而，我发现不少人，包括我自己，都曾陷入过这种 “唯技术论” 的思维里面去 --- 觉得只要不断提高自身的技术能力，就可以解决掉业务上的所有问题。
这是一种思维定势，人很容易陷入到这种思维盲区里面，然后拼命的努力，但结果却事与愿违！
业务逻辑本身就是要花时间去理解的，不能通过提升自己的技术能力来取代这个过程。
不少的程序员，会轻视业务逻辑，很多人会觉得业务逻辑没有技术含量，不值得花时间去熟悉，去了解。又因为每个系统的业务逻辑几乎都不一样，可复用性差，很多人，特别的是新人，几乎都不愿意花时间在业务逻辑上。
其实这是一种很错误的认知。
没有任何一种技术是可以脱离具体的业务，具体的场景存活下来的。技术是通过业务，通过产品，才体现出了技术的价值。可以说，完全不懂业务的技术，几乎是不存在的。
我以前做过通用存储系统，已经算是很基础的系统了(就是大家理解的比较有技术含量的那种系统)，但当时我们遇到的最大问题，其实不是技术实现问题，而且业务的访问模型。
我们当时的业务有上千个，从表象看，每个业务的需求都不同，但你不可能为每个业务都做一个存储系统，所以我们遇到的最大问题，其实是业务模型的抽象。
抽象成多少种模型，每种模型大概能覆盖多少需求，最终能够覆盖多少需求。这中间过程中，我们其实花费了不少的时间去跟同事了解具体的业务逻辑，最后才设计出了通用的存储模型。
我觉得一个人，技术能力的成长跟业务能力的成长，是相辅相成的。业务逻辑了解的越深入，业务能力越强，你就越有机会参与到更核心的系统中去，这反过来，又会进一步促进自身技术经验的积累和技术能力的成长。
所以，我觉得大家应该对业务，业务逻辑，业务代码有正确的认知。虽然不少的业务逻辑和业务代码繁杂，难懂，看起来没啥技术价值，但长远来看，业务能力跟技术能力是相辅相成的。
总体来说，技术之路可以走的长远的人，业务能力也不会太差！
- To Be Continued -
我建立的知识星球，提升技术认知，助力技术成长！欢迎扫码加入：