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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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