Источник: Nuances of Programming
Плохого кода не существует.
Просто он очень эффективно делает не то, что нужно.
Слово “эффективный” означает “способный достичь результата”. Однако у него есть разные смысловые оттенки значения. В одном случае оно значит “достигающий желаемых результатов”, а в другом — “способный достичь желаемых результатов без излишних затрат материалов, времени и сил”.
Теперь о ваших ошибках.
Все с ними нормально. Просто код делает не то, что нужно. Выполняемое им действие не планировалось. Но именно его он и совершает.
Как в этом случае быть?
Кто-то не отправляет код
Разработчики понимают, что функционально код не выполняет ожидаемое действие, поэтому какое-то время они его дорабатывают до требуемого результата. Это при условии, что им известно, как на самом деле он должен работать. Если они действительно знают (или думают, что знают), то добавляют тесты или даже используют методологию разработки через тестирование для получения нужного состояния. Только убедившись в том, что достигнутый результат соответствует ожиданиям, они его отправляют.
Кто-то отправляет
Возможно, они знают, что код не работает должным образом. И просто надеются, что никто не заметит. Иногда так и происходит.
Кого-то вынуждают отправлять
Имеются в виду ситуации, когда работа измеряется не достигнутым результатом, а объемом выполненного. Разработчики тратят X количество своих рабочих часов. “Время вышло! Так и быть, отправляем”, — говорит руководитель проекта, SCRUM- или SCUM-мастер. Образно говоря, кнут сломлен о спины трудящихся, а вместе с ним и их воля. Подначальные повязаны словом, и нет ничего более святого и обязывающего, чем оценки сложности задач (англ. story point) или “выгорание” в бешеном темпе. В пору вызывать психолога-криминалиста и фиксировать всеобщее психическое расстройство под названием пиромания.
Кто-то предоставляет пользователям возможность выявлять проблемы
Отличный подход при условии мониторинга и автоматизации цикла. Но сейчас речь не об этом.
Я говорю о таких по-настоящему плохих парнях, которые издеваются над пользователем и не обеспечивают автоматизацию предупреждений об имеющихся проблемах. Нет, они вынуждают его обращаться к ним. Это и есть признак истинного верного пользователя, который осмеливается бороться со службой поддержки. Бесплатно, без какой-либо выгоды от этого противостояния.
Истинный пользователь. Тот, перед кем благоговеют организации. Тот, кем можно гордиться. Такие пользователи закаляются в борьбе. Однако настоящая причина их появления — грубый непрофессионализм.
А надо лишь задаться вопросом: “Почему наш код не делает то, что нужно?”.
Кто-то не знает
Такие разработчики не имеют точного представления об ожидаемом результате. Они доверяют своим руководителям, зачастую необдуманно. Иногда такое руководство напускает туману, продумывая и создавая массивную подробную организационную схему, которая оформляется необычными художниками и включает длинные наименования уважаемых заказчиков. Этот туман рассеивается, как только проводится реорганизация. Руководству надо доверять.
Другие стараются экспериментировать и создавать короткие циклы между пользователями, представителями команды и руководителями проектов. Для многих такой подход оказывается весьма успешным. Как всегда, существует огромная разница между теми, кто реально делает, и теми, кто только создает видимость дел. Много разговоров, но мало дел.
Притворство не скроешь. Это как фальшивый бой между учеными: красивые словесные обороты и несогласованность движений тела и силы.
Кто-то знает
Есть и такие, кому удается создавать что-то ценное и делать это хорошо. Но в эту категорию попадают также и все те, кто сталкивается с разделением и политизацией своей организации. То, что одна сторона считает разумным, другая воспринимает как бред. Ничего хорошего дезинтеграция не приносит. Однако это обычное явление.
Люди на 99% шимпанзе. Помните об этом и будете спокойно спать по ночам, как я.
Вам не нужны напоминания, например в виде списка 50 наихудших изобретений в журнале Time (включая такие мерзости, как субстандартная ипотека и асбест) или перечня неудачных продуктов в Музее неудач. Если вы IT-специалист, просто хорошо делайте свою работу.
Именно этим занимается большинство из нас. Мы стараемся создавать продукт, который правильно выполняет поставленную перед ним задачу.
А что правильно для нас? Похоже, этого никто не знает.
И мы опять стоим на перекрестке всех дорог.
Читайте также:
Перевод статьи Mikael Vesavuori: There Is No Bad Code