树莓派 绿灯不亮 烧毁_我烧毁了不一致的代码库

树莓派 绿灯不亮 烧毁

我精疲力尽，辞掉工作，无法忍受跳入另一个非我自己的前端代码库的想法。

免责声明：本文不是关于X框架和Y框架，而是关于人们以使开发人员体验受挫的方式构建不可持续的Web应用程序。

我们都知道“每周都有一个新框架”的模因。 虽然它是一个很好的肋，但它碰到了开发Web应用程序时非常沮丧且不必要的事实。 人们一直在不断创新以做同样的事情。 它增加了复杂性，使应用程序膨胀，使新开发人员的登机成本高昂且乏味。 屁股上的皇家痛苦。

下面总结了前端中存在问题的各个方面，这些方面使我无所适从。

Frustration number 1 - Projects with inconsistency

是否曾经检查过代码库并想过-“这到底是什么”？

跨文件夹结构，命名约定或设计模式的不一致是开发人员最大的敌人。 它使逻辑难以遵循，难以支撑普遍的钻探，并且嵌套结构使发际线后退。 我从事的一个项目具有混合前缀的组件，例如“ Driving”，“ Drivers”和“ Driver”，并带有更多组合，例如“ Driverlicense”和“ DriversLicense”。 像这样的愚蠢的事情浪费了时间和心理健康。

如果经常听到“我听不懂”的声音，则意味着您需要做得更好，以使代码更具可读性或使文档更好。

不一致给新手开发人员带来了一个主要问题-他们必须解密正在发生的事情。 人们到处散布着文件的结构，redux逻辑和状态管理，自定义实用程序功能，为什么要建立自己的表单库……等等……为什么要建立自己的自定义表单库。 它在不需要时引入了特定于域的逻辑。

一致性的问题扩展到JavaScript / React允许开发人员完成相同任务的多种方式。 当您有多个开发人员在产品的使用寿命中添加React液时，这种自由就会变得无聊。 最终您会陷入酸性状态，使鼻子卷曲。 它鼓励新手努力学习深厚的领域知识，这些新手都在努力了解实现工作所需的复杂性和小技巧。

您应该始终以使下一位开发人员的生活更轻松为目标。

解决方案： 鸭子 （一种有组织的前端方式），每三个月进行一次审核，以识别和解决建筑技术方面的债务。

Frustration number 2 - I'll just roll my own

当您确实不需要时，开发人员可以在事情上添加自己的“ redux版本”。 在一个实例中，开发人员厌倦了必须重写样板以使用redux状态进行异步调用，因此决定将其包装在一个更高阶的组件中以使其变得更容易。

理论上的好主意，而不是实践上的好主意。

最终发生的事情是，他们在多个项目中实施了该项目，并随其进行了开发和改进。 这导致了具有非版本化，不断变化的实现的多个代码库。 它使许多试图理解它的工作原理的人迷惑不解，在他们为实现而苦苦挣扎的过程中，放慢了开发时间。

解决方案：在编写实用程序功能以替换标准化的工作方式之前，请三思而后行。 当可能有一个维护良好的库为您这样做时，真的值得吗？ 明智地构建。

Frustration 3 - Not using standard libraries.

开发人员决定不使用redux表单或本机表单输入，而是决定创建自己的与redux集成，进行异步调用并具有自己的验证实现的输入。 这是一场噩梦。 整个输入过程和多个存储库都使用了表单输入。 它是如此之深，以至于每当出现一个新的bug（经常发生）并且我们需要对其进行更改（我们做过）时，它将影响多个存储库。 从字面上看，该组件是复制粘贴在同一应用程序的存储库之间的，导致需要多次实施多个未跟踪的版本和错误修复（如果人们不愿保持一致）。 对于许多版本，会有许多不同的行为-这意味着对一种实现有效的方法，与其他实现不同。 正如我之前提到的-噩梦。

解决方案：表单并不是什么新鲜事物。 由于拥有大量经过良好开发和测试的第三方库，因此如今大多数Web应用程序绝对不需要卷入自己的表单。

Frustration 4 - People who just aren't very nice

招聘过程中极其重要的部分是文化契合度。 您会了解彼此的价值观，工作方式，并可以根据自己的意愿做出是否愿意合作的明智决定。 当您分配给客户时，情况就完全不同了，这与文化不符。 他们是客户，他们在付款，您与他们合作。 这种缺乏控制的情况，尤其是当客户不具有相同的核心价值时，会造成极大的挫败感。 对我自己而言，缺乏自主权和陷入与我所雇用的价值观截然不同的团队中，这是最终导致我精疲力尽的主要原因。

解决方案：在内部产品团队中工作-您将与通过相同文化面试的人一起工作。

What learnings can I pass on from all of this?

这可能会让人感到痛苦，让它从胸中散发出来，尽管这在写作时可以治愈，但我希望它能提供一些有价值的见解和总结。 除了笑话，上面提到的问题严重损害了我的心理健康。 我希望这将向您强调这些困难中的任何一个，为某些人提供解决方法，并为其他人发出危险信号。

它们似乎有些残酷，但是当您每天都在进行此类项目时-就像试图成为一名作家，笔尖在铅笔，笔和烟之间随意交替。

>对于低劣的代码，寿命太短，并且缺乏光泽的产品。 如果你们俩都有，那就搬团队或搬公司。
>调查您感兴趣的编程和应用程序的类型。 找出您喜欢使用哪种产品，然后找出您真正喜欢编程的哪些方面。 知道如何编程会打开很多门，打开那么几扇门，除非您尝试尝试，否则您将永远不知道。

>一致性有时比“正确地做事”更有价值。 如果您遇到一些可怕的模式，只是希望它们至少是一致的可怕模式。

>如果要在代理商处面试，请询问开发人员在团队之间转移的频率。 如果这种情况经常发生，我会认为这是一个潜在的危险信号。

我之所以非常不喜欢我的角色的一个关键方面是，它主要是错误修复，功能开发很少。 建造者不会成为修理其他建造者房屋的建造者。 虽然拥有技能非常有价值，但它并不能使您感到高兴。

当我意识到自己精疲力尽时，我：

试图解决内部问题-这些问题尚未解决。
请求移动团队-这是不可能的。
在其他公司接受采访-我收到了一些工作机会，但最终决定我已经拥有足够的前端，并决定从React退后一步。

我没有通过退出来解决自己的倦怠，尽管将自己从恶劣的环境中移除是其中重要的一部分。 我休假了一个月，以反思自己的职业，心理健康以及最终使我高兴的事情。 建立生活形式并修复其他人的错误不利于此。 我仍然喜欢编程的力量，它提供的生活方式以及它所带来的技术挑战。 我将继续编程，但要在一个更加“稳定”的生态系统中进行。

So what's next for me?

明确地说-虽然整个情况确实糟透了，但我很高兴它发生了。 它促使我仔细考虑自己目前的职业道路以及我真正想要增值的东西。 我的精神健康很好，我很高兴，为下一次冒险感到兴奋。

目前，我正在使用Cinema4D学习Webflow和运动设计。 最后，为我的YouTube频道创建一致的内容（3.8k！），并尝试进行一些IOS开发。 如果这是一个糟糕的主意-请在下面告诉我！

如果您开始感到倦怠，我强烈建议Smashing Magazine推荐这篇文章，该文章涉及与倦怠和JavaScript疲劳有关的一些不同（但非常相关）问题。 另一本出色的读物是“ 2016年学习JavaScript的感受”，这是对制作Web应用程序的漫长过程的深入，相关的探索。
‍
Adieu Weback，那么长的Babel，您将不会错过。

翻译自: https://hackernoon.com/front-end-development-broke-me-my-burnout-story-y56a3871

树莓派 绿灯不亮 烧毁