Как вы переводите программу из разработки в релиз?

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

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

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

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

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

РЕДАКТИРОВАТЬ

Я хочу уточнить несколько вещей.

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

• часто новая функция - это действительно то, что мы хотим опробовать и посмотреть, имеет ли смысл реализовывать что-то подобное. (особенно в мобильных приложениях, чтобы получить реальный внешний вид на реальном устройстве) Так что это что-то маленькое, что (imho) не оправдывает слишком много работы в первой итерации «посмотрим». Однако иногда возникает вопрос, КОГДА я плачу этот tech.debt? Вот о чем этот вопрос.

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

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

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

Не поймите меня неправильно - мое понимание «самого чистого кода» не имеет ничего общего с тем, чтобы сделать код красивым ради красоты. Это действительно то, что может замедлить вас. С моей точки зрения, чистый код - это код, который в основном объясняет себя (не нужно писать так много документов - вызывает ускорение), прост для понимания (меньше ошибок, поэтому требуется меньше отладки - ускорение, меньше времени требуется для поиска правильного место для изменения - ускорение), решает данную проблему с наименьшим количеством необходимого кода (меньше кода для отладки - очевидное ускорение), является СУХОЙ (только одно место, чтобы измениться, когда что-то должно быть изменено - ускорение - и меньше риск для внедрения новые ошибки, забыв поменять второе место), следуя стандартам кодирования (менее громоздкие вещи - думать об ускорении), использует маленькие,

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

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

Я нахожусь в середине тестирования и исправление ошибки будет переписать

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

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

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

У вас есть две отдельные проблемы, обе с одним и тем же симптомом (небрежный код):

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

Проблема № 2: Вы считаете, что материал, который вы пишете, «только сейчас» В разработке программного обеспечения «просто сейчас» код действительно крайне редок. Вы сами заметили, что, как только вы удовлетворяете требованиям пользователя, строгость спроса и предложения делает очень трудным оправдание возврата и повторной реализации функции «выполнено». Итак, что с этим делать? Всегда пишите производственный код. Функционально для вас это означает, что ваши оценки для заинтересованных сторон должны быть значительно выше, чтобы у вас было время, чтобы сделать это правильно.

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

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

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

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

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

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

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

непрерывно

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

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

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

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

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

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

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

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

Поэтому ответ таков:

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

(б) старайтесь не залатывать вещи. Не думайте о долгосрочной перспективе, только когда придет время проводить QA. На самом деле, вы должны тестировать каждый маленький кусочек, который вы строите, все время и охватывать все входные данные, в том числе и те, которые не находятся на счастливом пути. Патч / хак почти по определению является краткосрочным исправлением, которое вполне может иметь долгосрочную стоимость, затрагивая общую стоимость владения клиентов в системе. Опять же, давление, чтобы получить код, поэтому должен быть баланс. Но старайтесь не ставить краткосрочные исправления, особенно те, которые тесно связывают компоненты, которые действительно должны быть слабо связаны. Будет доработка, поэтому сделайте это РАНЬШЕ, чтобы сделать это намного проще, чтобы избежать взломов и исправлений, которые со временем нарастают и становятся неуправляемыми.

Ты пишешь:

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

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

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

Я думаю, что вы откладываете свою «очистку» на многое.

Мое эмпирическое правило:

• Начните с (под) функции
• не стесняйтесь писать неполные и неполные материалы, может быть, какой-нибудь c & p, чтобы почувствовать, что я реализую, или если мне придется потерять последние часы кодирования (обратите внимание, что это может идти рука об руку с TDD / тестами, просто все немного смягчено, чтобы быстро получить обратную связь с областью реализации, которую я изучаю)
• Подфункция "работает" достаточно хорошо сейчас
• Теперь выполните очистку: перед коммитом SCC .
  • Посмотрите код, чтобы увидеть, что очевидно
  • Сделайте diff против последнего коммита, чтобы рассмотреть изменения и, возможно, поймать некоторые проблемы
  • Исправить вещи, которые я записал на блокноте
• Теперь я делаю коммит - этот код качества готов к отправке

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