经验教训 软件开发_我作为开发人员10多年的经验教训

经验教训 软件开发

12个月。 (12 months.)

That’s the time we wasted while rewriting our software from scratch.

那是我们从头重写软件时浪费的时间。

Twelve long months in the software market.

在软件市场上呆了十二个月。

Without innovation.

没有创新。

Without moving forward.

没有前进。

Really, I cannot stop asking this question to myself.

真的，我不能停止对自己问这个问题。

What could we achieve in this fast-moving world in 12 months?

在这个瞬息万变的世界中，我们将在12个月内取得什么成就？

“Tuesday, January 20, 2015, 5:10 PM, AntiMalware product is finally going its first public beta.”

“ 2015年1月20日，星期二，下午5：10，AntiMalware产品终于将首次公开测试。”

After hours without sleeping, the first release note that would give a start to our new journey was published on the website.

经过数小时的不眠之夜，该网站上发布了第一个发行说明，它可以开始我们的新旅程。

I was working for one of the small cybersecurity companies which provides security software for end users and enterprise companies. Our software protects users against malware. It cleans their computer if they get infected. Our AntiMalware was one of them.

我曾在一家小型网络安全公司工作，该公司为最终用户和企业公司提供安全软件。 我们的软件可以保护用户免受恶意软件的侵害。 如果他们被感染，它将清理他们的计算机。 我们的反恶意软件就是其中之一。

The first beta version’s feedbacks and impressions were promising. We were four developers, working on that product and constantly fixing bugs, iterating new versions by improving the product.

第一个Beta版本的反馈和印象是令人鼓舞的。 我们是四个开发人员，致力于该产品并不断修复错误，并通过改进产品来迭代新版本。

第一个稳定版本 (First stable version)

After two months working on bug fixing, improving and coding, we released the first stable version of AntiMalware.

经过两个月的错误修复，改进和编码工作，我们发布了第一个稳定版本的AntiMalware。

What were users saying?

用户在说什么？

Most of our users’ feedbacks were great, and they liked the product. This was keeping our team motivated. We were actively working on the product to improve our core features.

我们的大多数用户反馈都很棒，他们喜欢该产品。 这使我们的团队充满动力。 我们正在积极开发该产品，以改善我们的核心功能。

飞机正在起飞。 (The airplane is taking off.)

2016–2017.

2016–2017。

Our golden years before the big storm.

我们在大风暴之前的黄金岁月。

AntiMalware was living its best times. It was becoming our flagship product. Users were recommending it to their friends. Every blog and forums related to security were recommending our software. It was the first option when it comes to rescuing infected users.

AntiMalware处于最佳时期。 它已成为我们的旗舰产品。 用户向朋友推荐了它。 每个与安全性相关的博客和论坛都在推荐我们的软件。 在挽救受感染的用户时，这是第一个选择。

Downloads, installations, sales.

下载，安装，销售。

Every metric was going up, the user base was growing quickly over months. Founders were happy, the team as well. This was the big success the company was looking for. Everyone thought: “We did it! Like other big companies, we thought we created our own success story.”

每个指标都在上升，用户群在几个月内Swift增长。 创始人和团队都很高兴。 这是该公司一直在寻找的巨大成功。 每个人都认为：“ 我们做到了！ 与其他大公司一样，我们认为我们创造了自己的成功故事。”

新机遇(至少我们这样认为)：进入企业市场 (New opportunities (at least we thought like that): Entering the enterprise market)

The company decided to enter the enterprise arena. We were building a new team for the corporate product. The product owner of AntiMalware was leaving the team. Our CTO was taking responsibility and becoming the new owner. (Big mistake. I will explain why).

公司决定进入企业领域。 我们正在为企业产品建立新的团队。 AntiMalware的产品所有者即将离开团队。 我们的首席技术官正在承担责任并成为新的所有者。 (大错误。我将解释原因)。

Some developers were leaving the company, but it was OK. We were handling everything well and AntiMalware was still the best option in the market.

一些开发人员要离开公司，但是还可以。 我们处理的一切都很好，AntiMalware仍然是市场上最好的选择。

好日子已经过去了。 让我们面对现实。 (Good days were behind. Let’s face reality.)

As I told you, our CTO was handling everything about AntiMalware. He was the main developer, constantly releasing new updates and improving the product’s capability. However, because of his position, he had to handle other company stuff also.

正如我告诉您的那样，我们的CTO正在处理有关AntiMalware的一切。 他是主要的开发人员，不断发布新的更新并提高产品的功能。 但是，由于他的职位，他还必须处理其他公司事务。

Sure, in the beginning, everything was going well. As in every development process, in our case also, we had to keep maintaining and improving our software.

当然，一开始一切都很好。 与每个开发过程一样，在我们的情况下，我们也必须继续维护和改进软件。

As we should have expected (clearly we didn’t), somehow, the development process started slowing down.

正如我们应该预期的那样(显然没有)，开发过程开始变慢了。

The days when we were releasing new updates were behind. At that moment we were living the reality of late updates and soon no updates at all. This bugged me a lot and one day I asked our CTO:

我们发布新更新的日子已经过去了。 那时，我们正在经历更新的现实，很快就没有更新。 这让我很烦恼，有一天我问我们的CTO：

“What is wrong with this product?

“这个产品怎么了？

He took a deep breath and started talking:

他深吸一口气，开始讲话：

“The code base is really complicated. It is not structured well and it is not loosely coupled. The architecture was designed in a totally wrong way. The UI and core logic interfere with each other. Whenever I fix a bug or change something, this affects other parts of the software. Even small changes are hard to be done. With every new update, something new comes up.

“代码库真的很复杂。 它的结构不完善，耦合程度也不高。 该体系结构的设计完全错误。 UI和核心逻辑相互干扰。 每当我修复错误或更改某些内容时，这都会影响软件的其他部分。 即使是很小的更改也很难做到。 每次进行新更新时，都会出现一些新变化。

There are some methods that take 20 parameters, they are two pages long! Can you imagine? There are many things that were supposed not to be implemented but they were implemented anyway.

有一些方法需要20个参数，它们长达两页！ 你可以想象？ 有许多事情本不应该执行，但无论如何都可以执行。

That’s why every update takes too long and I cannot implement a new feature. If we release a new update, I am scared that we might introduce new bugs and break the program’s core functionality that works well now. That’s why it is too risky for us to release a new update. We can lose our users. We can lose our product as well.”

这就是为什么每次更新都花费太长时间而我无法实现新功能的原因。 如果我们发布一个新更新，恐怕我们可能会引入新的错误并破坏程序的核心功能，这些功能现在可以正常运行。 这就是为什么我们发布新更新风险太大。 我们可能会失去用户。 我们也会失去我们的产品。”

A burst of reality came out from his end and all of us knew it. Actually, we were expecting this answer from him.

从他的尽头传出一阵现实，我们所有人都知道。 实际上，我们期待他的回答。

But there was one more thing to be asked. He was leading the previous main developer who led the product for one year, so how could the code be that messed up?

但是还有另外一件事要问。 他曾领导过负责该产品的前主要开发人员一年，那么如何将代码弄得一团糟？

“I didn’t want to break his motivation. We had to enter the anti-malware market as fastest as possible and he was good at this. That’s why I didn’t want to stop him.”

“我不想破坏他的动力。 我们必须尽快进入反恶意软件市场，他很擅长此事。 这就是为什么我不想阻止他。”

Basically, we sacrificed the code base to enter the market in the fastest way, but this destroyed our product’s future.

基本上，我们牺牲了代码库以最快的方式进入市场，但这破坏了我们产品的未来。

Lesson learned: Don’t hesitate to say “this is sh*t” if something is really sh*t. The future of your product is more important than your spaghetti code. Focus on to have a sustainable product.

获得的经验 ：如果确实存在某些东西，请不要犹豫地说“这是必需品”。 产品的未来比意大利面条代码更重要。 专注于拥有可持续发展的产品。

我们如何解决这个可怕的代码？ (How can we fix this terrible code?)

“We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.”

“我们是程序员。 程序员在他们心中是建筑师，当他们到达某个站点时，他们要做的第一件事就是将这个地方推平并建造宏伟的东西。 我们对渐进式的改造并不感到兴奋：修补，改善，种植花坛。”

— Joel Spolsky, CEO of Stackoverflow

— Stackoverflow首席执行官Joel Spolsky

Developers always have a tendency to throw away the code and start over. There’s a reason for that. The reason is that they think the old code is useless and a mess. But again we just think! However, when we try to find out what is the real reason behind that, we can face the fact:

开发人员总是倾向于丢弃代码并重新开始。 这是有原因的。 原因是他们认为旧代码没有用，而且一团糟。 但是我们再想一想！ 但是，当我们试图找出背后的真正原因是什么时，我们可以面对一个事实：

We are probably wrong!

我们 可能错了！

The reason that the old code might look messy to us and that it has to be rewritten from scratch isn’t actually because of the code but rather because of a cardinal, fundamental law of programming:

旧代码对我们来说可能看起来很凌乱并且必须从头开始重写的原因实际上并不是由于代码，而是由于编程的基本原理：

It’s harder to read code than to write it.

阅读代码比编写代码更难。

This is why it is so hard to reuse code. This is why we think “It’s a big hair mess”. This is why our subconscious mind whispers to our ears “Throw it away and start over” when we read another developer’s code.

这就是为什么很难重用代码的原因。 这就是为什么我们认为“ 这真是一团糟 ”。 这就是为什么当我们阅读其他开发人员的代码时，我们的潜意识会在耳边低声说“ 扔掉并重新开始 ”。

Like every developer, we fall into this trap. Just checking our messy code one time was enough to think about rewriting it from scratch.

像每个开发人员一样，我们陷入了这个陷阱。 一次检查我们的凌乱代码就足以考虑从头开始重写它。

After a series of meetings, even though our CTO was resistant to code rewriting (right behavior), he was convinced in the end and we started the rewrite.

经过一系列会议后，即使我们的CTO拒绝代码重写(正确的行为)，但最终他还是被说服了，我们开始了重写。

However, this decision didn’t last too long…

但是，这个决定并没有持续太久……

It was a weekend. Sunday. I was drinking my morning coffee and reading some articles. Like my feed knew what to show me, I came across the most known article about rewriting the code. It was Netscape’s rewriting story written by Joel Spolsky.

这是一个周末。 星期日。 我当时在喝咖啡，阅读一些文章。 就像我的提要知道向我展示什么一样，我遇到了有关重写代码的最著名的文章。 这是乔尔·斯波斯基 ( Joel Spolsky)撰写的Netscape重写故事 。

Sharing this article with the rest of the AntiMalware team, including our CTO, was my immediate action after I finished reading it.

阅读完后，我立即与AntiMalware团队的其他成员(包括我们的CTO)分享这篇文章。

Another discussion started.

另一个讨论开始了。

It was already hard to convince our CTO to rewrite the code but after reading that article, he changed his mind again. He did not want to execute this decision. Other team members were yelling at me:

已经很难说服我们的CTO重写代码，但是在阅读了这篇文章之后，他再次改变了主意。 他不想执行这个决定。 其他团队成员对我大喊：

“Why did you send this article? We already convinced him. This product must be rewritten from scratch. This is the only way.”

“您为什么发送这篇文章？ 我们已经说服了他。 必须从头开始重写该产品。 这是唯一的方法。”

Hereby, our first attempt was finalized and we closed that rewrite topic. Our CTO believed that he could manage this crappy code and that he could release a new update. This topic was closed until harsh reality knocked us down.

到此，我们的第一次尝试已经完成，我们关闭了该重写主题。 我们的CTO相信他可以管理这个糟糕的代码，并且可以发布新的更新。 这个话题是封闭的，直到残酷的现实使我们失望为止。

One year without any update…

一年没有任何更新…

Really, this is not a joke. This happened!

真的，这不是在开玩笑。 这发生过！

“Why no update?”

“为什么不更新？”

“It has been months since the last update.”

“距离上一次更新已经几个月了。”

These negative comments from our users become our reality. As a small company, we had too many products to manage, and on top of it, we entered the enterprise market which caused us to come to that point actually.

来自用户的负面评论成为我们的现实。 作为一家小公司，我们要管理的产品太多了，最重要的是，我们进入了企业市场，这实际上使我们达到了这一点。

Mix all of that and you get one point: we forgot about our users.

混合所有这些，您会得到一点：我们忘记了我们的用户。

So, imagine. We didn’t want to release a new update because we didn’t want to lose our users.

所以，想象一下。 我们不想发布新更新，因为我们不想失去我们的用户。

Actually, it should’ve been opposite: if we don’t release a new update we will definitely lose our users because hey we didn’t give them an update for over a year and a half.

实际上，应该是相反的：如果我们不发布新的更新，我们肯定会失去我们的用户，因为嘿，我们超过一年半没有给他们更新。

After the reality slapped us in the face, we decided to reach back and for us, rewriting software was the only option so we did it.

面对现实后，我们决定退缩，对我们来说，重写软件是唯一的选择，所以我们做到了。

Today.

今天。

“Monday, 17 December 2018, 21:40. The email was prepared to be sent to our private beta group.”

“ 2018年12月17日，星期一，21:40。 该电子邮件已准备好发送给我们的私人Beta版。”

After 12 exhausting months, we completed our rewriting process. We prepared the first beta release note, just like the first day our product met the market.

经过12个月的辛苦工作，我们完成了重写过程。 我们准备了第一个Beta版发行说明，就像我们的产品投放市场的第一天一样。

Here we are again…

我们又来了...

The rewritten version of the product is still in Beta. It has been almost one month. We are fixing bugs, listening to our users, reviewing feedbacks… As we did 4 years ago…

产品的重写版本仍处于Beta中。 已经快一个月了。 我们正在修正错误，听取用户意见，审查反馈…就像4年前一样…

What have we missed during these 12 long months? Who knows what else we could have done instead of rewriting?!

在这12个月里，我们错过了什么？ 谁知道除了重写我们还能做什么？！

Many questions can be asked at this point. All I know is that rewriting was the only option for us or we couldn’t see any other solution.

此时可以问很多问题。 我所知道的是，重写是我们唯一的选择，否则我们看不到任何其他解决方案。

If you fall into this trap too and start thinking “I should rewrite the software from scratch”, consider asking these questions that I believe every developer should ask before taking the first step to code rewriting.

如果您也陷入这个陷阱，并开始思考“我应该从头开始重写软件”，请考虑问这些问题，我相信每个开发人员在迈出第一步编写代码之前都应该问这些问题。

1.您准备抛弃所有这些知识吗？ (1. Are you ready to throw away all that knowledge?)

I am asking seriously! Please be honest with yourself and answer this question: Are you really ready to throw away all that knowledge, all those collected bug fixes, years of programming. This is what you expect when you throw away the code and start from scratch. When you look at code rewriting from this perspective, it’s painful, isn’t it? All those sleepless nights trying to fix bugs go through your eyes. Believe me, I know.

我是认真的问！ 请对自己诚实，并回答以下问题：您是否真的准备抛弃所有知识，所有已收集的错误修复程序，多年的编程经验。 这是您丢弃代码并从头开始时的期望。 从这种角度来看代码重写时，会很痛苦，不是吗？ 所有那些试图修复错误的不眠之夜都贯穿了您的眼睛。 相信我，我知道。

You had to talk to a lot of users to find the issue that caused your software not to work properly. Then you had to find this bug in your software. Then you had to reproduce the issue then find the fix, then… and so on and so on.

您必须与许多用户进行交谈，以找出导致软件无法正常运行的问题。 然后，您必须在软件中找到该错误。 然后，您必须重现问题，然后找到解决方法，然后……等等。

2.您能保证自己会比第一次做得更好吗？ (2. Can you guarantee that you are going to do a better job than you did the first time?)

It’s important to keep in mind that when you start from scratch there is no guarantee that you are going to do a better job than you did the first time.

重要的是要记住，当您从头开始时，并不能 保证您会做得比第一次更好。

Since you chose to throw away all that knowledge, collected bug fixes, there is a high possibility that same bugs might again come up.

由于您选择抛弃所有知识并收集了错误修复程序，因此很有可能再次出现相同的错误。

Probably, the rewriting team is going to be different than the team worked on the first version. So you don’t actually have “more experience”. You’re just going to make most of the old mistakes again and introduce some new problems that weren’t in the original version.

重写团队可能与第一个版本的团队有所不同。 因此，您实际上没有“更多经验”。 您将再次犯下大多数旧错误，并引入一些原始版本中没有的新问题。

If you don’t plan well the rewriting process, there is a big risk that a new version might be worse than the original version at solving your customer’s problem. With this rewriting decision, you’re going to take this risk that can cause you to lose your customers.

如果您没有很好地计划重写过程，则存在很大的风险，即新版本在解决客户问题方面可能会比原始版本差。 通过此重写决定，您将承担可能导致失去客户的风险。

3.您准备好给竞争对手几个月或几年的礼物了吗？ (3. Are you ready to give a gift of months/ years to your competitors?)

Do you know exactly how much time do you need to rewrite your software?

您确切知道需要多少时间来重写软件？

It takes a lot of effort, planning, preparations. You will plan each task and sprint one by one and you will exactly know your deadline to finish this painful process. Or you will miss the deadline. Who knows? There is a high possibility that you won’t finish this process on time.

这需要大量的努力，计划，准备。 您将计划每个任务并逐个冲刺，并且您将完全知道完成此痛苦过程的截止日期。 否则您会错过最后期限。 谁知道？ 您极有可能无法按时完成此过程。

You will be in an extremely dangerous position where you will have to ship an old version of the code for months or years, completely unable to make any strategic changes or react to new features that the market demands because you don’t have shippable code.

您将处于极其危险的境地，在几个月或几年内，您将不得不交付旧版本的代码，因为您没有可交付的代码，因此完全无法进行任何战略更改或对市场所需的新功能做出React。

Your customers might as well just abandon you because you don’t give anything new and you keep shipping your old product without any changes.

您的客户也可能只是放弃您，因为您没有提供任何新东西，而且您会继续运送旧产品而没有任何更改。

Did you think about this?!

您考虑过吗？

重写软件的经验教训 (Lessons learned in rewriting software)

Rewriting a system from the ground up is essentially an admission of failure as a designer. It is making the statement, “We failed to design a maintainable system and so must start over.” — Max Kanat-Alexander, Code Simplicity

从头开始重写系统本质上是承认设计者失败。 它声明：“我们未能设计出可维护的系统，因此必须重新设计。” — Max Kanat-Alexander ， 代码简单

So as other designers, we admitted that we failed to design our software and we learned a lot from that exhausting process. Here I am sharing lessons that stuck to me.

因此，作为其他设计师，我们承认我们未能设计软件，并且从疲惫的过程中学到了很多东西。 在这里，我分享了我的课程。

重写代码是开发人员的错觉，在大多数情况下不是解决方案。 (Rewriting code is a developer illusion, not the solution in most cases.)

When you are in trouble with your code, it is important to diagnose what is the issue exactly. As every developer will do, your initial thought shouldn’t be rewriting. This is just an illusion. It is illusion because you are struggling to read someone else’s code and you think you would do a better job if you rewrote it from scratch. In this case, always remember the fundamental law of programming.

当您遇到代码麻烦时，准确地诊断出问题所在很重要。 正如每个开发人员都会做的那样，您最初的想法不应该被重写。 这只是一种幻想。 这是一种幻想，因为您正在努力阅读别人的代码，并且认为如果您从头重写它，将会做得更好。 在这种情况下，请始终记住编程的基本定律。

在采取代码重写步骤之前，请考虑重构 (Consider refactoring before taking a step to code rewriting)

Targeted rewrites are useful to deal with the worst offenses in your code base. Don’t do a whole rewrite if you can limit the scope and address the majority of your problems. For example, the loading of your software is so slow. But this only affects a small part of the project. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. You don’t have to rewrite the whole thing.

有针对性的重写对于处理代码库中最严重的错误很有用。 如果可以限制范围并解决大多数问题，请不要完全重写。 例如，您的软件加载太慢。 但这仅影响项目的一小部分。 通过小心地移动代码，重构，更改接口，可以一次解决这些问题。 您不必重写整个过程。

谨防。 这是比您期望的更长，更难，更容易出现故障的路径。 (Beware. This is a longer, harder, more failure-prone path than you expect.)

There is a fact that developers usually realize it after they miss the deadline: everything takes longer than you think. Be very pessimistic in your estimates about the cost of a rewrite. It almost always costs more and takes longer than you would think. There will be always a lot of complexity that will make the rewriting process harder and more painful. In the end, the possibility of failure is hard to miss.

有一个事实，就是开发人员通常会在错过最后期限后才意识到这一点： 所有事情花费的时间比您想象的要长。 您对重写成本的估计非常悲观。 它几乎总是比您想像的要花费更多的时间和更长的时间。 总会有很多复杂性，这将使重写过程变得更加困难和痛苦。 最后，失败的可能性很难错过。

确保新产品更好地解决了用户的问题(或至少解决了同样的问题)。 更糟的是不能接受的。 (Make sure the new product is better at solving user’s problem (or at least the same). Worse cannot be acceptable.)

Rewrites have no direct effects/benefits for the customer. Your users don’t care about your code. They just want to solve their own problem. That’s all. In their eyes, you are successful if your product fits in solving their problem. Otherwise, they are not using the product. They don’t care about your rewriting decision, so the rewritten version must at least work as efficiently as the old one.

重写对客户没有直接影响/好处。 您的用户不在乎您的代码。 他们只是想解决自己的问题。 就这样。 在他们看来，如果您的产品适合解决他们的问题，那么您就是成功的。 否则，他们将不使用该产品。 他们不在乎您的重写决定，因此重写后的版本至少必须像旧版本一样有效。

继续维护和支持现有产品。 (Keep maintaining and supporting the existing product.)

In our case, we didn’t give any update to users for one year. This is too long in the world we live in today. Our product was still good enough, but users were complaining about no updates. Never stop maintaining a system that is currently in use so that the programmers can rewrite it. During the rewriting process, the old code still needs to be maintained. Small updates and bug fixing should be given to users while you are rewriting the old code. Otherwise, you will face losing your customers.

在我们的案例中，我们一年没有给用户提供任何更新。 在我们今天生活的世界中，这太长了。 我们的产品仍然足够好，但是用户抱怨没有更新。 永远不要停止维护当前正在使用的系统，以便程序员可以重写它。 在重写过程中，仍然需要维护旧代码。 重写旧代码时，应向用户提供小更新和错误修复。 否则，您将面临失去客户的机会。

让用户尽快参与设计过程。 (Involve users in the design process as soon as possible.)

Always show your current progress to your end users at regular intervals so that they can help you catch the worst offenses. It is important to meet your users as soon as possible. Their feedback will help you design a new product based on their needs. Don’t implement any unnecessary features. This will save you from having a complicated code base.

始终定期向最终用户显示当前进度，以便他们可以帮助您发现最严重的违规情况。 尽快与您的用户见面很重要。 他们的反馈将帮助您根据他们的需求设计新产品。 不要实现任何不必要的功能。 这样可以避免使用复杂的代码库。

使产品团队保持同步。 (Keep the teams working on the product synced.)

The product is not only about the programming team. Marketing, support, programming, design… Many teams work on it. Keep them synced by giving them regular updates about the rewriting process.

该产品不仅与编程团队有关。 营销，支持，编程，设计……许多团队都在为此工作。 通过定期向他们提供有关重写过程的更新，使它们保持同步。

In our case, we have dealt with many problems. For example, the marketing team was preparing our product beta campaign and they had to know exactly what was going on the product side so that they could prepare customers for upcoming product changes. Sometimes we made some changes without informing them. And this caused them to prepare their campaign all over from scratch. Don’t spend anyone’s time inefficiently.

就我们而言，我们已经解决了许多问题。 例如，营销团队正在准备我们的产品测试活动，他们必须确切地了解产品方面的情况，以便为即将到来的产品更改做好准备。 有时我们做了一些更改而没有通知他们。 这导致他们从头开始准备竞选活动。 不要浪费时间浪费别人的时间。

不要对产品进行重大更改。 (Don’t make dramatic changes to the product.)

It is important to know your product’s weak and strong sides. Don’t change the strong sides, the ones loved by users. If users are satisfied with your UI, don’t change it. Do minimal changes and small UX improvements. When you replace your existing software with the new one, your users shouldn’t be confused with the new dramatic changes. There are many cases where users abandoned new products because they didn’t find the same functionality as the previous product provided. Don’t let the same thing happen to you.

重要的是要知道您的产品的弱点和强项。 不要改变用户喜欢的强项。 如果用户对您的用户界面感到满意，请不要更改它。 进行最小的更改和小的UX改进。 当您用新软件替换现有软件时，您的用户不应与新的巨大变化混淆。 在许多情况下，用户因为找不到与先前产品相同的功能而放弃了新产品。 不要让同一件事发生在你身上。

不要让您的产品仅依赖一个开发人员。 (Don’t make your product depend on only one developer.)

In our case, our CTO was the responsible developer for our software. Due to his position, our product development was going slowly. Even small changes were taking several weeks, sometimes months. The point is to always keep moving. Never stop.

在我们的案例中，我们的CTO是我们软件的负责开发人员。 由于他的职位，我们的产品开发进展缓慢。 即使是很小的变化，也要花费数周甚至数月的时间。 关键是要始终保持前进。 永不止步。

迁移应该缓慢而稳定。 (Migrations should be slow and steady.)

Replace your original software with the new one when you are sure that the new one is ready. Do it step by step.

当您确定新软件已准备就绪时，请用新软件替换原始软件。 逐步进行。

First, start with a small private beta group and ship your product into that group. Continuously collect feedbacks and crash reports, fix the bugs, iterate new versions and again the same thing. Follow this cycle until you ensure that your product is ready to go public beta.

首先，从一个小型的私人测试版小组开始，然后将您的产品运送到该小组中。 不断收集反馈和崩溃报告，修复错误，迭代新版本，然后再次进行相同操作。 遵循此循环，直到确保您的产品已准备好公开发布Beta。

When you go public beta, feedbacks are going to be your best friend again. Your first goal here should be to ensure that your product solves the users’ problems. When you are sure that you are providing the same or better functionality as old software did, replacement can take place. Release the new software for new users, and migrate your existing users to the new one.

当您公开测试版时，反馈将再次成为您最好的朋友。 您的首要目标应该是确保您的产品能够解决用户的问题。 如果确定要提供与旧软件相同或更好的功能，则可以进行替换。 为新用户发布新软件，然后将现有用户迁移到新用户。

Those are the key lessons that I learned from our rewriting process. Rewriting is almost never the answer. More often than not, refactoring is a better bet. I strongly advise the slow approach of using refactoring. It’s less risky and you keep your customers happy.

这些是我从重写过程中学到的关键课程。 重写几乎永远不是答案。 通常，重构是一个更好的选择。 我强烈建议使用重构的缓慢方法。 风险较小，您可以使客户满意。

何时重写代码 (When to rewrite the code)

There are times when it is appropriate to do a rewrite. If I could have made a list about when to rewrite the code, this would be my list:

有时适合进行重写。 如果我可以列出何时重写代码，这将是我的清单：

Switching to another language or platform (as in our case): The language is so old. It is hard to find a developer or you have to pay a lot of money to get one. In both cases too much effort.

切换到另一种语言或平台(以我们的情况为例)：该语言过旧。 很难找到开发人员，或者您必须付出很多钱才能获得一名开发人员。 在这两种情况下，都需要付出过多的努力。

The existing codebase is not maintainable anymore (as in our case): How do you decide your code is not maintainable? It is hard to determine but if even small changes are hard to be done, if new updates take longer than usual, if any new change affects other parts of the software and introduces new bugs, your software is unmaintainable.

现有的代码库不再可维护(如本例所示)：您如何确定代码不可维护？ 很难确定，但是即使是很小的更改也很难完成，如果新的更新要比平时花费更长的时间，如果有任何新的更改影响软件的其他部分并引入新的错误，则您的软件将无法维护。

You have the resources available to both maintain the existing system and design a new system at the same time: Never stop maintaining a system that is currently in use so that the programmers can rewrite it. Systems must always be maintained if they are in use. And remember that your personal attention is also a resource that must be taken into account here — do you have enough time available in each day to be a designer on both the new system and the old system simultaneously, if you are going to work on both?

您有足够的资源来维护现有系统和同时设计新系统：不要停止维护当前正在使用的系统，以便程序员可以重写它。 如果正在使用系统，则必须始终对其进行维护。 并记住，您的个人注意力也是这里必须考虑的资源-如果您打算同时在新系统和旧系统上工作，那么您每天是否有足够的时间同时作为新系统和旧系统的设计师？ ？

The developers in the team are a bottleneck for software (as in our case): This shouldn’t be a reason to rewrite the code from scratch. You can always switch developers within the team or you can hire new developers to eliminate the bottleneck situation.

团队中的开发人员是软件的瓶颈(在我们的案例中)：这不应该是从头开始重写代码的原因。 您可以随时更换团队中的开发人员，也可以雇用新的开发人员来消除瓶颈情况。

However, sometimes, as in our case, there might be times where you have to choose the rewriting option. Our software was written with old technology and our CTO was the only responsible person to develop it. We tried to find a new developer but it was hard because of the age of this coding platform. Even if we could have found a new one, it would be very expensive for us. So together with other conditions, this was in our list to decide to rewrite code.

但是，有时，就像我们的情况一样，有时可能需要选择重写选项。 我们的软件是用旧技术编写的，而我们的CTO是唯一负责开发此软件的人。 我们试图找到一个新的开发人员，但是由于这个编码平台的时代而很难。 即使我们可以找到一个新的，对我们来说也很昂贵。 因此，连同其他条件一起，这是我们决定重写代码的清单。

The software is long-lived (I’m talking like 10–20 years or more): Maintenance becomes more and more expensive over time. This is due to the fact that the code is becoming more and more spaghetti-ish as the original architecture is sacrificed for quick maintenance patches. Also, developers for older technologies become rarer and more expensive. Finally, hardware begins to age and it gets harder and harder to find new hardware, operating systems, frameworks, etc. to run the old application on top of it. Also, businesses evolve, and most likely an older system will not be meeting the business needs of the organization.

该软件寿命很长(我的意思是说10到20年或更久)：随着时间的推移，维护变得越来越昂贵。 这是由于以下事实：由于牺牲了快速维护补丁的原始体系结构，因此代码变得越来越意大利面。 而且，用于较老技术的开发人员变得越来越稀有且价格更高。 最后，硬件开始老化，找到新硬件，操作系统，框架等以在其之上运行旧应用程序变得越来越难。 而且，企业在发展，很可能旧的系统将无法满足组织的业务需求。

So you have to weigh all of the ongoing maintenance cost, as well as the potential benefits of a new system, against the cost of rewriting it from scratch.

因此，您必须权衡所有正在进行的维护成本以及新系统的潜在利益，而不是从头开始重写它的成本。

If your case fits in one or more of the above points, you may be in a situation where it is acceptable to rewrite. Otherwise, the correct thing to do is to handle the complexity of the existing system without a rewrite, by improving the system’s design in a series of simple steps.

如果您的案例符合以上一个或多个要点，则可能处于可以重写的情况。 否则，正确的做法是通过一系列简单的步骤来改进系统的设计，而无需重写即可处理现有系统的复杂性。

Rewriting your code from scratch could be the single biggest mistake you make, but equally so, not-rewriting your code could lead to the same result. Here is a piece of advice. Refactoring should be the first option.

从头开始重写代码可能是您犯的最大错误，但是同样地，不重写代码也可能导致相同的结果。 这是一条建议。 重构应该是第一个选择。

Some developers will keep believing that all systems must eventually be rewritten. Always keep in mind that this is not true. It is possible to design a system that never needs to be thrown away. There will be always a software designer around you saying “We’ll have to throw the whole thing away someday anyway”. But if software is built right to start with and then properly maintained, why would it be thrown away?

一些开发人员会继续相信所有系统最终都必须重写。 始终牢记这是不正确的。 可以设计一个永远不需要扔掉的系统。 您周围总会有一个软件设计师说：“总有一天我们必须把整个东西扔掉”。 但是，如果从一开始就构建软件，然后对其进行适当维护，那么为什么要扔掉它呢？

Originally published at huseyinpolatyuruk.com.

最初发表于 huseyinpolatyuruk.com 。

Each ? is welcomed if you enjoyed this article!

每个？ 如果您喜欢这篇文章，欢迎您！

I write about programming, technology, AI, startups and self-growth. If you follow me on Twitter I won’t waste your time with unnecessary posts. ?

我写有关编程，技术，人工智能，创业公司和自我成长的文章。 如果您在Twitter上关注我，我不会在不必要的帖子上浪费您的时间。 ？

翻译自: https://www.freecodecamp.org/news/lessons-learned-in-my-10-years-as-a-developer-3d33c8702828/

经验教训 软件开发