坚持每天写代码，真的能提高编程水平吗？

每天都写业务代码，真不一定谈的上什么提高水平。

这跟游戏闯关一样啊，写业务代码=打小怪，你前期靠着小怪肯定能升级。你三五十级以后，还每天坚持打小怪，打一年也很难升级啊。

业务代码都写不好，肯定是不行的。但是只写业务代码，也不一定提高什么水平。

熟悉端到端比如说你负责web后台开发，但实际上用户发起一个http请求，要经过很多中间步骤才到你的服务器（例如浏览器缓存、DNS、nginx等），服务器一般又会经过很多处理才到你写的那部分代码（路由、权限等）这整个流程中的很多系统或者步骤，绝大部分人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大作用，例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。

“系统性”、“全局性”、“综合性”这些字眼看起来比较虚，但其实都是技术大牛的必备的素质，要达到这样的境界，必须去熟悉更多系统、业务、代码。

自学一般在比较成熟的团队，由于框架或者组件已经进行了大量的封装，写业务代码所用到的技术确实也比较少，但我们要明白“唯一不变的只有变化”，框架有可能要改进，组件可能要替换，或者你换了一家公司，新公司既没有组件也没有框架，要你从头开始来做。这些都是机会，也是挑战，而机会和挑战只会分配给有准备的人，所以这种情况下我们更加需要自学更多东西，因为真正等到要用的时候再来学已经没有时间了。

以Java为例，大部分业务代码就是if-else加个数据库操作，但我们完全可以自己学些更多Java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用，但真要用的时候，不是google一下就可以了，这个时候谁已经掌握了相关知识和技能，机会就是谁的。

以垃圾回收为例，我自己平时就抽时间学习了这些知识，学了1年都没用上，但后来用上了几次，每次都解决了卡死的大问题，而有的同学，写了几年的java代码，对于stop-the-world是什么概念都不知道，更不用说去优化了。

一、什么是业务逻辑？

不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑。在软件系统架构中，软件一般分为：表示层、业务逻辑层，数据访问层。

表示层：也就是界面和交互；

业务逻辑层：负责定义业务逻辑（规则、工作流、数据完整性），接收来自表示层的数据请求，逻辑判断后，向数据访问层提交请求，并传递数据访问结果，业务逻辑层很像一个中间件，承上启下的作用。

数据访问层：负责数据读取；

二、业务流程和业务逻辑的区别

逻辑更多的是页面之间的层级关系、承载信息和功能模块之间关系的逻辑说明。

流程更多的是从用户视角的完整场景操作流程、交互流程、页面路径、更注重功能顺序步骤，职能划分和基本结构等。

简单的说流程是用户看到的，看不到的是逻辑。——通过业务逻辑来调用业务流程。

三、需求转化能力

需求转化的能力，也就是理解需求的能力，围绕着两个核心内容：①沟通 ②逻辑

首先聊聊我见过的没有需求转化能力的人，接到需求直接开始做了，结果产品和需求不一致。为什么我说还需要一定的逻辑呢，我也接触过一个开发，写登录页面，不验证身份，这会导致啥问题，一个ip无限注册。

如何在接到需求的时候，保证需求的有效性和正确逻辑？

1、接到需求之后，自己独自记录上有疑问的点
2、参加需求讨论会，将所有需求过一遍，把疑问点及时沟通；
3、要确认需求和实现方式
4、确认无误开始开发流程
不要觉得弄明白了就直接上手写代码了！

先计划再写代码也是对自己的一种负责，毕竟有的开发的代码越写越多，越写越复杂，过一段时间之后自己都没法维护了。

大家可以自己去了解一下TDD，如果觉得这种方式麻烦的话，可以在接到需求的时候，自己先梳理思路成思维导图，把所有涉及到接口，对接的地方全部标出来。有计划的代码会提高实际工作的开发效率，不信你试试- -!

最后

带着脑子思考比较重要，重复代码写一年能有什么提高呢？是否可以引入设计模式呢？系统性能一般，是否可以优化呢？版本开发质量不高，是否引入高效的单元测试和集成测试方案？目前的系统太庞大，是否可以通过重构和解耦改为3个系统？阿里中间件有一些系统感觉我们也可以用，是否可以引入？

只要思考，就会发现，很多可以改进的地方。如果你觉得现在所接触的内容没什么好改进，只能说明水平还不够，不要只写代码了就，多看看业界其他公司怎么做的！