遵循我所知道的路径，然后尝试实施正确的编码实践，还是从良好的编码实践开始，并尝试弄乱我的方法？

首先，我想说我习惯于做过程编程，这是我的爱好-我正在尝试用几种语言学习OOP，并了解理论，而不是实践。

我有一个我想构建的宠物项目，特别是在带有数据库后端的PHP中（根本不在乎哪个）。我的主要原因是该应用程序可以在任何设备上使用，因此WebApp似乎是合乎逻辑的选择。

我了解要构建可维护的PHP WebApp，应使用OOP，类，框架，库等。这听起来很合逻辑，因此我决定尝试一些流行的应用程序。但是，在整个周末都只是尝试它们并尝试阅读教程之后，试图将这些教程适应我的小项目，我既困惑又沮丧。

我决定（主要是为了进行概念验证）在另一个程序（Microsoft Access）中构建该应用程序，并在短短几个小时内实现了我的主要目标-除了Web部件。

我的问题是，我应该遵循我所知道的道路，然后尝试实施正确的编码实践，还是应该从良好的编码实践入手，并尝试弄乱自己的方式？对于这个项目，我希望它可以在GitHub上开源，因此我将对使用和更改我的代码的其他人开放，但是我也知道，如果代码编写不当，将很难聚集编码人员来提供帮助。

最佳实践主要是从经验中收集的建议和提议，以帮助使项目更容易实现。

该恕我直言的关键方面是体验部分。尽管这些最佳实践是有更多经验的人们与初学者分享的好方法，但我认为仍然需要最低限度的经验才能真正了解这是什么最佳实践。否则，就等于盲目地遵循法治，这最终会减慢您的学习速度，因为您会慢慢让别人为您思考。

无论如何，对我来说，在软件项目中要做的最重要的事情是……好吧，完成它，交付它……简而言之，使它正常工作！

在此之前的任何东西都是汽器，是您想象力的虚构。只有当您有一个可行的东西时，您才能真正评估它是否缓慢，难以维护，难以测试等。使其运作的过程将揭示某些东西，也许有一种最佳实践可以帮助您重新考虑它。以使其更容易达到该目标的方式。

因此，是的，从您首先了解的内容开始，注意您所做的困难的事情。碰到墙时，请后退一步，看看那堵墙，了解它是由什么制成的。在很多情况下，您会意识到自己是问题的根源。您缺乏对要解决的问题的某些部分的了解，缺乏对如何更好地利用现有工具的知识，或者对整个过程都无所适从但仍未准备就绪的其他工具一无所知开始精通。

同时，继续阅读有关做事的新方法。阅读这些最佳实践，并尝试看看它们是否适用于您在项目中发现困难的任何事物。如果不是，请记住它们的存在并不时重新访问它们。保持好奇心。随着时间的流逝，您将看到上面所做的观察自然会随着您在此处获得的知识而自然而然地点击。

最后，对您学到的东西进行实验，看看它是否确实使事情变得简单。坚持下去，最终您将了解最佳实践。遭受痛苦并学到了使之变得更容易的人的简单建议。哎呀，您甚至可能不同意其中的一些，并发现您的方式实际上对您更有效。但是，如果您不了解，您只会盲目。

祝好运

TL; DR

您将一无所知。您所知道的每个“事物”周围总会有更多的深度和广度。边走边学。应用您认为现在相关的“最佳实践” 。犯错误。只是要避免犯下代价高昂的错误。如果您的项目可能导致重大错误，请寻找导师。

现在答案很长...

1.“工作软件是进度的主要衡量标准。” （敏捷宣言）

如果您能看到自己知识的优势，那就太棒了！追求边缘！保持学习！但是请记住，您可以永远学习和分析。

建立东西。

2.学习并犯错误；但不要制造“坏”的东西。*

不断突破知识/技能的界限。你会犯错误。您可以向他们学习。但是，您不必鲁ck。

您寻找和与更有经验的开发人员和导师一起工作的时间应与项目的业务价值和风险状况成比例地增加。

如果你正在做一个小CLI 自己：获取但是它的工作你想要的。

如果你正在写一个银行的门户网站：环绕自己与非常有经验的开发人员。

3.“最佳做法”应该用引号写出，并且要眨眼。

如果至少在某些情况下观察到成功完成X的操作，则“实践”被提升为“最佳实践” 。有人认识到实践A对实现收益X的好处，并宣布它是互联网上的“最佳实践”。其他人则表示同意-通常有充分的理由。但是，从那时起，我们通常会忽略为什么某些实践是“最佳实践”而另一些则是“反模式”或“臭味”。

问题是，“最佳实践”永远不会自私自利。“反模式”本身并不是真正的恶魔。而且，甚至“恶臭” 有时也仅来自腐烂。有时候，那臭味只是一种花哨，美味的奶酪...

您不练习“依赖注入”（DI）之类的事情，因为“依赖注入” 对于业务本身具有宝贵的价值。甚至不需要构建有效的产品。它完成了最终产品中您可能想要的东西。但是，这也可能会使您的工作花费更长的时间，而没有任何好处...

嗯...

因此，您应该遵循“最佳做法”吗？即使您不了解它们？...呃...是的。我是说不 但是，是的。但是，只有那些真正适用于您以及您的软件及其目的的软件。

调用POAP！^{（是的，我的博客。）}

原则，模式和实践不是最终目的。

因此，每种方法的良好和正确应用都会受到更高，更最终的目的的启发和约束。您需要了解为什么要做自己在做的事情！

（POAP不受POAP的限制。）

因此，例如，您可能不完全了解DI的每一个细微差别。但是，如果您了解意图，您将知道是否“应该”使用DI，并且您会更好地隐含地理解DI。

而且，一旦您发布了该产品，您就可以反思DI（或其他任何方式）是否真正有益。如果是这样，请以书面形式阐明原因。如果没有，请以书面说明原因...

奖励阅读/相关程度：

分析瘫痪是一回事。您需要分析和学习；但是，您还需要完成工作。平衡。

您可能总是觉得自己像个牛仔编码员。

^{* 如果您做任何值得注意的事情，您实际上都会犯下严重的错误。但是，我想你是人类。因此，我们会提前原谅您...或者，至少我愿意。也许。...好吧...我们拭目以待。}

我的问题是，我应该遵循我所知道的道路，然后尝试实施正确的编码实践，还是应该从良好的编码实践开始，然后尝试弄乱自己的方式？

也许会尽力而为，但还是要发货吗？用户如何评估产品的质量和吸引力以及其背后的开发人员如何评估代码的质量之间有两种不同的作用力。尝试使这两种力量尽可能地和谐。过多地专注于一个而又牺牲另一个通常是您最终会产生最适得其反的途径的原因。

好吧，首先，我建议您采用良好的编码实践不是在冒充……窍门是了解每种实践的目的以及如何正确实施。

快速的应用程序开发环境很诱人，因为您可以在很短的时间内完成很多工作。我一次在Access中建立了一个完整的会计系统。但是，您自己说了这句话：未经重写就无法将这样的应用程序带到Web上，那里所需的工具确实有所不同。

有理由为什么没人再使用Access或Visual Basic之类的可视化设计工具。它们往往使您与真正完成某些事情的代码隔离。访问是一个很好的工具，但是它确实需要Web应用程序专门设计来避免：安装。 自定义外观可能很困难；即使您不需要在网络上使用它，Access应用程序也总是看起来非常类似于任何其他Access应用程序。大多数编写第一个Access应用程序的人都不了解编写好的应用程序，而Access使得编写不好的应用程序变得容易。

因此，现在您辞职学习一种新技术，以将您的应用程序发布到网络上。您是否应该从一开始就以正确的方式构建它？当然。但是学习新的开发环境和哲学就像学习其他东西一样。您必须将其倾斜一会儿才能正确处理。

这就是为什么我认为您提出了错误的二分法。没有人首先学习所有的“最佳实践”。他们随身学习。但是要想在任何OOP语言中都能发挥作用，我认为您需要了解一些OOP，或者至少要了解类的基本工作原理。

就其价值而言，我认为PHP不是您的最佳选择。PHP之所以吸引人，是因为它“浅”，这意味着您无需了解很多即可编写有效的程序。最佳实践很大程度上取决于开发人员，这意味着PHP不会帮助您编写“好的”程序。这不一定是一件坏事，但这确实意味着，与Access一样，您最终可能会放弃PHP以使用更强大的平台。

将OOP视为可以在适当的时间应用的另一种模式。OOP并不是可以有条不紊地解决每个任务的框架。在软件工程中不存在这样的事情。

另请注意，人们声称是好的做法有时会令人怀疑。我经常看到经验不足的开发人员采用非常复杂的编程模式，这对于给定的问题是不必要的。代码的复杂性应适合于问题的复杂性。简单性是重要的价值。

网络上的文章，行业专家的言论以及高级同事的建议很可能是错误的。我已经看到很多了。

因此，我建议您使用最简单的解决方案来解决您的问题。可能包括您空间中一种流行框架的使用。在此约束内，您可以自由选择所需的代码类型。不要简单地认为他们的做法适合您的情况。

另外，了解为什么建议使用某些技术。例如，OOP与封装有关。您可以通过其他方式进行封装（过程也与封装有关）。

一个反面的例子：有时人们写一个数据访问层来抽象数据库。在这里，此模式的本质是变得独立于具体的数据存储，并将更简单的接口暴露给更高的代码层。但是，如果您不需要这些好处，那么就不需要数据访问层并且可以节省工作。但是，许多专家建议始终执行DAL，这是不正确的建议。

我发现好的代码经常很有趣。这很有趣，因为您可以根据实际需求进行工作，而不必担心基础架构问题。如果您发现自己所做的工作过于繁琐，则可能是您选择了错误的模式集。