Снова начинать? [Дубликат]

    

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

    

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

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

6 голосов | спросил kyndigs 4 MarpmFri, 04 Mar 2011 13:36:04 +03002011-03-04T13:36:04+03:0001 2011, 13:36:04

11 ответов


14
  

хотя я потеряю время, будет лучше просто начать все заново?

Нет.

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

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

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

  

Что вы должны рассмотреть перед тем, как сделать этот шаг?

Пересмотренный дизайн.

Как сохранить данные.

  

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

False. Мусор - это мусор. Отбросьте это рано и часто. Это не сильно, когда программное обеспечение является мусором.

  

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

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


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

Мы не «постепенно» меняем базу данных. Мы отбрасываем предыдущую версию и продвигаемся вперед.

Два из модулей находятся на основной версии 3. Два предыдущих удаления программного обеспечения для мусора.

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

Это отбрасывания предыдущей версии и перенос данных в новые таблицы с другой структурой (следовательно, основной номер версии).

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

ответил S.Lott 4 MarpmFri, 04 Mar 2011 14:06:24 +03002011-03-04T14:06:24+03:0002 2011, 14:06:24
14

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

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

ответил aufather 4 MarpmFri, 04 Mar 2011 14:17:30 +03002011-03-04T14:17:30+03:0002 2011, 14:17:30
3

Это происходит все время.

Критика Модель водопада сформулирована как . Многие из Детали [system] становятся известными только нам, когда мы продвигаемся в реализации [system]. Некоторые из вещей, которые мы изучаем, недействительны для нашего дизайна, и мы должны отступать ».

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

ответил LennyProgrammers 4 MarpmFri, 04 Mar 2011 14:06:44 +03002011-03-04T14:06:44+03:0002 2011, 14:06:44
2

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

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

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

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

ответил kamaal 4 MarpmFri, 04 Mar 2011 14:02:42 +03002011-03-04T14:02:42+03:0002 2011, 14:02:42
2

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

ответил SK-logic 4 MarpmFri, 04 Mar 2011 14:12:13 +03002011-03-04T14:12:13+03:0002 2011, 14:12:13
2

Первое, что я обычно делаю в такой ситуации - сделайте глубокий вдох и сделайте перерыв.

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

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

ответил Nikita Barsukov 4 MarpmFri, 04 Mar 2011 14:00:01 +03002011-03-04T14:00:01+03:0002 2011, 14:00:01
2

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

В любом случае, стоит сделать план.

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

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

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

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

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

ответил biziclop 4 MarpmFri, 04 Mar 2011 14:33:06 +03002011-03-04T14:33:06+03:0002 2011, 14:33:06
2

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

ответил bit-twiddler 4 MarpmFri, 04 Mar 2011 18:59:24 +03002011-03-04T18:59:24+03:0006 2011, 18:59:24
1

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

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

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

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

Когда я занимался магистерской диссертацией, я полностью перестраивал свое приложение три раза - это не было основной темой диссертации, но эти изменения были полностью достойными!

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

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

ответил Pedro Loureiro 4 MarpmFri, 04 Mar 2011 15:04:46 +03002011-03-04T15:04:46+03:0003 2011, 15:04:46
1

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

Возможно, будет возможно отделить его достаточно, чтобы извлечь нужные вам биты.

ответил CashCow 4 MarpmFri, 04 Mar 2011 15:44:46 +03002011-03-04T15:44:46+03:0003 2011, 15:44:46
0

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

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

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

ответил azani 19 J000000Saturday14 2014, 07:41:03

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

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

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