Как вы балансируете между «делай как надо» и «делай как можно скорее» в своей повседневной работе? [закрыто]

180

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

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

Я уверен, что я не единственный, кто попал в эти бесконечные циклы реального / идеального выбора. Так как же вы, мои коллеги-программисты, справляетесь с этим?

ОБНОВЛЕНИЕ: Спасибо всем за эту интересную дискуссию. Печально, что так много людей ежедневно выбирают между количеством и качеством своего кода. Тем не менее, на удивление, многие люди думают, что в этой битве можно выиграть, поэтому спасибо всем за поддержку.

Flot2011
источник
12
Просто: сделай это правильно и сделай это быстро
Рен
158
@ Рен: Ну, я полагаю, вы не программист, вы менеджер :-)
Flot2011
44
Обязательный. xkcd.com/844
MikeTheLiar
5
Сделай это как можно скорее. Тогда, если у вас еще есть время, сделайте это правильно.
Лоран Кувиду
8
Как говорит дядя Боб: медленный путь - это быстрый путь. Не торопитесь, чтобы написать эти модульные тесты, и хорошо написать свой код. Это может привести к тому, что для реализации этой функции потребуется больше времени, но в долгосрочной перспективе это сэкономит время, поскольку другим будет легче модифицировать и исправлять ошибки.
martiert

Ответы:

106

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

В конце дня мы доставляем товар платящему покупателю. У этого клиента есть потребности и ожидания, реалистичные или нет. Часто отдел продаж доставляет нам неприятности просто для того, чтобы получить комиссию. Иногда у клиента возникают нереальные ожидания или изменения спроса, даже если у нас есть контракт. Сроки происходят. ВОМ и потерянные дни во время спринта могут случиться. Все виды мелочей могут завершиться ситуацией, когда нас заставляют загадать: «делай это правильно» или «делай это как можно скорее». Почти всегда мы вынуждены «делать это как можно скорее».

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

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

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

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

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

Тяга между разработчиками и продавцами напоминает мне шутку. «В чем разница между продавцом подержанных автомобилей и продавцом программного обеспечения? По крайней мере, продавец подержанных автомобилей знает, что он лжет». Держите подбородок и старайтесь «делать правильные вещи» на ходу.

Akira71
источник
14
«Часто команда по продажам доставляет нам неприятности просто для того, чтобы получить комиссию». В какой момент вы считаете, что продажи должны нести ответственность за продажу того, что бизнес не может доставить - при условии, что оно есть? У вас есть примеры, когда они пересекали грань между агрессивным маркетингом и перепродажей?
Том
8
@ TomW У меня есть несколько собственных примеров, подробности, которые я не мог бы опубликовать здесь, но когда это происходит, это почти всегда происходит, когда нам нужен справочный счет или ближе к концу квартала. У нас есть очень хорошие продавцы, а некоторые не очень хорошие. В последнее время произошла большая перемена в уборке дома, когда было решено, что развитие не является проблемой, и вся структура продаж изменилась в лучшую сторону. С тех пор дела идут чудесно. Я хотел бы быть более конкретным, но не могу.
Akira71
9
+1 - «Я не буду жертвовать качеством в функции, которая движет потребителями, чтобы получить его как можно скорее, но что-то пойдет» ... это было фантастически.
Джоэл Б
59
@ TomW - Я всегда хотел бы отметить, что главный военно-морской архитектор Титаника, который предостерегал от сокращения затрат (Томас Эндрюс), потерпел крушение вместе с кораблем, в то время как лучший парень по продажам / маркетингу, который призвал сократить расходы и добиться успеха как можно скорее (Брюс Исмей), сбежал. в спасательной шлюпке.
jfrankcarr
4
Мне бы очень хотелось, чтобы время набирало такой ответ, но у меня есть клиент, звонящий моему боссу по телефону. «Часто команда по продажам доставляет нам неприятности только для того, чтобы получить комиссию». То же самое и здесь ... но каким-то образом они все еще получают эти бонусы!
Кензо
62

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

Потому что вы знаете, что действительно заставит вашего менеджера заставить вас или вашего клиента разозлить? Плохое качество .

Telastyn
источник
43
Хотя обычно есть время, чтобы сделать хорошую работу, обычно нет времени, чтобы сделать это идеально. Существует огромная разница между ними.
Donal Fellows
2
@DonalFellows конечно. «Правильно» - это всегда «следовать лучшим практикам, используя наше лучшее понимание проблемы на данный момент, в меру наших возможностей». Люди делают ошибки. Требования меняются. Лучшие практики меняются. Не срезайте углы и не выполняйте рефакторинг, когда что-то происходит.
Теластин
3
@DonalFellows - «Враг совершенства - совершенство». Программа, написанная в поддерживаемом стиле, которая отвечает требованиям клиентов и делает это с приемлемой производительностью, является программой, которая «сделана». Ничего, башня из слоновой кости об этом.
KeithS
1
@DonalFellows Никто не использовал слово идеальный, идеальное решение - неправильное решение, Теластин говорит о правильном решении. Правильное решение - это то, которое отвечает требованиям и вряд ли вызовет проблемы в будущем, и в то же время простое в обращении. Абсолюты всегда неправы.
Джимми Хоффа
7
+1 - для Теластина, пока все клиенты хотят, чтобы их вещи были сделаны сейчас. ДАЛЕЕ БОЛЬШЕ клиенты хотят, чтобы их вещи работали больше, чем сейчас. Кажется, что каждый, кто не согласен с Теластином, утверждает, что потеряет клиента, если это не будет сделано быстро. Это, безусловно, исключение, а не правило. Каково правило, что большинство людей, которые не согласны, это то, что они игнорируют то, что потеряют гораздо больше клиентов, поставляя некачественные продукты. Утверждение, что клиент хочет этого сейчас, является обычным оправданием для людей, которые не заботятся о качестве. Поэтому я скептически отношусь к заявленному риску.
Данк
21

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

  • Сообщить ценность

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

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

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

  • Получить команду на той же чертовой странице

Эго часто являются проблемой. Одна вещь, которая очень нужна командам разработчиков, - это установить ценность согласованного согласованного подхода к решению определенных типов проблем, когда каждый выпивает свою чашку Kool Aid d'jour, потому что они знают лучше. Можно полагать, что предпочтения другого парня хуже, чем у вас, но цените последовательность, а не правоту, если его подход выполним, и это аргумент, который вы не можете победить. Компромисс ради последовательности является ключевым. Когда вещи согласованы, сделать их неправильно сложнее, так как последовательный установленный путь обычно также будет самым быстрым.

  • Подберите правильные инструменты

Есть две школы фреймворков / наборов инструментов / библиотек / что угодно. «Сделай для меня 99%, так что я должен знать / делать очень мало» против «держись подальше от меня, когда я не хочу, чтобы ты был там, но помогай мне самому быстро и последовательно делать вещи, которые я действительно хочу использовать на моркови, а не придерживаться принципа ". Пользуйся вторым. Гибкость и детальный контроль никогда не должны приноситься в жертву на алтаре быстрого поворота, потому что, по сути, «мы не можем сделать это, потому что наши собственные инструменты не позволят нам» никогда не будет приемлемым ответом, и вопрос всегда будет возникать для разработка тривиального / одноразового продукта. По моему опыту, негибкие инструменты почти всегда ломаются широко или обходятся нелегко и создают огромный гигантский бесполезный беспорядок. Чаще да, чем нет, Гибкие / легко изменяемые решения такие же или почти такие же быстрые в краткосрочной перспективе, независимо. Быстрое, гибкое и удобное в обслуживании возможно с помощью правильных инструментов.

  • FFS, если инженеры не решают, по крайней мере получить вклад инженера при выборе инструментов

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

  • Сосредоточиться на дизайне над реализацией

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

  • Войдите ваши проблемы

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

Эрик Реппен
источник
Очень хороший и подробный ответ. Позвольте мне добавить, что я уже столкнулся с неудачным выбором правильных инструментов , что привело к большой трате времени. Мы могли бы отгружать продукт через месяц после того, как было принято решение отказаться от него и использовать то, что нас не блокирует.
н
1
Я чувствую себя хорошо об этом ответе, но также я только нашел свою первую работу, где biz и dev не всегда находятся в глотке друг друга, и воздействие восхитительно. Мы просто делаем вещи. Не всегда так быстро, как хотелось бы, но мы действительно учитываем будущее, и это проявляется как в продукте, так и в нашей способности изменять его по мере необходимости. Неизбежный Большой Шар Грязи - ложь, IMO.
Эрик Реппен
19

Есть только одно решение. Зарезервируйте около 10-20% проектного / рабочего времени для рефакторинга. Если трудно убедить руководство в том, что это оправданная задача, приведите им единственный реальный аргумент: без рефакторинга стоимость обслуживания кода со временем будет расти экспоненциально. Хорошо иметь несколько показателей / статей / результатов исследований, чтобы поддержать этот тезис во время встречи с менеджером :)

Изменить: есть несколько хороших ресурсов по «рефакторингу против растущих затрат на обслуживание», упомянутых в этом техническом документе: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Анджей Бобак
источник
12
Есть лучший вариант: сделать рефакторинг частью вашей обычной привычки кодирования. Суточная. Ежечасно. Всякий раз, когда вы добавляете или меняете функцию. Так что вам не нужно зарезервировать для этого дополнительное время или «убедить руководство».
Док Браун
Это действительно только тогда, когда вам не нужно иметь дело с кодом, который уже написан. Обычной задачей является добавление нового значения в старый / унаследованный / унаследованный исходный код. Но когда вы смотрите на этот код, вы не знаете, с чего начать, и чувствуете, что легче написать этот код заново, чем узнать, как он работает. Попытайтесь оправдать эти оценки: два дня, чтобы добавить новое значение, шесть дней, чтобы реорганизовать старый код, чтобы сделать его поддерживаемым. Часто звучит «не рефакторинг, просто добавь новое значение, позже мы выясним, что делать с этим старым кодом».
Анджей Бобак
1
@ Flot2011 Тогда у вас есть только одно решение. Пусть повседневный рефакторинг станет вашим обычным делом. Например, каждый вторник фокусируется только на улучшении качества кода. Убедитесь, что руководство уважает его, и убедитесь, что они знают, что рефакторинг - не пустая трата времени. Без этих двух условий рано или поздно они откажутся от идеи улучшения "того, что уже здесь и работает".
Анджей Бобак
1
@DocBrown Это работает, когда вы говорите с руководством. Если вы поговорите со старшим разработчиком и скажете ему, что вы добавите два поля в форму, и это займет у вас 3 дня ... Что ж, удачи :).
Анджей Бобак
2
Потребность раздуть ваши оценки, чтобы получить время обслуживания, проблематична по ряду причин. Иногда технический долг действительно стоит понести. Что происходит, когда biz внезапно замечает, что в чрезвычайной ситуации понадобилось 15 минут, чтобы шлепнуть два новых поля, когда в последний раз это занимало 8 дней. ИМО, бизнес должен осознавать технический долг и его долгосрочное влияние. Проблему нужно понимать так: либо вы платите сейчас, либо платите в 5 раз больше, когда все сказано.
Эрик Реппен
14

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

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

Если это не помогает, есть еще «стратегия Скотти», чтобы получить достаточно времени для правильной работы: умножьте все свои оценки в 4 раза:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

Док Браун
источник
Стратегия Скотти работает. Только не говори своему боссу, что ты это делаешь. Часто время, которое требуется на самом деле, удваивается. Всегда лучше закончить рано, чем поздно.
Люк
11

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

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

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

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

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

Шейн
источник
7

Это не сработает в каждом случае, но мне посчастливилось использовать эту стратегию, если проблема связана с поломкой производства, которую необходимо срочно устранить. Оцените время, чтобы сделать быстрое исправление, чтобы запустить производство, и время, чтобы сделать исправление качества в будущем. Представьте оценки своему боссу / клиенту и получите время, утвержденное для обоих. Затем вы делаете быстрое исправление, чтобы получить запуск производства и долгосрочное исправление сразу же после того, как срочное время выключено. Я обнаружил, что если я представлю это так, как мне нужно в этот раз, чтобы сделать работу правильно, но я могу поставить временное исправление, пока я не смогу сделать это, моим клиентам, похоже, понравится такой подход. Он снова начинает работать и получает долгосрочную помощь.

HLGEM
источник
7

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

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

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

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

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

Я потратил некоторое время на работу над проектом, который должен был занять шесть месяцев. Когда я присоединился, это продолжалось полтора года. Руководитель проекта задал руководителю проекта один вопрос в начале: «Вы хотите, чтобы я сделал это правильно или был отзывчив?» Через неделю была реализована функция в понедельник, среду и пятницу; Во вторник и четверг функция была удалена.

РЕДАКТИРОВАТЬ: Когда код выполняется на удовлетворительном уровне, оставьте его. Не возвращайтесь, чтобы исправить это, если вы найдете лучший способ сделать это. Если вы должны сделать себе записку. Если требуются изменения, просмотрите вашу идею и реализуйте ее, если она все еще имеет смысл.

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

BillThor
источник
Если DRY не означает запутанную, неразборчивую реализацию массивных каскадных схем наследования. Не делай этого. Извините, я говорю это много, но я действительно ненавижу это. Также +1 для минимального рабочего решения в большинстве случаев. Иногда некоторые перспективные архитектурные особенности могут быть полезны, если вы не переусердствуете с этим.
Эрик Реппен
1
@ErikReppen Код, который сбивает с толку, неразборчив, и реализация массивных каскадных схем наследования, не соответствовала бы моему определению DRY. Если вам нужно вычислять код каждый раз, когда вы его используете, проект явно не сулит DRY, даже если реализация прошла успешно.
BillThor
Это может включать много повторного использования кода. Раздражающая часть - лазить по дереву из 18 классов или прототипов, чтобы найти фактическое определение метода, который делает что-то действительно раздражающее, особенно если есть переопределения.
Эрик Реппен
6

Заставь это работать и сделай его идеальным

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

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

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

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

Фергус в Лондоне
источник
3
Когда руководство знает, что это работает. Они принимают это как это было сделано , и не хочу , чтобы вы проводите какие - либо другие усилия на рефакторинга и т.д.
Adronius
5

«Делать это правильно» означает делать правильный компромисс для конкретной ситуации. Некоторые из них:

  1. Время разработки и стоимость
  2. Простота чтения, отладки и обновления кода позже (все от имен переменных до архитектуры)
  3. Тщательность решения (крайние случаи)
  4. Скорость исполнения

Очевидно, что если фрагмент кода будет использован один раз и выброшен, №2 можно пожертвовать ради любого другого. (Но будьте осторожны: вы можете подумать, что вы собираетесь выбросить его, а затем обнаружите, что вам нужно продолжать использовать и поддерживать его, и в этот момент будет сложнее убедить людей дать вам время улучшить то, что «работает».)

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

Если вы в настоящее время поставляете код с ошибками (слабый на # 4) и занимает много времени, чтобы сделать это (слабый на # 1), и это потому, что вы пытаетесь обновить код, который был слабым на # 2, ну, вы получил твердый, прагматичный аргумент для изменения вашей практики.

Натан Лонг
источник
1
Я бы предложил: «Если НИКТО не будет поддерживать кусок кода ...»: написание мусора, сброс и запуск не должен быть вариантом (для любого, у кого есть совесть), но это случается слишком часто; подрядчики / консультанты / менеджеры следят за тем, чтобы они были в безопасности прямо перед тем, как «это» коснется вентилятора.
Фил В.
@PhillW. - Абсолютно согласен. Отредактировано соответственно.
Натан Лонг
4

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

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

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

Лучшие компании понимают, что хорошее программное обеспечение требует времени и мастерства.

Димитрий
источник
3

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

Маной Р
источник
5
Проблема в том, что времени почти не бывает, это именно та проблема, и ошибки такого рода всегда будут иметь самый низкий приоритет.
Flot2011
Я бы сказал, что это верно только в том случае, если под «чрезвычайной ситуацией» вы подразумеваете «то, что происходит не чаще одного раза в шесть месяцев», а под «когда у вас есть время» вы подразумеваете «в течение недели или около того». В противном случае ваш следующий вопрос станет «помогать, клиенту нужно что-то как можно скорее, но код, который я должен изменить, - запутанный беспорядок, и мне понадобятся недели, чтобы разобраться!»
Натан Лонг
3

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

Matt
источник
3

Вот хороший план:

  1. Сделайте так, чтобы ваш план «сделай это правильно» занял ровно столько же времени, что и сделай это как можно скорее.
  2. Оптимизируйте свое время, чтобы сделать это, пока ваше окружение не будет счастливым; сохранить качество
  3. ???
  4. успех
ТР1
источник
1

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

Время от времени (я хотел бы сказать, что два раза в день, но два раза в неделю более реалистично), особенно когда я нахожу что-то чрезвычайно скучным, чтобы делать обычным образом, я думаю, «что было бы УДИВИТЕЛЬНЫМ способом сделать это ?» и я трачу дополнительное время, чтобы найти или изобрести лучший способ сделать это.

Я думаю, что если я буду продолжать делать это достаточно часто, мое рутинное кодирование продолжит улучшаться.

RemcoGerlich
источник
1

Программное обеспечение - это странные вещи, а процесс разработки программного обеспечения - более странный.

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

Быстрее надежнее

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

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

Джеймс Андерсон
источник
Я не уверен, что согласен с вами, но это интересная, неортодоксальная точка зрения. +1 за нестандартное мышление.
Flot2011
-1

Работа не подходит для вас.

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

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

Б Семерка
источник