首先，先说明一下“规划项目结构”具体的工作内容是什么。以二个常见的程序开发平台来说，不管是用 Visual Studio 来开发 .NET 的程序，还是用各种 IDE 来开发 Java 的程序，都会有一组用来辅助 IDE 进行代码项目管理的文件、甚至会伴随着一到数个特定的目录结构。只不过，这些都不是这篇文章要涉及的部份。而是除了这些内容以外，由开发人员自行产生的文件该如何妥适的进行分门别类的工作，就是这篇文章所提到“规划项目结构”要主要工作内容。
对很多的从业人员来说，“规划项目结构”可能是个无足轻重的工作项，心里会想：不就是开几个目录把文件往里面丢就完事了吗？能编能跑才是王道！会这样想，大部份应该都是以开发小型项目为主，所以好与不好的项目结构在效益上并没有太大的差别。
举个例子，如果你是网拍的卖家，打算做个小本生意，只有一人负责接单、发货。货品的种类和数量都不会很多的情况下，进来的货可能就只是随手扔在脚边，不管怎么堆只要有一套自己的逻辑就行了，不愁找不到货。但是如果网拍的事业开始小有名气了、要逐步地扩大规模，发货的品项或数量都不再是一个人可以负荷得来时，就得要增加人手。一旦人手增加了，同样的模式下问题就跟着出现。如果放任新加入的人随个人喜好来摆放货物、大家各做各的，要如何才能有效地掌握目前存货的情形？况且人吃五谷杂粮哪有不生病，没有统一的理货方法，其他的人要如何接手？所以把例子的层级拉高来看，对于一个成熟的网购业者来说，仓储就是一门学问，如何设计货架以便分门别类地来存放货品，是维持营运的重要环节。
同理可证，很多大型开发项目也都是由小系统开始，应该很少有人会听到自己的老板一照面就说：咱们来做个功能无敌丰富的系统呗！大部份应该都是：我有个想法，先做个小系统来看看市场的反应，如何？好吧，既然是个小系统，那开发就随性一点，看起来有个样子、功能正常就行了。
跟先前网拍的例子一样，你怎么知道你现在的小系统不会意外地发展成大系统？有些人也许会觉得：等到了适当的阶段，再一次性地投入资源，进行重构就好啦！不要花时间在无谓的事情上。然而，系统的发展很多时候就像是温水煮青蛙一般，等察觉到系统已经大到需要有一个较好的分类模式时，代码早就已经盘根错节。在大部分的人都会有的因循苟且心态下，重构？别傻了，只要能够如期交付工作就上天保祐了，哪有多余的力气去做吃力不讨好的事。
好的项目结构也是工作质量指标其中一环，当代码依据着规则分门别类地放置，在后续的维护上自然会有一定程度的助益。不论是开发人员间工作上的指派、轮调，或是在降低新进人员的学习曲线上，都会比杂乱无章的项目结构要来得成本低。
另外一方面，在面向对象的原则之下，每一个类的任务应该要尽可能的单纯，其中的一个效果就是让单元测试可以更容易地被开发。在测试程序的代码覆盖率达到一定的程度，有自动化回归测试的辅助，这时候谈重构才会有足够的利基。否则谈到重构，最大的恐惧都是来自于对于系统稳定度的疑虑，在这种情况下自然不会有人甘冒风险去更动已经完成的部份。
这时合宜的结构规划就可以辅助开发人员，做为类内容是否过于复杂的衡量基准。如果每一个类功能够单纯，则在分类上就会减少很多模棱两可的情况出现。反之，则会因为类负担了多个任务，在分类上容易出现歧见，或是无法决定该放在哪一个分类之下。
所以古人说“慎始”，同时也说了“勿以恶小而为之”，养成良好的习惯是很重要的一件事。当你是架构师时“规划项目结构”是你要思考的细节。就算是一人项目，也应该认真地考虑替自己设定一个可以因应系统扩大的准则，为未来承接更大的系统而做好准备。
附注
新开了一个架构师的文集，未来打算在这个文集里不定期地放一些在担任架构师时的工作经验或心得，有兴趣的朋友可以关注、期待一下。
