Как объяснить программисту бизнес-приоритеты?
У меня постоянные разногласия с программистом по поводу качества кода. Он настаивает на том, чтобы весь его код был написан в соответствии с высочайшими стандартами (т. е. чтобы он выглядел точно так же, как примеры в учебниках по стилям кодирования), независимо от того, как это влияет на функциональность. Я, с другой стороны, считаю более важным, чтобы написанный код отвечал потребностям бизнеса, т. е. чтобы он работал эффективно, не требовал слишком много времени для разработки и был разумно удобен в сопровождении.
Недавно у нас был спор о том, что конкретный сценарий, который он написал , выглядит великолепно, идеально оформлен и работает точно так, как в различных книгах описывается лучшая практика. У меня есть альтернативная версия, которая была написана с использованием так называемого «анти-шаблона», и он настаивает на том, что это абсолютно ужасный код, который никогда не следует использовать. Тем не менее, он также работает примерно в пять раз быстрее.
Я пытался убедить его, что ему нужно использовать этот анти-шаблон, даже если это «плохой код», потому что быстро работать важнее, чем хорошо выглядеть. Он не согласен и категорически отказывается рассматривать возможность написания любого кода, который не соответствует признанным «хорошим» шаблонам стиля, даже если это означает, что его написание занимает больше времени и не работает так же хорошо.
Пример: он хочет использовать ORM для доступа к базе данных. Для одного особенно сложного запроса ORM плохо его оптимизирует, и его выполнение занимает более 4 часов. Я напрямую вставил немного необработанного SQL и сократил время выполнения до 30 секунд. Он очень сильно возражал, говоря, что писать необработанные sql-запросы напрямую — плохая практика, и мы всегда должны использовать ORM. Теперь он отказывается работать над этой частью программы.
Я пытался объяснить, что иметь хорошо работающую программу важнее, чем иметь красивый код, но он просто говорит «нет, это не так» и продолжает писать свой стильный, неэффективный код, который мне иногда приходится плохо переписывать. прежде чем его можно будет использовать.
На данный момент мы находимся в плохом положении, потому что он отказывается идти на компромисс со своими стандартами, а это означает, что все, что он делает, должно быть проверено мной и в некоторых случаях изменено, чтобы убедиться, что оно соответствует потребностям бизнеса, и не только его эстетические стандарты.
Как я могу убедить его изменить приоритеты и поставить цели бизнеса выше красоты своего кода?
Редактировать: Стефан Коласса предложил мне включить это: технически я его менеджер, но мы такая маленькая компания (~ 10 человек), что я также программирую, и в то же время я своего рода его коллега, что просто делает его немного сложнее, и у нас нет фиксированных организационных стандартов или процедур разрешения конфликтов.
Я бы не стал диктовать ему стиль кодирования, пусть делает так, как хочет. Если производительность является фактическим задокументированным бизнес-требованием, и он не может его выполнить, сообщите ему об этом.
Если он продолжает не выполнять требования бизнеса, значит, он не справляется со своей работой, начните давать ему официальные устные предупреждения, затем письменные предупреждения, а затем отпустите его, если придется.
Похоже, на вас работает примадонна или, того хуже, Мишель Анджело. Как давно он занимается программированием? Я задаю этот вопрос, потому что между программированием и программированием огромная разница. Те, кто был в окопах какое-то время, могут сказать ему, что совершенство может быть уродливым.
Его код может быть хорош как учебник, но реальность такова, что этот код должен выполняться, а код, для выполнения которого требуется 4 часа, а не 30 секунд, — этот код вряд ли можно описать как работающий. Я занимаюсь разработкой программного обеспечения, но со стороны DevOps Дома: если код не масштабируется, этот код никуда не годится, независимо от того, насколько хорошо этот код написан и задокументирован. И отказоустойчивый, поддерживаемый код, который плохо работает, никуда не годится. Что касается меня, то либо он понимает, что я говорю, либо его нет. У него есть свобода писать код в своем собственном стиле, но этот код ДОЛЖЕН работать.
Не говорите ему идти против шаблона. Скажите ему, каково ваше требование, дайте ему крайний срок и дайте ему свободу действий, чтобы выяснить, как его выполнить. Учитывая, насколько он увлечен тем, что его код написан как учебник, у него есть все стимулы удовлетворить ваши требования, сохраняя при этом свой код как учебник, и это неплохо.
Как его менеджер, вам придется повысить его статус и установить закон. Вам придется сказать ему, что он несет ответственность за выполнение своего кодекса, и вы должны убедиться, что у вас есть полномочия от вышестоящего руководства, чтобы обеспечить соблюдение этой ответственности. Я дам ему стимул давить на него: как его менеджер, ВЫ будете нести ответственность, если его код не будет работать. Поставьте его на место, потому что, если вы этого не сделаете, первым, за кем начнет охотиться ваше высшее руководство, будете вы.
Вы говорите, что вы "технически" его менеджер. Ну, либо ты его менеджер, либо нет. Прими решение (*)
Если вы его руководитель, то он подотчетен вам так же, как вы подотчетны своему руководству. В таком случае время для объяснений, которые он не будет слушать, закончилось. Неоспоримым требованием является то, что код должен работать, и он должен соответствовать этому требованию. Вот и все.
(*) Я столкнулся с похожей проблемой еще в 1987 году с инженером-экологом, который не следовал нашим передовым методам, изложенным вашим покорным слугой. А поскольку мой титул был официально равен его титулу, он отмахивался от всего, что я говорил. Я устроил трехстороннее свидание между ним, боссом отдела и мной, где я изложил в недвусмысленных выражениях, каковы последствия несоблюдения нашего процесса. Начальник приказал ему подчиниться, а потом сказал мне пару слов наедине о моей жесткости. Я не возражал против упрека - единственное, что имело значение для меня, это то, что я добивался согласия, а он больше не просверливал днище нашего корабля. Эскалация до высшего руководства была не очень приятной, но она сработала. Это все, что имело для меня значение.
Как старший разработчик, вы оба правы. Это поиск баланса, к которому вы должны стремиться.
Во-первых, с вашей стороны ваши требования должны быть четко детализированы. Я бы рекомендовал использовать подход разработки, основанной на поведении (BDD) . Это позволяет детализировать ваши требования и убедиться, что программное обеспечение им соответствует.
В настоящее время рекомендуется следовать практике разработки через тестирование (TDD). В этом случае разработчик пишет «достаточно» кода для решения проблемы — написав неудачные тесты и заставив их пройти. Эти определения BDD будут отправной точкой. Дальнейшие модульные тесты будут исключены, но как только все тесты BDD станут зелеными, вы можете быть уверены, что требования выполнены.
На протяжении всего этого ожидается, что вы продолжите диалог — обычно в начале и в конце разработки. Это гарантирует, что обе стороны понимают требования, устраняя любую двусмысленность. Кроме того, в этом разговоре можно было бы обозначить важность или ценность запроса.
Важно, чтобы код был ясным и понятным для будущей разработки и обслуживания. Однако следует соблюдать баланс между постоянной полировкой и предоставлением ценности.
Если вы и он этого не сделали — я бы посоветовал прочитать «Чистый код: руководство по Agile Software Craftsmanship» Роберта К. Мартина .
Что касается ваших дебатов об ORM, у ORM есть свои плюсы и минусы. Как вы подчеркнули, они могут быть медленными и неэффективными при плохой настройке . Кроме того, написание встроенного SQL может добавить дополнительную связь между базой данных и кодом. Почему бы просто не вызывать хранимые процедуры ?
Вероятно, есть столько же статей о том, почему вы должны, чем о том, почему вы не должны использовать ORM в Интернете. Однако запрос, выполнение которого занимает четыре часа, особенно если его можно оптимизировать до 30 секунд, неприемлем.
В качестве последней мысли - это ваш единственный разработчик? Может быть, ему было бы полезно заниматься парным программированием с другими? Может быть, он просто не подходит для работы в вашей компании?
Во-первых, вы оба не правы. Он ошибается, настаивая на том, что код выглядит хорошо, и вы ошибаетесь, настаивая на использовании антишаблона. Подходящий способ разработки программного обеспечения лежит где-то посередине двух ваших идеологий. Можно следовать лучшим практикам и по-прежнему иметь код, который можно быстро разработать, который имеет хорошую производительность и удобен в сопровождении, и это то, к чему вам обоим нужно добраться.
Есть много способов сделать это. Похоже, ваш разработчик из тех, кто видит «лучшие практики» и никогда не отклоняется от них, даже когда лучшие практики меняются. Лучший способ исправить это — найти лучшую передовую практику для удовлетворения ваших потребностей, а затем вы оба должны ей следовать.
Важно не зацикливаться на терминологии или точной методологии, и похоже, что это может стать проблемой для вашего разработчика. Никакая передовая практика не годится, если вы не можете ее реализовать или если она приводит к плохой производительности кода. Вместо того, чтобы спорить со своим разработчиком, вы должны попытаться понять, почему он отказывается писать код, который не выглядит хорошо, а затем подтолкнуть его к практике, которая позволит ему писать хорошо выглядящий код, а также хорошо работающий код.
Если вы не считаете, что форматирование является проблемой, просто введите в Google фразу «пробел или программирование с отступом» и удивитесь всему этому. То, как форматируется код, во многом определяет его удобство сопровождения в долгосрочной перспективе. Кроме того, ознакомьтесь с некоторыми из этих книг , рекомендованных Джеффом Этвудом. Все они хороши и помогут вам лучше понять, почему вы так же неправы, как и ваш разработчик.
В конечном счете, вам нужно перестать конкурировать с разработчиком. Вы находитесь на противоположных сторонах спектра, и если вы оба просто скажете: «Я прав», вам никогда не станет лучше. Вы должны попытаться понять, откуда он исходит, и, надеюсь, он увидит ваши усилия, а затем попытается понять, откуда вы исходите. Возможно, если вы попытаетесь оптимизировать 4-часовой запрос, используя другую «лучшую практику», которая все еще выглядит хорошо, он поймет лучше.
Некоторые ссылки на несколько методологий разработки:
Есть много других. Некоторые будут хорошими, некоторые будут плохими. Некоторые больше не используются по какой-то причине. Наша работа оплатила семинар по Agile, на котором мы рассмотрели Agile в целом и выбрали подмножество этих принципов для реализации. Это помогло нам во многих отношениях, а также помешало нам в паре. Это намного лучше, чем то, что мы делали раньше, но в нашем случае проблема была связана с процессом.
Мы обнаружили, что больше всего нам помогло научиться концентрироваться на минимально жизнеспособном продукте. Это означает, что мы сначала даем клиенту наименьшую часть функциональности для удовлетворения его потребностей, а затем расширяем ее по мере необходимости. Это предотвращает раздувание программного обеспечения вещами, которые клиент никогда не просил.
Я никогда не встречал компетентного человека в какой-либо области, который ценит строгое соблюдение правил и форм выше результатов и функций. Если завернуть себя в флаг — первое прибежище негодяя, то завернуть себя в набор жестких правил — первое прибежище некомпетентного.
Я был бы обеспокоен тем, что вы застряли с программистом из «культа груза» или «поваренной книги», то есть с тем, кто не понимает своего дела, а просто подражает примерам других.
Возможно, он цепляется за шаблоны и форматирование с таким упорством, чтобы замаскировать, что на самом деле не понимает нюансов того, когда какие шаблоны и практики использовать. Он использует моральные аргументы о личной и профессиональной честности, которые, как он утверждает, требуют от него писать код «Единственным верным способом», чтобы скрыть тот факт, что он не знает другого способа написания кода.
Я думаю, это довольно ясно, потому что все настоящие заявления о « лучших практиках » всегда сопровождаются оговоркой « для следующих обстоятельств или параметров ». Не существует такого универсального набора «лучших практик», который всегда будет оптимальным выбором. для каждого проекта.
В частности, передовая практика может сильно различаться между небольшими магазинами, такими как ваш, и крупными учреждениями. В небольших магазинах основными требованиями являются скорость, гибкость, исполнение и, прежде всего, доставка. Если вы малы и не шипперите, вы умрете. Такие вопросы, как форматирование и стиль, не имеют большого значения, потому что люди, которые поддерживают код, скорее всего, будут теми, кто его написал. Небольшие магазины выполняют больше работы «под ключ», где ручная настройка производительности является важной добавленной стоимостью.
И наоборот, в крупных корпоративных или государственных учреждениях основными требованиями часто являются интеграция в более крупные проекты в сочетании с долгосрочной поддержкой отдельными лицами, годами позже, которые не писали код. Производительность часто не является такой большой проблемой, потому что большие ребята часто могут просто добавить больше оборудования для решения проблемы.
Мне кажется, что ваш кодер зациклен на «лучших методах» программирования для крупных организаций, а не на лучших методах программирования для небольших компаний. Большинство книг и даже формальное образование в наши дни, кажется, сосредоточены на этом рынке, поэтому, если он на самом деле только имитирует то, что он прочитал, он может не понять, что «лучшие практики» меняются вместе с окружающей средой.
Я думаю, вам нужно проверить его, чтобы выяснить, какой именно программист он на самом деле, т.е. является ли он высокомерным, придурком primo uomo с навыками или некомпетентным, который прячется за фасадным перфекционизмом. Прикажите ему создать оптимизированный вручную код, как вы написали, просто посмотрите, сможет ли он на самом деле это сделать.
Если у него есть навыки, но он просто ценит форму, а не функцию, то вы, возможно, сможете привести его к осознанию того, что не существует такой вещи, как универсальные «лучшие практики» и определенно не существует такой вещи, как универсальное «лучшее форматирование».
Но держу пари, вы обнаружите, что ему не хватает навыков. В лучшем случае он программист поваренной книги, а не хакер-ковбой, который может работать без структуры и правил, если придется (даже если ему это не нравится). Держу пари, вам придется его отпустить.
"He maybe clinging to patterns and formatting with such tenacity to disguise that he doesn't actually understand the nuances of when to use which patterns and practices."
Не существует такой вещи, как одна «лучшая практика». Лучшие технологии и шаблоны кодирования сильно различаются для разных задач. Используйте лучший инструмент для работы; не меняйте работу, чтобы соответствовать инструменту. Это ключ, который ОП должен понять, чтобы его программист понял. Бывают случаи, когда ускорение в 10 000 раз не имеет значения, а бывают случаи, когда ускорение на 1% имеет большое значение. Хорошие инженеры знают разницуКак объяснить программисту бизнес-приоритеты?
Нет, по крайней мере, для этого программиста, который не хочет этого слышать. Он не менеджер и, по-видимому, не хочет, чтобы ему разрешали принимать решения или действовать без указаний, направленных на улучшение бизнеса.
Ему нужны входные данные в виде запросов функций, а выходные данные — в виде идеального кода.
Ваше желание научить его принимать решения или заботиться о бизнесе не является плохим желанием, но в этом случае вам следует отложить это желание в сторону и сосредоточиться на бизнес-приоритетах — сделать этого программиста продуктивным.
Когда у вас есть система, которая не работает, вы можете открыть ее и повозиться с внутренними компонентами, или вы можете возиться с вводом, пока он не выдаст правильный результат.
В этом случае я предлагаю вам возиться с вводом в программатор, а не пытаться изменить программатор.
У меня постоянные разногласия с программистом по поводу качества кода.
Перестаньте спорить об этом.
Коротко и мило:
Поэтому в следующий раз, когда вы сообщите ему о задаче, сделайте это примерно так:
Описание:
Нам нужно реализовать, протестировать и развернуть функцию X к пятнице, 3 июня.
Требования:
- Должен включать тестовый пример, выходящий за пределы, и правильную работу.
- Выполнение в производственной базе данных SOME_DATABASE не должно занимать более 180 секунд.
- Должен пройти тестирование LINT / и т. д. для стандартов кодирования компании.
Затем во время обсуждения выясните, есть ли у него проблемы с требованиями. Если да, то вы выполняете задание или переделываете требования под его возможности. Отнимите у него тяжелую работу и справьтесь с ней сами — между вашей и его работой должно быть четкое разграничение. Когда он терпит неудачу, не пытайтесь «исправить» его — выясните, почему он не оправдал ваших ожиданий, и составьте требование, которое поможет сообщить ему о ваших ожиданиях для следующей аналогичной задачи.
На данный момент, я надеюсь, вы понимаете, что ваш текущий способ заставить его измениться в соответствии с вашими потребностями не сработает. Нужно понять его возможности, а потом только поручить ему ту работу, на которую он способен. Если вы дойдете до того, что он больше не будет удовлетворять ваши потребности, то вам лучше уволить его - если деловые отношения между его выгодами и его результатами больше не имеют для вас смысла, тогда разорвите их и найдите кого-то другого, чтобы выполнить его роль. . Необязательно в этом порядке.
В этот момент я обычно произносил несколько примирительных фраз о том, что люди должны иметь возможность меняться и постоянно повышать свои навыки, но сейчас вам просто нужно сосредоточиться на понимании собственных требований, а затем четко изложить их ему. Как только вы разберетесь с общением , вы можете перейти к тому, чтобы помочь ему улучшить свои навыки, чтобы он мог написать запрос ORM, который выполняется вовремя. А до тех пор общайтесь, общайтесь, общайтесь и примите тот факт, что некоторые задачи вам придется выполнять самостоятельно.
Это больше касается практики кодирования, чем бизнес-приоритетов.
Я программист и немного настроен по-своему, но этот программист вне сети. Я не понимаю, почему кто-то предпочитает стиль скорости. ORM удобны, но не эффективны. Неплохой стиль использования SQL. Неплохой стиль - денормализация базы данных для повышения производительности. Преждевременная оптимизация — плохая практика кода, но оптимизация узких мест — хорошая практика кода. Я рассмотрю любой запрос, который занимает более 2 секунд.
Моя любимая мозоль — настраиваемые элементы управления. Бизнес потребует очень конкретного взгляда, и я отвечу, но стандартный контроль представляет информацию. Стандартные элементы управления быстрые и проверенные. При обновлении нам не нужно координировать несколько библиотек.
Зачем программисту использовать ORM, запуск которого занимает 4 часа? На проверку уйдет 4 часа. Если бы программист боролся за то, чтобы перейти на SQL, чтобы сократить 8-секундный запрос на 4 секунды, а бизнес сказал, что 8 секунд достаточно, и мы хотим оставить ORM для удобства обслуживания, тогда я бы получил эти дебаты.
А как убедить программиста? Я бы назвал это скорее вопросом кодовой практики, чем бизнес-приоритетами. Бизнесу не нужно доказывать, что 30-секундный поиск лучше, чем 4-часовой. Я использую ORM только потому, что написание сырого SQL - плохая практика, просто неприемлемая. Если язык и платформа поддерживают необработанный SQL, это приемлемо. Программист должен быть включен в программу корректирующих действий, и HR должен быть вовлечен. Если вы не его босс, то идите к его боссу.
Why would any programmer want to use a ORM that takes 4 hours to run? It would take 4 hours to test.
Только это получает мой голос. Если программист защищает свою позицию, говоря, что стиль экономит время на поддержку кода, тогда аргументы в пользу того, как эффективность может сократить затраты на поддержку, бесконечно лучше любого аргумента «эффективность лучше, чем стиль». Всегда представляйте аргумент в терминах, которые другой человек уже признал важными.Аргументируйте из первых принципов.
Ни один клиент или клиент действительно не заботится о «лучших практиках». Но они, безусловно, заботятся о качестве . Больше всего они хотят, чтобы их проблема была решена, и чем быстрее, проще и дешевле, тем лучше. (Они также хотят сэкономить время, деньги и усилия в долгосрочной перспективе, что является большой частью «качества».)
Да, некоторые клиенты/заказчики используют «лучшие практики» в качестве показателя качества, эффективности и так далее. Но только потому, что их основные интересы — это качество, эффективность и т. д.
Поэтому любой, кто предлагает услугу (даже программист, предлагающий услуги бизнесу), должен оценивать свою работу с помощью таких вопросов, как «качественно ли это?», «быстро ли доставлено?», «делает ли это то, что хочет клиент?», « экономит ли это время/деньги/ресурсы в долгосрочной перспективе?»
На эти вопросы трудно ответить. Гораздо проще ответить на такие вопросы, как «Соблюдаю ли я соглашения о написании кода?», «Правильно ли я реализую спецификацию?» и «Есть ли у меня описание Javadoc для каждого метода?» Такие вопросы — простой способ избежать трудных вопросов. Но хороший программист задает сложные вопросы о своем коде.
Важны лучшие практики. Они помогают создавать качественные продукты, которые в долгосрочной перспективе экономят время/деньги/ресурсы. Они особенно полезны, когда вы пытаетесь принять решение и у вас мало веских доказательств того, какая альтернатива лучше. Но когда у вас есть четкая информация об альтернативе (например, это займет 10 минут вместо 4 часов, с очень малой вероятностью возникновения проблем позже), тогда здравый смысл преобладает над передовой практикой!
Если ваш программист считает, что часть кода «ужасна и никогда не должна использоваться», попросите его обосновать это из первых принципов (а не из лучших практик). У него есть ошибка? Есть ли риск, что он содержит уязвимость в системе безопасности? Может ли это добавить много времени на обслуживание или новые функции в будущем? Не смутит ли это других программистов? И действительно ли проблемы с этим стоят времени, потраченного на реализацию «лучшей» альтернативы? Убедитесь, что вы слушаете, что он говорит. Если он приводит сильный аргумент, не позволяйте своему эго взять верх.
Заметка о честности и привычке
Хорошие привычки ценны. Если ваши разработчики постоянно тренируются и совершенствуют свои навыки написания ясного, чистого, хорошо документированного кода, они станут более эффективными и у них не будет соблазна лениться и срезать углы. Это отлично подходит для качества вашей кодовой базы!
У вашего программиста явно есть честность. Не пытайтесь убить его — используйте его! Дайте ему задания, где важно качество . Например, попросите его очистить беспорядочный код, написанный кем-то другим, который становится трудно поддерживать. Попросите его реализовать функциональность там, где важно, чтобы код можно было поддерживать.
Он настаивает на том, чтобы весь его код был написан в соответствии с высочайшими стандартами (т. е. чтобы он выглядел точно так же, как примеры в учебниках по стилям кодирования), независимо от того, как это влияет на функциональность. Я, с другой стороны, считаю более важным, чтобы написанный код отвечал потребностям бизнеса, т. е. чтобы он работал эффективно, не требовал слишком много времени для разработки и был разумно удобен в сопровождении.
Вы понимаете, что у вас обоих одна и та же цель, верно?
Лучшие практики таковы по причине. Они существуют для того, чтобы код был хорошо организован и разделен, чтобы он работал эффективно, не требовал слишком много времени для разработки и был разумно ремонтопригоден.
Конечно, ваш разработчик может извлечь выгоду из прагматизма или лучшего понимания того, когда правила можно безопасно обойти. Но это также звучит так, как будто вы могли бы извлечь выгоду из более долгосрочного взгляда на то, как качество кодовой базы помогает вашим бизнес-целям.
Ваш вопрос о том, как объяснить программисту бизнес-приоритеты, но похоже, что вы это сделали. Чего вы не сделали, так это прислушались к бизнес-приоритетам вашего программиста. Вам двоим придется пойти на компромисс. Есть гораздо больше решений проблемы, чем «использовать прямой SQL» и «использовать ORM». Вы можете улучшить производительность ORM. Вы можете попытаться изолировать SQL, чтобы он не доставлял хлопот программисту.
Короче говоря, чтобы получить желаемое, нужно перестать спорить и начать сотрудничать.
Честно говоря, я бы дисциплинировал парня и уволил бы его, если бы это было необходимо. В ответах, уже опубликованных здесь, есть несколько хороших моментов, касающихся гибкости подходов к проблемам, поэтому я не буду их перефразировать.
Похоже, что сотрудник, с которым у вас возникли проблемы, уже находится на руководящем уровне или близко к нему и много понимает в программировании. Однако это не вся его работа. Если технически вы его менеджер, он должен слушать вас независимо от того, нравится ему это или нет. Очевидно, мы не видели, как вы двое обсуждаете проблемы, но это должно быть довольно напряжённо. Да, большинство проблем можно решить несколькими способами, и вам обоим следует научиться быть более гибкими, но некоторые из сказанных вами вещей указывают на то, что этот человек наносит компании ущерб, а не актив.
Теперь он отказывается работать над этой частью программы.
Неприемлемо и по-детски, а также отказ выполнять обязанности на работе , что, по моему мнению, является основанием для увольнения.
но он просто говорит «нет, это не так» и продолжает писать свой стильный, неэффективный код, который мне иногда приходится плохо переписывать, прежде чем его можно будет использовать.
То же самое.
Я могу только представить (и надеяться), что в своем разочаровании вы немного приукрасили, и я надеюсь , что как его «технически» менеджер вы сможете придерживаться более высоких стандартов и не вступать с этим человеком в детские разногласия. Тем не менее, если ситуация такова, как вы говорите, сотрудник негибок до отказа. Потенциально вы могли бы получить некоторое образование и рекомендации о том, как обращаться с трудными людьми, но, в конце концов, этот сотрудник категорически отказывается улучшать продукт, основанный на эзотерических стандартах. Есть только один способ, которым это может повлиять на ваших клиентов, и это плохо. Каким бы хорошим ни был этот программист, в какой-то момент он станет обузой для компании (а может быть, уже стал).
В конце концов, вы нанимаете их для создания рабочего продукта, а не красивого кода. Если они не могут этого сделать, значит, они не выполняют свою работу.
Сказав мой кусок, постарайтесь помнить, что он не черный и белый, и это точно не вы против них, просто у вас разные представления о том, что правильно. Мои комментарии здесь основаны на понимании того, что вы пытались объяснить бизнес-приоритеты, и человеку, похоже, все равно, что, на мой взгляд, означает, что он не подходит для вашей компании. Может быть, этот парень преуспеет на веб-сайте, который обучает лучшим практикам или что-то в этом роде.
Возможно, вам придется выяснить, что он считает важным. «Хороший стиль» — это просто стиль. Он должен согнуться, чтобы удовлетворить потребности бизнеса, и он должен это знать. Тем не менее, может быть основной страх, с которым он имеет дело, и с которым необходимо справиться.
В качестве примера я работал в команде, которая постоянно производила программное обеспечение более медленными темпами, чем требовалось клиентам. Руководство постоянно злилось на нас. У нас была веская причина для медлительности. Руководство создало враждебную среду разработки, в которой ни одна часть кода не могла быть изменена без явной команды сделать это от нашего клиента. К сожалению, у нас было явное требование поддерживать это программное обеспечение в течение десятилетий, в то время как мало кто из наших клиентов когда-либо думал больше, чем на месяц вперед, что делало невозможным убедить их в долгосрочной рентабельности инвестиций. На нас была возложена большая ответственность за программное обеспечение, но практически не было полномочий что-либо с этим делать. Наша мантра звучала так: «Первый рабочий прототип, показанный заказчику, станет вашей окончательной реализацией». Мы так и не разрешили этот контрольно-пропускной пункт. Руководство никогда не работало с нами, чтобы поддержать программу в соответствии с нашими обязанностями (нам фактически было приказано не пытаться решить ее, потому что простое поднятие вопроса могло поставить под угрозу продолжение финансирования). Вместо этого программа умерла, потому что никто не стал решать основную проблему сбоя в бизнесе.
После этого мы как разработчики потратили много времени, пытаясь выяснить, что именно пошло не так, и что мы могли бы сделать в следующий раз, чтобы этого избежать. Одним из наших выводов из этого упражнения была ценность наличия нескольких способов решения проблемы. Ему нравится стиль ORM, в то время как вы экономите эоны вычислений с помощью команды SQL или двух? Сделайте так, чтобы оба могли существовать бок о бок. Довольно часто ценность подхода не очевидна для другой стороны до тех пор, пока он не будет завершен. Позвольте обоим стилям сосуществовать в дикой природе и выясните, какой из них выживает в суровых условиях бизнеса. Развивайте чувство гармонии между подходами вместо того, чтобы пытаться диктовать один подход, чтобы управлять ими всеми. Возможно, он делает всю свою первичную разработку, используя свой экстремальный стиль, но конечный продукт требует добавления хаков.
Если он не принимает это, то он действительно не прав. Он не голос компании, он просто сотрудник. Его голос является частью целого, а не центром целого (если только вы не наняли его быть центром). Сотрудник, который не может проявить гибкость, потому что придерживается принципов, противоречащих потребностям компании, действительно должен быть уволен. Но, наоборот, у разработчиков есть точка зрения на программное обеспечение, которую нельзя найти больше нигде. Бизнесу действительно нужно приспосабливаться, когда разработчик указывает на проблему, которую трудно увидеть кому-либо еще.
Цель состоит в том, чтобы выяснить, как обеспечить сосуществование двух точек зрения достаточно долго, чтобы их можно было изучить должным образом. Однако это может в конечном итоге потерпеть неудачу, если одна сторона особенно застряла в грязи. В этот момент вам нужно будет провести вежливую беседу, объяснив, что его стиль кодирования не является центром мира, и если он будет мешать бизнесу, ему будут давать задачи, которые дают ему все меньше и меньше свободы в подходах. ему разрешено брать. В качестве альтернативы он может согласиться на такие вещи, как «размер зарплаты» в обмен на свободу выполнять свою работу.
Я не хотел создавать еще один ответ, предлагающий итеративную разработку, но я хотел добавить его в конец своего ответа. Итеративная разработка дает ему возможность изучить «хороший стиль» за одну итерацию, а затем заставить вас применить бизнес-барашки, чтобы превратить его в полезный продукт. Вы можете априори не знать, что задачу можно выполнить за 30 секунд. Однако после первой итерации у вас должно появиться ощущение времени. Это ощущение времени должно позволить вам обеспечить временные требования во второй итерации.
Если вы даете бизнес-требование, чтобы запрос занял менее 5 минут, а он говорит, что это невозможно, то вежливо заберите у него задачу и сделайте ее сами. Пусть вертит пальцами, пока не начнет понимать, что его зарплата в опасности.
Лучший ответ, который я читал по этому вопросу, взят из FAQ по C++.
https://isocpp.org/wiki/faq/big-picture#biz-dominates-tech
Вам это может не понравиться, но краткий ответ: «Нет». (С оговоркой, что этот ответ адресован практикам, а не теоретикам.)
Зрелые разработчики программного обеспечения оценивают ситуации на основе бизнес-критериев (время, деньги и риск) в дополнение к техническим критериям, таким как «хороший объектно-ориентированный подход» или «хороший дизайн класса». Это намного сложнее, поскольку включает в себя вопросы бизнеса (график, квалификация людей, выяснение того, куда компания хочет двигаться, чтобы мы знали, где обеспечить гибкость программного обеспечения, готовность учитывать вероятность будущих изменений — изменений, которые вероятно, а не просто теоретически возможно и т. д.) в дополнение к техническим вопросам. Однако это приводит к решениям, которые с большей вероятностью принесут хорошие результаты в бизнесе.
Как разработчик, вы несете фидуциарную ответственность перед своим работодателем за инвестирование только такими способами, которые имеют разумные ожидания возврата этих инвестиций. Если вы не зададите деловые вопросы в дополнение к техническим вопросам, вы будете принимать решения, которые будут иметь случайные и непредсказуемые последствия для бизнеса.
Нравится вам это или нет, но на практике это означает, что вам, вероятно, лучше оставить такие термины, как «хороший дизайн класса» и «хорошее объектно-ориентированное программирование», неопределенными. На самом деле я считаю, что точные, чисто технические определения этих терминов могут быть опасными и могут стоить компаниям денег, а в конечном итоге, возможно, даже лишить людей работы. Звучит странно, но на это есть веская причина: если эти термины определены в точных, чисто технических терминах, благонамеренные разработчики склонны игнорировать деловые соображения в своем желании соответствовать этим чисто техническим определениям «хорошо».
Любое чисто техническое определение «хорошего», такое как «хорошее объектно-ориентированное проектирование» или «хороший дизайн» или что-то еще, что можно оценить без учета графика, бизнес-целей (чтобы мы знали, куда инвестировать), ожидаемых будущих изменений, корпоративной культуры с уважение к готовности инвестировать в будущее, уровень квалификации команды, которая будет выполнять техническое обслуживание и т. д., опасно. Это опасно, потому что это обманывает программистов, заставляя их думать, что они принимают «правильные» решения, тогда как на самом деле они могут принимать решения, которые могут иметь ужасные последствия. Или эти решения могут не иметь ужасных последствий для бизнеса, но в том-то и дело: когда вы игнорируете соображения бизнеса при принятии решений, последствия для бизнеса будут случайными и в некоторой степени непредсказуемыми. Плохо.
Дело в том, что деловые вопросы преобладают над техническими, и любое определение «хорошего», не учитывающее этот факт, является плохим.
Рассмотрим это утверждение:
Затем покажите ему пример того, как можно радикально улучшить его код.
Если он не может (или не хочет) соединить точки между этим утверждением и вашим примером, вам нужно избавиться от него. Это похоже на представителя службы поддержки, который отказывается пользоваться своим телефоном, потому что предпочитает отправлять клиентам электронные письма.
На самом деле есть два отдельных вопроса: один заключается в том, что разработчик программного обеспечения (по понятным причинам) хочет создавать код высочайшего качества, в то время как бизнес хочет, чтобы он создавал код, предлагающий как можно больше функций за то же время.
Необходимо пойти на компромисс: в какой-то момент чрезмерная полировка кода больше не дает никаких преимуществ. С другой стороны, если качество кода недостаточно хорошее, вы получите код, который дает неверные результаты, или дает сбой, или работает слишком медленно, или не может поддерживаться.
Вам нужно убедить своих разработчиков не переусердствовать, и они должны убедить вас, что несоблюдение какого-либо ограниченного стандарта иногда дорого обходится в краткосрочной перспективе, а часто и в долгосрочной. С другой стороны, дороговизна в долгосрочной перспективе может быть приемлемой, если только за счет доставки в короткие сроки бизнес выживет достаточно долго, чтобы беспокоиться о долгосрочной перспективе. Если вы не можете убедить своих разработчиков производить правильныеколичество качества, и это стоит вам денег, вам, возможно, придется отделить. (Очевидно, что если кто-то производит низкое качество за восемь часов, а кто-то другой производит высокое качество за восемь часов и его нельзя заставить производить низкое качество за шесть часов, вы все равно предпочитаете второго разработчика. Или если этот разработчик счастлив, создавая высокое качество и продуктивным, а заставляя его отказываться от качества, вы делаете его несчастным и непродуктивным, это тоже никуда не годится).
Другой вопрос: похоже, ваш разработчик настаивает на каком-то формальном подходе, который является неэффективным, вместо того, чтобы использовать неформальный подход, который очень эффективен (когда неэффективность на самом деле является проблемой для бизнеса). В этом я вижу серьезную проблему. Если у бизнеса есть проблема, которую необходимо решить, то любая техника, которая не решает проблему, неприемлема, и настаивать на такой технике, зная другую, решающую проблему, я считаю неприемлемым.
При необходимости разработчик должен не стесняться добавлять комментарии к коду с разглагольствованиями о том, почему техника, которую он использует, намного хуже другой техники, но это нужно было сделать для эффективности. (На самом деле было бы неплохо записать причины, если его спросят, почему он использовал этот подход через два года.) Тем не менее, то, что нужно сделать, нужно сделать.
Это проблема с его отношением, и его нужно изменить.
Его намерения кажутся достаточно благородными — он пытается внедрить код, который выучил в школе, который, как он узнал, безопасен и гигиеничен для программы, и придерживается лучших практик кодирования. Этот аспект — то, что вы хотите от программиста.
Чего вы не хотите, чтобы он чувствовал, так это того, что он может принимать решения на высшем уровне о том, как должно функционировать приложение. Он, я полагаю, младший программист, и он еще не научился приспосабливаться к особым ситуациям, не говоря уже о тонкостях вашего собственного приложения.
Если это повторяющийся инцидент, я предлагаю вам поговорить с ним о том, что передовой опыт, хотя и полезный для подражания, не всегда является правильным решением. Напомните ему также, что вы его босс, и что вы не потерпите, чтобы он отвергал ваши решения или действовал за вашей спиной, программируя «его» пути .
И на индивидуальном уровне ваша группа в любом случае должна провести проверку кода, прежде чем вы сделаете коммит, так что воспользуйтесь этой возможностью, чтобы просмотреть его хорошо отформатированный, но крайне неэффективный код и шаг за шагом объяснить, почему он неэффективен.
Если он отказывается меняться, поручите сдачу кому-то другому или возьмите на себя. К сожалению, это может быть признаком того, что он совершенно не работает в группах, и вам, возможно, придется отпустить его или найти другую группу, которая лучше работает с его «всегда строгим» стилем кодирования.
В своем вопросе вы не говорите о том, что код работает правильно . Возможно, ваш программист тратит слишком много времени на то, чтобы код выглядел красиво, но, возможно, он тщательно проверяет ошибки. Хороший код имеет несколько требований:
Как менеджер/представитель бизнеса в целом, вы хотите, чтобы код был качественным, дешевым и быстро разрабатываемым. К сожалению, опыт показал, что вы можете получить только два из них. Качественный, быстро разработанный код стоит дорого. Быстро разработанный, дешевый код — это низкое качество. Качественный и дешевый код требует много времени для разработки.
Некоторые программисты не пойдут на компромисс в отношении качества (я признаю, что я один из них) из-за огромного количества дополнительного времени, необходимого для устранения неполадок, исправления ошибок и последующей перезаписи. Я сознательно не позволю новой ошибке появиться в сети.
Однажды я работал над огромным, плохо написанным проектом. Код был унаследован от третьей стороны, и над ним работали очень хорошие разработчики. Бизнес продолжал просить сделать его лучше, а мы продолжали говорить: «Это настолько хорошо, насколько это возможно». В конце концов мы добились того, что код стал работать лучше, но на это ушло от 6 месяцев до года, и у нас никогда не было четкого представления о том, как заставить код работать быстрее. Когда мы говорили: «Это настолько хорошо, насколько это возможно», на самом деле мы имели в виду: «Мы исчерпали все наши текущие идеи».
Ваш программист может быть в похожей ситуации. Он буквально делает все возможное и не может придумать лучшего способа сделать что-то. Вероятно, ему не нравится, когда его насильно кормят определенными идеями, и он автоматически отвергает их. Если он независимо придумает одну и ту же идею, вы оба выиграете! Поскольку компания небольшая, у него, вероятно, не так много возможностей обмениваться идеями с другими людьми или получать идеи нестандартного мышления от людей, которые не так близки к проекту.
Поработав над чужим кодом, могу сказать, что иногда мне приходилось тратить полчаса на переформатирование кода, прежде чем я мог его понять. Код форматирования важен для эффективности вашего программиста, даже если он может работать одинаково.
Не пытайтесь убедить своего программиста принять «плохой код». Объясните, почему есть несколько способов сделать одно и то же, и только потому, что один из них является «хорошим кодом», это не делает другие автоматически «плохим кодом». Вы должны показать ему, что вы на его стороне. Вы тоже хотите хороший код! Но затем определите, что такое хороший код. Если быть эффективным важно, тогда дайте ему задание сделать его эффективным! Четко сформулируйте ожидаемый результат. Например, нам нужно запускать этот запрос 1000 раз в час, а это означает, что он должен выполняться не реже одного раза каждые 3,6 секунды (что, вероятно, ужасная производительность!)
Его наняли в качестве технического эксперта, а не бизнес-эксперта. Таким образом, его профессиональные цели могут быть не такими, какими вы хотели бы их видеть. Вам нужно объяснить, как то, что он делает, влияет на остальную часть бизнеса, а также понять, как остальная часть бизнеса влияет на его работу. Я бы не рекомендовал управлять им, если только вы не планируете его уволить.
Вы также можете изучить возможность автоматического форматирования кода. Таким образом, он мог сосредоточиться на программировании и с помощью макроса или небольшой утилиты переформатировать код так, как ему нравится, менее чем за секунду. С SQL я согласен с ним, что напрямую написанные запросы — это плохо, но, например, в PHP вы можете использовать PDO для выполнения точно таких же запросов с очищенным вводом. Это хорошая практика! Должен быть компромисс, при котором вы получаете желаемую скорость, а он получает «хороший код», который ему нужен.
Я бы также предложил, чтобы он профилировал код, чтобы найти узкие места и сделать их приоритетными для эффективности. В конце концов, если его красивый код работает быстро (и он быстро его пишет), вы не возражаете, не так ли? Вы хотите, чтобы он увидел вашу точку зрения, поэтому продемонстрируйте, что вы можете видеть и ценить его точку зрения. Вам придется возмещать ущерб, нанесенный вашим профессиональным отношениям, и важно, чтобы вы оба доверяли друг другу.
Это может быть сложно. Это во многом зависит от того, на что негативно влияет его поведение.
Производительность программы
Хороший программист должен понимать разделение интерфейса и реализации. Требования - "интерфейс" так сказать проекта, и хороший дизайн
Я предполагаю, что вы хотя бы частично отвечаете за требования этого проекта. Вы можете создать требование для этого сценария, чтобы он выполнялся в течение 6 минут.
Пока он соответствует требованиям, вам все равно , что он делает. (Это реализация.)
Это может помочь ему увидеть, что с точки зрения всех остальных (кто не может видеть его исходный код) его программа дерьмовая .
Время разработки
Это немного сложнее. С одной стороны, вы можете выделить время для завершения «требования» проекта, но оценка времени для завершения проекта (соответственно) остается на усмотрение человека, который его создает.
Это во многом связано с его работой. Вы должны подходить к этому так же, как и к любой другой проблеме с производительностью труда. Вероятно, это означает серьезную встречу, на которой вы выражаете свои опасения по поводу его способности вовремя закончить работу и т. д. Здесь нет простых решений.
Тот факт, что этот программист отказывается работать над этим компонентом, является для меня явным признаком того, что это вопрос ответственности компонента.
С точки зрения вашего клиента, ваша оптимизация — это правильное решение: черный ящик, которым является ваша программа, работает лучше, и ваша компания как организация несет ответственность за весь этот ящик.
Внутри вашей компании отдельные люди несут ответственность за отдельные компоненты, и всякий раз, когда компонент выходит из строя, вина лежит на специалисте по сопровождению этого компонента.
Вы не можете отделить эту ответственность от полномочий по принятию решений.
Отмена решения является вашей прерогативой как менеджера, но в то же время вы берете на себя полную ответственность за решение, которое включает бумажный след, документирующий возражения вашего программиста и почему они были отклонены, с копией для всех.
Ваш программист предсказывает, что это будет иметь негативные последствия в будущем, и пытается прикрыть свой зад.
Скажите ему, что его работа НЕ состоит в том, чтобы писать программы как таковые — его работа состоит в том, чтобы писать код, приносящий прибыль компании.
Напомните ему, чтобы он был коммерчески жизнеспособным как сотрудник, код, который он пишет, должен быть коммерчески жизнеспособным. Если он не может этого сделать, то он несет коммерческую ответственность перед компанией и будет рассматриваться как таковой. Вы говорите, что у вас небольшая компания, так что есть шанс, что он может уничтожить всю компанию.
Кроме того, вы можете объяснить, что он может писать программы для развлечения и удовольствия (или для улучшения своих навыков) в свободное время, и многие программисты так и делают. Но программы, написанные на время компании, должны приносить прибыль компании.
Если он отказывается изменить свой стиль (возможно, чтобы сделать код, возможно, менее красивым, но существенно улучшающим производительность), спросите его, как бы он хотел, чтобы компания платила ему так же: всего 10% от его зарплаты, но с использованием действительно приятного цвета. распечатанный чек. Произведение искусства, написанное от руки и подписанное генеральным директором, он может повесить его на стену :-)
Да, прагматичные решения иногда накапливают технический долг — ( википедия ), чтобы обеспечить ЦЕННОСТЬ для бизнеса.
Отказ принять технический долг аналогичен отказу принять финансовый долг: иногда допустимое решение — занять деньги для поставки продукта (даже если позже вам нужно будет оплатить долг).
Иметь менее чем идеально поддерживаемый, но более производительный код — это то же самое, что платить за возобновляемый кредит: это позволяет компании оставаться в бизнесе.
Если на доставку решения уходит в 10 раз больше его времени, он заслуживает только 10% от зарплаты. Если он не может принести пользу бизнесу, его следует заменить тем, кто это делает. (Я уверен, что это принесет мне несколько отрицательных голосов, потому что это откровенный наркотик, а не теплый и нечеткий язык - ну, жизнь слишком коротка. И да, отрицательные голоса льются. Вот почему я больше не участвую в этом форуме. ).
край
корсика
Эрик Липперт
Моника Челлио
пользователь36758
пользователь8365
Бенуберд
Бенуберд
Гаурав Агарвал
Раскол
медная шляпа
Д_Бестер
Эрик Липперт
рука
Мацеманн
ланчмясо317
Энтони Х
Пикантный
Турбьёрн Равн Андерсен
HLGEM
папарацци
Фейт
Демончерный
Еще один случайный пользователь
Бенуберд