Refactor або концентрат на завершення програми

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

Завершення програми означатиме, що згодом вам буде дуже важко підтримувати додаток?

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

Змусити це працювати. Тоді зробіть це швидко. Нарешті, зробіть це красивим.

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

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

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

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

Я завжди рефактор, коли їду, особливо використовую TDD.

1. Напишіть тести

2. Зробіть проходження тестів

3. Рефактор

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

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

Реконструкція - це як забрати свою кімнату.

Якщо ви тримаєте впорядковані речі, у вас є лінійні накладні витрати, пропорційні кількості продуктивної роботи, яку ви робите над кодом, O (n) з точки зору алгоритмолога. Якщо припустити, що ви витрачаєте 10% часу на реконструкцію (або утримуючи свою кімнату в порядку), це 10% - це дані, і воно буде залишатися незмінним у часі.

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

Кожен, хто коли-небудь занурювався в поняття алгоритмічної складності, зауважить, що десь існує точка беззбитковості, тобто є оптимальна кількість брудної білизни, яку потрібно накопичити; скільки це залежить від постійних факторів, які відкидаються в нотації big-O. Ще один фактор - цінність вашої роботи з часом: якщо ваша робота зараз стоїть багато, але на наступному тижні дешева (тобто, в цю п'ятницю є крайній термін для цього проекту та ще три, але після цього ви будете здебільшого простоювати ), рівняння може виявитися на користь не рефакторингу.

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

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

TL; DR: Якщо є сумніви, рефактор. Ви повинні мати справді хороші докази, перш ніж вирішити цього не робити.

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

Дійсно залежить від того, де ти знаходишся!

Інші речі, про які варто подумати:

Наскільки ви впевнені, ви справді отримали правильний функціональний дизайн? Чи можете ви знову переробити дизайн після отримання відгуків користувачів?

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

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

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

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

Рефакторинг буде дуже важливим під час роботи над заповненням заявки.

+ ВЕС

1. Чистий потік: Рефакторинг надасть ясність коду, оскільки іноді, якщо код мало неструктурований, зрозуміти потік коду через певний проміжок часу стане важко, а код рефакторингу може стати важким завданням і помилки можуть вступити.

2. Підвищення продуктивності: Правильне рефакторинг програми безумовно допоможе покращити продуктивність програми.

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

-ВИ

1. Затрата часу: Це би забирало набагато більше часу на кожному етапі вашого прогресу. Тож може виникнути затримка завершення.

Нижня лінія

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

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

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