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


19

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

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

Друга порада: справді продумайте проект, перш ніж писати будь-який код.

Я мав успіх в обох методах, і я б сказав, що я згоден з кожною філософією.

Але зараз я починаю вирішувати набагато складніші проекти, які я поняття не маю, як виконати (наприклад, розподілені програми та графічне програмування, кероване продуктивністю).

Як мені піти про ці проекти?

Чи я просто починаю кодувати SOMETHING і вчитися (платформи / методи / мови / архітектури), коли я йду - або я не втримуюсь від кодування і виконую тону досліджень / читання, перш ніж я навіть відкрию IDE?

Як я погоджую ці суперечливі частини програмних порад?


Робіть і те, і інше. Повторіть, документуйте, повторіть, документуйте, повторіть і, як тільки ви отримаєте чіткий план, який працює. Побудуйте його: D
Matt D

1
Дещо пов’язане з есею Кента Бека на тему "Зробіть його, а потім зробіть його правильним, В.С. зробіть це правильно, а потім змусьте його запустити": facebook.com/notes/kent-beck/runright-and-vice-versa/…
Тіаго Сільва


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

Дуже глибокий. Я згоден. Мій середній професійний проект - це приблизно 40-50% на передній проектній роботі, 10, максимум 15% кодування та інше для тестування.
Мауг каже, що повернемо Моніку

Відповіді:


20

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

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

Просто невеликий приклад. Днями я боровся з рішенням про розробку програмного забезпечення. Заднім поглядом це було відносно тривіально, але у мене було дві альтернативи, і здавалося, що вони обоє будуть працювати. Я постійно крутився до плюсів / мінусів кожного, а потім кружляв назад і переглядав свої рішення. Озираючись назад, трохи бентежить, скільки часу я витратив на роздуми. Тоді я сказав собі: f # @ k it! І замість того, щоб використовувати будь-яку з конструкцій, я просто пішов вперед і зламав якийсь код разом, повністю ігноруючи всі хороші речі, які ви дізнаєтесь про хороший дизайн. У мене ця функція працювала приблизно за 45 хвилин. Потім я повернувся назад, подивився на свій код і переробив його на щось солідне, і щось мені не соромно було б перевірити контроль над джерелами. Найцікавіше, що після того, як я зламав роботу, я придумав "

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


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

5

Є певні рішення, які потрібно прийняти достроково.

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

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

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

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


1

Я не розглядаю їх як взаємовиключні.

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

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

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

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


1

"Ітерація" та "мислення через це" не суперечать один одному, натомість є взаємодоповнюючими.

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

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

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

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

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

Латинський корінь вирішують кошти «відрізати». Ітерація дозволяє вирішити, що працює на практиці, а не просто теорію, а ітерація дозволяє вирізати інші варіанти, які неможливо.

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


0

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

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

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