企业上云？也许只差一个代码生成器

Posted 2020-11-29 溪源的个人博客

甲方爸爸，大概你要的是代码生成器吧？

一

1）

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

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

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

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

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

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

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

他：你倒这么说，也有那么一点点像。

2）

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

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

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

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

3）

我： 你们太难了。为啥这么赶啊？

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

我：那能不能多招几个测试？

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

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

二

1）

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

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

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

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

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

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

2）

然后，有那么几年，市场突然间就“做烂“了。
一方面，国家将投资方向重点放在了房地产领域，对信息化的投入也逐渐收紧了许多；
另外一方面，企业过去匆忙上线了太多的软件系统，不同软件系统之间的对接沟通困难，操作过程缺乏连贯性，使得基层员工开始抗拒这些”看似“能够带来效率提升，却容易出现各种质量问题导致自己过去几天工作量返工的所谓”信息化“系统；
另外，大家也都很清楚，效率提升其实带来的是”裁员“，首先被裁的...

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

三

1）

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

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

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

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

2）

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

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

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

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

2）

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

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

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

回顾这段时光时，老张说了一段话：

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

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

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

四

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

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

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

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