Что такое / Есть ли правильный способ сообщить руководству, что наш код отстой?

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

Некоторые из основных моментов:

• Мы все еще используем фреймы (попробуйте получить что-то из строки запроса, почти невозможно)
• VBScript
• Источник Сейф
• Мы «используем» .NET - под этим я подразумеваю, что у нас есть .net-обертки, которые вызывают COM-библиотеки DLL, что делает почти невозможным легкую отладку
• Все в основном одна гигантская функция
• Код не подлежит ремонту. Каждая страница имеет несколько файлов, которые создаются каждый раз, когда создается новая страница. Основная страница в основном выполняет Response.Write () несколько раз для рендеринга HTML (runat = "server" - никак). После этого может быть много логики на стороне клиента (VBScript), и, наконец, страница отправляет себе (часто хранит много вещей в скрытых полях), где она затем отправляет на страницу обработки, которая может делать такие вещи, как сохранение данные в базу данных.
• Технические характеристики, которые мы получаем, смехотворны. Часто они вызывают такие вещи, как «автоматическое заполнение поля X либо полем Y, либо полем Z» без указания того, когда выбирать поле Y или поле Z.

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

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

Убедитесь, что вы не слишком остро реагируете. Вы новичок, вероятно, не работали во многих (вообще?) Других местах, и поэтому не готовы к миру "реального кода". Реальный код жизни - ужасная вещь. Это как ваш хороший школьный код и ваш одержимо подправленный личный код проекта занимался сексом в подвале ядерного реактора, а ребенок вырос в канализации токсичных отходов; это отвратительный мутант.

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

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

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

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

Полная перезапись? Почти всегда плохая идея.

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

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

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

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

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

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

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

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

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

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

Худший подход, который я видел, - это попытаться сделать большой скачок непосредственно от устаревшей системы к самой последней и лучшей, например, перейти от работающей, но неуклюжей системы VB6 / Classic ASP / COM + к системе MVC / Entity Framework.

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

(частично перефразировано из комментария Азкара к вопросу)

Начните читать Joel on Software (Джоэл Спольски / Основатель Stack Exchange) ...

Первое, что я хотел бы сделать, это выполнить тест Джоэла .

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

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

Надеюсь, это поможет! Добро пожаловать в программирование (вчерашний код обычно отстой) ;-)

Совет: если вы предлагаете управление со списком причин, по которым вам следует кодировать по-другому, включите в качестве аргумента «Улучшенный моральный дух / условия труда для программистов».

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

• Управление фактически диктует дизайн? Если позади вас большая часть команды, что вас останавливает? Будьте активны и решайте как группа. Придумайте план по его постепенному осуществлению . Затем сделать его.
• Диктует ли управление инструменты разработки, которые вы используете? Если нет времени на замену инструмента, управление, как правило, не заботится. Будьте активны и решите в группе, какие инструменты разработки вы хотите использовать. Если вам нужно выкупиться у руководства, покажите им план миграции и анализ затрат и выгод. Затем сделать его.
• Диктует ли руководство языки, которые вы используете? Будьте активны и решите, как группа, что использовать вместо VBScript. Придумайте план по его постепенному внедрению и сделайте это. Если вам нужно управление купить, покажите им план. Затем сделать его.
• У меня ничего нет для спецификации. Это обычно сильно зависит от людей и процессов на вашей работе. Определение того, что сломано, и минимальных изменений, необходимых для исправления процесса, требует времени, анализа и понимания того, как вещи работают в настоящее время и как они должны работать. Если вы знаете, что можете придумать план и попытаться убедить руководство.

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

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

Примером может быть «Код не поддерживается»:

Текущий код не поддерживается из-за X , Y и Z (перечислите причины, по которым он не поддерживается). Это делает запросы на изменение и новые функции очень трудными для выполнения, потому что X , Y , Z (причины, по которым внесение изменений затруднено). Поскольку изменения трудны, команда разработчиков не может легко реагировать на исправления ошибок и улучшения.

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

Удачи. Вам это понадобится.

«Я начал только что из колледжа», - должен ответить на ваш вопрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

Не делай этого.

Переписывание большого проекта с нуля в большинстве случаев является большой ошибкой.

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

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

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

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

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

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