Являются ли разработчики программного обеспечения, которые игнорируют качество / стандарты лучше для компании? [закрыто]

Разве разработчики программного обеспечения, которые предпочитают не ставить оптимизацию кода, стандарты и передовые практики в качестве первоочередных задач, создают более полезный код, чем те разработчики, которые хотят беспокоиться об оптимизации, внедрении стандартов и практик кодирования, а не о своевременном выполнении задач?

Как эти разные методологии сравниваются, когда дело доходит до отдельных обзоров эффективности?

Как эти стили сравниваются в рецензиях?

Каков наилучший способ повлиять на вашу команду для внедрения большего количества лучших практик во время SDLC?

Нет, они будут получать уважение только от владельца проекта на данный момент.

Они будут уничтожены годами

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

Они могут даже получить такое же лечение от:

• текущие тестеры,
• составители текущей технической документации.

Ложная дихотомия: качества ортогональны.

                Высокое качество Низкое качество

Прибыльный УДИВИТЕЛЬНЫЙ Эскиз

Убыточный Iffy FIRE FIRST

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

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

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

Согласен ли я с разработчиками, которых не волнует оптимизация кода и практики? Нет .

Они делают работу, которую им нужно сделать? Да.

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

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

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

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

Вас будут ненавидеть сопровождающие, но ваш начальник полюбит их.

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

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

Вы пишете одноразовый веб-сайт для одноразового маркетингового продвижения (вы, вероятно, тоже этого не делаете, или не задали бы вопрос, но это более вероятно, чем спутник)? Тогда, черт возьми, да, вытащите этот кусок пуха через любые средства, необходимые для соблюдения сроков, следующий директор по маркетингу, вероятно, все равно будет делать что-то еще с другой компанией. ТО, ЧТО ВЫ ДЕЛАЕТЕ, НЕ ИСКУССТВО ИЛИ НАУКА - ПОЛУЧИТЕ ОПЛАТУ.

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

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

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

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

Какое уважение они получают, вероятно, зависит от конкретного случая. В какой-то момент, однако, кто-то заметит.

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

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

Все зависит от клиента.

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

Подумайте о строительстве кабинета.

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

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

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

Время покажет. Делай то, что хотят менеджеры, или найди другую работу.

Нет никогда. Оптимизация кода IMO, лучшие практики, реальное мастерство - это САМАЯ важная вещь в кодовой базе; без этого все превращается в осадок и скрепляется клейкой лентой. Это неустойчивый дизайн. Это похоже на игнорирование опухоли, потому что она маленькая и ты здоров; конечно, вы здоровы сейчас, но через несколько лет он станет терминальным, потому что вы так долго игнорировали его.

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

Хорошее чтение: http://www.joelonsoftware.com/items/2009/09/23.html

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

Что бы ты ни думал, не будь придурком по этому поводу.

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

Лучше для компании? Это зависит.

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

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

Лучше для индивидуального разработчика? На самом деле это не имеет значения. Просто сделайте то же, что и ваши коллеги, и пусть руководство справится с последствиями - это не ваша работа. Если вы все время чините чужое дерьмо, вы БУДЕТЕ выглядеть медленным, и вы будете тем, кто все еще там, в то время как другие были продвинуты над вами. Возьми с собой программу или уйди пока можешь, если это так плохо.

Зависит от разработчика и проекта / ситуации.

Необычные времена требуют чрезвычайных мер.

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

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

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

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

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

Основная ценность программного обеспечения заключается в том, что оно гибкое.

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

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

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

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

Так что нет плохого качества, с точки зрения гибкости, никогда!