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

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

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

Оновлення: поєднання YAGNI з sunpech та відповідями M.Sameer має для мене ідеальний сенс :) дякую всім за допомогу.

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

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

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

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

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

як завжди...

Це залежить

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

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

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

Якщо ви прототипуєте, чому ви думаєте про чистий код? Сама ідея складання прототипів полягає в тому, що воно покликане довести поняття чи ідею, а потім їх викинути.

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

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

Я думаю про кодування так, як писав би статтю:

Коли ми пишемо папір, ми починаємо десь, замальовуємо ідеї, контури тощо. Він не міститиме всіх деталей або не має закінченого вигляду - це, по суті, перший чернетка, за ним другий тощо. Багато чого буде переписано, замінено та / або навіть видалено по дорозі до більш вишуканого та готового паперу. (Очевидно, що ця аналогія не заходить так далеко, щоб сказати, що код коли-небудь справді закінчується чи закінчується, як документ.)

Існує два типи прототипування:

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

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

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

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

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

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

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

І те й інше добре. Обидва мені подобаються. Вони не суперечать один одному.

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

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

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

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

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

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

Я написав статтю, яка могла б дати підказки щодо початку: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d