Топ-5: непреднамеренная ложь программистов

Я знаю, я лгал!

Признаюсь. Я был разработчиком и остаюсь им. Разработка  —  больше, чем просто работа. Это  —  состояние души. Невозможно просто перестать писать код. Бросив курить много лет назад, люди всё ещё думают о сигаретах. Так и с разработкой. Для увлечённых людей она становится зависимостью. Будучи разработчиком, я сталкивался со многими ошибками и сложными ситуациями. Я взял на себя роль руководителя группы, а затем роль технического директора. И я изменился и вскоре стал узнавать себя, наблюдая за программистами в моих командах.

Интересно то, как я предотвращал ошибки, подталкивая людей к правильному решению и таким образом избегая подводных камней. Нет, это не сверхспособность. Всё просто: я ошибался больше других. И я расскажу вам, как и о чём лгут разработчики другим людям, но прежде всего  —  самим себе.

Сразу оговорюсь: я не осуждаю никого. Разработка  —  одна из самых сложных областей в мире, особенно когда вы младший сотрудник или работаете в небольшой команде без чёткой структуры. Ложь разработчиков не преднамеренна, её причина  —  сложность работы.

1. Код работал…

Итак, нечто проверенное не работает, когда применяется кем-то другим. Так, возможно, происходит из-за недостаточного тестирования. Или из-за поляризации тестирования: человек, создающий функцию, использует её только одним способом, оставляя конечному пользователю пространство для импровизации. Вопрос не в том, почему что-то, что должно работать, на самом деле не работает. Разработчик не может поверить, что код не работает: он протестировал, программа работала. Почему же теперь не работает? Первое невинное объяснение  —  “Всё работало на моей машине” или даже ”Код работал… вчера”. Ну, никто не отрицает, что эта функция работала когда-то, но факт остаётся фактом: есть ошибка и её нужно исправить.

Программа  —  решение вашей проблемы?

Мы живем в мире, где с помощью программ делается всё. Где программа  —  панацея. Вам нужен график работы? Воспользуйтесь программой. Открыто слишком много вкладок? Снова воспользуйтесь программой. Мы стараемся решать вопросы с помощью приложений или программного обеспечения. И это часть цифровой трансформации. Но программное обеспечение  —  всего лишь инструмент. Просить его решить проблему предприятия  —  всё равно, что просить подводную лодку плыть, цитируя Дейкстру. Молодые разработчики видят мощь ПО, например, CRM или SaaS-решения, и думают, что эти программы решат все проблемы. Но проблемы решается сложнее.

Проблема  —  не вопрос инструментов. Большинство коммерческих решений предлагает гораздо больше необходимого. Речь идет о компании. Прежде чем принять инструмент в работу, вы должны адаптировать процессы и поддержать это изменение через обучение людей, воспитание культуры применения этого инструмента.

Нет никаких решений в электронной коммерции, увеличивающих продажи, если ваш продукт плох или бренд слишком слаб. Нет никакой способствующей продажам CRM, если ваша команда не знает, какой продаёт продукт. Программные решения  —  толчок, поэтому, когда разработчик предлагает их, подумайте о том, какие усилия нужно приложить, чтобы применить решение эффективно.

2. Можно сделать что угодно. Это лишь вопрос времени

Обычно так разработчики отвечают на сложный запрос. Время —  решающий фактор, когда нужно разработать сложное решение. Очевидно, для создания Facebook требуется больше времени, чем для написания простого веб-сайта. Но вот в чём проблема: время  —  не единственное, что имеет значение. Наверное, правильный ответ должен быть таким: “Мы могли бы сделать это, если бы у нас было время, компетенции и соответствующий опыт”. Но часто трудно признать, что нечто необъятно для нас.

3. Не беспокойтесь

Фразы “не волнуйтесь” или “доверьтесь мне” всегда должны вызывать тревогу. Мы думаем о логике причинно-следственных связей. Вы думаете, что ничего не случится, или полагаете, что не было никаких последствий?

Но ваша точка зрения ограничена личными опытом и знаниями. В сложных ситуациях трудно найти более широкий подход. Решение требует глубоких объяснений. Они помогают всем проникнуть в детали и обнаружить реальные проблемы. Вопрос не в доверии. Мы должны доверять каждому коллеге, от самого младшего до того, кто скоро выйдет на пенсию. Я говорю о быстрых ответах или о сведении проблем к минимуму.

4. Так чище

Этот аргумент часто применяется, когда разработчик хочет убедить вас выбрать сложный и долгий вариант. Вы слышите “так чище”, когда других аргументов нет.

Программное обеспечение не о чистоте или загрязнённости. Существуют стабильные, надёжные решения, реализуемые написанием правильного кода, или нестабильное, запутанное программное обеспечение, заставляющее проект бесконтрольно расти.

Хотите убедить человека следовать одному решению, а не какому-то другому, поскольку оно лучше, но дольше в реализации? Дайте ему мотивацию.

5. Ответственность за это несу не я, а другая команда/человек/ещё что-то

Сколько раз я слышал: “Это сделал кто-то другой/это аппаратная проблема/это дело бэкенда”.

Перекладывание ответственности  —  совершенно неверный подход. Когда мы работаем в мульти-командных проектах, совершенствование программного обеспечения  —  общая миссия. Работающее решение всегда оплачивается, а завершение проекта в срок, с надёжным результатом  —  общий интерес. Вот почему перекладывание ответственности  —  не решение проблемы. Показавшись решением в краткосрочной перспективе, оно вернётся бумерангом.

Старший разработчик не просто увлекает других собственными ошибками. Он помогает быстро понять, в чём проблема.

Часто большая часть проекта реализуется фронтендом и бэкендом. В такой ситуации я слышал “это их вина” так много раз, что эти слова стали моим ночным кошмаром. Когда вы говорите “это не моя вина”, я вам доверяю. Но сделайте шаг вперед. Передайте полученную информацию другой команде, а затем будьте доступны для совместного тестирования. Речь идет не об ответственности, но об обязательствах. То же самое случается, когда вы не уверены, где причина проблемы и просто указываете на аппаратное обеспечение. Но как системный администратор поможет вам без нужной информации? И как вы можете быть уверены, что проблема связана с разрешением экрана клиента, а не с ошибкой? А как насчет управления и этим хитрым разрешением? Возможно, небольшими усилиями команда решит вопрос для небольшого набора устройств.

Последнее, главное правило: никогда не доверяйте разработчику, доверяйте работающему коду

Как разработчик, я могу сказать вам: никогда не доверяйте разработчику! Дело не в честности. Просто у разработчиков трудная работа. На этапе между идеей и реализацией произойти может всё, особенно с младшим разработчиком.

В больших проектах ни у кого нет охвата во всём, что необходимо знать. Часто разработчик пишет код, руководствуясь описанием задачи, потому что он ничего не знает о бизнес-логике. Непонимание всегда приводит к ошибкам. Лучший способ доверять разработчику и эффективно работать с ним  —  понимать его работу, быть на одной стороне. Объяснять, почему ему нужно делать что-то.

Ориентированный на решение задач подход  —  сделай это прямо сейчас  —  может работать в строго структурированном проекте с защищёнными от ошибок описаниями задач. Но в реальном мире лучше работать вместе. Доверяйте коду! Спасибо, что прочитали!

Перевод статьи Daniele Fontani: 5 Common Lies That Developers Tell