Значна частина мого коду має головний недолік дизайну. Закінчити чи виправити це зараз? [зачинено]


186

Я студентка середньої школи, яка працює над проектом C # зі своїм другом приблизно з таким же рівнем майстерності, як і я. Поки ми написали приблизно 3 000 рядків коду та 250 рядків тестового коду за проміжок в 100 коміт. Через школу я відклав проект на кілька місяців, і нещодавно мені вдалося забрати його знову.

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

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

Мені здається, що я маю пару варіантів: просто закінчити функціональність, обробляючи поганий дизайн, а потім переробляючи, коли все працює, зупиняючи все і працюючи над розкручуванням всього, перш ніж решта функціональності може бути закінчена, починаючи проект все так, щоб він знову був свіжим у моїй свідомості, або прямо відмовляючись від проекту через його надмірний розмір (по суті, "назад до дошки для малювання").

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


13
Серйозно: Маючи великий недолік дизайну в своїх продуктах, ніколи не зупиняв Ларрі Еллісона. Чому дозволяєте це турбувати вас?
Пітер Геркенс

54
Робота не пішла даремно. Це зробило вас кращим програмістом.
sampathsris

10
Наразі це може не стосуватися вас, але в майбутньому, якщо ви напишете щось, що маєте намір професійно підтримувати, ніколи не робіть великих масових перезаписів .
gcampbell

8
@JoeBlow "100% програмного забезпечення швидко стає абсолютно марним і його потрібно переробляти з нуля". Це твердження не має логічного сенсу. Ви кажете мені, що програмне забезпечення, яке я використовую щодня ... абсолютно марне і його потрібно переробляти з нуля?
oldmud0

10
"Ну - так, звичайно. Ніхто не використовує OS9 або Windows3. Програмне забезпечення надзвичайно тимчасове." Ви, як завжди, помиляєтесь, незважаючи на свою впевненість! Ядро Windows NT, представлене в NT 3.1, лежить в основі навіть Windows 10. У Windows протягом 20 років не було «повного переписування».
Гонки легкості по орбіті

Відповіді:


273

Якби я був у вашому взутті, я, мабуть, спробував би це так:

  • по-перше, закінчіть поточний проект - принаймні частково - якнайшвидше, але в робочому стані . Ймовірно, вам потрібно зменшити свої початкові цілі, подумайте про мінімальний функціонал, який ви дійсно повинні бачити у "версії 1.0".

  • тоді, і лише потім подумайте про перезапис з нуля (давайте називати цю "версію 2.0"). Можливо, ви можете повторно використати частину коду з V1.0. Можливо, після сну знову над ситуацією ви прийдете до рішення, яке ви зможете переробити V1.0 і зберегти більшу частину цього. Але не приймайте це рішення до того, як у вас не буде "доказу концепції V1.0".

Робоча програма "1.0" - це те, що ви можете показати іншим, навіть коли код поганий (що ніхто більше не буде турбувати, крім вас). Якщо в середині створення V2.0 ви зрозуміли, що у вас закінчується час, у вас все ще є частково успіх V1.0, що значно покращить ваш мораль. Однак якщо ви спочатку не закінчите V1.0, є велика ймовірність, що ви ніколи не завершите V2.0, оскільки, перебуваючи на півдорозі, з’явиться момент, коли ви знову незадоволені дизайном, а потім? Ви відмовитесь від V2.0 знову і працюєте на V3.0? Є високий ризик нарватися на це ніколи не закінчене коло, ніколи не закінчитися.

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


71
Можна також розглянути робочу версію 1.0 як можливість дізнатися про процес рефакторингу.
jpmc26

20
Це. Я часто знаходжу більше однієї групи недоліків дизайну / обмежень дизайну / оновлень вимог, коли я переходжу від нічого до першого робочого прототипу. Досягнення фактичного робочого стану є важливим.
Євген Рябцев

14
З мого досвіду, погані рішення щодо дизайну та / або розробки зазвичай виникають у міру зростання проекту. Як свідчить відповідь, найкраще мати робочу версію 1.0, а не перезапускати з нуля. Потім ви можете використовувати цю версію 1.0 як базову лінію для наступної версії.
Кіл

9
Завершення проекту дозволить вам побачити потенційні проблеми, з якими ви ще не стикалися, і може фактично показати вам, що деякі речі, які, на вашу думку, є проблемами, можливо, не такі великі, як ви вважаєте, що вони є. Зберігайте хороші замітки і починайте розробляти план на 2.0, поки ви закінчите 1.0
CaffeineAddiction

9
Останнє речення дивовижне:Better take this as an opportunity to learn how to achieve intermediate goals, instead of an opportunity to learn how to leave projects in an unfinished state behind.
Брендон

119

Готові ІТ-проекти, навіть несправні, набагато краще, ніж незавершені.

Незакінчені теж можуть багато чого навчити, але не так, як готові.

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

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

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


11
Чесно кажучи, у нетривіальних проектах завжди є кілька помилок. Перерахуйте їх і виправте в наступній версії. Ось для чого і нотатки до випуску.
RedSonja

56

Я б із задоволенням розпочав проект із початку.

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

  • Ви не несете професійної відповідальності за свій код; якби ви зараз видалили весь проект і пішли, ви не зазнаєте жодних наслідків. Це величезна перевага для розробника. У питанні, яке ви пов’язали, ці розробники намагаються підтримувати програмне забезпечення, за яке люди платять гроші, і навіть крихітні помилки можуть спричинити великі проблеми з клієнтами, що робить його небезпечним писати з нуля. У вас немає такої проблеми.

  • Як особистий проект, це ідеальна можливість спробувати нові речі та вчитися на своїх помилках. Чудово, що ви визнаєте, що ваш старий код має проблеми, адже це означає, що ви навчилися робити краще. Досвід проб і помилок може бути неоціненним для початківців програмістів.

  • Ваш проект порівняно невеликий, і ви в основному не маєте тестів. Можна написати кілька рядків з нуля за кілька хвилин, тим більше, що ви вже маєте ідеї, що робити краще наступного разу.

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

Це може бути чудовим шансом спробувати написати більш модульну програму з одиничними тестами. Це значно полегшує розуміння коду, якщо ви повернетесь до нього після тривалої перерви, і допомагає запобігти помилкам, які ви можете випадково ввести через забудькуватість.

Нарешті, ось одна думка щодо мудрості іноді робити кроки назад, щоб зробити більші кроки вперед.


46
Переписування з scrarch рідко вчиться на помилках і часто просто робить нові
whatsisname

28
На мою думку, закінчити проект набагато важливіше, ніж мати ідеальний проект. Загроза вічного циклу "недостатньо добре" реальна.
Пітер Б

9
Іноді, коли ви копаєте собі нору, вам потрібно припинити копати; вивчіть урок, що подається, та зробіть другу версію простішою . Друга системна помилка, яку роблять люди, - це побудувати її більш привабливо і складніше.
Дейл Джонсон

15
Слід підкреслити, люди, що ОП працює над іграшковим проектом . Я прочитав нарис Джоела про переписування з нуля , і жоден з його пунктів не стосується цієї справи. ОП не продають свій код у реальному світі, не мають терміну виконання тощо. Витратити вдвічі більше часу на програмування означає, що вони навчаються вдвічі більше.
Кевін

6
@whatsisname Вони не будуть робити однакових помилок. Як ви сказали вище, вони створюватимуть нові, які навчать їх нового.
Кевін

34

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

Робіть справи - це єдине найважливіше, що вам потрібно навчитися. Повірте, я знаю безліч людей (не лише програмістів), які застрягли в циклі "продовжувати починати з нуля, оскільки я так багато навчився, перш ніж почати цей проект". Проблема в тому, що це ніколи не закінчується - поки ти не перестанеш вчитися новому, що не приємно бути :)

Це також важливо для можливості насправді закінчити що-небудь. Починати з початку - захоплююче, класно, весело ... але якщо ви лише цього навчитесь, ви ніколи нічого не зможете закінчити. Знову ж таки, це не дуже корисна здатність, і насправді це не так добре, як робити щось корисне (або весело). Життя коротке, час обмежений, і ти не можеш просто продовжувати займатися без відчутних результатів - ти з цього підеш зовсім з розуму. Якщо ви виявите, що не можете почати працювати, тому що просто не можете вирішити, який підхід застосувати, ви вже в небезпечній зоні.

Завжди знайдуться імпульси для початку. Навіть у навчальному середовищі це, швидше за все, погана ідея. Це не означає, що вам потрібно переносити кожен прототип до програми, готової до виробництва, далеко від нього. Але вам потрібно принаймні дійти до діючої фази прототипу - це, швидше за все, допоможе вам морально, і це дуже корисна риса для будь-якого розробника. Зробіть справи . І найцікавіша частина полягає в тому, що ви швидко побачите, що є мільйон більше веселощів або корисних речей, які ви можете зробити зі своїм прототипом, а не «переписати його з нуля» - а в багатьох випадках навіть переробити його. Все, що ви робите, має вартість - принаймні, ви могли тим часом займатися чимось іншим.


25

Я дотримуюся ідеології "Зробіть це, зробіть це правильно, зробіть це швидко" в розробці програмного забезпечення.

  1. Зробіть це так : Напишіть основну функціональність, щоб проект був корисним. Робіть те, що вам потрібно, щоб все працювало, навіть якщо це означає некрасивий код.
  2. Зробіть це правильно : виправте помилки та рефактор коду, щоб його було легше читати, розуміти та підтримувати.
  3. Зробити це швидко : Оптимізуйте програму, прагнучи забезпечити хороший баланс між швидкістю, використанням ресурсів та ремонтом.

Наразі ви ще не закінчили крок 1. Спершу працюйте, і тоді ви можете переживати, наскільки потворний ваш код. Насправді створення робочого продукту - одна з найскладніших речей для нових розробників, тому що вони настільки втягнуті в намагання зробити свій код ідеальним вперше, і тому вони застрягають в оптимізаційному пеклі і ніколи насправді не доходять до фінішу. реалізація всіх функцій. Ви повинні навчитися позбавляти всіх цих проблем щодо рефакторингу та оптимізації, щоб ви могли просто зосередитись на тому, щоб програмне забезпечення працювало. Як тільки ви отримаєте трохи досвіду, ви, природно, будете робити більше справ правильно з першого разу, тому потрібно менше рефакторингу.

Майте на увазі: передчасна оптимізація - корінь усього зла (див. Це чудове питання програмістів. SESE для гарного обговорення). Якщо ви витрачаєте занадто багато часу на роздуми над тим, як поліпшити свій код, ви застрягнете в паралічі аналізу . Це вбиває проект. Краще просто виконати проект, перш ніж почати намагатися його оптимізувати.

Цитувати чудового мотиваційного спікера: просто зробіть це .

Як завжди, є релевантний xkcd:

xkcd оптимізація


1
У відкритому коді ви навіть можете вставити крок 0, "просто зробіть це". Навіть якщо це не спрацює, якщо це досить цікаво, відпустіть його, і, можливо, хтось допоможе вам з кроком 1.
Jörg W Mittag

1
Особисто мені подобається правильний код. Я навіть думаю, що правильний дизайн може бути кориснішим, ніж проблемний код. Незалежно від порядку №1 та №2, я +1, тому що мені подобається бачити відмінність. Якщо існують основні проблеми впровадження, такі як перевірка умов перегонів, такі проблеми часто можна виправити без необхідності переробляти API (які функції викликають що), тож ви можете виправити помилки, зосередившись на деталях впровадження, не потребуючи особливого акцентування уваги на функціонуючий дизайн дизайну вищого рівня. Тож (потенційно) може бути корисно наявність (напів?) Робочої версії коду.
TOOGAM

Я не думаю, що це стосується. ОП, очевидно, говорить про основні проблеми дизайну . Ви не можете їх безпечно "латати" пізніше.
Гонки легкості по орбіті

1
Не забувайте кроки 0,5, 1,5, 2,5 та 3,5: зробіть його читабельним.
candied_orange

23

Перепишіть його. Непрацюючий код має мало значення, а три тисячі рядків - не багато коду. Це не займе майже стільки часу, скільки потрібно було написати код, який у вас є, і це буде набагато краще. Я часто викидав п'ятсот чи тисячу рядків поганого коду, і часто переписування становить одну п’ятій.

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

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


7
Якщо ви намагаєтеся пройти спритний цикл розвитку, ідея полягає в тому, що якщо ви зрозумієте, що ви зійшли з неправильної кролячої нори, відкиньте її і спробуйте в іншому напрямку, однак якщо ви використовували джерело управління svn / git, вам слід вміти повернутися до зобов’язання перед тим, як ви пішли неправильним шляхом, щоб це не було занадто великими змінами - якщо ні, нехай це буде урок, який потрібно робити часто.
Тереза ​​Форстер

2
У 3-х рядках коду може знадобитися більше часу, щоб перевірити комісії, а потім просто переписати всю річ.
Метью Віт

Що стосується git repo, просто видаліть його і почніть спочатку. Поточний код майже напевно абсолютно безцінний. Яка причина залишити його на якомусь сервері? - жодної. Натисніть Видалити.
Fattie

1
@JoeBlow: немає причин видаляти gpo repo. Просто зробіть нову гілку. Ви ніколи не можете сказати, коли ви хочете посилатися на старі речі.
кевін клайн

19

Перезапуск з нуля, як правило, є поганим кроком у реальних проектах, головним чином тому, що реальні проекти накопичують помилки, про які не знає новий розробник (наприклад, дивіться речі, яких ви ніколи не повинні робити , з Joel на блозі програмного забезпечення .)

Незважаючи на те, шкільні проекти не успадковують таку історію і зазвичай починаються з кодування та проектування одночасно з частковими знаннями обчислень та відсутністю досвіду. Я б розглядав вашу першу версію як прототип, який використовується як доказ поняття, яке не вдалося, і я б із задоволенням відкинув її (див. Які відмінності між викинутими та еволюційними прототипами? Для обговорення викидання проти еволюційного прототипування.)

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


12

Я з повагою не погоджуюся з пропозиціями про те, що переписати це погана ідея.

У царині життєвого циклу програмного забезпечення загальновизнано, що час і зусилля, необхідні для виправлення помилки, збільшуються на порядок кожного шару життєвого циклу. Тобто, якщо на виправлення помилки на рівні вимог знадобиться 1 година, для проектування знадобиться 10 годин, 100 годин кодування-тестування та 1000 годин для усунення помилки. Ці цифри можуть здатися кричущими, але вони вважаються галузевими приблизно правильними. Очевидно, що в меншому проекті менше, але загальна ідея залишається. Якщо ваш проект має основний недолік дизайну, то більш доречним буде викликати досвід навчання та повернутися назад, переглянути свої початкові вимоги та переробити дизайн.

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


3
Що означає "промисловість прийнята"? Яке джерело для номера?
Крістіан

1
@Christian це, здається, джерело: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

1
TDD - це шлях!
2rs2ts

10

Ви втратили мене в цьому реченні:

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

Я вірю в принцип (заявлений в Systemantics ), що

  • Складна система, яка працює, незмінно виявляється, що розвинулася з простої системи, яка працює.
  • Складна система, розроблена з нуля, ніколи не працює і не може бути виправлена, щоб вона працювала. Почати потрібно з початку, починаючи з простої робочої системи.

Отже, написання складної системи включає

  • Написання простої системи
  • Переконайтесь, що це працює

... тобто наступні кроки:

  1. Напишіть трохи коду
  2. Перевірте це, щоб переконатися, що він працює
  3. Напишіть трохи більше коду
  4. Перевірте ще раз
  5. І т.д.

Зауважте, що крок 3 може містити:

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

Також крок 2 "Перевірте його, щоб переконатися, що він працює" може включати певне переписування, якщо цього не відбувається.

Якби я будував на гнилій кодовій базі, я би відмовився додавати додаткові функції. Тож я схиляюсь запланувати щось на зразок "спростити існуючу реалізацію потоків" як наступну роботу, яка повинна бути реалізована. Якщо припустити, що ви проходили тестування, ви хочете ставитись до цього, як до рефакторингу. Критеріями успіху / виходу для цього робочого етапу були б:

  • Вихідний код простіший
  • І жодних нових помилок не впроваджено
  • (І деякі старі помилки усунені)

Між іншим, "тестування його, щоб переконатися, що він працює", не обов'язково означає "тестові одиниці" - коли структура команди проста, ви можете протестувати (просту) систему, використовуючи (прості) системні тести (замість одиничних тестів) .


7

Однією з проблем, з якою ви стикаєтеся при подібній проблемі, - це ви емоційно прив’язані до коду, який ви написали до цих пір.

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

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

Спробуйте зробити чесну оцінку того, який варіант є найкращим за час, доступний для проекту.

3 варіанти є

  • Видаліть його (повністю, без огляду назад)
  • Продовжуйте працювати в старому дизайні
  • Код Refactor, поки ви йдете.

Я був професійним програмістом понад 10 років, і в своїй роботі я прийшов до висновку, що останній варіант - це більшість разів обраний, але це не завжди найкращий варіант.


3
Колись у мене був фрагмент коду, який мав помилку. Я витратив три дні на пошуки помилок, коли мій тест зіткнувся, і мені вдалося видалити код, ніяких резервних копій. Я переписав усю базу коду з пам'яті у все ближче, і всі мої помилки зникли. Близько 3000 ліній кодової бази. Так що іноді це підходить. Але у виробництві цього ніколи не буває.
joojaa

6

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

Пам'ятайте, що це не те, що потрібно поставляти як робочу програму для замовника. Це було написано спеціально для практики. Тож, якщо ви не хочете займатися питаннями доставки та помилкою доставки замість цього, я думаю, що ви зараз перебуваєте у фазі розвитку, коли робота ваших "дизайнерських м'язів" виявиться плідною.

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


6

Рефактор. Рефактор. Рефактор! РЕФАКТОР !!!!

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

Це просто не вийде. Якщо ви це зробите, ваша заявка / гра ніколи не буде завершена. Натомість спробуйте виділити свій час на проект так, щоб деякі з ваших "завдань" були перефабрикувати поганий код. Скажімо, наприклад, у вас був жахливий метод збереження гри. Продовжуйте працювати над самою грою, але знайдіть деякий час, щоб перефактурувати (замінити) цей жахливий метод. Постарайтеся, щоб рефактори були маленькими, і це не повинно бути проблемою.

Коли ви потрапите на більшу частину програми, якій потрібен рефактор, ви робите це неправильно, серйозно. Розбийте це рефакторинг на менші частини. Спробуйте витратити сім годин на написання коду та одну годину рефакторингу.

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

Завжди знайдеться щось рефакторне.


4

Я б сказав, що це трохи залежить від того, який код у вас зараз і де саме лежать проблеми. Тобто, якщо ваші основи хороші (правильний дизайн класу в більшості частин, хороша розв'язка / згуртованість і т. Д., Лише кілька поганих варіантів, таких як нитки, про які ви згадали), то будь-якими способами отримуйте голі кістки 1,0, а потім рефактор, як завтра немає

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

У наступній версії виконайте спритний підхід: встановіть собі фіксовану повторювану шкалу часу, як-от 2 тижні або що відповідає вашому графіку. На початку кожного куска (назвемо його спринт), поставте собі цілі, досяжні за 2 тижні. Ідіть і робіть їх, спробуйте найсміливіших, щоб це спрацювало. Поставте свої цілі так, щоб через кожні 2 тижні у вас з’явилося щось, що можна показати другові, а не лише якусь абстрактну внутрішню роботу. "Scrum" та "розумна мета" від Google. Це все дуже легко зробити, якщо ви один, лише аркуш паперу з кількома швидко зафіксованими кулями точки.

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


3

Ви повинні вдягнути себе у взуття роботодавців.

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

Робіть все це за допомогою хорошого процесу версії, гілок та тегів.

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

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


Який роботодавець? ОП в середній школі, займається проектом для домашніх тварин.
Гонки легкості по орбіті

Діяти професійно з самого початку не може бути дуже погано, а середня школа не надто далека від реальної можливості IMHO для роботи.
Стів Чамайлард

1
"Діяти професійно" абсолютно не має нічого спільного з тим, чи ви рефактор чи ні.
Гонки легкості по орбіті

Це є, в чомусь. Починати над проектом і втратити тонну роботи більшість випадків непрофесійно, тоді як його рефакторинг і тим самим поліпшення показує кращі довгострокові результати (більшість разів).
Стів Чамайлард

І це не один з тих часів.
Гонки легкості на орбіті

3

Просто додати частину мого минулого досвіду в суміш. Я працюю над побічним проектом вже більше року, кожного разу, коли отримую запасні хвилини. Цей проект перейшов від простої пробної таблиці до статичного класу до об'єктно-орієнтованого дизайну з тонкою підкладкою, який він є зараз.

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

Це означає, що мені вдалося вдосконалити код швидше, ніж я міг би раніше. Це також означало, що я йшов легше сказати, що потрібно видалити, тобто непотрібні заняття, а що може залишитися легше, ніж переписування старої ідеї, яка все ще зберігається в моїй думці.

Тому моя порада полягатиме в тому, щоб переробити код і перейти звідти, в міру необхідності вдосконалюючись. Хоча пам’ятайте, якщо ви все-таки вирішили переписати з нуля, вам слід взяти добрі ідеї старого проекту і уважно подивитися на них, щоб побачити, де вони недоліки. Тобто не просто копіюйте старий код у новий проект.


3

Відповідь залежить від того, що я люблю називати "стелею складності". По мірі того, як ви додаєте все більше і більше в кодову базу, існує тенденція до того, що вона стає все більш складною і менш організованою. У якийсь момент ви потрапите на «стелю складності», і тоді прогрес вперед стає дуже важким. Замість того, щоб намагатися продовжувати рухатися грубою силою, краще створити резервну копію, переорганізувати / переписати, а потім продовжувати рухатися вперед.

Тож ваша кодова база настільки погана, що ви наближаєтесь до стелі складності? Якщо ви відчуваєте, що це так, знайдіть певний час, щоб почистити та спростити, перш ніж продовжувати. Якщо найпростіший спосіб очищення - це переписати деякі частини, це добре.


2

Ні? Обидва?

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

Якщо у вас є раціональні взаємодії, це може бути гарним місцем для початку ("надмірна нитка в рендері" звучить як неефективність, а не щось, що може спричинити проблеми з правильністю). Подивіться, чи зможете вияснити або загальний спосіб відходу від перегонів (і, можливо, тупиків), або принаймні кілька конкретних способів цього зробити.

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

Я вважаю, що в цілому я більше мотивований виправляти проблеми з кодом, який робить щось корисне, а не викидати його і знову починати з нуля. Бувають випадки, коли розвиток випаленого поля (аналогічно до greenfield та brownfield ...) є більш задовольняючим, але це зазвичай для речей, де існуючий підхід настільки виходить, звідки має бути, що він навіть не помиляється.


2

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

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


2

Перше питання, яке ви повинні задати собі, - "наскільки поганий недолік?"

Що саме ви зробили не так?

Якщо щось настільки погано, що ви витратите багато годин, намагаючись попрацювати з проблемою, викрийте конфіденційні дані (паролі / кредитні картки) або спричините погану вразливість, то, можливо, вам слід це відредагувати, але більшу частину часу ви можете візьміть те, що у вас є, закінчіть його та вирішіть проблему пізніше.


Програмісти люблять вдосконалювати свої програми, бажаючи, щоб вони були "найкращими, що можуть бути", але це не правильний підхід.

Якщо ви випустите заявку якнайшвидше, навіть якщо вона не на 100%, помилки і всі інші, тоді ви отримуєте FEEDBACK від інших, в той час як встигаєте виправити помилки та інші речі для версії 1.1. Інші люди зможуть допомогти вам зробити додаток набагато кращим, і ви, можливо, витратили час, роблячи щось, що людям, можливо, не сподобалось.

Тож у вашому випадку дістаньте його, отримайте трохи відгуків, а потім зможете структурувати версію 2.0 із усіма змінами та виправити недолік, який у вас є.


Інша річ, яку потрібно пам’ятати, - це те, що ми постійно вдосконалюємось. Є приказка, що якщо ви можете переглянути свій код ще рік тому і побачити, що це погано, це означає, що ви все ще вдосконалюєтесь, і це чудова річ.


1

Це залежить від того, наскільки зіпсований ваш код.

  • Якщо ви зробили справжні помилки n00b, які роблять ваш код надмірно складним або багатослівним, я рекомендую переписати ці частини.

  • Якщо ви думаєте, що у вас є серйозні помилки, які вам доведеться все-таки виправити, то напишіть кілька тестів, які можуть перевірити, чи виправили помилку (... оскільки ви ще не можете запустити програму). Краще виправляти помилки рано, і, безумовно, краще виправляти помилки, поки ви ще пам’ятаєте, що робить код.

  • Якщо вам не подобається, як називаються методи, або до якого класу вони належать, або такі дрібниці, просто використовуйте IDE. (Пам'ятайте, що це C #, а не якийсь JavaScript, python, perl, php тощо). Коли ви працюєте над кодом, який використовує компонент, що впливає, і у вас в голові чітке уявлення про те, що повинен робити цей компонент, потім переробляйте його, якщо ваш IDE робить його безболісним.

В іншому випадку змусьте його працювати і відточити свої навички на наступному проекті.


1

Як підказали інші, оскільки це особистий проект, а не (поки що) професійний проект, я б серйозно подумав про перезапис.

Однак ви можете використовувати тут науковий метод, виконавши експеримент. Спочатку задумайте гіпотезу. Моє було б, "напевно, час переписати". Щоб заощадити час, знизити витрати на відмову та дещо обмежити апріорні упередження, перш ніж займатись більше програмуванням, визначтеся з тривалістю часу ("часовий блок"). Я б запропонував, можливо, 4 години настінного годинника. Також визначитесь з методологією оцінки гіпотези. Оскільки ставки низькі, я б запропонував як методологію, просто запитайте себе: "Я радий, що я це зробив?" Тепер починайте експеримент. Після обраного вами часу, що таке оцінка гіпотези? Наприклад, з мого прикладу, ви раді, що ви почали переписувати зараз, коли на це витратили 4 години? Тоді це, мабуть, правильний вибір.

Ви можете попросити всіх порад у світі, але немає нічого подібного до тестування гіпотези емпіричним шляхом.

Кілька причин вважати вибір переписати своїм експериментом:

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

Закінчити щось - це гарна ідея, але не у вакуумі. Якщо ви почнете перезаписувати, ви можете вирішити щось, закінчивши певний підмодуль. Ви можете встановити це як першу мету після вищезазначеного експерименту. Оздоблення ще не означає ще завершення вашого початкового основного проекту. Після того як ви закінчите модуль, закінчіть інший і т.д., поки не закінчите переписати весь обсяг свого оригінального проекту, якщо вам це подобається.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.