续：过度工程

在上一篇博客中，提到了几种常见的过度工程，然而不幸的软件团队有各自的不幸，故事似乎远不止这么多。

 

 

又见可扩展性，到底要扩展到什么时候？

见过一些同事，写代码处处考虑灵活、兼容，已经易扩展，一个简简单单的类实现，硬生生地被拆成从接口到抽象类到策略接口到策略实现类到辅助类到工具类十几个类来完成，和可是结果呢？还没等扩展开始，项目就黄了；或者某心态居高的程序员看到了，看着不爽，想不明白，给重写了。

这类程序员拥有负责任的心态和充满热血的心肠，可他们需要健康的引导，否则这样的人会写出危害深重的代码，成为“简单问题复杂化”最常见的一种表现形式。

我们需要优秀的代码结构，需要考虑未来的一二三，可是倘若能让简洁的代码刚刚好交付，让这些兴许成为庸人自扰的可扩展性等到需要的时候再重构完成，岂不更快哉？

 

引入新技术的纠结

程序员对技术的*本质是一件好事，但是在新技术的引进上，无论小大，必须有清醒的头脑。至少需要考虑这些问题：（1）License？

（2）是否能对短期内项目带来有效提升，或者对可以预见的时期内给项目带来价值？如果提升不大，或者价值太遥远，宁愿放弃它。

（3）学习成本？

（4）问题定位成本？比如，我希望新技术有广泛的社区支持，有成熟的团队支持，有既有的成功应用，我可以拿到开源代码等等。

（5）性能、体验、可维护性等方面是否带来不可接受的负向效应？

……

 

分层、分层、再分层

一个通用的解决WEB应用的办法是分层，把MVC扩展，M可以归类到不同的区域中，V可以分摊到各类模板集合中，C可以拆分成Action-Facade-Service；还可以继续拆！这只是最简单的拆分，拆分永无止境，总想把这个项目所有的问题统一到一个通用的结构中去。

结果看到了诸多这样的代码：

class UserFacade
{
  public User getUser(XXX)
  {
    return userService.getUser(XXX);
  }
  public void setUser(User user)
  {
    userService.setUser(user);
  }

}

 

到处是这样的代码（往往伴随着尚无用的接口出现），薄薄的一层，没做什么有价值的事情，直接调用下一层的代码，除了“啰嗦”和“多此一举”我不知道还能用什么来形容它。

 

转测试的艰辛

ST、SDV转测试发布版本，通用的瀑布模型，但是头轻脚重。设计阶段草草了事，编码阶段不断加班+延期，到了ST、SDV阶段，拼了命地改bug，过基础功能测试用例、转测试发布，从ST两轮，SDV1再到SDV6，问题仍不见收敛，程序员大量的时间用来进行测试验证，走问题单的流程，可质量依然、似乎永远是个痛，可怜的程序员，怎么总要折腾在发布版本的边缘？

 

程序员还在没日没夜的干活，故事就不会停歇，也许有一天，大家都突然想，做项目应该是一件创造性的活动啊，不应该是这个样子的……

 

文章系本人原创，转载请注明作者和出处