Дизайн програмного забезпечення за допомогою псевдокодування?

Чи знаєте ви хороший спосіб розробити (тобто записати) програмне забезпечення методом, заснованим на псевдокоді?

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

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

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

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

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

 I thought agile is about schedule only?

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

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

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

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

Є кілька інших альтернатив, які ви також можете виглядати:

• Діаграми потоку даних
• Діаграми стану
• Діаграми потоку процесів

Хороші посилання: Підручники з розробки програмного забезпечення . Крім того, я б особисто порадив прочитати хороший блог на Псевдокоді чи Кодексі? опублікував Coding Horror - мій улюблений блог для читання :)

Загалом, є деякі компроміси, які потрібно врахувати.

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

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

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

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

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

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

Я думаю, що графічні інструменти краще, ніж псевдокодування, але UML просто настільки сильно ускладнюється, що поєднує в собі ці погані методи :-)

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

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

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

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

Якщо ви втратили свій графік і бачите безліч рівноцінних можливих рішень, перейдіть на псевдокод або навіть запишіть цей код з макетними об'єктами - на Java, це майже не має різниці. Перегляньте код, відчуйте структуру та зручність використання цих компонентів, це допоможе вам виправити графік і приймати рішення. Але це працює ТІЛЬКИ, якщо ви готові викинути цей код, якщо вам здається, що це погано. Я думаю, що це перевага псевдокоду: менша спокуса зберігати його, коли він працює, але він неправильний у структурі (і, як завжди, у вас не вистачає часу). :-)