转载

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

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

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

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

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

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

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

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

01

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

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

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

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

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

02

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

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

03

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

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

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

04

刚进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 编程模型几乎是一样的,都是异步的、事件驱动的, 就像喝凉水一样轻松掌握了, 后来写了一篇文章《Node.js:我只需要一个店小二》

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

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

原文  http://news.51cto.com/art/202003/612850.htm
正文到此结束
Loading...