Невже за останні 20 років не було жодної речі, яка б забезпечила величезні успіхи в розробці програмного забезпечення? [зачинено]

У " No Silver Bullet" Фред Брукс робить різні прогнози щодо майбутнього інженерії програмного забезпечення, найкраще підсумовані за:

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

Його аргумент дуже переконливий. Брукс писав у 1986 році: він мав рацію? Чи розробники в 2014 році виробляють програмне забезпечення зі швидкістю, що не перевищує 10 разів швидше, ніж їх аналоги в 1986 році? За якоюсь відповідною метрикою - наскільки насправді був приріст продуктивності?

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

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

Підвищення продуктивності відбулося за рахунок поєднання факторів. Примітка: Цей список не є вичерпним:

1. Кращі компілятори
2. Величезні потужніші комп’ютери
3. Intellisense
4. Орієнтація на об'єкт
5. Функціональна орієнтація
6. Кращі методи управління пам’яттю
7. Перевірка меж
8. Статичний аналіз коду
9. Сильне введення тексту
10. Тестування одиниць
11. Краще дизайн мови програмування
12. Генерація коду
13. Системи управління вихідним кодом
14. Повторне використання коду

І так далі. Усі ці методи поєднуються для отримання підвищення продуктивності; не існує жодної срібної кулі, яка б ніколи не виробляла порядку прискорення.

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

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

Коли я розпочав свою кар'єру, не було STL, .NET, QT тощо. У вас був сирий C або C ++, і це було про це.

Речі, які раніше займали дні чи тижні або працювали (XML-аналіз, TCP / IP-з'єднання, HTTP-комунікація), тепер можна зробити за допомогою декількох рядків коду C #. Саме тут ми набрали на порядок кращі з точки зору загальної продуктивності розробників.

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

Заради аргументів я не згоден із твердженням Фреда Брукса .

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

Можливість миттєво знайти відповідь на майже кожну проблему, з якою ви можете зіткнутися як розробник, дає величезний приріст продуктивності. Не знаєте, як вибрати n-й елемент у JQuery? Пошук Google призводить до відповіді на точне запитання щодо переповнення стека . Не знаєте, як користуватися overflowCSS? MDN Mozilla знаходиться тут . Забули, що virtualозначає ключове слово у C #? Google знову допомагає .

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

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

• Очевидно, що на Stack Overflow. Наприклад, я не бачив жодної книги, яка б згадувала про цю проблему .

• У блогах. Я знайшов велику допомогу в блогах, коли у мене виникли особливі проблеми, чи це буде конфігурація WCF або проксі-сервер, який не запускається, або криптований помилка при використанні певного API на машині з культурою, відмінною від EN-US.

• У звітах про помилки, що стосуються програмного забезпечення з відкритим кодом. Наприклад, це було дуже корисно останнім часом, коли я намагався використовувати MAAS Ubuntu та коли я використовував PXE. Ви також не знайдете подібної інформації в книгах.

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

• Інтернет не дуже допомагає під час фаз архітектури та дизайну (Programmers.SE може допомогти, але архітектору було б набагато корисніше читати книги про архітектуру та дизайн, вивчати шаблони дизайну тощо).

• Вона починає корисно під час кроків тестування та впровадження, коли виникають фактичні проблеми.

• Але більшість проблем, що виникають під час технічного обслуговування, саме там, коли допомога інших через Інтернет видається вирішальною . Основний приклад: сервіс WCF прекрасно працює на моїй машині , але не працює без винятку при розгортанні у виробництві, хоча він працював останні два тижні. Це сталося зі мною, і я вдячний авторам блогу та спільноті Stack Overflow за те, що вони допомогли мені вирішити проблему за лічені години, а не за тижні.

Чи виправдає це підвищення продуктивності x10? Складно сказати.

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

• З іншого боку, загальна продуктивність покращилася на основі багатьох факторів, таких як поліпшення управління проектами (приходить в голову Agile, TDD тощо), кращого управління командою ( на розум приходить радикальне управління Стівена Деннінга), кращих інструментів (налагоджувачі, профілі , IDE тощо), кращого обладнання (ні, я не буду дуже продуктивним, якщо змушений писати в Assembler для повільного процесора та дуже обмеженої оперативної пам’яті) тощо.

Я б сказав, що Інтернет є досить хорошим кандидатом. StackOverflow та Google - це найпотужніший інструмент для розробників. Миттєвий обмін знаннями на глобальній основі! У ці дні вам не потрібно знати відповідей, потрібно лише знати, як дізнатися відповіді - і це цілком адекватний підзасіб, який дозволяє розробникам витрачати менше часу на читання і більше часу на кодування, і, таким чином, бути продуктивним. Це означає, що кожен програміст у світі має доступ до всіх відповідей, і все, що їм потрібно зробити, - це вміти ставити правильні запитання.

Я б припустив, що тенденції, що тягнуть нас в іншому напрямку (тобто до зниження продуктивності), принаймні такі ж сильні, як і тенденції, про які ви запитували. Досвід роботи з інструментом розробки клієнтів / серверів, як VB6 або PowerBuilder, наблизився до ідеалу «Швидка розробка додатків» (RAD). Ви повинні намалювати свої форми, і для вашого процедурного або SQL-коду були очевидні гачки.

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

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

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

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

Технологія дуже просунулася, і тепер у нас є все те, що Роберт Харві перелічує у своїй відповіді, але:

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

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

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

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

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

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

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

• Одним із смаків зрілості індустрії програмного забезпечення є те, що ліцензії на програмне забезпечення продовжують стверджувати, "<companyX> не дає жодних уявлень про придатність цього програмного забезпечення для будь-якої конкретної мети. Він надається" як є "без явної чи побічної гарантії". Уявіть собі виробника обладнання, який заявив, що їхній продукт не підходить для будь-якої конкретної мети. Це зараз сучасний стан.

Хоча можна сперечатися з конкретними показниками (тобто, чи покращилися речі в 9,98?), Я (кажучи як щось стареньке) повинен погодитися з загальними почуттями коментаря Брукса.

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

Технологія компілятора дозволила приблизно в 10 разів покращити "продуктивність" програміста порівняно з 1970 р., Коли одна функція фігури виробляється розділеною на фактичний час кодування, але розповсюдження нових або "перероблених" мов програмування та середовищ означає, що середній програміст витрачає все більше і більше час в режимі "наздогнати" і менше на продуктивної діяльності. Apple, Google та Microsoft розкривали нові та суттєво несумісні "оновлення" свого середовища зі швидкістю, яка трохи нижче, що могло б спровокувати бунт серед їх кріпаків ... е, програмуючих клієнтів. Аналогічно, HTML / CSS / Javascript / все стає складнішим.

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

Додано: Я думав про це з вчорашнього дня, і зокрема, думав над проектом, над яким працював приблизно з 1978 року до 2008 року. Цей проект (IBM System / 38 та його наступники) був дещо унікальним у тому, що від початку зусилля були зроблена для контролю її складності (одна - це поділ програмного забезпечення на дві приблизно рівні частини, з "машинним" інтерфейсом між ними). У тій конкретній області, де я працював, кілька моїх колег аналогічно були присвячені контролю складності (хоча ми не використовували цей термін багато в той час). У результаті вийшов продукт, який (спочатку) був досить надійним і «вдарив» з клієнтами майже з git-go. І працювати було приємно - як грати у добре навченому оркестрі.

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

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

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

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