Как убедить моего босса в том, что качество - это хорошая вещь в коде? [Дубликат]

    

У этого вопроса уже есть ответ:

    

Мой босс пришел ко мне сегодня, чтобы спросить меня, можем ли мы реализовать определенную функцию через 1,5 дня. Я посмотрел на него и сказал ему, что от 2 до 3 дней будет более реалистичным. Затем он спросил меня: «А что, если мы сделаем это быстро и грязно?» Я попросил его объяснить, что он имел в виду «быстро и грязно».

Оказывается, он хочет, чтобы мы писали код так же быстро, как по-человечески, путем (например) копирования битов и фрагментов из других проектов, вставляя all код в код сайта WebForms , перестаньте заботиться о DRY и SOLID и считайте, что код и функциональные возможности никогда не будут изменены или изменены. Что еще хуже, он не хочет, чтобы мы делали это только для этой функции, но для all кода, который мы пишем.

  

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

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

  • Мотивация разработчика: Я объяснил, что сложно заставить разработчиков мотивироваться, когда они постоянно находятся под давлением нереалистичных сроков и бюджета, чтобы быстро писать неряшливый код.
  • Читаемость: Когда проект передается другому разработчику, более чистый и улучшенный структурированный код будет легче читать и понимать.
  • Поддержание работоспособности: Легче, безопаснее и меньше времени для адаптации, расширения или изменения хорошо написанного кода.
  • Тест: Обычно проще тестировать и находить ошибки в чистом коде.

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

Что еще я могу сказать, чтобы он увидел, что он не прав? Я хочу купить ему копии Peopleware и The Mythical Man-Month, но у меня есть чувство, что они тоже не изменят свое мнение.

Многие из вас, вероятно, скажут что-то вроде «Беги! Убирайся оттуда сейчас !» или «Я бы ушел!», но это не вариант, так как работы в области веб-разработки .NET довольно редки в регионе, где я живу ...


Update

Ничего себе, я не ожидал получить так много ответов. Спасибо всем за ваш вклад и ваше мнение!

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

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

  1. Маленькие веб-сайты, созданные с помощью нашей собственной системы CMS или электронной коммерции (65%)
  2. Веб-приложения среднего размера (35%)

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

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

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

185 голосов | спросил 3 revs, 2 users 100%
Kristof Claes
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

25 ответов


151

Простите, но,

Вы не захотите это услышать, но он не совсем ошибается .

  

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

Тогда существует YAGNI : если проекты являются одними из проектов, которые не будут стоить вам ничего для поддержания или перезаписывать, и все это время при обслуживании и переписывании оплачивается, делая это right , в первый раз на самом деле стоит вам еще больше денег. Затем ваш босс снова будет на 100% прав.

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

Все, что вы делаете выше и выше того, что удовлетворяет клиент, - это потраченное впустую усилие на все части: они не оценят его. Ваш босс снова на 100% прав.

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

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

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

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
90

Звучит как мое старое задание

(1 человек продаж, 1 персонаж, 2 программиста)

Это всегда случалось на моей старой работе. Я согласен, что продажи управляют всем. Менеджер магазина (Skill Set: 80% Sales 20% Graphics) постоянно находил недостатки, которые требовали клиенты. 20-часовая работа будет продаваться по 10-часовой цене, потому что клиент не хотел платить больше или (я склонен думать), менеджер по продажам не подчеркивал достаточно Значение , клиент был получение.

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

После нескольких повторных сессий «Почему бы вам не сделать это быстрее ... вы уже сделали это для клиента x». и «Для клиента ушло всего 10 часов, так как для клиента z требуется 16 часов».

Мы спросили продавца, что это за цель? Он сказал, что продает как можно больше таких виджетов, как можно дешевле, чем мы можем.

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
53

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
33

Научите его техническому долгу

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

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

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

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

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

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

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

Последнее, что вы могли бы отметить, это то, что разработчики более продуктивны, если они очень мотивированы;)

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
17

Стоимость обслуживания часто намного выше и часто является основной частью стоимости программного обеспечения.

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

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

Разве ваш босс не понимает этого?

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
12

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
10

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

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

Есть две части:

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
7

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
4

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
4

Да, сегодня мы можем взломать это.

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

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

Это приемлемо для вас?

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
4

W. Эдвардс Деминг известен своей работой по восстановлению японского производства после Второй мировой войны. Часто игнорируется тот факт, что его работа на самом деле больше связана с управлением, чем с производством. Фактически, основной раздел его книги Out of the Crisis посвящен улучшению качества в сервисных организациях. Его примеры сервисных организаций включают программное обеспечение, банковское дело, страхование и церкви.

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

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

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

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

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

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

Деминг - одна из главных причин того, что Япония является мировой державой в производстве. Премия Деминга названа в его честь.

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
3

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
3

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
3

Я прошел через все вопросы и увидел, что никто не попал в точку зрения безопасности ...

Да, другие упомянули время отладки, но отладка в этом случае выполняется только до уровня «эй, он наконец-то работает»

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
2

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

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
2

Бросьте математику на него. К сожалению, у меня нет книг на руках, чтобы предлагать цитаты (надеюсь, кто-то может мне помочь), но один или оба из The Pragmatic Programmer и Code Complete 2 имеют раздел справочных исследований, в которых показано влияние затрат на то, что нужно делать быстро 'n' грязный путь, в отличие от времени, чтобы исправить это позже. Другие плакаты предоставили множество аргументов о пулевой точке, но, в зависимости от поведения вашего босса, он может лучше реагировать на поддержку существующих исследований. Он может подумать, что вы просто заставляете буферизировать свое время и облегчить свою рабочую нагрузку. Показывая ему, что это общепризнанный факт, а не только ваше мнение, может быть билетом.

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
2

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

Метод, который я использовал для поддержания качества кода при соблюдении крайнего срока, - это непрерывный рефакторинг. Если меня попросят написать функцию A за 1 день, что на самом деле займет от 3 до 5 дней, чтобы писать с высоким качеством, я просто сделаю быстрый и грязный способ и доставлю. Но, делая быстрый и грязный способ, я делаю заметки о области, которая может /должна быть улучшена. Затем в цикле разработки я просто найду фрагменты фрагментов времени здесь и там, чтобы реорганизовать мой код в функции А.

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
1

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

Проблемы с фиксацией более длинные

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

Добавление новой функции длится

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

Скрывающие элементы пользовательского интерфейса и терминология для новых клиентов становятся длиннее

Компания, с которой я работаю прямо сейчас, их веб-клиент начал копировать и вставлять беспорядок кода спагетти. До того, как я начал, потребовалось 2 недели, чтобы скинуть веб-клиента для нового клиента.

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


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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
1

Наилучшим возможным ответом будет подход Agile:

релиз рано, часто выпускайте

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-2

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-3

Скажите ему, что он может сэкономить деньги. Роджер Прессман написал, что вы тратите 20% своих денег на создание программного обеспечения и 80% на его сохранение.

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-3

Я хочу сократить его.

  • Если код будет поддерживаться в течение длительного времени, качество кода будет проблемой.
  • Для прототипирования кода это не очень важно. Обычно люди выбрасывают такой код.
  • Качество кода, написанного программистом, достигается с помощью практики. Как способ, которым мы получаем опыт, мы достигнем хорошей скорости Vs. Коэффициент качества. Я видел программистов, которые спрашивали: «Дайте мне 3 дня, чтобы обновить стандарт кодирования». Это полное дерьмо. Почему они заботятся при написании самого кода? После того, как тест будет выполнен, и запуск стандартных обновлений может привести к проблемам.
  • Даже мы официально не разрабатываем что-то, у нас будет какой-то дизайн, прежде чем писать код. В этих ситуациях качество зависит от мысли разработчиков.
  • Менеджеры печально известны графиками, усилиями и бюджетом. Если вы можете что-то сделать в заданной границе, согласитесь. В противном случае сообщите ему, что вы можете сделать в течение данного периода. Или дайте предложения о людях, которые могли бы внести свой вклад в конкретную проблему.
ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-4

Как получить лучшее из обоих миров? Используйте программные заводы. Потратьте свой мозг на создание инструментов, которые могут делать вещи, которые можно повторить. Например, взгляните на Ruby on Rails или, если вы являетесь человеком .NET, посмотрите на ASP.NET MVC в сочетании с пакетом nuget под названием MVCScaffolding . Я в настоящее время копаю в этом инструменте и настраиваю его для создания того, что мне нужно для моего рабочего процесса. Создание простого, управляемого базой данных сайта CRUD - это простой контроллер Scaffold. Теперь я могу потратить свое время на настройку пользовательского интерфейса и уточнение бизнес-логики, которая управляет приложением.

Как я уже упоминал, вы можете настроить инструмент (например, я изменил шаблон контроллера по умолчанию, чтобы использовать мои внутренние утилиты IRepository /IUnitOfWork, позволяющие легко переключаться между хранилищами данных EF и InMemory для тестирования). По большей части большая часть моей разработки проводится для уточнения объектной модели для поддержки сценариев использования бизнеса.

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-4

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33
-5

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

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

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

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

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

ответил Pierre François 18 Jpm1000000pmThu, 18 Jan 2018 13:51:33 +030018 2018, 13:51:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132