面向需求编程才是常态，聊聊我的经历

Posted 2021-04-27 码农翻身

这篇文章中的内容在几年前曾经发过，之所以今天整理一下再发一次，是因为最近不少有人问我类似的问题：

工作无聊，主要是增删改查。

现有项目很烂，在上面修修补补

没有从事过高并发，大流量的项目，简历没有亮点

......

想想我自己这10多年的开发经历，主要做企业应用开发，业务复杂，业务逻辑都不讲逻辑，要求稳定性，很少有机会去设计高并发，大流量的项目。连从头开始一个项目的机会都不多，大部分时间都是在现有项目的基础上面向业务，面向需求做开发。

我想这才是中国软件业的常态吧！在这种情况下，抱怨没用，跳个槽估计业差不多，还不如自己多思考，看看在工作中怎么搞点事情，提升自己的价值，我举几个我自己的案例。

0 1

我原来做过一段税务系统的开发，公司有一个自研的平台，包括了表单设计和工作流设计，把底层的Java EE都给封装起来了，在上面做开发，让人很绝望，什么底层都接触不到。

实现了一些税务的具体操作以后，我就慢慢的发现了这些操作的共性，但就是不知道该怎么描述出来, 思考了很久也没有头绪。

有一天骑自行车回家的路上， 突然间就“顿悟”了：奥，这些税务操作其实就是点（x,y）在二维坐标系下的移动 !

第二天回去就把这个东西整理成文档， 并且把代码也做了改写，因为有理论指导，代码变的特别简单，很健壮--- 之后这就成为我简历中的亮点了。

一个月后有个老外来北京， 看到了我抽象出来的关于税务的操作，吃惊不已， 一直在问：这是你搞出来的吗？

0 2

使用那个自研平台的工作流开发出来的程序，必须得部署到app server中才能测试，并且只能手工测试，费时费力，我当时就想能不能像Junit那样写好脚本，然后自动化地去测试啊，把这个想法给Leader说了，他非常支持，就按照这个想法去实现， 后来发现和数据库紧密耦合，难以完整实现。虽然如此，这也是我工作中的亮点了。 

值得一提的是，这些亮点最终都指向了业务目标：更好更快地实现需求，而不仅仅是show 技术。技术是为业务服务的，仔细想想公司的业务，流程，用的工具，从技术角度好好想想，是能发掘出东西来的。

0 3

我曾经在一个研究所工作过几年，虽然有开发任务，但是很少有进度的压力， 在那里是很清闲的。

当时在做一个小数据集成项目，需求明确， 系统也不复杂 ，开发着也挺无趣的， 我就琢磨着能不能搞点别的事情， 后来就发现了敏捷软件开发， 对里边的实践非常认同，于是就学习了单元测试，TDD(测试驱动开发)，结对编程，用户故事 等实践，  在项目中也尝试着做了应用， 尤其是TDD, 的确不错。

再后来就进了IBM， 没想到几年前种下的种子开花结果了。IBM 也开始提倡敏捷转型，于是我几年前的积累就用上了， 不仅仅帮助本团队做了敏捷转型， 还走出去帮助工行、农行、华为、鼎桥等公司做了敏捷咨询， 不但进一步提升了水平， 也为自己的简历增光不少。

0 4

刚进IBM的时候做了一个极其简单的小项目， 就是用户登录， 然后显示一个Applet （没错，就是上古时代的Applet）， 这个Applet 基于IBM 的Samtime ， 实现了让用户和公司的客服实时通信功能， 类似于QQ, 但是只能发文本消息。

后来由于Sametime升级， Applet也要更新， 我就接触了Applet的源码，做了改动， 一切看起来没什么大不了的， 很正常。

唯一的不同是我多做了一点工作， 深入的研究了Sametime 的SDK, 带来了两个重要的好处：

(1) 在developerWorks上发表了第一篇中文的sametime sdk文章，后来形成了一个系列。

这一系列文章被很多人看到， 并且直到6，7年以后，我都离开IBM了，还有人发信问我相关的问题， 影响力应该是很深远的。

(2) 彻底理解了基于事件的编程模型 ， 因为Sametime SDK的编程就是基于事件的， 等到几年后Node.js 开始出现并且流行开来时， 我发现它和当年的Sametime 编程模型几乎是一样的，都是异步的、事件驱动的， 就像喝凉水一样轻松掌握了， 后来写了一篇文章《》

看完了我的故事，也许你有所触动，像那些高并发、大流量的项目不是每个人都能接触到的，面向需求编程才是常态。

在开发过程中，建立对整个系统端到端的理解，在业务、流程、工具等领域多想一想，肯定能发现让自己闪光的、有价值的点。

（完）