什么是中型项目

中型项目是个很模糊的词，这里的中型项目需要满足一下两个特征：

• 代码量到了你不能乱写的地步
• 系统一直在运行，必须维护这个系统保障运行

什么叫代码量到了不能乱写的地步？对于小项目，比如一些小工具类项目，你能把控整个项目。你可以随意的重构，抽象成不同Pattern，而不影响工具的使用。而一旦过了临界点，到了一个中型项目，你对于每次重构需要考虑的点比较多超过你能管理的范围。说一说我对中型项目代码的理解，很多都是编程多年的经验。

注重模块化，谨慎抽象

在写中型项目的代码的时候，时时可以考虑项目的模块化组织，简单的将一些操作包装在一些函数里，进而形成一个模块。从而提高可操作的等级。建模和抽象却要推迟进行，特别是早期项目代码，你对业务理解没有那么深刻的情况下，你施加的抽象却能贯彻你的整个应用。无时无刻不影响着你。由于对业务的不了解或者业务本身的不稳定，你无时无刻不在偿还这些抽象的代价，加一个类似补丁似的代码。这会进一步恶化现有的代码，从而让以后可能的重构也失去了机会。

注重模块化的另一个优点是，给后期对业务的理解加深或者业务趋于稳定提供了重构的砖块。当项目模块化结构很好的时候，你再抽象出稳定的结构要简单的多。而对于已有抽象，你想要应用重构的风险和难度也要更大。

注重模块化的另一个好处其实是提炼业务本身，不同的应用有着不同的模式，但是这些近似的模式却有着细微不同，这也是为什么需要客制开发很多，你很难应用一个成熟应用配置来实现的原因。从模块化过程中走过来，你更加理解你的应用和别的类似应用的区别。而这些区别也是当前这个应用最大的价值所在——解决真正的业务问题。

注重应用运行时的可观测性

因为系统一直在跑业务，为了：

• 更快的处理问题
• 更好挖掘应用和业务

你还得注意和投入更多的精力在应用的可观测性上，即程序的动态表现。比如程序动态性能，业务的热点路径，问题的定位和隔离。最基础和实用的莫过于给应用程序加上合理的日志，让程序可profile，比如设置性能上的Checkpoint，Assert的你假设。当程序出现异常时候及时提醒。

然而更有趣的是通过观测应用的动态运行数据，更深入的了解和优化现有的业务。通过设置一些Counter，以及针对业务埋设的一些观测点，你可以知道你业务中的真实热点。有的时候业务上的热点并不是你期望的热点。当然你可以提高热点的性能，你可以通过引导来将热点引导到你期望的热点中。

我们程序员会时常陷入到一个问题：我们的优化方向在哪里，即我们下步做什么？如果只是听业务方或者项目经理的，一来你会很被动，二来，他们的判断也有可能会跟真实业务情况相差很多，这不仅是我们自己的价值体现，更是业务本身的价值体现。