Чи повинні методи розвитку розбити індивідуалізм розробника?

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

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

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

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

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

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

Ні, інструктор має рацію сказати вам перелічити всі властивості та методи наперед, якщо ви використовуєте метод водоспаду. Вікіпедія відзначає критику водоспаду:

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

Ці методи проектування не розбивають виконавця індивідуалізму дизайну, оскільки є ще частини для інтерпретації та способів нанести унікальні штрихи на структуру, наприклад, малюнок, що надається скелету та додавання м'язів та інших тканин, щоб створити тварину цікаво, скільки свободу, чи потрібно було вам проектувати цю тварину?

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

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

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

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

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

Це все дуже справедливі моменти.

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

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

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

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

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

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

Тому?

чи інструктор сказав нам неправильно, попросивши перерахувати кожну функцію?

Ні. Це загальна вимога.

І, чи ці методи проектування пригнічують реалізатор дизайну (розробник) індивідуалізму, щоб написати код, як вони найкраще це зрозуміють?

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

Ні. Ти просто балуєшся на тугу. Отримайте це і поверніться до роботи.

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

І методології теж створені для обмеження.

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

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

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

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

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

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

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

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

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

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

Викладач "сказав вам неправильно"?

Я думаю так.

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