Поняття та дизайн перед кодуванням: наскільки це правда? [зачинено]

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

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

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

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

Я думаю, що відповідь має бути: Плануйте стільки, скільки можете, але не більше того.

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

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

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

Це абсолютно правда. Чим більша і складніша вимога, тим правдивіше це.

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

Але як щодо торгової платформи в реальному часі, яка, як очікується, буде робити мільйони транзакцій в секунду, поширюються в усьому світі, і для цього потрібно 99,9999 часу безперервного часу і 100% коректності? Ви б просто перестрибнути в кодування цього?

Існує безліч інших варіантів між цими двома крайнощами.

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

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

Я ніколи не встигав сконструювати і задумати все з самого початку

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

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

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

Але саме тому вона називається м'якої -ware і не важко -ware. Це податливо і може бути змінено.

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

Це правда.

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

І там є ваша проблема.

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

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

Перед кодуванням ви абсолютно повинні мати якийсь дизайн .

Причина досить проста - якщо у вас немає дизайну, ви не знаєте, що робите .

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

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

Розвиток ітеративний.

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

Спробуйте більше, ніж один підхід.

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

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

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

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

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

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

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

Один приклад - розмістити розмір на чомусь великому. Концепція: "Створіть візуальний хмарний інструмент, який дозволяє бізнесу інтегрувати свої програмні платформи". Це звучить чудово, і можна почати писати маркетингові матеріали та продавати їх ще до того, як вони навіть з’являться. Ви повинні мати це перед кодуванням.

Попередній дизайн: "Майте фігури та стрілки, як у Visio, щоб описувати логіку; мати можливості плагіну для підключення до різних платформ (SAP, SF, бази даних ...); мати консоль моніторингу, де можна шукати дані, що проходять через система; мати спосіб візуального опису даних та перетворення одного формату в інший ". Ще один чудовий маркетинговий блок. Це також дає вам декілька ідей щодо того, що важливо, має бути такий приблизний ескіз і до кодування.

Дизайн / код: "У веб-переглядача розміщений HTML-дизайнер з такими та подібними функціями; кодуйте резервний сервер на Java, щоб він міг працювати на будь-якому існуючому сервері; визначте структури даних та UX для запитів або зміни їх за потребою; плануйте відновлення після аварій, помилку звітування, журнал аудиту; контроль версій плану; контроль доступу до плану; .... "- чим тонший список, тим нереальнішим буде його передбачити.

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

Я завжди виділяю час так:

1. 1/3 Дизайн
2. 1/3 Розробка
3. 1/3 Тестування

Дизайн: Не тільки візуальний, але й концептуальний. Розділіть його на частини, як візуально, так і за логікою. Шукайте спільності, які повторно використовуються та є дизайнерською схемою.

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

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

Окрім цих аспектів, майте на увазі, що проект також має 3 фази на вершині цих фаз.

1. Перша спроба недостатньо спроектована
2. Друга спроба з інженерії, з уроків, отриманих з першої спроби.
3. Правильно спроектована третя спроба.

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

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

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

Рішення таке:

1. Напишіть код, який, на вашу думку, може вирішити проблему.
2. Придумайте дизайн, заснований на тому, що ви дізналися з коду.
3. Викиньте весь код і перепишіть його з нуля відповідно до дизайну.
4. Повторіть по мірі необхідності.

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

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

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

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

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

потім виберіть найкращий стек

Я розробник LAMP

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

щоб додати це, навчіться використовувати рамки MVC, ZEND та CAKEPHP - найкращі рамки швидкого розвитку (PHP)