Хорошая дискуссия о лжи, которую иногда говорят разработчики
Привет Питер,
спасибо за этот ответ. Очень подробно и видно, что вы дочитали статью до конца, за это большое спасибо!
Я также очень рад, что вы привели некоторые крайние случаи (крайние, но из реального мира).
Я думаю, что как разработчик мы всегда должны быть прозрачными и четко объяснять, в чем проблема, брать на себя ответственность (но не более того) и быть готовыми сотрудничать с другими для создания лучшего программного обеспечения.
Сказал, что постараюсь ответить на ваши вопросы, чтобы вы знали, что я о них думаю и как я постараюсь их решить.
«Это работало на моем локальном компьютере с Windows, но не на сервере с Linux. Когда я начинал, я просил рабочую станцию с Linux, и вы сказали «нет». Могу ли я получить ее сейчас?
Это хороший вопрос. Здесь есть технические и процедурные вопросы, которые необходимо решать. В этом случае вы не скажете «это сработало на моем локальном компьютере», но «я не смог воспроизвести правильное поведение на моем локальном компьютере из-за плохого процесса, который мы разработали, поэтому у нас есть выбор: продолжать в том же духе, с ошибками и неэффективностью, или потратьте некоторое время на поиск решения, которое улучшит наш процесс и сэкономит время и деньги». В настоящее время существует множество технических решений для работы без ОС-зависимых (т.е. контейнеров), так что здесь нет оправданий. То же самое с инструментами DevOps. Таким образом, вы переносите проблему с ответственности за тестирование чего-то, что вы не можете протестировать, на обработку проблем. Решение этого конфликта создаст лучшую среду.
«Программное обеспечение — это решение вашей проблемы» для этой конкретной проблемы, с которой мы продолжаем бороться, и которую было очень легко решить в моей предыдущей компании. Если мы немного изменим наш процесс, мы сможем использовать это готовое решение. Вы знаете, я никогда не говорил, что речь идет только о программном обеспечении, верно?
Это всегда компромисс. Если программное обеспечение само по себе решает 95% ваших потребностей, и вам нужно потратить 5% бюджета на настройку программного обеспечения и достижение полного решения, это правильно. Часто, особенно при использовании продуктов крупных поставщиков, вы рискуете потратить больше на те 5%, которые вам нужны, чем на создание полностью пользовательского приложения с нуля, адаптированного к потребностям клиента. Иногда клиенты продвигают решение, которое они продают, иногда разработчики продвигают единственный продукт, на котором они обучены. В других случаях это просто ползучесть… трудно сказать. Но с моей точки зрения, учитывая эволюцию рынка разработки, каждый разработчик всегда должен быть скорее небольшим архитектором программного обеспечения и проектировать решение на основе проекта, а не пытаться использовать всегда одно и то же лекарство от всех болезней.
"Мы можем сделать все, это просто вопрос времени", потому что когда я в последний раз сказал, что невозможно нарисовать 7 красных перпендикулярных линий синими чернилами, вы сказали мне, что я не должен быть таким негативным. Технически 1 миллион лет — это «всего лишь» вопрос времени.
Это еще один хороший момент. Главное, чтобы было прозрачно. 7 перпендикулярных линий невозможны? Попробуйте для начала объяснить почему, а потом сделайте вывод, что это невозможно. Чем больше менеджер понимает, какая сложность скрывается за капотом, тем больше они смогут вам доверять. Конечно, если ваш менеджер не послушает… он заплатит команде из 7 человек за бесконечное время, пытаясь провести 7 перпендикулярных линий.
"Не беспокойтесь", как в прошлый раз, когда я пытался объяснить сложную проблему, и вы назначили больше людей, чтобы "помочь". Нет, это не сделало проблему менее сложной.
Решение также в случае может состоять в том, чтобы объяснить, в чем сложность и как вы собираетесь ее решать. Это убедит менеджера в том, что вы сможете решить ее самостоятельно и в случае каких-то незапланированных вопросов вы не окажетесь в ситуации, когда вы сказали «не волнуйтесь» и возникли проблемы.
Чище, если мы потратим полдня больше на размышления о типичных пограничных случаях, чем на то, чтобы просто надеяться на лучшее, а через 3 месяца, когда я буду работать над другим проектом, вы попросите меня приоритетное оперативное исправление.
Просто объясните это так. Менеджер поймет или заплатит за последствия (и в этом случае вы будете рядом, чтобы помнить его выбор).
«Ответственность несет другая команда/человек/вещь» — я, конечно, могу помочь в расследовании, как только мой трехнедельный запрос на доступ к производственным журналам будет выполнен.
Вы не можете брать на себя ответственность за другие команды, вам нужна помощь для завершения расследования. В этом процессе все должны быть отзывчивыми и мотивированными. Во многих случаях небольшое усилие с нашей стороны, превышающее строго необходимое, может помочь смазать колеса и в долгосрочной перспективе также может сэкономить время (каждая команда по пинг-понгу требует времени и умственных усилий).
«Последнее важное правило: никогда не доверяйте разработчику, доверяйте работающему коду», если только вы не хотите построить хорошиедолгие рабочие отношения ;)
Да, ты прав. Личные отношения имеют основополагающее значение. Мне посчастливилось работать в средней ИТ-компании, где большинство из нас, коллег, также являются друзьями, это фантастика. Поэтому важно никого не обвинять и считать, что все работают с добрыми намерениями. Кстати, то, что написано в исходниках, и есть настоящий источник правды.
Если вы хотите связаться с нами, вы можете присоединиться к моей сети Linkedin https://www.linkedin.com/in/daniele-fontani/ или подписаться на мой средний аккаунт https://medium.com/@daniele.fontani. .
