起因

说实话，我不是那种经常编写大项目的狼，显而易见，我的项目通常很小，我保证它们模块化和仅有必要的功能。
但是最近，我接受了一个大项目。我不知道为什么，真的，通常来讲我会拒绝这样的委托，但是这一次不一样，我完全没有拒绝的意思。
那么就会遇到一个很头痛的问题——源代码分类。
这个项目的源代码经过其他人之手，项目有些杂乱无章。我尝试进行 O.R.I. 重构，并且对源代码文件进行分类，但是最终依然一团糟。但如果要项目重构，分类问题依然是个很严肃的事情。

即便我自认为我已经很大程度上做的很好，我保证命名井然有序，保证文件分包的包名称目录具有一目了然的特性，但我意识到过度有序会导致我的文件夹相当多，复杂，难以管理。我开始怀疑自己对分类的理解。

解决

我搜素资料，试图解决这个问题。别惊讶，任何喜欢优化自己工作区的开发者都会不停的为止奋斗，然后在社交平台上展示它们。

我得到了我想要的答案——feature（特征）。
没错，只需要一个文件夹，我的工作区就会变得爽朗。为什么？这是我将会提到的：

整顿

事实上很多分包可能会被分的很细致，但是它们有个共同点——属于工具,或者功能。如果工具都会放在 util，那么功能就非常适合放在 feature，无论是记录器，还是函数。

为什么这么说？举个例子：我们可能在服务端有一些数据处理器，而在客户端有另一些。这样我们可能会有两个分包，分别在 server 与 client。但是事实上可以合并为一套文件，一套 DataHandler，放在 feature。目录和文件都被减少了，同样的思路去处理项目里其他本不应该被分成多分的文件，这比 O.R.I. 高效多了。

合并

即便我们合并了一些客户端和服务端的数据处理器，但这还不够。通常我们可能有一些自己的数据需要处理，如果是普通项目，这些处理器会被放在 core.func 下。好吧，我不会建立 handler 文件夹的，太具针对性了。helper 文件夹更是意义不明，曾经的我才会喜欢这些东西。

是时候合并文件了。把数据处理器压缩成几个函数，再通过 Lambda 集成到 HashbasedTable，最终得到一套文件，而这个文件也非常适合放进 feature 文件夹。

清理

当一切都井然有序的安排，那么肯定会多出一些空文件夹，或者仅剩下几个文件的文件夹，此时可以保持分类，尽量消灭这些文件夹（除非必要）。