Я знаю, я лгал!
Признаюсь. Я был разработчиком и остаюсь им. Разработка — больше, чем просто работа. Это — состояние души. Невозможно просто перестать писать код. Бросив курить много лет назад, люди всё ещё думают о сигаретах. Так и с разработкой. Для увлечённых людей она становится зависимостью. Будучи разработчиком, я сталкивался со многими ошибками и сложными ситуациями. Я взял на себя роль руководителя группы, а затем роль технического директора. И я изменился и вскоре стал узнавать себя, наблюдая за программистами в моих командах.
Интересно то, как я предотвращал ошибки, подталкивая людей к правильному решению и таким образом избегая подводных камней. Нет, это не сверхспособность. Всё просто: я ошибался больше других. И я расскажу вам, как и о чём лгут разработчики другим людям, но прежде всего — самим себе.
Сразу оговорюсь: я не осуждаю никого. Разработка — одна из самых сложных областей в мире, особенно когда вы младший сотрудник или работаете в небольшой команде без чёткой структуры. Ложь разработчиков не преднамеренна, её причина — сложность работы.
1. Код работал…
Итак, нечто проверенное не работает, когда применяется кем-то другим. Так, возможно, происходит из-за недостаточного тестирования. Или из-за поляризации тестирования: человек, создающий функцию, использует её только одним способом, оставляя конечному пользователю пространство для импровизации. Вопрос не в том, почему что-то, что должно работать, на самом деле не работает. Разработчик не может поверить, что код не работает: он протестировал, программа работала. Почему же теперь не работает? Первое невинное объяснение — “Всё работало на моей машине” или даже ”Код работал… вчера”. Ну, никто не отрицает, что эта функция работала когда-то, но факт остаётся фактом: есть ошибка и её нужно исправить.
Программа — решение вашей проблемы?
Мы живем в мире, где с помощью программ делается всё. Где программа — панацея. Вам нужен график работы? Воспользуйтесь программой. Открыто слишком много вкладок? Снова воспользуйтесь программой. Мы стараемся решать вопросы с помощью приложений или программного обеспечения. И это часть цифровой трансформации. Но программное обеспечение — всего лишь инструмент. Просить его решить проблему предприятия — всё равно, что просить подводную лодку плыть, цитируя Дейкстру. Молодые разработчики видят мощь ПО, например, CRM или SaaS-решения, и думают, что эти программы решат все проблемы. Но проблемы решается сложнее.
Проблема — не вопрос инструментов. Большинство коммерческих решений предлагает гораздо больше необходимого. Речь идет о компании. Прежде чем принять инструмент в работу, вы должны адаптировать процессы и поддержать это изменение через обучение людей, воспитание культуры применения этого инструмента.
Нет никаких решений в электронной коммерции, увеличивающих продажи, если ваш продукт плох или бренд слишком слаб. Нет никакой способствующей продажам CRM, если ваша команда не знает, какой продаёт продукт. Программные решения — толчок, поэтому, когда разработчик предлагает их, подумайте о том, какие усилия нужно приложить, чтобы применить решение эффективно.
2. Можно сделать что угодно. Это лишь вопрос времени
Обычно так разработчики отвечают на сложный запрос. Время — решающий фактор, когда нужно разработать сложное решение. Очевидно, для создания Facebook требуется больше времени, чем для написания простого веб-сайта. Но вот в чём проблема: время — не единственное, что имеет значение. Наверное, правильный ответ должен быть таким: “Мы могли бы сделать это, если бы у нас было время, компетенции и соответствующий опыт”. Но часто трудно признать, что нечто необъятно для нас.
3. Не беспокойтесь
Фразы “не волнуйтесь” или “доверьтесь мне” всегда должны вызывать тревогу. Мы думаем о логике причинно-следственных связей. Вы думаете, что ничего не случится, или полагаете, что не было никаких последствий?
Но ваша точка зрения ограничена личными опытом и знаниями. В сложных ситуациях трудно найти более широкий подход. Решение требует глубоких объяснений. Они помогают всем проникнуть в детали и обнаружить реальные проблемы. Вопрос не в доверии. Мы должны доверять каждому коллеге, от самого младшего до того, кто скоро выйдет на пенсию. Я говорю о быстрых ответах или о сведении проблем к минимуму.
4. Так чище
Этот аргумент часто применяется, когда разработчик хочет убедить вас выбрать сложный и долгий вариант. Вы слышите “так чище”, когда других аргументов нет.
Программное обеспечение не о чистоте или загрязнённости. Существуют стабильные, надёжные решения, реализуемые написанием правильного кода, или нестабильное, запутанное программное обеспечение, заставляющее проект бесконтрольно расти.
Хотите убедить человека следовать одному решению, а не какому-то другому, поскольку оно лучше, но дольше в реализации? Дайте ему мотивацию.
5. Ответственность за это несу не я, а другая команда/человек/ещё что-то
Сколько раз я слышал: “Это сделал кто-то другой/это аппаратная проблема/это дело бэкенда”.
Перекладывание ответственности — совершенно неверный подход. Когда мы работаем в мульти-командных проектах, совершенствование программного обеспечения — общая миссия. Работающее решение всегда оплачивается, а завершение проекта в срок, с надёжным результатом — общий интерес. Вот почему перекладывание ответственности — не решение проблемы. Показавшись решением в краткосрочной перспективе, оно вернётся бумерангом.
Старший разработчик не просто увлекает других собственными ошибками. Он помогает быстро понять, в чём проблема.
Часто большая часть проекта реализуется фронтендом и бэкендом. В такой ситуации я слышал “это их вина” так много раз, что эти слова стали моим ночным кошмаром. Когда вы говорите “это не моя вина”, я вам доверяю. Но сделайте шаг вперед. Передайте полученную информацию другой команде, а затем будьте доступны для совместного тестирования. Речь идет не об ответственности, но об обязательствах. То же самое случается, когда вы не уверены, где причина проблемы и просто указываете на аппаратное обеспечение. Но как системный администратор поможет вам без нужной информации? И как вы можете быть уверены, что проблема связана с разрешением экрана клиента, а не с ошибкой? А как насчет управления и этим хитрым разрешением? Возможно, небольшими усилиями команда решит вопрос для небольшого набора устройств.
Последнее, главное правило: никогда не доверяйте разработчику, доверяйте работающему коду
Как разработчик, я могу сказать вам: никогда не доверяйте разработчику! Дело не в честности. Просто у разработчиков трудная работа. На этапе между идеей и реализацией произойти может всё, особенно с младшим разработчиком.
В больших проектах ни у кого нет охвата во всём, что необходимо знать. Часто разработчик пишет код, руководствуясь описанием задачи, потому что он ничего не знает о бизнес-логике. Непонимание всегда приводит к ошибкам. Лучший способ доверять разработчику и эффективно работать с ним — понимать его работу, быть на одной стороне. Объяснять, почему ему нужно делать что-то.
Ориентированный на решение задач подход — сделай это прямо сейчас — может работать в строго структурированном проекте с защищёнными от ошибок описаниями задач. Но в реальном мире лучше работать вместе. Доверяйте коду! Спасибо, что прочитали!
Читайте также:
- 4 простых способа рефакторинга кода
- Комментарий в коде написать - всё равно, что проиграть
- Учимся программированию как Эйнштейн
Перевод статьи Daniele Fontani: 5 Common Lies That Developers Tell
