Большая часть моего кода имеет главный недостаток дизайна. Завершить его или исправить? [закрыто]

Я ученик средней школы, работающий над проектом C # с моим другом с примерно тем же уровнем мастерства, что и я. До сих пор мы написали около 3000 строк кода и 250 строк тестового кода в диапазоне 100 коммитов. Из-за школы, я отложил проект на несколько месяцев, и недавно я смог снова забрать его.

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

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

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

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

178 голосов | спросил oldmud0 7 J0000006Europe/Moscow 2016, 03:12:42

21 ответ


259

Если бы я был на твоем месте, я бы, наверное, попробовал это так:

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

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

Работая программа «1.0» - это то, что вы можете показать другим, даже если код плохой (о котором никто не будет беспокоиться, кроме вас самих). Если в середине создания V2.0 вы понимаете, что у вас заканчивается время, у вас все еще есть V1.0 в качестве частичного успеха, что будет намного лучше для вашего морального духа. Однако, если вы не закончите V1.0 во-первых, есть большая вероятность, что вы никогда не закончите V2.0, потому что когда вы на полпути, будет точка, когда вы снова не удовлетворены дизайном, а затем? Будете ли вы снова отказаться от V2.0 и работать с V3.0? Существует высокий риск столкновения с этим бесконечным кругом, никогда не заканчивающийся.

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

ответил Doc Brown 7 J0000006Europe/Moscow 2016, 07:18:53
113

Готовые ИТ-проекты, даже неисправные, намного лучше, чем незавершенные.

Неоконченные могут научить вас слишком много, но не так сильно, как готовые.

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

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

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

ответил tymtam 7 J0000006Europe/Moscow 2016, 05:26:12
54

Я бы с радостью начал проект.

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

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

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

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

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

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

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

ответил Hylianpuffball 7 J0000006Europe/Moscow 2016, 03:52:39
31

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

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

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

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

ответил Luaan 7 J0000006Europe/Moscow 2016, 12:46:47
23

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

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

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

Имейте в виду: преждевременная оптимизация - это корень всего зла (см. этот отличный вопрос Programmers.SE для хорошего обсуждения). Если вы слишком много времени думаете о том, как лучше сделать свой код, вы застряли в паралич анализа . Это убивает проект. Лучше просто выполнить проект, прежде чем вы начнете его оптимизировать.

Процитировать великого мотивационного оратора: просто сделать это .

Как всегда, существует соответствующий xkcd:

 xkcd optimization

ответил Mego 7 J0000006Europe/Moscow 2016, 08:30:04
22

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

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

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

ответил kevin cline 7 J0000006Europe/Moscow 2016, 09:39:34
19

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

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

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

ответил mouviciel 7 J0000006Europe/Moscow 2016, 10:38:49
12

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

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

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

ответил dlb 7 J0000006Europe/Moscow 2016, 17:34:18
10

Ты потерял меня в этом предложении:

  

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

Я верю в принцип (в систематики ), который

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

Итак, запись сложной системы включает

  • Написание простой системы
  • Убедитесь, что он работает.

... т. е. следующие шаги:

  1. Напишите немного кода
  2. Протестируйте его, чтобы убедиться, что он работает.
  3. Напишите немного больше кода
  4. Тест снова
  5. Etc.

Обратите внимание, что шаг 3 может включать:

  1. Напишите немного больше кода
    1. Рефакторинг существующего кода, чтобы подготовить его для нового добавления.
    2. Проверьте рефакторинг, чтобы убедиться, что он все еще работает.
    3. Добавить новую функциональность

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

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

  • Исходный код проще
  • И никаких новых ошибок не было.
  • (И некоторые старые ошибки устранены)

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

ответил ChrisW 7 J0000006Europe/Moscow 2016, 18:11:48
7

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

Коллега сказал мне, что он писал программу в университете, когда он учился у известного профессора (я считаю, что это Дийкстра). Он попросил профессора взглянуть на код, над которым он работал больше месяца. Профессор спросил его, сделал ли он резервную копию, он ответил нет. Затем профессор удалил весь свой код и попросил его написать его снова.

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

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

3 варианта:

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

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

ответил Alfons 7 J0000006Europe/Moscow 2016, 16:26:30
6

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

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

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

ответил JDługosz 7 J0000006Europe/Moscow 2016, 10:51:06
6

Рефакторинг. Рефакторинг. Рефакторинг! Реорганизовывать !!!!

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

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

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

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

В рефакторе всегда найдется что-то.

ответил coteyr 8 J0000006Europe/Moscow 2016, 19:59:25
4

Я бы сказал, что это немного зависит от того, какой код у вас есть сейчас, и где именно проблемы лежат. То есть, если ваши фонды хороши (правильный дизайн классов в большинстве частей, хорошая развязка /сплоченность и т. Д., Всего несколько неправильных вариантов, например, упомянутые вами потоки), тогда, во всяком случае, вы получите bare-bones 1.0, а затем рефакторинг как завтра не будет.

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

В следующей версии выполните гибкий подход: установите фиксированную повторяющуюся временную шкалу, например, 2 недели или что-то подходящее для вашего расписания. В начале каждого фрагмента (назовем его спринтом) задайте себе цели, достижимые за две недели. Иди и делай их, попробуй свой damnest, чтобы он работал. Задавайте свои цели, чтобы после каждых двух недель у вас было что-то, что можно показать другу, а не только некоторые абстрактные внутренние работы. Google «scrum» и «умная цель». Это очень легко сделать, если вы одиноки, просто лист бумаги с несколькими точками с быстрой записью.

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

ответил AnoE 7 J0000006Europe/Moscow 2016, 18:59:10
3

Вы должны поместить себя в обувь для работодателей.

Для большинства рекрутеров вы были бы наиболее ценными, если бы пошли так: - Завершите его 100% -ным тестированием нового кода, который вы пишете. - Добавить тесты для старого (плохо спроектированного) кода. - Реорганируйте его, чтобы достичь того, что вы хотели в качестве дизайна.

Сделайте все, что с хорошим процессом управления версиями, ветвями и тегами.

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

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

ответил Steve Chamaillard 8 J0000006Europe/Moscow 2016, 08:21:21
3

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

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

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

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

ответил TheLethalCoder 8 J0000006Europe/Moscow 2016, 13:38:31
3

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

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

ответил Alex D 10 J0000006Europe/Moscow 2016, 20:13:51
2

Ни? Оба?

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

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

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

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

ответил Vatine 7 J0000006Europe/Moscow 2016, 11:42:23
2

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

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

ответил Micheal Johnson 11 J0000006Europe/Moscow 2016, 13:29:30
2

Первый вопрос, который вы должны задать себе, - «насколько плох этот недостаток?»

Что именно вы сделали неправильно?

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


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

Если вы отпустите свое приложение как можно скорее, даже если это не 100%, ошибки все, то вы получите FEEDBACK от других, имея время исправить ошибки и другие вещи для версии 1.1. Другие люди смогут помочь вам сделать приложение намного лучше, и вы могли бы потратить время делать что-то, что люди могли бы не любить.

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


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

ответил XaolingBao 16 J0000006Europe/Moscow 2016, 02:06:51
1

Это зависит от того, насколько запутан ваш код.

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

  • Если вы считаете, что у вас серьезные ошибки, которые вам все равно придется исправлять, напишите некоторые модульные тесты, которые могут проверить, исправлена ​​ли ошибка (... поскольку вы еще не можете запустить программу ). Лучше исправить ошибки раньше, и определенно лучше исправить ошибки, пока вы все еще помните, что делает код.

  • Если вам не нравится то, что вызовы методов или какой класс они принадлежат, или что-то вроде этого, просто используйте среду IDE. (Помните, что это C #, а не javascript, python, perl, php и т. Д.). Когда вы работаете над кодом, который использует затронутый компонент, и у вас есть четкая картина в голове того, что должен делать этот компонент, затем реорганизуйте его, если ваша среда IDE делает ее безболезненной.

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

ответил Aleksandr Dubinsky 15 J0000006Europe/Moscow 2016, 22:47:38
1

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

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

Вы можете попросить все советы в мире, но нет ничего похожего на тестирование эмпирической гипотезы.

Несколько причин рассмотреть выбор переписывания в качестве эксперимента:

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

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

ответил Will 12 FebruaryEurope/MoscowbMon, 12 Feb 2018 17:49:41 +0300000000pmMon, 12 Feb 2018 17:49:41 +030018 2018, 17:49:41

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

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

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