业务开发：永远被业务驱使或者强奸，越来越忙，支持业务越来越疲于奔命。产品、业务上线快，bug也很多。

这可能是大多数业务开发的写照吧，换了份工作之后，自己也是一直在写业务相关的东西，想说说最近业务开发的经历

每天都在做什么

经常做的是熟悉需求、梳理业务、新的，旧的系统功能点、讨论、写代码。而写业务代码，基本上用到的都是公司封装好的框架，使用起来简化了很多开发步骤，并且根基本上是参照之前代码的写法。

熟悉需求，肯定要做新功能啊，但是新功能从最老大的哪里提出来，产品梳理好之后告诉我们，开发不在第一线，产品与开发各自分工，文档给了开发，要做功能，只有梳理需求，需求文档基本上在整个开发过程都用得到。

梳理业务，新员工都要熟悉公司的业务，时间比较久的公司业务复杂，所以需要梳理。

新、旧系统功能点，也在和梳理业务，需求有很密切的关系，旧系统的功能是超级多的，有需要的都要看。新功能要理

讨论，需求宣讲会，功能点讨论，设计方案讨论等， 完全取决于会议是否高效

写代码，比重不是很大，但一切都要落实到代码上，写代码才能实现需求啊。

总的感觉，不是像网上传的天天码代码，熬夜加班， 这里基本不存在。反而觉得写业务代码太简单...梳理流程重要而且复杂，麻烦。

写业务代码对技术要求不高，公司提供的基础设施比较丰富。

既然是业务开发，那就是业务很复杂，觉得都在试着理解业务。业务代码一个旧的模块几十万行代码，几百个对外服务接口，调用其它模块也很多。而重构是我们要做的事，梳理几十万行代码。

如何提升自己

业务方面每个公司的业务都不同，而写业务代码技术不会有太多提高，所有的业务依赖的都是技术。

提升技术能力，研究轮子，自己造轮子，或造产品

提升对业务的理解能力，如下建议，优化业务架构

业务开发：除了满足产品提出的各种需求外，需要给留20%-40%的时间（用加班也行），想着怎样优化本身的业务架构：如怎样提升原来设计不合理的架构，优化之，提升稳定性、性能（容量）。一些通用的架构，需要提交到架构组，讨论方案。个人认为，能满足未来至少3年以上需求的架构方案，才算合格。

针对自己的情况，我时间还算过得去，这些时间取决于自己怎么利用，最终会产生不同的结果

早上：7点30左右到公司，到9点的时候都可以试着钻研一些技术相关的东西

晚上：20点多点以后基本上都是自己的时间

坚持做一件有意义的能让自己成长的事吧

最后

共勉，早日实现程序员的百万年薪！