When I was a child, I liked building Lego models. I still do like building Lego models, but these days I also building software products. And those are a bit more tricky…
小时候，我喜欢构建乐高模型。 我仍然喜欢构建Lego模型，但是这些天我也正在构建软件产品。 而且这些还有些棘手……
With a Lego model, all of the pieces come in small bags with numbers on them, and there are picture books describing how to snap the pieces together. The requirements are understood up front, and a vision of the end product is well formed.
使用乐高(Lego)模型，所有作品都放在带有数字的小袋子中，并且有图画书描述了如何将这些作品扣在一起。 预先了解需求，并很好地形成最终产品的愿景。
It is a pity, but this is not quite the case with software projects! Greenfield software projects do not come with a cool picture of what is should look like on the box. Actually, there is no box… And no numbered bags of parts. Or pre-moulded parts. It is all a lot more complex, and with that complexity, comes the opportunity to really create some proper, old fashioned. chaos!
可惜的是，但是对于软件项目却并非如此！ 格林菲尔德软件项目并没有提供包装盒上应有的外观。 实际上，没有盒子……也没有编号的零件袋。 或预成型零件。 一切都变得更加复杂，并且随之而来的是真正创建一些合适的，老式的机会。 混沌！
This post is a whimsical look at the course of a software project that is going off the rails, from the point of view of the technical team. I will follow this up at some point with some concrete and practical tips on keeping things on (or at least kinda near) the rails. But for now, unwittingly illustrated by the great Thomas Cole, I present the Course of Software Empire.
从技术团队的角度来看，这篇文章奇特地介绍了一个软件项目的发展过程。 在某些时候，我将提供一些具体实用的技巧，以使事物保持(或至少接近)轨道。 但是现在，由伟大的托马斯·科尔(Thomas Cole)无意间说明了这一点，我介绍了软件帝国课程。
Hello World! A new project is born. There is zero technical debt, there are no code smells. There is no… anything actually. Total freedom to craft a new project. And this time… this time it is going to be different. This will be the perfect project. Only the best and newest technologies. We will test, and test first. It will be enough to make Alan Turing weep.
你好，世界！ 一个新项目诞生了。 技术债务为零，没有代码异味。 实际上没有任何东西。 完全自由地制定新项目。 而这次……这次将有所不同。 这会是 完美的项目。 只有最好和最新的技术。 我们将测试，并第一次考验。 这足以使Alan Turing哭泣。
Things you may hear yourself saying:
您可能会听到自己说的话：
“I’m really excited to be working on this project”
“我很高兴能参与这个项目”
“I was thinking about this all weekend and…”
“我整个周末都在想这个……”
“I built this prototype last night. Who needs sleep…. right? …right?”
“我昨晚建造了这个原型。 谁需要睡觉...。 对？ …对？”
“We should all read the ‘gang of four’ book”
“我们都应该读'四人帮'书”
What you probably should be saying:
您可能应该说的是：
This is the fun part of the project, and I definitely do not want to take away from that. But this is also the place where the success or failure of the project is largely decided, and making mistakes at this stage can have serious and unrecoverable repercussions for the duration of the project.
这是项目的有趣部分，我绝对不想从中脱颖而出。 但这也是在很大程度上决定项目成败的地方，在此阶段犯错误可能会对项目持续时间造成严重且不可恢复的影响。
The most important thing to do at the start of a project, is to make sure that you are building something that your users or customers actually want. That sounds obvious… right? But I have often found myself working on projects that seemed like a good idea, but simply did not sell or get used. The way to do this is to sit down with your users, and ask them what they actually want. You need to get to understand their pain points, and make sure that whatever it is you are building mitigates these pain points in some way.
在项目开始时要做的最重要的事情就是确保您正在构建用户或客户真正想要的东西。 听起来很明显…对吗？ 但是我经常发现自己从事的项目似乎是一个好主意，但是根本没有出售或使用。 做到这一点的方法是与您的用户坐下来，问他们实际想要什么。 您需要了解他们的痛点，并确保您正在构建的内容以某种方式减轻了这些痛点。
It’s natural as coders for us to pay attention to the tech stack at this stage and push for all of the ‘new coolness’. But remember that the dogrwn side of being on the cutting edge is that sometimes you get cut. There is a lot to be said for always using technology that has been proven in the field.
作为编码人员，我们很自然地要在此阶段关注技术堆栈，并推动所有“新奇事物” 。 但是请记住，处于最前沿的那种顽固的一面是有时您会被割伤。 始终使用在该领域已被证明的技术有很多话要说。
It’s also easy for coders to pay attention to the creation of the technical team, and ignore all the other aspects of the team. This is definitely a mistake. Always remember that a bunch of good developers does not, a team, make. If the company is not also recruiting testers, designers, QA people, managers, and technical leads, then run screaming at this point, because chaos will inevitably ensure.
编码人员也很容易注意技术团队的创建，而忽略了团队的所有其他方面。 这绝对是一个错误。 永远记住，一群优秀的开发人员并不会创造团队。 如果公司还没有招聘测试人员，设计师，质量检查人员，经理和技术负责人，那么此时就大喊大叫，因为不可避免地会造成混乱。
Things are picking up. The management are excited, the clients are excited, the sales team are… probably massively overselling things. The developers feel like rock stars, because all of the good ideas, practices, hard work, weekend coding, etc is paying off. Backs are being slapped and success is assured.
事情正在加速。 管理层很兴奋，客户很兴奋，销售团队很……可能是超额销售。 开发人员感觉像是摇滚明星，因为所有的好主意，实践，辛勤工作，周末编码等等都在有所回报。 背上打耳光，并确保成功。
Things you may hear yourself saying:
您可能会听到自己说的话：
“Forty clients and counting! I sure hope those sales team are not promising things that we can’t deliver”
“有40位客户，而且还在增加！ 我肯定希望那些销售团队不会承诺我们无法交付的东西。”
“I’m putting half my pay into equity. I’ll be a millionaire by Christmas”
“我将一半的薪水投入股票。 我要在圣诞节前成为百万富翁。”
“This is so fucking clever. I mean, look at this! It’s like, all of the gang of four patterns at the same time. Amazing”
“这真是太聪明了。 我的意思是，看看这个！ 就像是同时出现四种模式的所有帮派一样。 惊人”
What you probably should be saying:
您可能应该说的是：
All projects look like they are going to succeed at this point, but many are not. It can be hard to identify when there is pain in the post, but there should be warning signs at this point. Just because it looks like it kinda maybe works on the test server, does not mean that it will be fine when a swarm of clients appear, and expect the reality of the product to match the sales brochure.
所有项目看起来都将在这一点上取得成功，但很多项目都不会成功。 很难确定何时有疼痛，但此时应有警告信号。 仅仅因为它看起来似乎可以在测试服务器上运行，并不意味着在出现大量客户并且期望产品的实际情况与销售手册相匹配的情况下就可以了。
At this stage of a project, you really need to be making sure that it is going to work in production. If you are skipping things like versioning, deployment, and release management, then there is trouble in the post as these things cannot really be easily fixed in production.
在项目的这个阶段，您确实需要确保它可以在生产中正常工作。 如果您跳过诸如版本控制，部署和发布管理之类的事情，那么在发布中就会遇到麻烦，因为这些事情实际上无法在生产中轻松修复。
This is the point where the developers have the most ability to make a difference if we see things going wrong, so don’t be afraid to speak up if you see trouble brewing. Failure to speak up now if technical debt is building at an unacceptable level, will come back to haunt you.
如果我们发现问题出了错，这就是开发人员最有能力做出改变的地方，因此，如果遇到麻烦，不要害怕大声疾呼。 如果技术债务正在增加到无法接受的程度，现在不敢大声说出来，这会再次困扰您。
While it may be the management or the sales team who apply the pressure that ultimately results in technical debt, it is up to the technical team to keep it under control — the clue is in the name! Make sure to keep on top of the technical debt at this stage, and chaos can be averted.
尽管可能是管理层或销售团队施加了最终导致技术债务的压力，但要由技术团队来控制它-线索就在此！ 确保在此阶段保持技术债务的领先地位，并且可以避免混乱。
It is in production — finally. There is definitely some technical debt in there. There are a few places where it’s best not to look to closely at the code. Everyone is terrified when it comes time to update production but, that’s fine for now, right? It’s a new project and we’ll fix all those little gremlins in the next release, just as long as we get some breathing space from the sales team to clear up the debt…
终于在生产中。 那里肯定有一些技术债务。 在某些地方，最好不要仔细查看代码。 每个人都对更新生产感到恐惧，但是现在还好吧？ 这是一个新项目，只要我们能从销售团队那里获得喘息的机会来清理债务，我们就会在下一个版本中修复所有这些小怪物。
Things you may hear yourself saying:
您可能会听到自己说的话：
“Hang on, is that.. every single gang of four pattern. Like, at the same time?”
“等等，就是这样。每个帮派都有四个模式。 喜欢，同时？”
“Are those clients, or is that an invading barbarian hoard?”
“是那些客户，还是那位入侵的野蛮人？”
“Who wrote this crap… ah fuck”
“谁写了这个废话……啊，他妈的”
“Can anyone remember why CQRS is a good idea?”
“谁能记住CQRS为什么是个好主意？”
“What does CQRS mean?”
“ CQRS是什么意思？”
“That’s not refactoring, that’s re-writing”
“那不是重构，那是重写”
What you probably should be saying:
您可能应该说的是：
Technical trouble when a product is in production should be treated like an emergency. If it is not, then all of the good work that has been done prior has been wasted.
产品生产中的技术故障应视为紧急事件。 如果不是这样，那么先前已经完成的所有良好工作都被浪费了。
If there is serious technical issues, and new features are still being requested, then it is time to run to the hills. As a technical person, it is not too late at this stage to change the course. But, once there are paying customers out there, the consequences of bugs are exponentially higher, and ‘taking a step back’ to fix stuff is sometimes not possible.
如果存在严重的技术问题，并且仍在要求新功能，那么该是时候上山了。 作为技术人员，现在改变路线还为时不晚。 但是，一旦那里有付费的客户，错误的后果就会成倍增加，并且有时无法“退一步”修复问题。
If a project is a wee bit off the rails, and in production, then I think that the most important thing for the technical team to do is to keep on top of their own personal work-life balance. It is easy to feel personally responsible for the systematic screw ups that the company has made, but this is never the case. Keep on top of things, while keeping a health sleeping schedule!
如果一个项目在生产和生产过程中有些微不足道，那么我认为技术团队要做的最重要的事情就是保持自己的个人工作与生活平衡。 对公司进行的系统性搞砸很容易感到个人责任，但事实并非如此。 保持最重要的状态，同时保持健康的睡眠时间表！
The reckoning. This is where all of the shortcuts that have been taken come back to bite you. Hard. The technical debt has built up to the point that there is virtually no work on new features. This has not stopped the sales team from selling the new features that are not being worked on, so there are a bunch of hacked off clients trying to get their money back. The technical team are blaming the sales team for overselling. The sales team are blaming the technical team for being bad at their jobs. The management are playing golf.
推算。 在这里，所有已采取的快捷方式都会再次咬住您。 硬。 技术债务已经累积到几乎没有新功能的地步。 这并没有阻止销售团队出售尚未使用的新功能，因此，有很多黑客试图收回他们的钱。 技术团队指责销售团队销售过剩。 销售团队指责技术团队对他们的工作不好。 管理层正在打高尔夫球。
Things you may hear yourself saying:
您可能会听到自己说的话：
“I hate clients”
“我讨厌客户”
“I hate lawyers”
“我讨厌律师”
“I’m going to kill the sales team”
“我要杀死销售团队”
“Do you think that the management are actually lizard people in suits? Like actual lizards. With scales under the suits?”
“您认为管理层实际上是穿着西装的蜥蜴人吗？ 像实际的蜥蜴一样。 西装下有秤吗？”
“You can’t fire me! I know all of the gang of four patterns!”
“你不能解雇我！ 我知道所有四种模式的帮派！”
What you probably should be saying:
您可能应该说的是：
Whatever you are saying, it should be said to the upper management. If they are not listening, then it’s time for a change.
无论您说什么，都应该对上级管理层说。 如果他们不听，那就该改变了。
As a coder, this is not a great place to find yourself. If things have gotten to this stage, the situation if probably unrecoverable, and it is probably time to move on. However, all may not be lost, and often this is the place where the real learning can happen.
作为一名编码人员，这不是找到自己的好地方。 如果事情已经到了这个阶段，那么这种情况可能就无法恢复了，现在该是继续进行的时候了。 但是，一切可能不会丢失，通常这是可以进行真正学习的地方。
Of course, when a project has gone off the rails like this, there is probably systematic failures in the company that are not within the wheelhouse of the development team to fix.
当然，当一个项目像这样脱离轨道时，公司中可能会出现系统性故障，而这些故障不在开发团队的指导范围之内。
But, we should all strive to ‘be the change we want to see in the world’. If you want to make a difference here, then this is the time for really candid discussions with the upper management. If that doesn’t go well then it is time for a change.
但是，我们所有人都应努力做到“成为我们希望在世界上看到的变化” 。 如果您想在这里有所作为，那么现在正是与上级管理层进行坦率讨论的时候了。 如果进展不顺利，那么该是时候改变了。
I think, after a few years working as a coder, we have all been here. There are still a few users lurking about, and there is still a yet-to-be-fired manager who thinks that it’ll all work out eventually. There is no money to update anything, and there is nothing wrong with VB6 and SourceSafe.. right? It was fine in the 90s, it’s probably fine now.
我认为，在担任编码员几年后，我们所有人都来过这里。 仍然有一些用户在潜伏，还有一个尚未被解雇的经理认为这最终会解决。 有没有钱去更新任何东西，并没有什么不妥 VB6和SourceSafe的..对不对？ 在90年代还不错，现在可能还不错。
Things you may hear yourself saying:
您可能会听到自己说的话：
“Wow, we just got an enquiry about a new license! LOL”
“哇，我们刚刚得到了有关新许可证的咨询！ 大声笑”
“Remember when we implemented a mediator between out CQRS layer in the MVC pattern to make the flux capacitor work. What were we smoking that day?”
“请记住，当我们在MVC模式中的CQRS外层之间实现调解器以使通量电容器工作时。 那天我们在抽什么？”
“There used to be more of us here.”
“这里过去有更多的人。”
“I wrote half of this shit so now I feel like I have to support it forever.”
“我写了一半的内容，所以现在我觉得我必须永远支持它。”
“Silverlight wasn’t a bad choice at the time. It’s a great to develop with”
“ Silverlight在当时并不是一个坏选择。 与我一起发展很棒”
What you probably should be saying:
您可能应该说的是：
Say whatever you like at this point, as long as you are saying it to your recruitment agent.
此时，只要您对招聘代理说，就随便说什么。
Working on dead or zombie projects is no fun. There may be a few clients lurking about still, but there is no chance of success at this point. The project will never be updated, and you will be supporting ancient technology for the rest of your time at that company.
在僵尸或僵尸项目上工作并不有趣。 也许有一些客户还在潜伏，但是目前还没有成功的机会。 该项目将永远不会更新，您将在该公司的其余时间里为古老的技术提供支持。
The big problem with working on legacy projects and technologies, is that as a coder your skill set rusts at an alarming rate. This should be treated as apersonal emergency, because when the plug gets pulled — and it will get pulled — you will emerge into a job market that has moved on. There is no benefit in working on dead technologies or dead products, don’t do it!
处理遗留项目和技术的最大问题是，作为编码人员，您的技能集生锈的速度惊人。 这应该被视为个人紧急情况，因为当拔出插头(并且插头将被拔出)时，您将进入不断发展的就业市场。 从事过时的技术或过时的产品没有任何好处，请不要这样做！
There is no recovery at this point. Tidy up your LinkedIn profile, polish your resume, and get yourself a new position at a new company with a new product and make sure that this time around.. it is going to be different. Only the best new technologies…
此时没有恢复。 整理您的LinkedIn个人资料，完善您的简历，并使用新产品为自己在新公司中的新职位，并确保这次...将会有所不同。 只有最好的新技术…
It doesn’t have to be like this! In amongst all of the examples of what not to do, there are plenty of teams doing things right these days. Over the next few posts, we’ll take a look at some of the practices and behaviours (technical and otherwise) that can contribute to success, happiness, and general back-slapping all round when a software empire is being built.
不必一定是这样！ 在所有不做事的例子中，如今有很多团队在做正确的事。 在接下来的几篇文章中，我们将了解一些在建立软件帝国时可以为成功，幸福和全面回击做出贡献的实践和行为(技术和其他方面)。
翻译自: https://medium.com/@andy.watt83/the-course-of-software-empire-3ae4556774d1
相关资源：四史答题软件安装包exe