Как объяснить программисту бизнес-приоритеты?

Бенуберд

Как объяснить программисту бизнес-приоритеты?

У меня постоянные разногласия с программистом по поводу качества кода. Он настаивает на том, чтобы весь его код был написан в соответствии с высочайшими стандартами (т. е. чтобы он выглядел точно так же, как примеры в учебниках по стилям кодирования), независимо от того, как это влияет на функциональность. Я, с другой стороны, считаю более важным, чтобы написанный код отвечал потребностям бизнеса, т. е. чтобы он работал эффективно, не требовал слишком много времени для разработки и был разумно удобен в сопровождении.

Недавно у нас был спор о том, что конкретный сценарий, который он написал , выглядит великолепно, идеально оформлен и работает точно так, как в различных книгах описывается лучшая практика. У меня есть альтернативная версия, которая была написана с использованием так называемого «анти-шаблона», и он настаивает на том, что это абсолютно ужасный код, который никогда не следует использовать. Тем не менее, он также работает примерно в пять раз быстрее.

Я пытался убедить его, что ему нужно использовать этот анти-шаблон, даже если это «плохой код», потому что быстро работать важнее, чем хорошо выглядеть. Он не согласен и категорически отказывается рассматривать возможность написания любого кода, который не соответствует признанным «хорошим» шаблонам стиля, даже если это означает, что его написание занимает больше времени и не работает так же хорошо.

Пример: он хочет использовать ORM для доступа к базе данных. Для одного особенно сложного запроса ORM плохо его оптимизирует, и его выполнение занимает более 4 часов. Я напрямую вставил немного необработанного SQL и сократил время выполнения до 30 секунд. Он очень сильно возражал, говоря, что писать необработанные sql-запросы напрямую — плохая практика, и мы всегда должны использовать ORM. Теперь он отказывается работать над этой частью программы.

Я пытался объяснить, что иметь хорошо работающую программу важнее, чем иметь красивый код, но он просто говорит «нет, это не так» и продолжает писать свой стильный, неэффективный код, который мне иногда приходится плохо переписывать. прежде чем его можно будет использовать.

На данный момент мы находимся в плохом положении, потому что он отказывается идти на компромисс со своими стандартами, а это означает, что все, что он делает, должно быть проверено мной и в некоторых случаях изменено, чтобы убедиться, что оно соответствует потребностям бизнеса, и не только его эстетические стандарты.

Как я могу убедить его изменить приоритеты и поставить цели бизнеса выше красоты своего кода?

Редактировать: Стефан Коласса предложил мне включить это: технически я его менеджер, но мы такая маленькая компания (~ 10 человек), что я также программирую, и в то же время я своего рода его коллега, что просто делает его немного сложнее, и у нас нет фиксированных организационных стандартов или процедур разрешения конфликтов.

край

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат . Хотя может быть интересно обсудить технические аспекты этого вопроса, есть другие сайты SE (или чат), которые являются гораздо лучшим средством для этого обсуждения. Спасибо!

корсика

Какой уровень опыта у этого программиста? Если это младший разработчик, возможно, ему просто нужно понять, что реальный мир отличается от учебников. Если это более старший разработчик, вероятно, будет другой подход.

Эрик Липперт

Замечу, вы говорите, что худший код работает в пять раз быстрее, как будто это хорошо. Кого волнует, что он работает в пять раз быстрее? Насколько мне известно, сценарий, который запускается за 0,01 секунды, и сценарий, который запускается за 1,0 секунды, выполняются за одинаковое время, но один из них в сто раз быстрее другого. Метрика, которую вы должны использовать, — соответствует ли сценарий документально подтвержденным требованиям к производительности? , а не то, что быстрее . Возможно, ни один из них не достаточно быстр.

Моника Челлио

Пожалуйста, примите участие в обсуждении в связанном чате. Эти комментарии будут удалены позже.

пользователь36758

Действительно ли есть конфликт? например, разница между 4 часами и 30 секундами на самом деле не имеет значения, если вы выполняете запрос ночью и это не мешает другим вещам. Он действительно владеет соответствующей информацией? Он может подумать, что запрос предназначен только для выполнения в одночасье, и не осознавать, что люди на самом деле могут использовать информацию, которой меньше минуты. Или он может не понимать, что этот запрос мешает другим вещам.

пользователь8365

Значит, вы несете ответственность за любой код, который он может создать, но у вас нет полномочий объявить этому человеку выговор? Технически это значит быть чьим-то менеджером, но не иметь полномочий?

Бенуберд

@JeffO Да, в значительной степени.

Бенуберд

@Jimbo На самом деле это звучит довольно точно. К сожалению, если кто-то не зациклен на деньгах, мы останемся без клиентов, и тогда все это не будет иметь значения. В конце концов, цель бизнеса — зарабатывать деньги, а не писать красивый код.

Гаурав Агарвал

Поскольку я не могу опубликовать ответ из-за какого-то сбоя в системе, я добавлю его сюда. Другой разработчик говорит о качестве кода. По моему опыту, красивый код всегда создает качественные системы. Однако в этом случае код не является элегантным на всех уровнях. ORM не может создать элегантный код SQL для требуемой проблемы, что приводит к проблемам с производительностью. Я предлагаю вам объяснить разработчику, что если он хочет быть чистым со своим решением, то он понимает, что ORM имеет свои ограничения и не является самым элегантным решением. Если он беспокоится о ремонтопригодности, добавьте модульные тесты.

Раскол

@Gaurav Не глюк. Этот вопрос защищен. Поскольку вы не заработали 10 повторений на этом сайте , вы не можете опубликовать ответ.

медная шляпа

В идеале человек пишет хороший код и зарабатывает деньги. Если вы работаете в небольшой компании и есть компромисс, то зарабатывание денег (предположительно связанное с функциональностью) имеет приоритет. Если сотрудник не может этого понять, у вас проблемы с кадрами. Если это небольшая компания, вам нужно разобраться с этим быстро.

Д_Бестер

@EricLippert Очевидно, мы с тобой живем в разных мирах. Там, где я работаю, код измеряется производительностью. В моем маленьком магазине нет "задокументированных требований к производительности". Вся моя работа для моего босса, внешних контрактов нет. Производительность имеет значение. Если это быстрее, это обычно лучше.

Эрик Липперт

И сколько миллионов долларов вы готовы потратить на процент ускорения? Конечно, чем быстрее, тем лучше, но и дешевле, и возможностей больше. Все эти вещи стоят денег, и если вы не делаете разумных компромиссов между ними, то, вероятно, кто-то перерасходует.

рука

Бенуберд, просто отправьте своему программисту URL этой страницы и скажите ему, чтобы он прочитал ответы. Он либо уволится с работы, либо подчинится (и то, и другое является положительным результатом).

Мацеманн

Похоже, этот человек прочитал много книг по программному обеспечению, но не The Pragmatic Programmer. Я могу порекомендовать это.

ланчмясо317

Я очень надеюсь, что под «сырым SQL» вы подразумеваете «хранимую процедуру». Есть компромиссы, знаете ли.

Энтони Х

Ваш разработчик может полагать, что его работа заключается в том, чтобы следовать «лучшей практике», и бояться, что, если он не будет следовать лучшей практике, его могут вызвать за невыполнение своей работы. Он может стремиться накопить опыт в «передовой практике», чтобы оправдать такое утверждение в своем резюме. Какой бы ни была мотивация, «лучшая практика» — это идеал, а не жесткое правило. Тем не менее, «лучшая практика», при правильном соблюдении, должна привести к доказуемо правильным, эффективным, производительным и ремонтопригодным решениям. Если использование ORM не соответствует бизнес-целям по производительности, то вместо этого вполне допустимо использование более эффективного SQL.

Пикантный

4 часа или 4 минуты?

Турбьёрн Равн Андерсен

Если скорость важна, сделайте ее бизнес-требованием.

HLGEM

КСТАТИ. ORM не лучшая практика! Они удобны для разработчиков. они пишут паршивый код.

папарацци

@EricLippert Миллион долларов за процент ускорения? Это сырой SQL, написанный деловым человеком для повышения скорости 480:1.

Фейт

Я лично не думаю, что ваш сценарий возможен: когда вы пишете хороший код, этот код также оказывается очень эффективным. Конечно, возможно, какой-то «антипаттерн» позволит вам добиться немного лучшей производительности, но это улучшение настолько незначительно, что вы даже не заметите (с 4 часов до 30 секунд? Пожалуйста! Он вообще хорошо настроил ORM?) . Другими словами, ваш программист некомпетентен и эгоистичен. Он просто прячется за своими «знаниями», чтобы скрыть свою некомпетентность. Вы должны просто уволить его или, по крайней мере, пригрозить ему сделать это, если он не сделает то, о чем вы просите.

Демончерный

@Phate У нас было хранилище данных, которому потребовалось 6 дней для обработки данных за месяц. После восстановления с нуля теперь это занимает 2 дня и обрабатывает в 48 раз больше данных. Я лично переписал запросы, которые занимали часы, и сократил их до нескольких минут. Самым крайним случаем был запрос, который занял 6 часов, а после перетасовки таблиц теперь занимает 7 секунд. От 4 часов до 30 секунд очень разумно, когда вы говорите о сотнях миллионов записей, а запрос использует плохой план.

Еще один случайный пользователь

Что такое ORM в этом контексте? Я немного знаком с программированием и SQL и не могу придумать возможного объяснения этой аббревиатуры. Совершенно уверен, что это не "Управление операционными рисками", например....

Бенуберд

@YetAnotherRandomUser это «объектно-реляционный преобразователь», библиотека, которая преобразует объекты кода в записи БД.

пользователь1450877

Я бы не стал диктовать ему стиль кодирования, пусть делает так, как хочет. Если производительность является фактическим задокументированным бизнес-требованием, и он не может его выполнить, сообщите ему об этом.

Если он продолжает не выполнять требования бизнеса, значит, он не справляется со своей работой, начните давать ему официальные устные предупреждения, затем письменные предупреждения, а затем отпустите его, если придется.

край

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .

джморт253

@user, привет. На Workplace мы ищем ответы, которые также объясняют, почему и как , чтобы читатели понимали причину ответа и могли сделать более грамотную интерпретацию того, почему ответ правильный. Можете ли вы отредактировать этот пост, чтобы указать причину, по которой это лучший ответ? Благодарю вас!

Вьетни Пхуван

Похоже, на вас работает примадонна или, того хуже, Мишель Анджело. Как давно он занимается программированием? Я задаю этот вопрос, потому что между программированием и программированием огромная разница. Те, кто был в окопах какое-то время, могут сказать ему, что совершенство может быть уродливым.

Его код может быть хорош как учебник, но реальность такова, что этот код должен выполняться, а код, для выполнения которого требуется 4 часа, а не 30 секунд, — этот код вряд ли можно описать как работающий. Я занимаюсь разработкой программного обеспечения, но со стороны DevOps Дома: если код не масштабируется, этот код никуда не годится, независимо от того, насколько хорошо этот код написан и задокументирован. И отказоустойчивый, поддерживаемый код, который плохо работает, никуда не годится. Что касается меня, то либо он понимает, что я говорю, либо его нет. У него есть свобода писать код в своем собственном стиле, но этот код ДОЛЖЕН работать.

Не говорите ему идти против шаблона. Скажите ему, каково ваше требование, дайте ему крайний срок и дайте ему свободу действий, чтобы выяснить, как его выполнить. Учитывая, насколько он увлечен тем, что его код написан как учебник, у него есть все стимулы удовлетворить ваши требования, сохраняя при этом свой код как учебник, и это неплохо.

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

Вы говорите, что вы "технически" его менеджер. Ну, либо ты его менеджер, либо нет. Прими решение (*)

Если вы его руководитель, то он подотчетен вам так же, как вы подотчетны своему руководству. В таком случае время для объяснений, которые он не будет слушать, закончилось. Неоспоримым требованием является то, что код должен работать, и он должен соответствовать этому требованию. Вот и все.

(*) Я столкнулся с похожей проблемой еще в 1987 году с инженером-экологом, который не следовал нашим передовым методам, изложенным вашим покорным слугой. А поскольку мой титул был официально равен его титулу, он отмахивался от всего, что я говорил. Я устроил трехстороннее свидание между ним, боссом отдела и мной, где я изложил в недвусмысленных выражениях, каковы последствия несоблюдения нашего процесса. Начальник приказал ему подчиниться, а потом сказал мне пару слов наедине о моей жесткости. Я не возражал против упрека - единственное, что имело значение для меня, это то, что я добивался согласия, а он больше не просверливал днище нашего корабля. Эскалация до высшего руководства была не очень приятной, но она сработала. Это все, что имело для меня значение.

Вьетни Пхуван

Мой ответ ОП. Ответ в простом тексте: код, который является учебником, но не работает, никуда не годится. Если работник этого не понимает, то его уже нет. Никто не возражает против того, чтобы сотрудник писал учебник по коду, но этот код должен соответствовать неоспоримому требованию, которое код должен выполнять. Иначе он мог бы и ничего не писать. Не проектируйте Lamborghini, когда вам нужно, чтобы эта машина ездила по грунтовым дорогам.

Брэдли Аффнер

Мне нравится идея превратить это в вызов для него. Ни один хороший программист не может устоять перед вызовом. «Найдите способ сделать это менее чем за 60 секунд, вы можете сделать так, чтобы оно выглядело так красиво, как вы хотите, и следуйте любым рекомендациям, которые вы хотите, пока оно выполняется менее чем за 60 секунд».

корсика

Ммм... лучшие программисты зарабатывают себе на жизнь, преодолевая вызовы . Лучшие программисты отфильтровывают необходимое от того, что приносит удовольствие, и делают то, что необходимо.

чем

@corsiKa Я бы сказал, что есть разница между задачей разработки и интеллектуальной задачей. Это интеллектуальная задача, чтобы избежать проблем развития. Удовольствие приходит от интеллектуального вызова, если вы хороши. Похоже, этот парень доволен тем, что у него нет интеллектуальных способностей, что на самом деле делает его плохим программистом, несмотря на его предполагаемое владение стилем и лучшими практиками.

смайлы

+1 за «совершенство может быть уродливым» - это правда, особенно когда вы зависите от несовершенного программного обеспечения других людей! Ради интереса, было ли выражение «сверлить дырки в днище нашего корабля» метафорическим или буквальным?

корсика

@thanby нам просто нужно согласиться или не согласиться. Судя по тому, что мы читали, он кажется плохим программистом, но я бы не сказал, что его стремление найти интеллектуальные задачи является одним из них. Я не считаю, что для того, чтобы хорошо программировать, нужно получать от этого удовольствие на любом уровне.

Вьетни Пхуван

@psmears .. метафорично. С другой стороны, если бы этот корабль, т.е. наш проект, затонул, они (руководство) позаботились бы о том, чтобы я утонул первым. У меня просто трясутся руки от возбуждения от того, что я отвечаю за счет за другого парня. лажа :)

Джодрелл

Микеланджело создал работы, которые помнят до сих пор, как звали людей, которые хотели, чтобы он закончил раньше, или использовал более дешевую краску, меньше рабочей силы и т. д.? Конечно, более вероятно, что человек, о котором идет речь, просто плохой декоратор.

Павел

Как старший разработчик, вы оба правы. Это поиск баланса, к которому вы должны стремиться.

Во-первых, с вашей стороны ваши требования должны быть четко детализированы. Я бы рекомендовал использовать подход разработки, основанной на поведении (BDD) . Это позволяет детализировать ваши требования и убедиться, что программное обеспечение им соответствует.

В настоящее время рекомендуется следовать практике разработки через тестирование (TDD). В этом случае разработчик пишет «достаточно» кода для решения проблемы — написав неудачные тесты и заставив их пройти. Эти определения BDD будут отправной точкой. Дальнейшие модульные тесты будут исключены, но как только все тесты BDD станут зелеными, вы можете быть уверены, что требования выполнены.

На протяжении всего этого ожидается, что вы продолжите диалог — обычно в начале и в конце разработки. Это гарантирует, что обе стороны понимают требования, устраняя любую двусмысленность. Кроме того, в этом разговоре можно было бы обозначить важность или ценность запроса.

Важно, чтобы код был ясным и понятным для будущей разработки и обслуживания. Однако следует соблюдать баланс между постоянной полировкой и предоставлением ценности.

Если вы и он этого не сделали — я бы посоветовал прочитать «Чистый код: руководство по Agile Software Craftsmanship» Роберта К. Мартина .

Что касается ваших дебатов об ORM, у ORM есть свои плюсы и минусы. Как вы подчеркнули, они могут быть медленными и неэффективными при плохой настройке . Кроме того, написание встроенного SQL может добавить дополнительную связь между базой данных и кодом. Почему бы просто не вызывать хранимые процедуры ?

Вероятно, есть столько же статей о том, почему вы должны, чем о том, почему вы не должны использовать ORM в Интернете. Однако запрос, выполнение которого занимает четыре часа, особенно если его можно оптимизировать до 30 секунд, неприемлем.

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

Крис Хейс

Ребята, я знаю, что множество людей начинали с Stack Overflow, но вас там больше нет. Перенесите технические обсуждения в чат.

край

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат . (копия @Lilienthal)

Дэйв Джонсон

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

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

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

Если вы не считаете, что форматирование является проблемой, просто введите в Google фразу «пробел или программирование с отступом» и удивитесь всему этому. То, как форматируется код, во многом определяет его удобство сопровождения в долгосрочной перспективе. Кроме того, ознакомьтесь с некоторыми из этих книг , рекомендованных Джеффом Этвудом. Все они хороши и помогут вам лучше понять, почему вы так же неправы, как и ваш разработчик.

В конечном счете, вам нужно перестать конкурировать с разработчиком. Вы находитесь на противоположных сторонах спектра, и если вы оба просто скажете: «Я прав», вам никогда не станет лучше. Вы должны попытаться понять, откуда он исходит, и, надеюсь, он увидит ваши усилия, а затем попытается понять, откуда вы исходите. Возможно, если вы попытаетесь оптимизировать 4-часовой запрос, используя другую «лучшую практику», которая все еще выглядит хорошо, он поймет лучше.

Некоторые ссылки на несколько методологий разработки:

Есть много других. Некоторые будут хорошими, некоторые будут плохими. Некоторые больше не используются по какой-то причине. Наша работа оплатила семинар по Agile, на котором мы рассмотрели Agile в целом и выбрали подмножество этих принципов для реализации. Это помогло нам во многих отношениях, а также помешало нам в паре. Это намного лучше, чем то, что мы делали раньше, но в нашем случае проблема была связана с процессом.

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

Бенуберд

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

Бенуберд

Конкретный 4-часовой запрос можно было бы оптимизировать по-другому, таким образом, чтобы он был счастлив его использовать, но это добавило бы больше недели работы (вероятно, две) ко времени разработки. Учитывая, что вся задача, за исключением этого запроса, заняла меньше недели, я не думаю, что затраты времени оправданы.

Дэйв Джонсон

@Benubird В обоих случаях я говорю «итак?» Если вы знаете, как заставить его задуматься, вы должны это сделать. Но, может быть, менее конкретно. Найдите общий подход, который заставит его быстрее сосредоточиться на хорошем коде. В Agile есть целый ряд методологий, которые помогут в этом. И правильное программирование иногда требует больше времени, и это всегда оправдывается повышением производительности позже.

Ипнипн

"это всегда оправдано повышением производительности позже" - будьте осторожны при использовании always ; Я могу придумать множество исключений из этого утверждения.

ТехЗен

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

Я был бы обеспокоен тем, что вы застряли с программистом из «культа груза» или «поваренной книги», то есть с тем, кто не понимает своего дела, а просто подражает примерам других.

Возможно, он цепляется за шаблоны и форматирование с таким упорством, чтобы замаскировать, что на самом деле не понимает нюансов того, когда какие шаблоны и практики использовать. Он использует моральные аргументы о личной и профессиональной честности, которые, как он утверждает, требуют от него писать код «Единственным верным способом», чтобы скрыть тот факт, что он не знает другого способа написания кода.

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

В частности, передовая практика может сильно различаться между небольшими магазинами, такими как ваш, и крупными учреждениями. В небольших магазинах основными требованиями являются скорость, гибкость, исполнение и, прежде всего, доставка. Если вы малы и не шипперите, вы умрете. Такие вопросы, как форматирование и стиль, не имеют большого значения, потому что люди, которые поддерживают код, скорее всего, будут теми, кто его написал. Небольшие магазины выполняют больше работы «под ключ», где ручная настройка производительности является важной добавленной стоимостью.

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

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

Я думаю, вам нужно проверить его, чтобы выяснить, какой именно программист он на самом деле, т.е. является ли он высокомерным, придурком primo uomo с навыками или некомпетентным, который прячется за фасадным перфекционизмом. Прикажите ему создать оптимизированный вручную код, как вы написали, просто посмотрите, сможет ли он на самом деле это сделать.

Если у него есть навыки, но он просто ценит форму, а не функцию, то вы, возможно, сможете привести его к осознанию того, что не существует такой вещи, как универсальные «лучшие практики» и определенно не существует такой вещи, как универсальное «лучшее форматирование».

Но держу пари, вы обнаружите, что ему не хватает навыков. В лучшем случае он программист поваренной книги, а не хакер-ковбой, который может работать без структуры и правил, если придется (даже если ему это не нравится). Держу пари, вам придется его отпустить.

джеймскф

Хотел бы я проголосовать за это около 20 раз. Я вижу слишком много людей, которые рассматривают любую методологию, которую им довелось изучать в школе, как Единственный Верный Путь — хотя, возможно, мне не следует жаловаться, поскольку я выгляжу хорошо, когда выжимаю из их кода улучшение производительности на пару порядков. :-)

Луан

+1 д. Хотя на самом деле я встречал довольно много людей, которые были компетентны и в то же время полностью бизнес-слепы. Насколько компетентными они были на практике, в большей степени зависело от менеджера/руководителя группы – научиться использовать его сильные стороны и ограничивать его слабости. Это большая часть того, чтобы быть лидером. Конечно, он также мог быть просто придурком, но это действительно не то, что ОП может решить самостоятельно. Но, в конце концов, ваша цель — наилучшая ценность для компании и клиента — обычно это означает некоторый компромисс между хорошей ремонтопригодностью и производительностью/скоростью реализации.

рейраб

+1 за "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% имеет большое значение. Хорошие инженеры знают разницу

Уэйн Вернер

Мне очень нравится изображение, которое я нашел в твиттере - все (*) в масштабе. Либо код медленнее, либо быстрее. Команды больше или больше. Код работает более-менее. Хитрость заключается в том, чтобы решить, где провести черту в каждом конкретном случае.

ТехЗен

@Luaan - я не уверен, что мы здесь говорим о «бизнес-слепоте». По моему опыту, мало что известно о корреляции между навыками и гибкостью программирования и управлением/организацией бизнеса. У них действительно разный набор навыков. На самом деле наличие программистов в качестве менеджеров — относительно новая разработка. В начале 90-х большинство людей, которые управляли самими программистами, не имели опыта программирования, потому что еще не было достаточного количества людей, прошедших через трубу. Я не думаю, что этот человек слеп к бизнесу, он слеп к программированию или, по крайней мере, имеет узкое зрение.

ТехЗен

@WayneWerner - я сказал одному из своих профессоров в колледже, что это выглядело так: «независимо от того, что вы делаете, это компромисс». В моем юношеском идеализме я не думал, что так должно быть, но мой профессор сказал: «Да, этот второй закон термодинамики — х**ня». Он был прав. В конечном итоге это сводится к реальной физике 2-го закона. Если вы вкладываете энергию в одну функцию или что-то еще, вы должны украсть ее у другой. Бесплатного обеда не бывает

Еще один случайный пользователь

+1 «Мне кажется, что ваш кодер зациклен на« передовых методах »для крупного институционального программирования, а не передовых методах программирования для небольших компаний».

Адам Дэвис

Как объяснить программисту бизнес-приоритеты?

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

Ему нужны входные данные в виде запросов функций, а выходные данные — в виде идеального кода.

Ваше желание научить его принимать решения или заботиться о бизнесе не является плохим желанием, но в этом случае вам следует отложить это желание в сторону и сосредоточиться на бизнес-приоритетах — сделать этого программиста продуктивным.

Когда у вас есть система, которая не работает, вы можете открыть ее и повозиться с внутренними компонентами, или вы можете возиться с вводом, пока он не выдаст правильный результат.

В этом случае я предлагаю вам возиться с вводом в программатор, а не пытаться изменить программатор.

У меня постоянные разногласия с программистом по поводу качества кода.

Перестаньте спорить об этом.

Коротко и мило:

  • Не позволяйте ему вести разговор о «качестве кода».
  • Не говорите ему, что он делает что-то неправильно или зря тратит время.
  • Не верьте, что он действует непрофессионально, даже если вам это ясно.
  • Примите его объяснение «Это не моя работа» и сообщите ему ТРЕБОВАНИЯ .
  • Все запросы на будущие задачи теперь должны быть сделаны в письменной форме (можно по электронной почте) с последующим обсуждением.
  • Все запросы задач имеют жесткие, объективные ограничения на время, которое он может потратить на задачу, и на то, насколько эффективной должна быть задача.

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

Описание:

Нам нужно реализовать, протестировать и развернуть функцию X к пятнице, 3 июня.

Требования:

  • Должен включать тестовый пример, выходящий за пределы, и правильную работу.
  • Выполнение в производственной базе данных SOME_DATABASE не должно занимать более 180 секунд.
  • Должен пройти тестирование LINT / и т. д. для стандартов кодирования компании.

Затем во время обсуждения выясните, есть ли у него проблемы с требованиями. Если да, то вы выполняете задание или переделываете требования под его возможности. Отнимите у него тяжелую работу и справьтесь с ней сами — между вашей и его работой должно быть четкое разграничение. Когда он терпит неудачу, не пытайтесь «исправить» его — выясните, почему он не оправдал ваших ожиданий, и составьте требование, которое поможет сообщить ему о ваших ожиданиях для следующей аналогичной задачи.

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

В этот момент я обычно произносил несколько примирительных фраз о том, что люди должны иметь возможность меняться и постоянно повышать свои навыки, но сейчас вам просто нужно сосредоточиться на понимании собственных требований, а затем четко изложить их ему. Как только вы разберетесь с общением , вы можете перейти к тому, чтобы помочь ему улучшить свои навыки, чтобы он мог написать запрос ORM, который выполняется вовремя. А до тех пор общайтесь, общайтесь, общайтесь и примите тот факт, что некоторые задачи вам придется выполнять самостоятельно.

КоллинВ

+1 Люди так часто смешивают требования и решения, особенно когда они носят две шляпы. Очень редко существует абсолютное и единственно правильное решение, поэтому споры о том, какая реализация лучше, контрпродуктивны, если требования не ясны, не измеримы и не задокументированы.

папарацци

Это больше касается практики кодирования, чем бизнес-приоритетов.

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

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

Зачем программисту использовать ORM, запуск которого занимает 4 часа? На проверку уйдет 4 часа. Если бы программист боролся за то, чтобы перейти на SQL, чтобы сократить 8-секундный запрос на 4 секунды, а бизнес сказал, что 8 секунд достаточно, и мы хотим оставить ORM для удобства обслуживания, тогда я бы получил эти дебаты.

А как убедить программиста? Я бы назвал это скорее вопросом кодовой практики, чем бизнес-приоритетами. Бизнесу не нужно доказывать, что 30-секундный поиск лучше, чем 4-часовой. Я использую ORM только потому, что написание сырого SQL - плохая практика, просто неприемлемая. Если язык и платформа поддерживают необработанный SQL, это приемлемо. Программист должен быть включен в программу корректирующих действий, и HR должен быть вовлечен. Если вы не его босс, то идите к его боссу.

Джейн С

Я полностью согласен. Я старший разработчик, и очень важно адаптировать технологию к задаче, а не наоборот...!

HLGEM

Худшая практика — не писать SQL, когда того требует ситуация. Он слишком невежественен, чтобы знать это. Никому не должно быть разрешено прикасаться к ORM без основательного опыта написания кода SQL, потому что, если вы не понимаете, что нужно базе данных, вы невежественны и причините вред системе. Данные никогда не бывают черным ящиком, который вам не нужно понимать. Значение данных и то, как они структурированы, имеют решающее значение для получения правильного ответа. ORM в руках того, кто знает, что делает, — хорошая практика, в руках новичка — ожидающая беда.

Лорд Фаркуад

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, чтобы он не доставлял хлопот программисту.

Короче говоря, чтобы получить желаемое, нужно перестать спорить и начать сотрудничать.

Зиббобз

Похоже, он дал этому разработчику много шансов объясниться, а этот разработчик — нет. Слушать и понимать своих программистов — это одно, позволять им диктовать структуру приложения на пагубном уровне недопустимо.

Теластин

@Zibbobz - как ты думаешь? Совершенно ясно, что программист говорит: «Чистота кода важна для меня». Они могут быть не в состоянии четко сформулировать , почему , но затем менеджер должен разобраться в этом - он должен быть квалифицированным коммуникатором в этой роли. Я не говорю, чтобы они диктовали что-то, но заставлять их делать что-то по-твоему (микроменеджмент) так же плохо.

IDRinkandIKnowThings

@Telastyn - Вы предполагаете, что «чистота кода важна для меня», но для меня это больше похоже на структуру кода, которую я делаю, и я отказываюсь использовать другой шаблон проектирования, потому что мне нравится шаблон, который я использую. Несмотря на то, что паттерн, который использует программист, малоэффективен и малоэффективен для поставленной перед ним задачи.

джеймскф

Re «Лучшие практики таковы по какой-то причине». Да, но слишком часто причина в том, что человек, распространяющий определенный набор «лучших практик», думал, что они будут продаваться лучше, если он назовет их «лучшими», а не «мой личный вкус». (Пища для размышлений: если практики действительно «лучшие», почему так много разных?)

Теластин

@jamesqf - некоторые внутренние документы - не лучшая практика. Общий консенсус экспертов (например, рецензируемые ответы на SE) гораздо ближе.

джеймскф

@Telastyn: Я предполагаю, что «лучшие практики» здесь означают то, что ОП называет учебниками по стилю кодирования, шаблонами проектирования, различными методологиями с модными словами (на ум приходит Agile) и тому подобное. Все утверждали, что их верующие были «лучшими», без, насколько мне известно, объективных доказательств.

Флориан Хейгл

«Чего вы не сделали, так это прислушались к бизнес-приоритетам вашего программиста». как получилось, что он выбирает свой собственный, особенный, другой набор бизнес-приоритетов? разве что он вложил деньги и владеет долей компании?

Теластин

@FlorianHeigl - потому что он эксперт (или, по крайней мере, так близко к эксперту, как эта компания). Игнорирование советов ваших экспертов — это быстрый и простой способ потерпеть неудачу.

Дрю Джордан

Честно говоря, я бы дисциплинировал парня и уволил бы его, если бы это было необходимо. В ответах, уже опубликованных здесь, есть несколько хороших моментов, касающихся гибкости подходов к проблемам, поэтому я не буду их перефразировать.

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

Теперь он отказывается работать над этой частью программы.

Неприемлемо и по-детски, а также отказ выполнять обязанности на работе , что, по моему мнению, является основанием для увольнения.

но он просто говорит «нет, это не так» и продолжает писать свой стильный, неэффективный код, который мне иногда приходится плохо переписывать, прежде чем его можно будет использовать.

То же самое.

Я могу только представить (и надеяться), что в своем разочаровании вы немного приукрасили, и я надеюсь , что как его «технически» менеджер вы сможете придерживаться более высоких стандартов и не вступать с этим человеком в детские разногласия. Тем не менее, если ситуация такова, как вы говорите, сотрудник негибок до отказа. Потенциально вы могли бы получить некоторое образование и рекомендации о том, как обращаться с трудными людьми, но, в конце концов, этот сотрудник категорически отказывается улучшать продукт, основанный на эзотерических стандартах. Есть только один способ, которым это может повлиять на ваших клиентов, и это плохо. Каким бы хорошим ни был этот программист, в какой-то момент он станет обузой для компании (а может быть, уже стал).

В конце концов, вы нанимаете их для создания рабочего продукта, а не красивого кода. Если они не могут этого сделать, значит, они не выполняют свою работу.

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

Бенуберд

К сожалению, не приукрашивание - сегодня утром я пытался ему это объяснить, а он надел наушники и отвернулся, пока я говорил. Он говорит (цитата): «Я программист. Мне платят за то, чтобы я программировал, а не думал о бизнесе». Проблема в том, что большая часть его кода очень хороша, и мы не можем позволить себе платить рекрутеру, чтобы найти кого-то нового, или потратить несколько недель на их обучение.

Дрю Джордан

Что ж, тогда вам предстоит принять трудное решение: такое отношение во всех смыслах неправильно. Дисциплинарные меры скорее всего не вызовут у него еще большей обиды на вас, что тоже не к добру. Вам придется решить, хотите ли вы просто иметь с ним дело или пройти через боль, пытаясь найти кого-то нового и обучить его. Совершенно ясно, что лучше в долгосрочной перспективе... Использует ли ваша компания стимулы? Может быть, вы можете связать какое-то вознаграждение/наказание непосредственно с целями бизнеса.

Зиббобз

@Benubird Может ли ваша компания позволить себе в долгосрочной перспективе удерживать этого упрямого программиста, который отказывается слушать своего босса? Если нет, то они должны начать инвестировать в набор уже сейчас .

Флориан Хейгл

@DrewJordan Спасибо за этот пост. Это была моя мгновенная мысль, когда я начал читать вопрос. после всех ответов я не заметил, чтобы мое впечатление изменилось.

Корт Аммон

Возможно, вам придется выяснить, что он считает важным. «Хороший стиль» — это просто стиль. Он должен согнуться, чтобы удовлетворить потребности бизнеса, и он должен это знать. Тем не менее, может быть основной страх, с которым он имеет дело, и с которым необходимо справиться.

В качестве примера я работал в команде, которая постоянно производила программное обеспечение более медленными темпами, чем требовалось клиентам. Руководство постоянно злилось на нас. У нас была веская причина для медлительности. Руководство создало враждебную среду разработки, в которой ни одна часть кода не могла быть изменена без явной команды сделать это от нашего клиента. К сожалению, у нас было явное требование поддерживать это программное обеспечение в течение десятилетий, в то время как мало кто из наших клиентов когда-либо думал больше, чем на месяц вперед, что делало невозможным убедить их в долгосрочной рентабельности инвестиций. На нас была возложена большая ответственность за программное обеспечение, но практически не было полномочий что-либо с этим делать. Наша мантра звучала так: «Первый рабочий прототип, показанный заказчику, станет вашей окончательной реализацией». Мы так и не разрешили этот контрольно-пропускной пункт. Руководство никогда не работало с нами, чтобы поддержать программу в соответствии с нашими обязанностями (нам фактически было приказано не пытаться решить ее, потому что простое поднятие вопроса могло поставить под угрозу продолжение финансирования). Вместо этого программа умерла, потому что никто не стал решать основную проблему сбоя в бизнесе.

После этого мы как разработчики потратили много времени, пытаясь выяснить, что именно пошло не так, и что мы могли бы сделать в следующий раз, чтобы этого избежать. Одним из наших выводов из этого упражнения была ценность наличия нескольких способов решения проблемы. Ему нравится стиль ORM, в то время как вы экономите эоны вычислений с помощью команды SQL или двух? Сделайте так, чтобы оба могли существовать бок о бок. Довольно часто ценность подхода не очевидна для другой стороны до тех пор, пока он не будет завершен. Позвольте обоим стилям сосуществовать в дикой природе и выясните, какой из них выживает в суровых условиях бизнеса. Развивайте чувство гармонии между подходами вместо того, чтобы пытаться диктовать один подход, чтобы управлять ими всеми. Возможно, он делает всю свою первичную разработку, используя свой экстремальный стиль, но конечный продукт требует добавления хаков.

Если он не принимает это, то он действительно не прав. Он не голос компании, он просто сотрудник. Его голос является частью целого, а не центром целого (если только вы не наняли его быть центром). Сотрудник, который не может проявить гибкость, потому что придерживается принципов, противоречащих потребностям компании, действительно должен быть уволен. Но, наоборот, у разработчиков есть точка зрения на программное обеспечение, которую нельзя найти больше нигде. Бизнесу действительно нужно приспосабливаться, когда разработчик указывает на проблему, которую трудно увидеть кому-либо еще.

Цель состоит в том, чтобы выяснить, как обеспечить сосуществование двух точек зрения достаточно долго, чтобы их можно было изучить должным образом. Однако это может в конечном итоге потерпеть неудачу, если одна сторона особенно застряла в грязи. В этот момент вам нужно будет провести вежливую беседу, объяснив, что его стиль кодирования не является центром мира, и если он будет мешать бизнесу, ему будут давать задачи, которые дают ему все меньше и меньше свободы в подходах. ему разрешено брать. В качестве альтернативы он может согласиться на такие вещи, как «размер зарплаты» в обмен на свободу выполнять свою работу.

Я не хотел создавать еще один ответ, предлагающий итеративную разработку, но я хотел добавить его в конец своего ответа. Итеративная разработка дает ему возможность изучить «хороший стиль» за одну итерацию, а затем заставить вас применить бизнес-барашки, чтобы превратить его в полезный продукт. Вы можете априори не знать, что задачу можно выполнить за 30 секунд. Однако после первой итерации у вас должно появиться ощущение времени. Это ощущение времени должно позволить вам обеспечить временные требования во второй итерации.

Если вы даете бизнес-требование, чтобы запрос занял менее 5 минут, а он говорит, что это невозможно, то вежливо заберите у него задачу и сделайте ее сами. Пусть вертит пальцами, пока не начнет понимать, что его зарплата в опасности.

Майк

Лучший ответ, который я читал по этому вопросу, взят из FAQ по C++.

https://isocpp.org/wiki/faq/big-picture#biz-dominates-tech

Вам это может не понравиться, но краткий ответ: «Нет». (С оговоркой, что этот ответ адресован практикам, а не теоретикам.)

Зрелые разработчики программного обеспечения оценивают ситуации на основе бизнес-критериев (время, деньги и риск) в дополнение к техническим критериям, таким как «хороший объектно-ориентированный подход» или «хороший дизайн класса». Это намного сложнее, поскольку включает в себя вопросы бизнеса (график, квалификация людей, выяснение того, куда компания хочет двигаться, чтобы мы знали, где обеспечить гибкость программного обеспечения, готовность учитывать вероятность будущих изменений — изменений, которые вероятно, а не просто теоретически возможно и т. д.) в дополнение к техническим вопросам. Однако это приводит к решениям, которые с большей вероятностью принесут хорошие результаты в бизнесе.

Как разработчик, вы несете фидуциарную ответственность перед своим работодателем за инвестирование только такими способами, которые имеют разумные ожидания возврата этих инвестиций. Если вы не зададите деловые вопросы в дополнение к техническим вопросам, вы будете принимать решения, которые будут иметь случайные и непредсказуемые последствия для бизнеса.

Нравится вам это или нет, но на практике это означает, что вам, вероятно, лучше оставить такие термины, как «хороший дизайн класса» и «хорошее объектно-ориентированное программирование», неопределенными. На самом деле я считаю, что точные, чисто технические определения этих терминов могут быть опасными и могут стоить компаниям денег, а в конечном итоге, возможно, даже лишить людей работы. Звучит странно, но на это есть веская причина: если эти термины определены в точных, чисто технических терминах, благонамеренные разработчики склонны игнорировать деловые соображения в своем желании соответствовать этим чисто техническим определениям «хорошо».

Любое чисто техническое определение «хорошего», такое как «хорошее объектно-ориентированное проектирование» или «хороший дизайн» или что-то еще, что можно оценить без учета графика, бизнес-целей (чтобы мы знали, куда инвестировать), ожидаемых будущих изменений, корпоративной культуры с уважение к готовности инвестировать в будущее, уровень квалификации команды, которая будет выполнять техническое обслуживание и т. д., опасно. Это опасно, потому что это обманывает программистов, заставляя их думать, что они принимают «правильные» решения, тогда как на самом деле они могут принимать решения, которые могут иметь ужасные последствия. Или эти решения могут не иметь ужасных последствий для бизнеса, но в том-то и дело: когда вы игнорируете соображения бизнеса при принятии решений, последствия для бизнеса будут случайными и в некоторой степени непредсказуемыми. Плохо.

Дело в том, что деловые вопросы преобладают над техническими, и любое определение «хорошего», не учитывающее этот факт, является плохим.

Принсиг

Рассмотрим это утверждение:

  • Как программист, создание достаточно эффективного кода является частью вашей работы, так же как умение быстро печатать является частью работы машинистки.

Затем покажите ему пример того, как можно радикально улучшить его код.

Если он не может (или не хочет) соединить точки между этим утверждением и вашим примером, вам нужно избавиться от него. Это похоже на представителя службы поддержки, который отказывается пользоваться своим телефоном, потому что предпочитает отправлять клиентам электронные письма.

IDRinkandIKnowThings

Похоже, что ОП пробовал это, и программист несколько раз отказывался от «улучшенных» версий.

Йорген Фог

Тогда применяется вторая часть ответа: «... вам нужно избавиться от него».

скрежет729

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

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

Вам нужно убедить своих разработчиков не переусердствовать, и они должны убедить вас, что несоблюдение какого-либо ограниченного стандарта иногда дорого обходится в краткосрочной перспективе, а часто и в долгосрочной. С другой стороны, дороговизна в долгосрочной перспективе может быть приемлемой, если только за счет доставки в короткие сроки бизнес выживет достаточно долго, чтобы беспокоиться о долгосрочной перспективе. Если вы не можете убедить своих разработчиков производить правильныеколичество качества, и это стоит вам денег, вам, возможно, придется отделить. (Очевидно, что если кто-то производит низкое качество за восемь часов, а кто-то другой производит высокое качество за восемь часов и его нельзя заставить производить низкое качество за шесть часов, вы все равно предпочитаете второго разработчика. Или если этот разработчик счастлив, создавая высокое качество и продуктивным, а заставляя его отказываться от качества, вы делаете его несчастным и непродуктивным, это тоже никуда не годится).

Другой вопрос: похоже, ваш разработчик настаивает на каком-то формальном подходе, который является неэффективным, вместо того, чтобы использовать неформальный подход, который очень эффективен (когда неэффективность на самом деле является проблемой для бизнеса). В этом я вижу серьезную проблему. Если у бизнеса есть проблема, которую необходимо решить, то любая техника, которая не решает проблему, неприемлема, и настаивать на такой технике, зная другую, решающую проблему, я считаю неприемлемым.

При необходимости разработчик должен не стесняться добавлять комментарии к коду с разглагольствованиями о том, почему техника, которую он использует, намного хуже другой техники, но это нужно было сделать для эффективности. (На самом деле было бы неплохо записать причины, если его спросят, почему он использовал этот подход через два года.) Тем не менее, то, что нужно сделать, нужно сделать.

джеймскф

Я не согласен с тем, что программист "хочет создавать код самого высокого качества". Скорее он усвоил определение качества, которое придерживается абстрактных академических (я бы даже сказал квазирелигиозных) стандартов, но не имеет никакого отношения к стандартам, необходимым его работодателю, то есть что код работает в практическом времени. , и быть ремонтопригодным. (Код, написанный в соответствии с определенным академическим стандартом, иногда непонятен людям, незнакомым с этими стандартами.)

Джошуа

Одно из моих высказываний: «лучшие практики не полны по Тьюрингу».

Зиббобз

Это проблема с его отношением, и его нужно изменить.

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

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

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

И на индивидуальном уровне ваша группа в любом случае должна провести проверку кода, прежде чем вы сделаете коммит, так что воспользуйтесь этой возможностью, чтобы просмотреть его хорошо отформатированный, но крайне неэффективный код и шаг за шагом объяснить, почему он неэффективен.

Если он отказывается меняться, поручите сдачу кому-то другому или возьмите на себя. К сожалению, это может быть признаком того, что он совершенно не работает в группах, и вам, возможно, придется отпустить его или найти другую группу, которая лучше работает с его «всегда строгим» стилем кодирования.

Бенуберд

Я пытался объяснить, что передовой опыт не всегда является лучшим решением, но он просто не понял — должно быть, я не очень хорошо объясняю. Я не думаю, что вы могли бы указать мне на какие-то ресурсы, которые объясняют это, может быть, лучше, чем я?

Зиббобз

@Benubird Я бы указал вам на ответ на этот вопрос, получивший наибольшее количество голосов. ;) Хотя, если вы хотите что-то более конкретное для отдельных проблем, есть целый SE, посвященный таким вещам.

IDRinkandIKnowThings

@Benubird - я бы порекомендовал вам прекратить попытки оспаривать «лучшие практики» и вместо этого предложить ему найти способ применить эти лучшие практики таким образом, чтобы это имело смысл для бизнеса.

Зиббобз

@ReallyTiredOfThisGame «Не всегда» лучшее решение не означает «Никогда» лучшее решение. Лучшие практики называются так не просто так, но работающий код важнее красивого кода.

IDRinkandIKnowThings

@Zibbobz - согласен. Но когда вы бросаете вызов твердому убеждению кого-то, он немедленно чувствует необходимость защищать свою веру, и поэтому любой вызов этому убеждению должен быть защищен, а любые другие моменты, как правило, игнорируются. Так что вместо того, чтобы напрямую оспаривать эти убеждения, позвольте программисту самостоятельно определить, что есть другие способы сделать что-то. Скорее всего, если это намного менее эффективно, программист все равно неправильно применяет лучшие практики.

Зиббобз

@ReallyTiredOfThisGame Когда вы позволяете кому-то врезаться в стену, он либо остановится, когда поймет, насколько это больно, либо будет продолжать, пока не уничтожит себя. Я думаю, что если это повторяющаяся проблема, которую он все еще отказывается менять (и это если она повторяется и вызывает проблемы с приложением), то пришло время заняться этими проблемами напрямую.

IDRinkandIKnowThings

@Zibbobz - И если бы заданный вопрос был «должен ли я избавиться от этого программиста», то это был бы правильный ответ. ОП спросил, как он может связаться с программистом. Точно так же, как ОП хочет, чтобы программист был эффективным, ОП спрашивает, как он может быть более эффективным менеджером. Поэтому вместо того, чтобы предлагать ему удариться о стену другим способом, предложите ему поискать способ обойти стену. (ваша метафора не моя)

Зиббобз

@ReallyTiredOfThisGame Не сбрасывайте со счетов ответ «избавьтесь от этого программиста». Тем не менее, похоже, что у вас есть собственное решение этой проблемы - может быть, вы должны опубликовать его? Я признаю, что в этом ответе есть недостатки, которые могут быть устранены другим ответом.

IDRinkandIKnowThings

@Zibbobz - я думаю, что по большей части ваш ответ точен. Я просто пытался ответить на комментарий Benubirds, где он сказал, что пытался объяснить, что лучшие практики не всегда были лучшими. По сути, пытаясь заставить его реализовать ваш ответ немного иначе, чем он пытался в прошлом.

Си Джей Деннис

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

  • Он должен работать приемлемое количество времени
    • Приемлемый может означать не менее 95% или не менее 100% - это ваше определение.
  • Это не должно вызывать побочных эффектов в другом коде/системах (см. первый пункт)
  • Он должен быть ремонтопригодным
    • Хорошо отформатированный код намного легче поддерживать, чем плохо отформатированный код.
  • Он должен быть доставлен к сроку (когда бы он ни был, и помня, что сроки могут быть сброшены в зависимости от потребностей бизнеса)
  • Он должен быть доступным
  • Наверное много других моментов

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

Некоторые программисты не пойдут на компромисс в отношении качества (я признаю, что я один из них) из-за огромного количества дополнительного времени, необходимого для устранения неполадок, исправления ошибок и последующей перезаписи. Я сознательно не позволю новой ошибке появиться в сети.

Однажды я работал над огромным, плохо написанным проектом. Код был унаследован от третьей стороны, и над ним работали очень хорошие разработчики. Бизнес продолжал просить сделать его лучше, а мы продолжали говорить: «Это настолько хорошо, насколько это возможно». В конце концов мы добились того, что код стал работать лучше, но на это ушло от 6 месяцев до года, и у нас никогда не было четкого представления о том, как заставить код работать быстрее. Когда мы говорили: «Это настолько хорошо, насколько это возможно», на самом деле мы имели в виду: «Мы исчерпали все наши текущие идеи».

Ваш программист может быть в похожей ситуации. Он буквально делает все возможное и не может придумать лучшего способа сделать что-то. Вероятно, ему не нравится, когда его насильно кормят определенными идеями, и он автоматически отвергает их. Если он независимо придумает одну и ту же идею, вы оба выиграете! Поскольку компания небольшая, у него, вероятно, не так много возможностей обмениваться идеями с другими людьми или получать идеи нестандартного мышления от людей, которые не так близки к проекту.

Поработав над чужим кодом, могу сказать, что иногда мне приходилось тратить полчаса на переформатирование кода, прежде чем я мог его понять. Код форматирования важен для эффективности вашего программиста, даже если он может работать одинаково.

Не пытайтесь убедить своего программиста принять «плохой код». Объясните, почему есть несколько способов сделать одно и то же, и только потому, что один из них является «хорошим кодом», это не делает другие автоматически «плохим кодом». Вы должны показать ему, что вы на его стороне. Вы тоже хотите хороший код! Но затем определите, что такое хороший код. Если быть эффективным важно, тогда дайте ему задание сделать его эффективным! Четко сформулируйте ожидаемый результат. Например, нам нужно запускать этот запрос 1000 раз в час, а это означает, что он должен выполняться не реже одного раза каждые 3,6 секунды (что, вероятно, ужасная производительность!)

Его наняли в качестве технического эксперта, а не бизнес-эксперта. Таким образом, его профессиональные цели могут быть не такими, какими вы хотели бы их видеть. Вам нужно объяснить, как то, что он делает, влияет на остальную часть бизнеса, а также понять, как остальная часть бизнеса влияет на его работу. Я бы не рекомендовал управлять им, если только вы не планируете его уволить.

Вы также можете изучить возможность автоматического форматирования кода. Таким образом, он мог сосредоточиться на программировании и с помощью макроса или небольшой утилиты переформатировать код так, как ему нравится, менее чем за секунду. С SQL я согласен с ним, что напрямую написанные запросы — это плохо, но, например, в PHP вы можете использовать PDO для выполнения точно таких же запросов с очищенным вводом. Это хорошая практика! Должен быть компромисс, при котором вы получаете желаемую скорость, а он получает «хороший код», который ему нужен.

Я бы также предложил, чтобы он профилировал код, чтобы найти узкие места и сделать их приоритетными для эффективности. В конце концов, если его красивый код работает быстро (и он быстро его пишет), вы не возражаете, не так ли? Вы хотите, чтобы он увидел вашу точку зрения, поэтому продемонстрируйте, что вы можете видеть и ценить его точку зрения. Вам придется возмещать ущерб, нанесенный вашим профессиональным отношениям, и важно, чтобы вы оба доверяли друг другу.

HLGEM

Нет ничего плохого в написании кода SQL, на самом деле во многих случаях это правильно. Базы данных предпочитают хорошо написанный SQl (который часто выглядит некрасиво для неспециалиста по базам данных), потому что это то, с чем они были созданы для наилучшей работы. Плохо написанный код, особенно когда он спроектирован так, что возможна инъекция SQl, — это плохо, хорошо написанный код SQL — это хорошо и часто необходимо. Проблема с ORM заключается в том, что вы теряете способность обучать кого-то, как решать сложные проблемы, для которых ORM является плохим инструментом, потому что они никогда не изучают основы SQL.

Пол Дрейпер

Это может быть сложно. Это во многом зависит от того, на что негативно влияет его поведение.


Производительность программы

Хороший программист должен понимать разделение интерфейса и реализации. Требования - "интерфейс" так сказать проекта, и хороший дизайн

Я предполагаю, что вы хотя бы частично отвечаете за требования этого проекта. Вы можете создать требование для этого сценария, чтобы он выполнялся в течение 6 минут.

Пока он соответствует требованиям, вам все равно , что он делает. (Это реализация.)

Это может помочь ему увидеть, что с точки зрения всех остальных (кто не может видеть его исходный код) его программа дерьмовая .


Время разработки

Это немного сложнее. С одной стороны, вы можете выделить время для завершения «требования» проекта, но оценка времени для завершения проекта (соответственно) остается на усмотрение человека, который его создает.

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

Саймон Рихтер

Тот факт, что этот программист отказывается работать над этим компонентом, является для меня явным признаком того, что это вопрос ответственности компонента.

С точки зрения вашего клиента, ваша оптимизация — это правильное решение: черный ящик, которым является ваша программа, работает лучше, и ваша компания как организация несет ответственность за весь этот ящик.

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

Вы не можете отделить эту ответственность от полномочий по принятию решений.

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

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

IDRinkandIKnowThings

На самом деле это не ответ на вопрос, а повторный анализ проблемы ... этого уже было много.

Саймон Рихтер

@ReallyTiredOfThisGame, ответ - взять на себя ответственность за решение. Ни один из других ответов не говорит об этом.

Питер М. - расшифровывается как Моника

Скажите ему, что его работа НЕ состоит в том, чтобы писать программы как таковые — его работа состоит в том, чтобы писать код, приносящий прибыль компании.

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

Кроме того, вы можете объяснить, что он может писать программы для развлечения и удовольствия (или для улучшения своих навыков) в свободное время, и многие программисты так и делают. Но программы, написанные на время компании, должны приносить прибыль компании.

Если он отказывается изменить свой стиль (возможно, чтобы сделать код, возможно, менее красивым, но существенно улучшающим производительность), спросите его, как бы он хотел, чтобы компания платила ему так же: всего 10% от его зарплаты, но с использованием действительно приятного цвета. распечатанный чек. Произведение искусства, написанное от руки и подписанное генеральным директором, он может повесить его на стену :-)

Да, прагматичные решения иногда накапливают технический долг — ( википедия ), чтобы обеспечить ЦЕННОСТЬ для бизнеса.

Отказ принять технический долг аналогичен отказу принять финансовый долг: иногда допустимое решение — занять деньги для поставки продукта (даже если позже вам нужно будет оплатить долг).

Иметь менее чем идеально поддерживаемый, но более производительный код — это то же самое, что платить за возобновляемый кредит: это позволяет компании оставаться в бизнесе.

Если на доставку решения уходит в 10 раз больше его времени, он заслуживает только 10% от зарплаты. Если он не может принести пользу бизнесу, его следует заменить тем, кто это делает. (Я уверен, что это принесет мне несколько отрицательных голосов, потому что это откровенный наркотик, а не теплый и нечеткий язык - ну, жизнь слишком коротка. И да, отрицательные голоса льются. Вот почему я больше не участвую в этом форуме. ).

IDRinkandIKnowThings

На самом деле это не ответ на вопрос, а повторный анализ проблемы ... этого уже было много.

Джереми Френч

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

Питер М. - расшифровывается как Моника

Измененный. Очевидно, это нужно обсудить с программистом.

Питер М. - расшифровывается как Моника

Вопрос ОП: как объяснить бизнес-приоритеты программисту, который убежден, что его наняли для написания красивого кода, не обращая внимания на производительность? Как мое первое предложение НЕ отвечает на этот вопрос?

комар

«Это одно предложение является кратким изложением того, что другие люди сказали с гораздо большим количеством слов, и всего, что нужно сказать. Дело закрыто». -- это не читается как объяснение для меня. См. Резервное копирование и не повторяйте других

Питер М. - расшифровывается как Моника

Не уверен, как, по вашему мнению, мой ответ можно улучшить. Первое предложение - это действительно все, что нужно сказать. Нужно ли объяснять, почему компания должна быть прибыльной?

Питер М. - расшифровывается как Моника

Я имею в виду, что я даже привязался к объяснению, что такое технический долг, и почему и когда имеет смысл его накапливать (какой программист, вопрос, отказывается понимать). Что еще нужно объяснить?

край

Привет, Питер, хотя вы можете указать это в первом предложении, ОП ищет, как справиться с этой ситуацией. Однострочник, говорящий ему что-то сделать, не объясняя, как это должен сделать ОП, не очень полезен для них - как заявляют другие, вопрос заключается в том, «как я могу объяснить бизнес-приоритеты?»

Питер М. - расшифровывается как Моника

Насколько сложно было бы сказать это одно предложение этому одному программисту? Программист либо просветится и изменит свой подход, либо нет - и он изменит компанию.

Джошуа

Голосую за последний абзац. Всё остальное хлам.