CINT the Space Fleet 1(8)

那是三年前的初春。虽然程序规模必须史无前例地庞大，人们仍不言放弃。多态、重载、继承、接口、工厂模式、动态代理、面向切面，各种各样神奇的方法被用来规整代码。
（不仅是软件。在硬件需求同样爆炸的时代，奈芙莲和威廉也在默默努力着。然而人们习惯于漠视硬件的成就。）
但大型程序仍然面临代码混乱的严重挑战。程序一旦需要修改，经常牵一发而动全身。我甚至见过某前辈做了这样的游戏：几千个if语句盘根错节，一万条数据表挤在一个类(class)里，还为游戏里非常不重要的无征种角色做了35种模型，每种80帧动画……[26]
珂怕的是，这样的程序竟然能正确运行！即使是当时不怎么会编程的特等武官，也直接惊呼“麻吉呀巴库内！”。
写出这个游戏的老姐[27]值得佩服，但如果代码需要改动，她的设计模式就会招致灾难。我总结出了这样的经验：良好的程序应当“解耦”，降低不同模块间的依赖。
当时的程序猿大会上，我和珂朵莉在最高武官面前起了争执。
支持珂朵莉的人们大喊：“MVC[28]天下第一！”

因为珂朵莉能写出无比宏大却100%正确快速的逻辑控制。接着，珂朵莉做出了伟大的“数据库”。这项发明基于海量算法的坚实基础。没有算法的支持，我们就不可能在短时间内对海量数据完成增删改查。最后，珂朵莉本人作为完全超越传统评价标准的大神，当然不需要任何图形界面。于是，第一艘空中军舰上采用MVC设计模式的条件完全成熟了。
但我认为MVC不适用于一切军舰。这种设计方式仍然在代码间产生了较多的依赖。至少，控制器层的许多代码大概会被普通码农们做成几百个if {} else if {} else if {}……
我认为应该用“微服务”架构来搭建军舰上的程序。每个微服务都独立运行，负责简单漂亮地完成一件很小的事。各个微服务之间可以利用httpc[29]协议来通信协作。这样即使是萌新程序员，也可以参与小功能的开发，而不至于让整个系统都难以修改。
然而，没有人明确支持我——除了珂朵莉。
“抱歉啊……我的支持者反而在压迫我了。放弃MVC的话会被他们反对的……”珂朵莉这样对我说。