梁祝二胡独奏_发展独奏

How to write a production-grade project as a one-man team (or a small team)

如何以一个人的团队(或一个小团队)编写生产级项目

Developing a software project solo is no easy task. With no one to unstuck you, review your code, or provide guidance, you are completely on your own, venturing into the unknown.

d eveloping一个软件项目的独奏是不容易的任务。 没有人让您烦恼，查看代码或提供指导，您完全可以独自一人，进入未知领域。

Mostly, inexperienced developers will either:

通常，没有经验的开发人员会：

1. Take this as an opportunity to disregard code quality standards and pay no attention whatsoever to code convention.

   以此为契机，无视代码质量标准，不关心代码约定。

2. Do the complete opposite and over-engineer everything way beyond what is needed.

   进行完全相反的工作和过度设计，超出所需范围。

However, as I will try to demonstrate in this article, both approaches are equally damaging. So without further ado, let’s go through a few points.

但是，正如我将在本文中尝试证明的那样，两种方法均具有相同的破坏性。 因此，事不宜迟，让我们讲几点。

Note: If you are looking for practical advice, skip ahead to the Specific Recommendations section.

注意：如果您正在寻找实用建议，请跳至“特殊建议”部分。

认识你的敌人 (Know your enemies)

There are two enemies you need to avoid and I do base lots of my opinions on that. In fact, you can consider this a TL;DR of this article.

您需要避免两个敌人，对此我的确有很多看法。 实际上，您可以将其视为本文的TL; DR。

1. Willpower: Make better easierThis is your enemy as a human being, generally speaking. We place a lot of trust in our willpower, a very unstable and limited resource. You will write good code when it’s easier than writing bad code just like you’d go to the gym more often if there’s one in the same building.

   意志力：让事情变得更轻松一般来说，这是您作为人类的敌人。 我们非常信任我们的意志力，这是一种非常不稳定和有限的资源。 与编写不良代码相比，编写优质代码要容易得多，就像在同一座建筑物中有很多人去健身房一样。

2. Verbosity: Type less, achieve moreAn unbelievable amount of time can be wasted copying boilerplate code around and forgetting to add that little property here or change that string there only to find out one hour later that it’s causing the weird bug you have been struggling with. As a solo developer, this problem can be frustrating at times as so much verbosity definitely impacts your valuable limited productivity.

   细节：打字少，成就多浪费大量时间浪费大量的时间来复制样板代码，而忘记在此处添加该小属性或在该位置更改该字符串，只是一小时后才发现它正在导致您一直在困扰的怪异错误。 作为一个单独的开发人员，这个问题有时会令人沮丧，因为太多的冗长性肯定会影响您宝贵的有限生产力。

您必须感到“舒适” (You must feel “comfortable”)

Making sure you are comfortable with the environment is essential. Having a personal template that you use to kickstart your projects helps a ton, however, this might not be applicable for new domains of development you are tackling. So, you need to master the art of getting yourself comfortable.

确保您对环境感到舒适是必不可少的。 使用个人模板来启动项目会有所帮助，但是，这可能不适用于您要解决的新开发领域。 因此，您需要掌握使自己感到舒适的艺术。

The first thing you usually choose, if you don’t have a favorite already, is the IDE. It’s essential to have proper IDE support. Here are the most useful IDE features that are quite important for all developers and an absolute must when developing solo:

如果您还没有收藏夹，通常选择的第一件事就是IDE。 拥有适当的IDE支持至关重要。 以下是最有用的IDE功能，这些功能对所有开发人员都非常重要，并且是单独开发时的绝对必需：

1. IntelliSense and spell-checking.

   IntelliSense和拼写检查。

2. Error detection and quick-fix suggestions

   错误检测和快速修复建议

3. Automatic code linting

   自动代码整理

4. Auto-generating and refactoring code snippets

   自动生成和重构代码段

5. Step-by-step debugger (that can even step into libraries)

   分步调试器(甚至可以逐步进入库)

6. Quick shortcuts to easily navigate and modify your code (quick find, renaming, documenting, etc)

   快速快捷方式可轻松导航和修改您的代码(快速查找，重命名，记录等)

Surely you can pull off a production-ready codebase in vim! Albeit within the next 10 years or so.

当然，您可以在vim中发布可用于生产的代码库！ 尽管在未来10年左右。

自动化，自动化，自动化 (Automation, automation, automation)

If it can be automated within the time it takes to do it over the course of 3 months, automate it.

如果可以在3个月的时间内将其自动化，请对其进行自动化。

Let me clarify that last sentence a bit more with an example. If you have to test a specific critical use case every time you deploy and it takes 5 minutes to do so and you deploy 10 times per month, then that costs 50 minutes per month (assuming you don’t skip it or forget it every now and then). Now this means that the cost over 3 months is 150 minutes and thus, it’s completely acceptable to spend up to 150 minutes of your time writing an automated E2E test for this particular flow even if you have other pressing matters placed on-hold.

让我用一个例子来澄清最后一句话。 如果每次部署都必须测试特定的关键用例，并且需要花5分钟时间，而每月要部署10次，那么每月就要花费50分钟(假设您现在不跳过或忘记它)接着)。 现在，这意味着3个月的成本为150分钟，因此，即使您有其他紧迫的问题待解决，花费多达150分钟的时间为此特定流程编写自动E2E测试也是完全可以接受的。

Out of all professionals out there, you as a developer should embrace automation to the max!

在所有专业人士中，作为开发人员，您应该最大程度地拥抱自动化！

One more good reason to write automated tests is that with no one reviewing your code, there will be more room for error. And since no one in their right mind wants to manually test every feature of their application every time they release a new version, you need a lot of automated testing. The rule of the thumb is “if it breaks the flow of user experience, then write a test for it”. Don’t go as far as to write tests for aesthetic features unless you really have the time for it. It’s particularly useful though to have snapshots of your UI as part of your unit testing to watch for UI parts going MIA (e.g. StoryShots).

编写自动化测试的另一个好理由是，没有人检查您的代码，就会有更多的出错空间。 而且由于没有人在他们每次发布新版本时都想手动测试其应用程序的每个功能，因此您需要进行大量的自动化测试。 经验法则是“如果它破坏了用户体验，请为此进行测试” 。 除非您真的有时间，否则不要去为美学特征编写测试。 尽管在单元测试中拥有UI快照作为监视MIA的UI部件(例如StoryShots )的一部分，但它特别有用。

You must also have an automated build, release, and deployment pipeline setup. You simply don’t have the resources to do all of these things yourself every single release. This can be a template that you reuse for different projects as this type of setup takes quite a long time to get right but is usually very generic and reusable.

您还必须具有自动构建，发布和部署管道设置。 您根本没有资源可以在每个发行版中自行完成所有这些事情。 这可能是您可以在不同项目中重复使用的模板，因为这种类型的设置需要花费很长时间才能正确完成，但通常非常通用且可重用。

In addition to proper testing, you should have some sort of staging environment as identical to the production environment as possible. Releasing into production directly with no beta testers standing by and with only a handful of high-value users can be disastrous. If you set up your CI/CD pipeline properly, it’s very easy to deploy to staging on feature branches and catch those production-only bugs before they slip (TLS cert issues, misconfiguration, CORS errors, etc).

除了适当的测试之外，您还应该具有某种与生产环境相同的过渡环境。 如果没有beta测试人员，只有几个高价值用户直接进入生产，这将是灾难性的。 如果正确设置了CI / CD管道，则很容易将其部署到功能分支上，并在这些仅生产性错误(TLS证书问题，配置错误，CORS错误等)消失之前捕获它们。

注意安全 (Pay attention to security)

You will be committing the cardinal sin of debugging using production APIs/Databases quite often. Even if you say NEVER right now, you will, it’s tempting and often practical. So, without any team-shaming involved it’ll happen, eventually. Stepping through that stubborn bug that you can’t reproduce in dev line by line is just so satisfying, and alluring.

您将经常犯使用生产API /数据库进行调试的主要罪过。 即使您现在从不说，您也会，这很诱人，而且通常很实用。 因此，最终不会发生任何团队欺骗。 逐步解决您无法逐行在开发人员中重现的顽固错误，这是如此令人满足且引人入胜。

So make sure you have a way of storing passwords locally instead of committing them to the repo. No one is there to see them, but purging repositories later and getting commit hashes and version tags messed up isn’t fun. Additionally, what if your git provider is hacked one day? What if you obliviously give access to someone who isn’t supposed to see them? Keep passwords on your machine in an environment or secrets file or even in your local IDE variables.

因此，请确保您有一种在本地存储密码的方法，而不是将密码提交到存储库。 没有人在那里看到它们，但是稍后清除存储库并弄乱提交哈希和版本标签并不是一件好事。 此外，如果您的git提供者有一天被黑了怎么办？ 如果您明显地允许不应该看到他们的人访问该怎么办？ 将密码保存在计算机上的环境或机密文件中，甚至保存在本地IDE变量中。

勤劳的工程师 (Over-engineer, with diligence)

Considering that over-engineering is always going to be a threat to a solo developer with no one judging and lots of precious time to potentially save (the root of any over-engineering prospect), let’s explore how we can mitigate the effects. As a solo developer, there are two types of over-engineering.

考虑到过度设计总是对没有人判断的潜在开发人员构成威胁，并且没有很多宝贵的时间可以节省(任何过度设计前景的根源)，让我们探讨如何减轻这种影响。 作为一个单独的开发人员，有两种类型的过度设计。

The Bad: Anything that adds verbosity.

坏处：任何增加冗长的内容。

The Good: Anything that reduces verbosity.

优点：任何减少冗长。

The further you over-engineer something, the more modular it becomes and the less logic you have within similar modules. In a good over-engineering example, the resulting modular code should be so small that you can type it from memory when creating a new module. You should also make sure that a simple IDE lookup can often find the exact line of code you want to change or at least one that leads to it (few duplicates and no vague flows the IDE can’t follow).

您对某些事物进行过度设计的程度越高，它就变得越模块化，并且在类似模块中的逻辑也就越少。 在一个很好的过度工程示例中，生成的模块化代码应该很小，以至于在创建新模块时可以从内存中键入它。 您还应该确保简单的IDE查找通常可以找到要更改的确切代码行，或者至少找到导致更改的代码行(很少重复，并且IDE不能遵循任何模糊流程)。

A very good example that I can recall now off the top of my head is Redux Saga vs Vuex Proxy. Both are very generalized libraries. But if we compare using sagas with all these verbose definitions and multiple layers vs using a proxy that generates mutations on demand when accessing the state… I guess we all know what’s better for a solo developer or even a rather small team.

我现在想起来的一个很好的例子是Redux Saga vs Vuex Proxy 。 两者都是非常通用的库。 但是，如果我们比较使用具有所有这些详细定义和多层结构的sagas与使用访问状态时按需生成突变的代理进行比较……我想我们都知道对于一个单独的开发人员甚至一个很小的团队来说，哪个更好。

使事情井井有条 (Keep things organized)

Whether it’s the code itself or different services your project is comprised of, keep things modular and standardized. This keeps your mind clear and your eyes quickly get used to the code. You’ll be surprised at the things you can now do on auto-pilot. So good code style and the use of containerization (e.g. Docker) are your best friends.

无论是代码本身还是项目所包含的其他服务，都应使模块保持模块化和标准化。 这样可以使您头脑清醒，并且很快就能适应代码。 您会对自动驾驶现在可以执行的操作感到惊讶。 因此，良好的代码风格和使用容器化(例如Docker)是您最好的朋友。

不要 (The Donts)

Let’s go a bit more in-depth with what you should avoid as a solo developer or a small team:

让我们更深入地探讨作为一个独立开发人员或一个小型团队应避免的情况：

1. Stay away from high performance but bulky languages and/or frameworks. You want your code to be minimal in size as you can’t afford to type/copy tens of lines of boilerplate code to achieve trivial functionality. You also need to be able to easily debug and step into any line of code. If enough users are using this service to warrant a performance upgrade of this type, chances are there will be a rather big team working on it.

   远离高性能但笨拙的语言和/或框架。 您希望代码的大小最小，因为您无力键入/复制数十行样板代码来实现琐碎的功能。 您还需要能够轻松调试并进入任何代码行。 如果有足够的用户使用此服务来保证这种类型的性能升级，则很有可能会有相当大的团队在为此服务。

2. Do not use languages that are not strongly- typed. You need to be able to see errors in development as often as possible and the advanced IntelliSense is a big plus you don’t want to miss on. The only exception to this is when you are working in a very specific domain that benefits from a specific language like ML and Python. But even then, you could still benefit from static type checking.

   请勿使用非强类型的语言。 您需要能够经常看到开发中的错误，而高级IntelliSense则是您不容错过的一大优点。 唯一的例外是，当您在非常特定的领域中工作时，可以从ML和Python等特定语言中受益。 但是即使那样，您仍然可以从静态类型检查中受益。

3. Do not go overboard over-engineering. One of the best ways I found to achieve that is to get all the over-engineering out of your system while setting up the project and building the most basic non-business requirements of it.

   不要过度设计。 我发现实现此目标的最佳方法之一是，在设置项目并建立最基本的非业务需求的同时，充分利用系统的过度设计。

4. Don’t trust your memory. Whenever you use a bash line or a tiny script to do something, save it and document it. You can make use of your GitHub wiki for instance or just use the README file. It’s also nice to have a “scripts” directory on your project and to make use of the npm/yarn scripts on node projects.

   不要相信你的记忆。 每当您使用bash行或微小的脚本执行某项操作时，请保存并记录下来。 例如，您可以使用GitHub Wiki，也可以仅使用README文件。 在项目上有一个“ scripts”目录，并在节点项目上使用npm / yarn脚本，也很不错。

5. Don’t use willpower too much, make better easier

   不要过多地使用意志力，让事情变得更好

These, for example, are my trusty scripts on node projects which serve as a demonstration of point 4 and 5:

例如，这些是我在节点项目上值得信赖的脚本，这些脚本演示了第4点和第5点：

"git:commit": "git status && git add -N . && git add -p && sgc",
"git:stash": "git stash --all",
"git:nah": "git checkout . && git clean -df",
"git:amend": "git commit --amend --no-edit",

具体建议 (Specific Recommendations)

数据管道/机器学习(Data Pipelines / Machine Learning)

Dockerize your projects and don’t rely too much on your personal machine being set up correctly. Even if you need to make use of your personal machine (e.g. local GPU), you can achieve that with a local Kubernetes cluster.

Dockerize您的项目，不要过多地依赖正确设置您的个人计算机。 即使您需要使用个人计算机(例如本地GPU)，也可以使用本地Kubernetes集群来实现。

后端 (Backend)

So as mentioned above you need to stick to strongly-typed languages and avoid verbosity. That means Python or Go is probably not your best option. Something like C# with Entity Framework personally appeals to me because of the ridiculously good IDE support whether it’s Rider or VS and the crisp clean ultra-readable architecture of the framework. If you can do most of what you want with intuition and a bit of IntelliSense without having to google it or read the docs, that’s the biggest win for a language/framework combination. Java is ok if you are a masochist (not a fan of java myself).

因此，如上所述，您需要坚持使用强类型语言并避免冗长。 这意味着Python或Go可能不是您的最佳选择。 带有Entity Framework的C＃之类的东西对我个人而言颇具吸​​引力，因为无论是Rider还是VS，以及该框架清晰清晰的超可读体系结构，其出色的IDE支持都可笑。 如果您可以用直觉和一点点IntelliSense来完成大部分所需的工作，而无需谷歌搜索或阅读文档，那么这是语言/框架组合的最大赢家。 如果您是受虐狂(我自己不是Java的狂热者)，则Java可以。

前端(Web应用程序) (Frontend (Web Apps))

I like both Vue and React when working solo as long as the project is TypeScript based. However, if it’s a big UI with lots of dynamic API integration and you are solo then definitely go for Vue. If you are using class components and Vuex module components (with the vuex-class-component package) fetching and saving data using your API becomes super easy. Having 2-way binding in any component becomes as easy as defining a class property! No need to worry about mutations, getters, setters, or any boilerplate code. That and hydrate/save/clear actions on the store module (with a hash and expiry timestamp for caching if you are classy) and you are good to go!

只要项目是基于TypeScript的，我就喜欢Vue和React。 但是，如果这是一个包含大量动态API集成的大型UI，并且您是个独舞者，那么绝对可以选择Vue。 如果您使用类组件和Vuex模块组件(带有vuex-class-component软件包)，则使用API​​来获取和保存数据变得非常容易。 在任何组件中进行2向绑定变得像定义class属性一样容易！ 无需担心突变，getter，setter或任何样板代码。 并在存储模块上进行水合/保存/清除操作(如果您是一流的，则具有用于缓存的哈希和到期时间戳记)，您可以使用！

建筑 (Architecture)

It might seem counter-intuitive at first but micro-services, although the hallmark of develeopment in multiple teams, are your friend.

乍一看似乎有点违反直觉，但微服务虽然是多个团队中发展的标志，但却是您的朋友。

• You are the sole owner of all the services and have absolute control over what they do and how they do it, that already avoids alot of the trouble that comes with microservices.

  您是所有服务的唯一所有者，对它们的工作方式和执行方式具有绝对的控制权，这已经避免了微服务带来的许多麻烦。

• You can use the same hosted instance of generic services with multiple apps (e.g. mail or push notifications). Whether this is a personal project or a contract you are doing, this is useful.

  您可以将通用服务的相同托管实例与多个应用程序一起使用(例如，邮件或推送通知)。 无论这是个人项目还是您正在做的合同，这都很有用。

• If you make a mistake somewhere and it slips past all measures and gets deployed (there’s no operations team or QA to catch it after all), it doesn’t affect the whole application; only that service will go down or have degraded performance.

  如果您在某个地方犯了一个错误，并且它超出了所有措施并得到部署(毕竟没有操作团队或QA来抓住它)，那么它不会影响整个应用程序； 只有该服务将崩溃或性能下降。

• You can start new modules of your app those serve a different purpose without threatening the stability of the existing services (what if you want a chat app to offer voice/video calls?).

  您可以启动应用程序中用于不同目的的新模块，而又不会威胁到现有服务的稳定性(如果您希望聊天应用程序提供语音/视频通话该怎么办？)。

In addition to that, make sure all your services are Docker-ready. Not only does this mean you can easily deploy them anywhere and have a nice production environment replica in staging and even development, but you can also leverage Kubernetes or AWS ECS and scale your app with a day’s work whenever needed!

除此之外，请确保所有服务都支持Docker。 这不仅意味着您可以轻松地将它们部署到任何地方，并在登台甚至开发中拥有一个不错的生产环境副本，而且还可以利用Kubernetes或AWS ECS并在需要时通过一天的工作来扩展您的应用程序！

结论 (Conclusion)

In the end, remember that this article is entirely based on the premise that you are working alone or with a small team and within a limited time window. Most of the software conventions we have today are built around development in big enterprises with huge teams so obviously, don’t expect solo rules to be a 100% match to the conventional wisdom.

最后，请记住，本文完全基于您是在有限的时间范围内独自工作还是与小团队一起工作的前提。 我们今天拥有的大多数软件约定都是围绕具有大型团队的大型企业的开发而建立的，因此，显然，不要指望单独规则与传统观点相匹配100％。

And again, the TL;DR of this article is “avoid verbosity and make better code easier without draining your willpower”.

同样，本文的TL; DR是“避免冗长，使更好的代码更容易，而又不会消耗您的意志力”。