Почему вы никогда не должны писать плохой код, будучи инженером-программистом
13 февраля 2022 г.A romp through the misadventures that can be caused by quickly built proof of concepts and hacks, in all areas of programming.
Обзор злоключений, которые могут быть вызваны быстро построенными доказательствами концепций и хаками во всех областях программирования.
"We just need a quick hack as a proof of concept"
«Нам просто нужен быстрый взлом в качестве доказательства концепции»
The Setup
Установка
As developers, we will have been in the position where we have been told "just build us a quick working prototype of x to woo the client". Or perhaps "we just need a quick proof of concept of Y so the boss can get the idea" - the budgets are always none existent, so is the brief, and the deadline was always yesterday. But you are assured it is just a proof of concept, so there is nothing to worry about if it's a bit janky.
Как разработчики, мы были в положении, когда нам говорили: «Просто создайте нам быстрый рабочий прототип x, чтобы добиться клиента». Или, возможно, «нам просто нужно быстрое доказательство концепции Y, чтобы босс мог понять идею» - бюджеты всегда отсутствуют, как и бриф, а крайний срок всегда был вчера. Но вас уверяют, что это всего лишь доказательство концепции, так что не о чем беспокоиться, если это немного дергано.
Although these words give you some trepidation, you are eager to please the paymaster. So you start building away with all your might. It's only a proof of concept, so you throw in a few bleeding-edge libraries that you have been gagging to try out, and you cut a few corners here and there. The software doesn't quite have the test coverage you want, and you had to disable some security features you didn't really have the time to understand to get it working in a staging environment. There are also many ill-thought-out chunks of code written where time was the priority. But it's alright because it is just a proof of concept.
Хотя эти слова вызывают у вас некоторый трепет, вы стремитесь угодить казначею. Итак, вы начинаете строить изо всех сил. Это всего лишь доказательство концепции, так что вы добавляете несколько передовых библиотек, которые вы так долго пытались опробовать, и тут и там срезаете несколько углов. Программное обеспечение не имеет необходимого тестового охвата, и вам пришлось отключить некоторые функции безопасности, на изучение которых у вас не было времени, чтобы заставить его работать в тестовой среде. Есть также много непродуманных кусков кода, написанных там, где время было приоритетом. Но это нормально, потому что это просто доказательство концепции.
==Except, proof of concepts tends to have a habit of becoming production code.==
==За исключением того, что доказательство концепций имеет привычку превращаться в производственный код.==
The Misadventure
Злоключения
It happens something like this. The paymaster loves the proof of concept and has a really pressing reason to get it into production ASAP. No need to rewrite from scratch, though, as clearly you have built it already? The paymasters are swept up in the facade of a working product, but they are unaware of the questionable things you had to do to make the "proof of concept". They are unaware of the string and bubble gum that's holding it all together.
Бывает как-то так. Кассир любит доказательство концепции, и у него есть очень веская причина запустить его в производство как можно скорее. Однако нет необходимости переписывать с нуля, поскольку вы уже создали его? Плательщики заинтересованы фасадом работающего продукта, но они не знают о сомнительных вещах, которые вы должны были сделать, чтобы сделать «доказательство концепции». Они не подозревают о веревке и жевательной резинке, которая держит все это вместе.
The poorly tested, ill-thought-out code, complete with unstable dependencies and security issues, makes its way into production and becomes the technical debt of tomorrow. With a vague promise, "we can take some time to improve it soon", only then to find its way to the tail-end of the backlog, where it sits like a ticking time bomb, all the while the business becomes ever more reliant on it.
Плохо протестированный, непродуманный код с нестабильными зависимостями и проблемами безопасности попадает в производство и становится техническим долгом завтрашнего дня. С расплывчатым обещанием: «Мы можем потратить некоторое время на то, чтобы улучшить его в ближайшее время», только затем, чтобы найти свой путь к хвостовой части невыполненной работы, где он сидит как бомба замедленного действия, в то время как бизнес становится все более зависимым. в теме.
This is an act of software development theatre that runs so frequently that it's cliche. I have seen it lead to service outages, security breaches, data leaks and technical debt so deep that you will struggle to find staff willing to service it.
Это акт театра разработки программного обеспечения, который проходит так часто, что становится клише. Я видел, как это приводило к перебоям в обслуживании, нарушениям безопасности, утечкам данных и техническому долгу настолько, что вам будет сложно найти персонал, готовый его обслуживать.
The Cure
Лечение
==Humans have an extraordinary ability to put short term gains in front of long term consequences.== This is compounded by the fact that we live in a time where most stakeholders are none technical. Code is not a physical thing they can reach out and touch, so they take it for granted. They cannot distinguish a secure, well-made piece of software from one that will become technical debt. They cannot grasp how complex modern software development and maintenance can be. If they are presented with a working proof of concept, they assume it's good to go, and their financial objectives will weigh stronger on their mind than your warning that the software should never see the light of day.
==У людей есть необыкновенная способность ставить краткосрочные выгоды выше долгосрочных последствий.== Это усугубляется тем фактом, что мы живем во времена, когда большинство заинтересованных сторон не разбираются в технических вопросах. Код — это не физическая вещь, до которой они могут дотянуться и потрогать, поэтому они принимают его как должное. Они не могут отличить безопасную, хорошо сделанную часть программного обеспечения от того, что станет техническим долгом. Они не могут понять, насколько сложной может быть разработка и обслуживание современного программного обеспечения. Если им представить рабочее доказательство концепции, они решат, что это хорошо, и их финансовые цели будут иметь для них большее значение, чем ваше предупреждение о том, что программное обеспечение никогда не увидит свет.
For this reason, as developers, we must take responsibility for ensuring that we do not produce poor quality code or quick hacks to please our paymasters. Even if it is just for a "proof of concept" or as part of a hackathon where you are supplied with free pizza for giving up your weekend. We must never write code assuming that it will not be launched into production, because one day, it probably will.
По этой причине, как разработчики, мы должны взять на себя ответственность за то, чтобы мы не создавали код низкого качества или быстрые взломы, чтобы угодить нашим казначеям. Даже если это просто «доказательство концепции» или часть хакатона, где вам бесплатно дают пиццу за то, что вы отказались от выходных. Мы никогда не должны писать код, предполагая, что он не будет запущен в производство, потому что однажды он, вероятно, будет запущен.
First published here
Впервые опубликовано здесь
Оригинал