Чи повторне використання програмного забезпечення виключає повторюваність процесу

Повторне використання коду як проблема

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

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

Деякі порівняння з іншими дисциплінами

Будівництво

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

Майстри будівельники - це експерти, визнані за те, що спроектували та / або побудували десятки, сотні чи тисячі речей у своєму районі. Наприклад, Френк Ллойд Райт , всесвітньо відомий архітектор і дизайнер designed more than 1,000 structures and completed 532 works. Порівнюйте це з Андерсом Хейльсбергом, який створив "всього" п'ять мов (Turbo Pascal; Delphi; J ++; C #; Typescript). Багато в чому це несправедливе порівняння, оскільки домени різні. Але на широкому рівні кількісно оцінюється виробництво у двох дуже розумних людей сильно відрізняється.

Бойові мистецтва

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

Деревообробка

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

Отже, чи повторне використання програмного забезпечення перешкоджає розробникам програмного забезпечення ставати більш досвідченими?

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

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

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

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

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

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

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

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

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

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

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

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

Що стосується продуктивності - коли ви будуєте, скажімо, міст, ви стикаєтесь із дійсно значними обмеженнями у реальному світі. Уявіть собі, якби архітектори платили великі суми грошей на проектування мостів для масових багатокористувацьких онлайн-ігор, де витрати на будівництво були майже 0, а обмеження значно менші, ніж у реальному світі. Вони б спроектували мости, які дивно складні за стандартами мостів у реальному світі. Фаза плану може зайняти трохи більше часу.

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

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

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

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

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

Але на ваше коротке і стисле запитання: З мого досвіду я б сказав і так, і ні.

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

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

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

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

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

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

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

Ага - бовтався, знову заглянув ... Моє виправдання, що я не спав 32 години, тому моя здатність до фокусування трохи ... що я говорив?

Якщо хтось ще читає, я робив висновок, що:

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

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

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

Для цього рекомендується прочитати: Аналогія побудови програмного забезпечення порушена

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

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

Коли я був тестувальником 1,5-річного проекту, ми проходили тестові цикли на щотижневих випусках "контрольно-пропускних пунктів", що приблизно в 70 разів перевищує проект. Це було ... досить повторюване, м'яко кажучи (не багато чого змінюється за тиждень). Тестування нічних будівель було, природно, ще більш повторюваним - приблизно 500 разів через проект (кілька розважальних помилок showstopper були надто рідкісними, щоб змінити значення).

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

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

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

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

Що стосується розробників проектів, то вони буквально побудували ("вночі будує") - бачте, слово те саме, і значення саме в цьому контексті - сотні речей у їхній області.

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

• Як приклад, ще один з моїх минулих проектів (знову ж таки, нічого вражаючого, досить регулярного), цього разу в ролі розробника, триває вже більше 5 років (8 основних релізів, кілька десятків другорядних). Були подібні щотижневі контрольно-пропускні пункти ( 5x52~=250з них), подібні нічні релізи ( 5x365~=1800з них) і аналогічно, ті ж команди розробників / контролю якості, що працюють над ними. День за днем, тиждень за тижнем, місяць за місяцем, в основному повторювані речі (не сильно змінюються між двома нічними складаннями) - як обіцяли, в межах тисяч разів (1800).

Проекти довшого життя, такі як Windows або Java, або AutoCAD можуть тривати 10, 20, 30 років, що легко пояснює повторення стількох "тисяч" нічних збірок і нічних тестів, скільки отримує.

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

практика ... кілька разів на день об'єднувати всі робочі копії розробників із спільним основним рядком ... CI можна розглядати як активізацію практики періодичної інтеграції ..

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

Повторність? саме там, стільки, скільки можна придумати.

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

вправа програмування, яка допомагає програмісту відточувати свої навички через практику та повторення ...

Деякі з сказаних вами правдиві: наприклад, бібліотеки вирішують функції, не вирішені мовами високого рівня, які вирішують проблеми, не вирішені складанням, які вирішують проблеми, не вирішені машинним кодом. Коли ви телефонуєте System.out.println () в Java, ви втрачаєте уявлення про те, як процесор виводить на пристрій.

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

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

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

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

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

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