对网络应用程序的担心不是“面向未来”

#1 楼

完美是善的敌人。

换句话说，今天不用担心。如果您的应用程序执行了所需的操作，那就很好。进一步重写软件部分并不是一件坏事。到那时，您1）更清楚地知道您要构建的内容，以及2）知道哪些位实际上是瓶颈。您可能会花费大量时间来编写可扩展到一百万用户的应用程序，但是对于您当前的六个客户而言，这不会比您现在拥有的更好。

#2 楼

关于如何克服这种思维障碍并确保我的应用程序可扩展的任何想法？


问题的症结不是可扩展性。问题的症结在于，您认为第一次就可以解决问题。

您应该专注于编写简洁的代码。因为当您将来（不可避免）需要更改某些内容时，简洁的代码可最大程度地提高便利性。这就是您应该达到的真正目标。

您现在想要做的就是尝试考虑编写完美的代码。但是，即使您成功做到了，谁会说要求不会改变，或者您可能是基于错误的信息或错误的沟通来做出决定？

即使有错误也无法避免不是你的错。专注于编写易于在以后进行更改的代码，而不是希望编写将来不需要更改的代码。


与项目紧密相连，并且我已经写过的代码，


我对此表示完全同情。但是，依附于您编写的代码是一个问题。

唯一应该成为常数的事情是您希望解决特定的问题。

如果明天发布的新工具将您的代码库减少80％，您是否会因为不再使用代码而感到沮丧？还是对代码库变得更小，更干净/更易于管理感到高兴？

如果是前者，则有问题：您看不到代码的解决方案。换句话说，您只是专注于代码，而没有看到更大的图景（它旨在提供解决方案）。


我担心我所做的所有其他工作都会在不久的将来，当应用程序随着业务增长而无法很好地扩展时，这种情况就发生了翻天覆地的变化。


在不同的日子里这是一个不同的问题。

首先，您要构建可行的东西。其次，改进代码以修复可能仍然显示的任何缺陷。您当前正在执行的操作是因为担心随后必须执行第二项任务而推迟执行第一项任务。

但是还有什么其他选择？你不能告诉未来。如果您花时间思考未来的可能性，无论如何您最终都会猜到。猜测总是很容易出错。

相反，请构建应用程序并证明确实存在问题。问题一旦解决，就可以开始解决。

换一种说法：亨利·福特从未制造过符合2018年标准/期望的汽车。但是，如果他没有按现代标准制造出有缺陷的T型车，就没有人会开始使用汽车，就没有汽车工业，也没有人会尝试改进汽车。 br />

我曾让雇主质疑我的选择，即在面试过程中不使用任何Web框架，这只会使我进一步怀疑我以前的工作。


此处的重要部分不是您使用的是哪个框架（任何以此为依据对您进行评估的雇主都无法正常工作）。这里的重要部分是知道您在做什么以及为什么这么做。例如，您可能会避免使用现有的框架，因为您想了解为什么这样做对框架有用首先是艰难的方式。或者，您可能要尝试创建自己的框架。

唯一的错误答案是“我不知道”，因为这表明缺乏明智的决策。这对雇主来说是个危险信号。


我根本不知道任何Web框架，也不知道要开始使用哪个框架。


这里也出现同样的问题。解决方案不是思考更多，而是行动起来：




停止思考完美的答案。
选择一个框架。除非您有偏好，否则请随机选择一个。使用飞镖，掷骰子，掷硬币，挑卡片。
使用它。
您喜欢使用它吗？您发现有什么烦人的东西吗？
请注意如何避免这些不良因素。您是否滥用了框架，或者这只是框架应该工作的方式？周期。

要详细了解此内容，请阅读《做事的心态》>思维的心态。作者对其进行了详尽的解释。


但是完成应用程序的压力越来越大，我正在考虑完全废弃该应用程序并重新开始


除非当前的代码库是绝对无法维护的混乱；您在做出相反的决定。
开发人员经常认为扔掉一些东西是更好的选择。这是一种非常普遍的感觉。但这很少是正确的选择。

从头开始扔掉代码就像在上班途中卡在交通中，担心自己上班迟到（错过最后期限），并且而是开车回家，再尝试沿着同一条路行驶。这没有道理。您可能会遇到交通拥堵的情况，但与在家时相比，您离工作更近了。

#3 楼

尽管Facebook和Google投入了大量资金来说服您，否则前端框架的存在主要有两个原因：


首先，将硬件/网络需求卸载到客户端通过将状态和逻辑放在客户端中的操作
第二，与支持第一点所必需的其他客户端逻辑有关，它们提供了隔离的执行上下文，以便您可以将其他人的代码填充到页面中而不会破坏任何内容。

如果您的应用程序本质上是有状态的，如果要保存的应用程序状态量非常复杂，并且可能需要很多，则可能只需要找到一个框架来解决这些问题。网络延迟（移动或与服务器距离较远）的客户端，或者是否有强大的业务需要支持特别高级的CSS或动态元素创建。

框架营销希望您相信他们的特殊方法阿奇结构提高了开发速度并使维护更加容易。对于从事简单项目的小型团队来说，这显然是不正确的。隔离代码和组织导入可以帮助大型团队更快地将产品推向市场。它只为一个已经在运行的项目中工作的单人开发团队提供了更少的钱。

与实际实现功能相比，您将花费更多的时间来学习如何将现有的功能代码放入框架中，并且很有可能有人在某处进行更新，并且用该框架编写的代码会除非有人在那里不断维护它，否则它将在18个月内停止运行。

Vanilla JS，以及程度较小但仍相当重要的JQuery，都不会遭受这些问题的困扰。除了一些值得注意的例外，JQuery + AJAX应用程序不依赖于浏览器特定的行为，并且在合理的情况下放弃了外部依赖关系，它们在最初编写时进行了很小的改动就可以继续工作10到15年。
非常适合支持不断发展，复杂且面向公众的Web应用程序的典型初创公司。他们使大型团队可以很好地协调，与供应商添加框架很好地集成，并支持新颖的小部件和设计范例，以帮助您保持竞争力。

对于具有固定您将要放弃的受众群体。采用框架既会降低您适应新范式的开发速度，又会带来不必要的兼容性风险。保持客户端代码简单（理想情况下是自托管）意味着兼容性风险的表面积大大降低。浏览器将发生变化，CDN网址将停止工作，依赖项将过时-但是没有人接触该服务器，它将保持正常运行。

除非解决了一个问题，否则不要采用框架。您今天遇到或可以很快预见到的特定体系结构问题，强烈建议您考虑采用另一种方法解决该问题，如果这一切都成立的话。

#4 楼

要使应用程序“面向未来”，最好的办法是遵循系统设计中的最佳做法，以最大程度地消除问题的耦合和分离。您的应用程序中没有什么部分可以避免过时，但是您可以做很多事情，以将由于X原因而过时的代码与不一定受X影响的代码隔离开来。

但是，我认为您对应用程序的增长/可扩展性的关注应小于您自己的经验和功能的增长率。您所描述的思维障碍对我来说听起来像是学习停滞或了解许多已知未知因素，而没有解决这些问题的策略或工具。

框架并不是特别适合解决“面向未来”的挑战，尽管它们通常可以通过MVC等高级设计模式为没有经验的人提供相关的初始指导。相反，它们往往通过提供强大的凝聚力而更有效地用作加速发展的方式，并且往往以更紧密的耦合为代价。例如，假设您在整个应用程序中使用某些框架提供的对象关系映射系统来与数据库进行交互，并完成缓存系统集成。也许以后您需要切换到非关系型数据存储，现在使用它的所有内容都会受到影响。

您现在遇到的麻烦不是来自使用的地方，而是您使用的地方（可能几乎到处都是后端）。如果呈现页面的代码从不获取其呈现的数据，那么您的状况会好得多。

假设您想向页面添加一些小部件，这需要额外的脚本和资源才能正常工作。如果您使用的是框架，则可以问“它如何让我为此添加依赖项到页面？”如果您不是，那么这个问题就更开放了：“我要解决的技术问题应该以某种方式分开？”这个问题需要更多的经验来回答，但是这里有一些提示：


如果明天将所有静态资源（脚本，图像等）移至单独的服务器，将会发生什么情况，内容分发网络等，或者开始尝试将它们打包在一起以提高性能？
如果您将此控件放置在不同的页面上，或者将其放置在同一页面上的多个实例，会发生什么？
您如何开始在不同版本的窗口小部件上执行AB测试？

如果其中的任何一个听起来不可行，那么我建议您现在应该使用一个框架，而不是为了您的目的而过多使用应用程序，但为了您自己的个人成长。不一定要从头开始。而是使用框架作为课程表来帮助指导应用程序的发展。

只有两种学习方法。一种是通过反复试验，另一种是通过学习他人的经验。试错法不能消除。从本质上讲，软件开发是一个不断学习的领域，根据定义，不需要执行任何新的或不同的代码。 （而不是使用已编写的代码。）

诀窍是通过在整个过程的每一步中主动寻找预先存在的知识（策略，最佳实践以及代码/库/框架），以将其最小化。开发过程，所以您不会发现自己在不断地重新发明轮子。

但是，对于您当前正在编写的应用程序，您的首要关注应该只是以最小的努力来完成它（这有点像代码的味道，但是对于开发过程而言）。鉴于人类学习的本质，实现高质量的最快方法是从某件事开始。当您可以通过批评已有的东西来塑造目标时，要理解目标就容易得多。

如果您可以接受编写的大部分代码，这是一个一次性的学习过程，并且是找到良好设计的必要条件，这将有助于您继续努力。毕竟，解决问题的挑战使软件开发引人入胜，并且如果您正在做的事情值得，那么这个挑战就永远存在（请参见上面的“持续学习”声明）。

#5 楼

最重要的是，“丢东西然后重新开始”绝不是选择...毕竟，您不是说您有“六个客户”吗？鉴于他们现在（大概）“对您的工作非常满意？”，您是否已经停下来考虑他们对您的发音有何看法？！

我喜欢用一个类比： br />

“我的工作是建造供人们居住的房屋，供人们在其中开展业务，等等。”我的工作是制造“那些不可能微小的，过度砂化的沙子”来做有用的工作。 （就像房屋建筑商用石膏墙板，瓷砖，混凝土砌块和2x4的房屋建造房屋一样。）
然而，房屋建筑商使用的“钉子”实际上在200年中变化不大（除了从“正方形”到“圆形”，然后在气动打钉机上变得有用），我们使用的技术千变万化，有时会发生非常深刻的变化。 （“顺其自然。”）
“尽管如此，每栋房屋一旦建成，将永远存在。”你不能驱逐他们。一旦构建并移交了密钥，“它不再是您的房子”。这就是现在，它将持续很长一段时间。

如今，我的大部分业务是帮助客户应对由十，二十， 30年前或更早的时候，使用当时的技术（我记得还记得），并且今天仍在使用（！）。

#6 楼

确保某种东西是未来的证明几乎是不可能的。不过，检查应用程序是否可扩展并不难。您只需要为该应用编写一些性能测试，并查看它可以处理多少个客户端。编写测试绝对可以使您的应用程序更具前瞻性，因为您可以在对应用程序进行更多更改后评估应用程序的行为。

wrt框架，我不会太担心性能/可伸缩性。这是您可以轻松检查并最有可能解决的问题。更大的问题是安全性。 Web框架通常可以帮助您编写适当的身份验证代码，Cookie，CSRF保护等。尤其是由于您经验不足，因此请专注于该领域。

#7 楼

我开始写有关学习框架的评论，但最终变成了看起来更像答案的东西，所以就在这里。

不知道任何框架似乎都是一个问题。基本上，在任何webdev作业中，您都需要使用某些框架。在知道一个框架后没什么大不了的，但是学习第一个框架可能要花一些时间-这就是为什么雇主可能会在意的。避免使用框架可能表示此处未发明综合症，这是不切实际的方法。

了解您的第一个框架的主要要点是学习通用语言，也许只是尝试学习在同行中流行的东西。您可以尝试修改一些用框架编写的简单项目。在您不了解的框架中从头开始一个项目是一种非常无效的学习方法。

现在，您的实际问题是关于特定项目并将其移植到框架中。为此，答案似乎是：取决于情况，我们无法真正告诉您。但是，将内容移植到您不知道的框架几乎肯定是个坏主意，因为您甚至不知道它是否有意义。因此，似乎您应该保持现状，并且一旦知道并喜欢某种框架，就在某个时候重新考虑这个决定。其他答案包含有关做出此类决定时应寻找的内容的要点。

#8 楼

本文在2.5年前的Hacker News上引起了很多关注：编写易于删除而不易于扩展的代码。这种观点可能会或可能不会帮助您处理当前的代码库，但将来，它可能有助于防止由于完美主义/过度设计而产生的挫败感。


代码行”作为“行数”，那么当我们删除代码行时，我们降低了维护成本。除了构建可重复使用的软件外，我们还应尝试构建一次性软件。

我不需要告诉您删除代码比编写代码更有趣。


（重点是我的）

关于Hacker News的文章主题可能也值得一读。

#9 楼

至于使它成为未来的证明并应用规模和框架原则，这是一个艰巨的任务，我自己可能不必担心，但是如果您必须：

保持代码清洁，请遵循SOLID，DRY原则> google。

尽快应用负载平衡器。

至少支撑两个Web服务器，在代码。

最后但并非最不重要的一点是，与LAMP相比，用于处理一百万个用户的堆栈更好，但是我确定它是完全可行的。

案例和重点，请参见：
https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade
该点有效，但10gb作为测试对象是微不足道的。