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

16

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

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

Як я прийшов до цього висновку? Ось кілька аргументів:

Відгуки

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

Без зворотного зв'язку важко розпізнати та виправити помилки.

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

Помилки та застереження від компілятора
Результати аналізу статичного коду
Одиничні тести

Помилки можна швидко розпізнати та виправити.

Послідовність

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

Рефакторинг

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

Є одна передумова, щоб зробити цю роботу: Код повинен бути досить легким для читання та розуміння. Цього, мабуть, неможливо досягти за допомогою Assembler, Basic або Fortran, але сучасні мови (і бібліотеки) набагато виразніші.

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

— Френк Пуффер
джерело

2

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

— Відновіть Моніку

14

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

— Док Браун

2

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

— whatsisname

2

Рекомендоване читання: Побиття середніх показників .

— Роберт Харві

1

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

— Нік Кейлі

9

Я сумніваюсь у тому, що мови все більш виразні. З сьогоднішнім кодом ASP.NET в c #, я пишу приблизно на тому ж рівні, що і коли я писав ASP-код у Visual Basic. Ми все ще використовуємо c ++. Javascript додав функції, але в цілому мова не змінилася. Те саме з SQL.

Я думаю, що ці інші зміни є більш значущими:

Прийняття автоматизованих одиниць тестів. Дехто сказав, що тести - це специфікація. Тому ми не усунули необхідності писати специфікації; швидше, ми пишемо їх у коді, а не в документах Word.
Зміни в методології розгортання. Раніше помилятися було дуже дорого, оскільки вам потрібно було б відправити оновлену копію програмного забезпечення. Тож треба було бути обережними. За допомогою веб-додатків ви можете розгорнути виправлення для негайного використання, і ви можете дозволити собі реагувати на проблеми, а не передбачати їх, реструктуруючи код у процесі роботи.
Прийняття моделей дизайну. Коли всі знають шаблони, вам навряд чи потрібно щось розробити; ви можете просто сказати "додати заводські сховища", і ваша команда повинна це зробити, не потребуючи перегляду UML.
Договори з даними SOA. На сьогодні все дуже SOA. Все, що вам потрібно, це WSDL. Пройшли дні визначення та документування форматів передачі даних. Нинішній рух до більш РЕСТЕКТНОГО та мікропослуг продовжує цю тенденцію.
Програмного забезпечення менше. Частково в результаті архітектури SOA команди створюють менші програми, пов'язані між собою. Кожен окремий компонент менш складний і вимагає менше передньої конструкції; Крім того, легше змінити частину архітектури, не порушуючи загальне рішення через пожежні перерви, вимушені визначеннями інтерфейсу між компонентами.
Значно, набагато більше використовуйте створені бібліотеки. .NET CLR пропонує безліч функціональних можливостей з полиці, тому не потрібно розробляти, скажімо, схему кешування даних сеансу. Сторонні бібліотеки, такі як інтерфейс jQuery або Bootstrap, встановлюють стандарти для написання коду, щоб працювати певним чином. Вам не потрібно документувати ці документи; команди повинні мати можливість просто їх використовувати.
Зрілість галузі. SWE дізналися, що не існує такого поняття, як проект "Battlestar Galactica", де ви проводите роки та роки, намагаючись досягти конкретної мети; до того часу, як минули ці роки, мета зміниться. Сьогодні ми знаємо, що час на ринок набагато важливіше, ніж отримувати все саме так, як ми цього хочемо в дизайні.
Краще і стабільніше освічені інженери. Цього дня ви можете найняти інженерів, які розуміють найкращі практики (сподіваємось) і просто впроваджуєте їх, не маючи документа на розробку, який би сказав їм, що робити.
Інструменти продуктивності, такі як TFS, дозволяють написати просте завдання, яке посилається на випадок використання та надає пару пунктів для будь-яких неоднозначних технічних рішень. Вам не потрібно набагато більше, ніж це. Розробники можуть переглядати, оцінювати, отримувати огляди коду, перевіряти і т. Д. Все через інструмент. Це набагато ефективніше, ніж робота з зовнішніми документами, оскільки вона пов'язує все разом.

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

— Джон Ву
джерело

3

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

— Роберт Харві

1

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

— ctrl-alt-delor

6

Я б заперечував за « ні» .

З простої причини, що

Для багатьох ІТ-людей, включаючи мене кілька років тому, ідеальний процес розробки програмного забезпечення передбачав би створення детальних проектних документів з великою кількістю діаграм UML до того, як з'явиться рядок коду.

Ніколи не вважався "ідеальним", оскільки Екстремальне програмування існує з 1990-х років . І як ви кажете:

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

Аргументувався століттями тому. Наприклад, ця легендарна стаття 1992 року: Що таке дизайн програмного забезпечення .

Сказане вище показує, що ви можете мати «екстремальний» процес із сильно еволюційною архітектурою та ітераційним підходом без необхідності складних мов чи IDE.

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

— Ейфорія
джерело

6

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

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

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

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

— JimmyJames
джерело

3

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

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

Немає необхідності мати документи, які описують точну поведінку системної системи у всіх деталях, оскільки дійсно вихідний код саме цьому і відповідає.

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

— ЖакБ
джерело

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

— Френк Пуффер

@FrankPuffer діаграма вартує 100 000 LoC.

— RubberDuck

1

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

— JimmyJames

1

@RubberDuck: Діаграми мають сенс у деяких випадках, наприклад, пояснити загальну архітектуру. Але я не думаю, що вони повинні бути типовими. Однозначно є хороші та корисні діаграми, але, на жаль, більшість UML, які я бачив, є більш заплутаними, ніж корисними. І що гірше, воно часто відрізняється від фактичного впровадження.

— Френк Пуффер

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

— RubberDuck

1

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

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

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

Одиничні тести

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

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

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

Напевно, на даний момент простіше використовувати інструмент для перевірки документації.

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

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

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