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

Для контексту я будую настільний додаток. Я єдиний розробник, і займаюся цим неповним робочим часом, оскільки працюю в день. Зараз для роботи я намагаюся робити все правильно, графік дозволяючи. Але для цього проекту, який, напевно, перетворюю, коли я отримаю відгуки від людей, я не впевнений, що це правильний підхід. На цьому тижні я провів кілька годин, вкладаючи в підручник дизайн контролера Model View, щоб повідомити про зміни в моделі на вигляд. Це взагалі чудово, але я не впевнений, чи потрібно мені кілька представлень для відображення даних, і я знаю, що я міг би швидше відображатись без додаткової архітектури. Маючи, можливо, 10-15 годин на тиждень, щоб витратити на проект, я вважаю, що це займе віки, щоб отримати щось, що я можу демонструвати, якщо дотримуватимусь належної програмної практики. Я знаю, що мої користувачі перемогли ' Не хвилюйтеся, що я використовував MVC внутрішньо, вони просто хочуть щось, що вирішить їхню проблему. Але я також потрапив у ситуацію, коли у вас виникло стільки технічної заборгованості за скорочення, що код просто неймовірно складно підтримувати та додавати нові функції. Я хотів би почути, як інші люди підходять до подібної проблеми.

Побудуйте це добре .

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

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

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

Крім того, є щось важливе, щоб усвідомити "добре його будувати" та проектувати архітектуру. Ти запитав...

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

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

Закон Джона Галла із систематики :

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

Швидко, то добре

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

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

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

Отже, швидко, тоді добре!

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

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

Таким чином, ви, в моєму досвіді, отримаєте програму зі звуковою архітектурою якомога ефективніше :)

Побудуйте його

Швидкий, якщо час на ринок важливіше якості

Добре, якщо якість важливіша за ринок часу

Швидке його створення принесе вам короткострокові вигоди та довгострокові втрати.

Добре будувати це призведе до короткочасних втрат, але довгострокових вигод.

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

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

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

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

Добре будувати = швидко будувати

Ярлики, як правило, обертаються і кусають вас ще швидше, ніж ви думаєте. Іноді навіть до обіду.

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

Добре, якщо ви вже знаєте, що робите, швидше, якщо цього не зробите

Я вчений-дослідник і пишу багато дослідницького коду, перш ніж у мене з’явиться поняття, що таке велика картина чи як буде розвиватися проект. У цих випадках важко навіть зрозуміти, як слід «визначити». Крім того, зазвичай важко побачити всі дрібні деталі та способи розширення речей вперед. Тому застосовується стара приказка:

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

Будуйте це добре .. завжди, але дайте ілюзію швидко йти

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

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

Баланс

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

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

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

що я очікую, що це перетвориться, коли я отримаю відгуки від людей

Ви сказали, що найкраще самі:

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

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

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

Побудуйте це добре . Якщо у вас немає часу, зменшіть набір функцій.

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

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

У моїх вухах, як ви її туди поставите, ви перераховуєте дві крайності. Перший вибір - порушення інкапсуляції, введення логіки моделі у погляди, це просто погане ліниве програмування. ІМХО, вирішення цих проблем - це не те саме, що введення більшої архітектури. Можливо, якщо тільки ви не говорите про те, що код інтерфейсу виконує операції SQL. Але тоді я б не сказав будувати більше архітектури, тоді я б сказав, що у вас повна відсутність дизайну та архітектури, і ви повинні отримати її.

Що стосується архітектури, я вибрав би найпростіший, який вирішує проблему зараз, а потім розширюватиметься у міру виникнення проблем.

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

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

Це, до речі, і підхід, який я використовую, коли працюю професійно. ;)

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

Зазвичай ви хочете бути посередині цих двох країв:

Створіть це добре = критичне для життя програмне забезпечення в реальному часі, від якого залежить життя людей. тобто контроль програмного забезпечення: ядерні реактори, діалізний апарат, МРТ-машини та ін.

Будуйте його швидко = марне програмне забезпечення, яке ніхто фактично не використовує.