写代码有将来吗_如何编写将来会喜欢的代码-CSDN博客

写代码有将来吗

Uncle Ben once told Peter Parker, “With great power comes great responsibility”. This quote applies to fellow programmers who are involved in building projects. Being in the industry for over 5 years has made me reflect on my experiences so far, and it is time I give back to the community.

本叔叔曾经对彼得·帕克(Peter Parker)说： “强大的力量伴随着巨大的责任” 。此报价适用于参与构建项目的其他程序员。从事该行业超过5年使我对自己的经验进行了反思，现在该是我回馈社区的时候了。

起点 (The Beginning)

I started my career in a multi-national corporation, but I soon realized I wanted to work on more challenging roles with bigger responsibilities. And so, after a year, I joined a startup.

我的职业生涯始于一家跨国公司，但不久我意识到我想从事更具挑战性，职责更大的职位。因此，一年后，我加入了一家初创公司。

It was only a five-member dev team. It changed my outlook on development. I luckily found a great mentor and awesome teammates who helped me grow. But then again, we were a fast-paced company. To ensure delivery on time we often compromised on our code quality. We often assumed we would fix it in the end. So as we built the ship, we left loopholes. This led to tech debt, which was not a bad thing.

当时只有五个人的开发团队。它改变了我的发展观。幸运的是，我找到了一位出色的导师和出色的队友来帮助我成长。但是话又说回来，我们是一家快节奏的公司。为了确保准时交货，我们经常在代码质量上做出妥协。我们常常以为最终会修复它。因此，当我们建造船时，我们留下了漏洞。这导致了技术债务，这不是一件坏事。

绝不妥协代码质量 (Never compromise on code quality)

After some time, we gradually realized, that we won’t be able to scale anymore. So we decided to rewrite the whole codebase, which in turn took more time. But this eventually led to a good codebase, which was scalable and fun to work upon. I still remember we used to have a ‘shame folder’ in case any developer decided to write code they knew would create additional work later on.

一段时间后，我们逐渐意识到，我们将无法再进行扩展。因此，我们决定重写整个代码库，这又花费了更多时间。但这最终导致了一个良好的代码库，该代码库具有可伸缩性且使用起来很有趣。我仍然记得我们曾经有一个“ 耻辱文件夹 ” 如果任何开发人员决定编写自己知道的代码，以后都会创建其他工作。

This way we made ourselves accountable to maintain quality. But the lesson I learned was this:

这样，我们使自己对保持质量负责。但是我学到的教训是：

Even if it takes a little more time to complete, we should take that time and write quality code for the future. Because of that extra effort we put in, we saved a lot of time and money.

即使完成需要花费更多时间，我们也应该花时间为将来编写高质量的代码。 由于我们付出了额外的努力，因此节省了大量时间和金钱。

We solved the architectural problem, but then came the fun part: performance. When we built our project, we used a lot of libraries for speedy development. We felt our project had put on some weight. It needed a lot of exercises. To shed those extra pounds, we did some analysis and realized that we had a lot of unnecessary libraries. We could have built these libraries ourselves. And so we scraped those libraries and built our own. Great!! Our page was faster due to a smaller bundle size.

我们解决了架构问题，但是有趣的部分出现了： 性能。 在构建项目时，我们使用了许多库来加快开发速度。我们觉得我们的项目增加了一些负担。它需要大量的练习。为了减轻这些负担，我们进行了一些分析，并意识到我们有很多不必要的库。我们可以自己构建这些库。因此，我们刮掉了那些库并建立了自己的库。大！！由于页面尺寸较小，我们的页面速度更快。

But the hunger for performance was not over. When you have built a project from scratch, that feeling of being a spartan slowly consumes you. The story can’t be over yet. We could be faster. Then it dawned upon us, we were still using libraries. What if we didn’t use any? The thrill of writing our own consumed us, so we did it. We built a project successfully with almost no libraries.

但是对性能的渴望并没有结束。当您从头开始构建项目时，成为斯巴达人的感觉会慢慢消耗您。故事还没有结束。我们可以更快。然后它突然降临，我们仍在使用库。如果我们不使用该怎么办？写我们自己的快感消耗了我们，所以我们做到了。我们成功建立了几乎没有库的项目。

始终记录和编写代码注释 (Always document and write code comments)

Then came a twist to our story: the startup was eventually acquired. I was moved to a new team. The new members were more acquainted with libraries that exist in the market. Suddenly our codebase was alien to them. We indeed wrote our libraries, but we didn’t have enough time to document them. It created a huge gap. I learned the important lesson of documentation and code comments.

然后，我们的故事发生了变化：这家初创公司最终被收购了。我被调到了一个新团队。新成员更熟悉市场上存在的图书馆。突然，我们的代码库对他们来说是陌生的。我们确实编写了库，但是没有足够的时间来记录它们。这造成了巨大的差距。我学到了重要的文档和代码注释课程。

I realised code is not just about yourself. As an author, it is your duty to write for the masses.

我意识到代码不仅仅关乎自己。 作为作家，为大众写作是您的责任。

So the moral is, it is not wrong to write your own libraries. But if you do, then documentation and code comments are a must. Anyone should be easily able to comprehend your library just by reading your docs. I can’t emphasize enough, don’t write for yourself! As a code reviewer and maintainer, it is your responsibility to ensure this.

因此，道理是，编写自己的库是没有错的。但是，如果您这样做了，那么文档和代码注释是必须的。只要阅读您的文档，任何人都应该能够轻松理解您的图书馆。我不能强调足够，不要为自己写！作为代码审查者和维护者，您有责任确保这一点。

除非您确保轮子可维护，否则不要重新发明轮子 (Don’t reinvent the wheel, unless you ensure it is maintainable)

As time passed by, I realized there was no point in reinventing the whole wheel. Unless we have a lot of time to develop and document the same so that it can be understood by all. If there is a library that exists and solves your problem, then it is a great idea to contribute to that specific project! There is a catch, and I would like to quote from Phil Walton’s blog:

随着时间的流逝，我意识到重新发明整个车轮毫无意义。除非我们有很多时间来开发和记录相同的内容，以便所有人都能理解。如果存在一个可以解决您问题的库，那么为该特定项目做出贡献是一个好主意！有一个问题，我想引用Phil Walton的博客：

Reinventing the wheel is bad for business, but it’s great for learning. You may be tempted to grab that typeahead widget or event delegation library from npm, but imagine how much more you’d learn by trying to build those things yourself.

重塑方向盘对企业不利，但对学习则有益。 您可能会很想从npm中抢走那个预先输入的窗口小部件或事件委托库，但是想像一下，尝试自己构建这些东西会学到多少。

So make your choice wisely ^_-

因此，明智地做出选择^ _-

始终测试您的代码库 (Always test your codebase)

I can’t emphasize enough how important this is. Thanks to libraries like Jest and React testing library, and many others, testing code has never been easier. Often when the codebase becomes large, even a single line of change can cause the application to break. If our testing is automated, we can be confident about the changes we push.

我不能足够强调这是多么重要。得益于Jest和React测试库等库，测试代码从未如此简单。通常，当代码库变大时，即使单行更改也可能导致应用程序崩溃。如果我们的测试是自动化的，我们可以对我们推动的变化充满信心。

保持学习 (Keep learning)

I wanted my frontend development to be fast and performant. I finally decided to learn React, mostly because of the background I came from. I found it to be unopinionated, and writing it was very close to writing plain JavaScript. It changed my life for the better.

我希望前端开发能够快速且高效。我最终决定学习React，主要是因为我的背景。我发现它是不受限制的，并且编写它非常接近编写普通JavaScript。它使我的生活变得更好。

Libraries like React, Vue, Angular and various others (especially Redux) don’t just tell you how to build a fast UI. They also open doors to other concepts like functional programming, immutability, and many others, which actually helps you become better at your craft. Learning React and Redux enhanced what I already knew.

React，Vue，Angular和其他各种库(尤其是Redux)之类的库不仅告诉您如何构建快速UI。它们还打开了其他概念的大门，例如函数式编程，不变性以及许多其他概念，实际上帮助您提高了自己的Craft.io水平。学习React和Redux增强了我已经知道的知识。

结论 (Conclusion)

As I gained experience, I eventually joined another startup, where I was tasked to build products from scratch and eventually lay the foundation. But this time I was armed with all my experiences and mistakes. I am happy to say, I am proud of what I have built so far and I am sure I have a long way to go. The pursuit for perfection is a never-ending path, but we can always strive to walk the right path.

随着经验的积累，我最终加入了另一家初创公司，在那里我负责从头开始构建产品并最终奠定了基础。但是这次我武装了我所有的经验和错误。我很高兴地说，我为迄今为止的建设感到自豪，并且我相信我还有很长的路要走。追求完美是一条永无止境的道路，但我们始终可以努力走正确的道路。

All the experiences I have mentioned are not meant to be the word of law. They are very specific to my journey in the industry. But I hope this will help you become a better developer, and I am always thankful to the community, who has helped me grow.

我提到的所有经验都并非要成为法律。它们非常适合我的行业旅程。但是我希望这可以帮助您成为更好的开发人员，并且我一直感谢帮助我成长的社区。

Follow me on twitter to get more updates regarding new articles and to stay updated in the latest frontend developments. Also, share this article on twitter to help others know about it. Sharing is caring ^_^.

在推特上关注我，以获取有关新文章的更多更新，并随时了解最新的前端开发。 另外，在Twitter上分享这篇文章，以帮助其他人了解它。 分享是关怀^ _ ^。