我对编程的了解已经足够让我陷入麻烦了大约 10 年。我没有受过正规教育，尽管我读过很多关于这个主题的各种语言的书籍。我现在主要关注的语言是 PHP，至少就我现在所做的事情的规模而言。
我使用了一些 OOP 类有一段时间了，但从未深入了解幕后的原理。我还没有达到我想要的表达水平，但是我最近阅读了The OOP Thought Process这本书让我想要提高我的编程技能。
有了新概念的动力，我开始了一个新项目。我编写了一些可重用的类来处理用户身份验证、用户配置文件、数据库接口以及我在大多数项目中经常使用的其他一些东西。
现在已经将我典型的乱码意大利面条碗混乱的代码拆分成一些有组织的文件，在确保文件在需要时全部包含在内，如何在逻辑上将脚本划分为类时，我遇到了一些问题，以及我应该如何划分每节课。
我真正需要的是建议或建议阅读，而不是关注特定的功能和代码格式，而是关注不仅仅是一个爱好项目的项目的逻辑布局。
我想学习如何正确地做事，虽然我还在某些领域学习，但除了创造性和试错之外，我对此一无所知。主要是错误。
感谢您的任何回复。这个地方很棒。
我将尝试在这里表达我以前项目的经验，也许它们对您有所帮助。
如果您尝试对项目进行细分，请尝试找到可能对自己有用的组件。如果您编写例如数据库层，请考虑如何使数据库层独立于应用程序的其余部分（实用程序类和配置除外）。如果您编写访问数据库层的 RichClient，请尝试将您需要的内容准确地放入其中，这些内容在从 Web 层访问它时也需要。现在您有了一个在命令行客户端中甚至可能有用的组件。
或者，如果您想从较低级别看到这一点，请将您的应用程序拆分为小单元，并且不要让这些单元具有循环依赖关系！！！如果两个组件具有循环依赖关系，则它们不能被拆分，实际上应该是一个组件。我知道，我有时违反了这条规则，因为你不能总是坚持下去，但这是了解应用程序构建块的好规则。
另一个流行的应用程序划分规则是模型-视图-控制模式 (MVC)，它指出模型（数据类）、控制（程序的逻辑）和视图（图形用户界面）应该是拆分成不同的包。当我坚持这一点时，我会像这样划分我的代码。在每个包中，我都有不同的模型、视图和控件类，但模型类对控制层一无所知，而控制层对 GUI 也一无所知。
由于 GUI 开发总是乏味的，因此通常是应用程序中测试最少的部分（至少在单元测试中），将其从控件中分离出来可以更容易地编写业务逻辑。事实上，它可以让您专注于您必须做的事情，即完成工作，您可以在业务逻辑中对其进行编码。如果这部分有效，您可以花时间为它编写一个漂亮的 GUI。当然GUI和易用性往往会给控件带来自己的要求，但至少它是松耦合的。
在我目前的大型项目中，我们有一些位组件，我们现在将它们视为独立产品，被真正的产品使用。这让负责人更容易测试和编写独立组件，并给每个人一个更稳定的组件。
只是我的2美分。