甲方爸爸,大概你要的是代码生成器吧?



1)

有一天,我的朋友Y童鞋分享了他正在做的一个内部开源项目,这个开源项目从外表上看,跟目前市场上那些代码生成器本没有特别大的区别,所以我兴趣并不大。

在他给我介绍了一下具体需求之后,我才体会了他的意思,并提起了那么一丢丢兴趣。。

毕竟,听起来有点“鬼扯”,为啥?因为,他居然试图依靠这个项目来生成”单元测试“。。。。


他:定义好数据库表和结构,然后就生成逻辑方法和代码、以及界面,还同时把“单元测试”代码给生成了,免得程序员要花时间去思考代码逻辑之余,还要想怎么写出可测试代码。

我:这样生成的代码还有灵魂么。。

他:有啊,编写高可测试代码,不就是我辈中人,这些有追求的码农应该实现的目标么?

我:这种模式怎么越看越像埃里克埃文斯大佬说的“Smart UI”模式啊。。

他:你倒这么说,也有那么一点点像。

2)

我:当然,能够生成单元测试倒也可以。毕竟大部分单元测试看起来似乎是一模一样的。无外乎就是“
Arrange\Act\Assert”,AAA操作猛如虎,测试代码一把梭。

他:我这个东西,生成的代码,除了看起来提高了单元测试覆盖率之外,其实,并不能提高代码的质量。

我:是什么逼得你要花时间去开发这样的代码生成器呢?


他:还不是被这班菜鸡开发者们产出的劣质产品闹腾的。我不是想着省测试的钱,又能提高产品的质量么?就自然而然只能靠压榨“程序员”来实现了。但是让我来对这么多人的代码进行审查,还是太难了。这不,用单元测试来操作,不就可以了?

3)

我: 你们太难了。为啥这么赶啊?

他:这不是甲方爸爸要加需求,他说得倒是好:加需求也就几行代码,多简单。但是我们这边,就得忙翻天,太特么累了。

我:那能不能多招几个测试?


他:端到端测试,只是看起来将缺陷扼杀在摇篮而已,实际上。。隐藏在冰山下的缺陷呢。。客户就是小白鼠啊。再说,我们现在家业太小,测试有两个了,再招就请不起了。。功能是不能少的,bug是不能多的,我只能想想单元测试这种办法了。

我:好吧。。我们也一样。。



1)

之前有个朋友老张介绍了一个故事,仿佛跟这个有点类似。他有幸参与了一个交通信息化的项目,这个项目的业主是国企单位,属于“体制内”的企业。

在过去一波有一波的信息化发展过程中,这些体制内的企业仿佛成为了许多IT企业竞相薅羊毛的对象。为啥,国企项目多、钱也不少,关键是国企对软件质量要求不高啊。


许多企业借助国企项目,他们依托所谓“快速上线”的神器,将中华民族艰苦奋斗的精神发挥到了极致,公司能够在最短的时间内,将原本停留在脑海里的软件,快速的转化成为实现,并部署到甲方爸爸的现场环境中。


至于软件的质量、软件的工程化水平,对不起,不重要?用户体验?性能?功能可用性?重要么,不重要。先快速上线回款再说。于是,这些企业获得了业绩的腾飞,老板们赚得盆满簸赢,好不自在。

而且老板们还会吹:我们公司最大的优点,就是在逆境下生存的能力,能够在最短的时间消化需求,做出最符合客户需求的软件。

好吧,仿佛这也是软件工程的一种方向?快速开发。。。。

2)

然后,有那么几年,市场突然间就“做烂“了。
一方面,国家将投资方向重点放在了房地产领域,对信息化的投入也逐渐收紧了许多;

另外一方面,企业过去匆忙上线了太多的软件系统,不同软件系统之间的对接沟通困难,操作过程缺乏连贯性,使得基层员工开始抗拒这些”看似“能够带来效率提升,却容易出现各种质量问题导致自己过去几天工作量返工的所谓”信息化“系统;
另外,大家也都很清楚,效率提升其实带来的是”裁员“,首先被裁的...

总之,有那么一段时间,国企对信息化是“弃若敝屣”的。



1)

但,随着“互联网”和“共享出行”的兴起,又让这个概念重新热炒了起来。


老张他们公司也有幸接到了一个这样的项目,公司还是一家非常大的出租车公司,拥有二十多家子公司,员工超过2万人。这个项目的目的是打通出租车和旅客的关系,借助于手机实现快速出行,同时打通企业内部信息孤岛,让总公司领导能够第一时间看到各种数据的流转情况,为建立科学决策提供依据。


老张被选为这个项目的负责人。在项目启动会上,他意气风发,向业主和公司老板们保证,将带领公司团队与甲方团队一起,以饱满的姿态打响这场战役,为业主的业绩腾飞贡献自己的一份力量。

然而,但项目启动后,他才深刻的明白这究竟是一个怎样的坑。

2)

首先是业主关系,由于业主是一家涉及大几万员工和二十几家子公司的大型集团公司,需要梳理的业务表单非常复杂,业务流程和体系,远比甲方爸爸预想的要复杂得多。


其次是开发周期短,不知从何时起,国企对于软件系统的印象就是“简单、容易、很快就能实现”,仿佛一个需求只要说出来,这般不要命的程序员们就能很快的实现功能。当老张跟他们提到需求太多,根本做不完时,甲方爸爸甚至说:怎么可能有做不出来的软件系统,是不是你能力不行?

再次是外部系统多,由于不同的子公司往往采购了不同的系统,要统一对接到一个系统 。

还有就是涉及的技术点多,需要在许多领域进行专门的技术攻关,由于公司暂时缺乏相关资源,使得开发过程屡屡收到阻塞。

2)


经过长达几个月的需求调研,老张编写了一份超过一千页纸的需求规格说明书,并获得了业主的批准,但项目正式开始时,他却只获得了短短半年的开发周期。此时,他手上能够调动的开发者资源,才不过10余人。


为了干完这个项目,他和项目团队的成员不得不牺牲周末和假期,辛苦坚持了半年,才把项目功能都开发完,但在项目实施环节时,由于子公司与总公司的意见不统一,根本用不起来。

最终,项目崩盘,公司倒闭,甲方将近一年的投入近乎白费。老张和项目团队也白白辛苦了大半年,还得去劳动仲裁,找老板讨薪。

回顾这段时光时,老张说了一段话:

“企业信息服务化的项目,看起来合同工价很高,其实都是坑啊。有的业主,根本不懂什么叫“合适的软件”。


在互联网如此发展的今天,这些业主,要的还是“快速开发”。但凡想到什么就往里面加,程序员不猝死太难了。许多需求今天提,明天就要,但是用了一次呢这些功能就不用了,我根本不知道这些软件,干出来有什么意义。

千万别跟业主提敏捷,他们会在你的每个迭代中塞根本干不完的工作量;也不要提拥抱变化,他们变起脸来,自己都怕。”



仔细想想,许多传统企业领导想上云、或转型到互联网,不就是这样么,恨不能一天就把项目干完,干完项目就“升官发财”,至于项目能不能用,谁知道呢。。

也许,他们要的并不是软件,而是一种“代码生成器”。嗯,输入“甲方爸爸的一万种需求”,输出“一个功能齐全、包容万物、自由变化的软件”。。

作为有追求的码农们,我们能像Robert大叔在《代码整洁之道-程序员的自我修养》一书中写的方法:选择“拒绝”么。

额。。生存要紧。。偶尔吐吐槽,饭还是得恰啊。