Маслоробка

Ти чув про хлопця, який попрощався з ООП?
ні. Ще один? Що ж він сказав?
Він описав всі обіцянки ООП, і жодна з них насправді не було виконано, і що всі можливості ООП обходяться дорожче, ніж вони реально коштують, і функціональне програмування краще, і ...
Ох. Так, я чув все це раніше...
Таким чином, ООП остаточно померла, і ми можемо рухатися далі.
Рухатися далі до чого?
Ти чого? До наступного технологічного прориву, звичайно!
А, до цього… І що там у нас на черзі?
Не знаю, мене дуже приваблює ідея мікро-сервісів; і я дуже зацікавлений в Elixr; і я чув React по-справжньому крутий; і ...
Так. Так. Маслоробка. Ти попався в Олійницю.
Чого? Що ти хочеш цим сказати? Зараз чудовий час.
Як на мене, скоріше гнітюче.
Чому? Нові технології виникають щотижня! Ми піднімаємося на все більш високі висоти.
Тю! Все, що ми робимо, заново винайшли колесо, знову і знову. І ми даремно витрачаємо час і величезні зусилля на це.
Ой, да ладно! Ми створюємо ПРОГРЕС.
Прогрес. У самому справі? Це не те, що я бачу.
Ну, і що ж ти бачиш?
Я бачу марнотратство. Масові, незліченні втрати часу та коштів. Марнотратство помножене на марнотратство і помножене на ще більше марнотратство.
Як ти можеш таке говорити?
Ну, розглянемо хоча б це питання з ООП. ООП не померло. ООП ніколи не було живим. ООП є технікою, гарною технікою. Стверджувати, що воно мертве, це як стверджувати, що хороша викрутка мертва. Прощатися з ООП, це як прощатися з хорошою викруткою. Це марна трата!
Але функціональне програмування краще!
Мені дуже шкода, але це як говорити, що молоток краще викрутки. Функціональне програмування не "краще", ніж об'єктно-орієнтоване програмування. Функціональне програмування являє собою метод, і дуже хороший, який може бути використаний спільно з об'єктно-орієнтованим програмуванням.
Це не те, що я чув. Я чув, що вони є взаємовиключними.
Та ні, звичайно. Вони спрямовані на вирішення ортогональних проблем. Проблем, які присутні у всіх проектах.
Дивись, є люди, які думають, що розвиток програмного забезпечення являє собою лінійний прогрес. Типу ми піднімаємося на одну сходинку сходів раз за разом, і кожна "нова" сходинка краще, ніж попередня "стара". Але це так не працює.
як же це працює по-твоєму?
Прогрес в області програмного забезпечення слід логарифмічної кривої зростання. У перші роки прогрес був різким і драматичним. У наступні роки прогрес став набагато більш поступовим. В даний час прогрес практично відсутня.
Дивись: асемблер був набагато краще, ніж машинний код. Fortran був набагато краще, ніж асемблер. C було суттєво краще, ніж Fortran. C++ ймовірно краще, ніж C. Java був поліпшенням у порівнянні C++. Ruby ймовірно трохи краще, ніж Java.
Каскадна модель (водоспад) була набагато краще, ніж нічого. Agile була краще, ніж водоспад. Lean був трохи краще, ніж Agile. Kanban можливо був чимось типу поліпшення.
Кожен рік, хоча ми докладаємо величезних зусиль, ми робимо менший прогрес, ніж роком раніше. Тому що кожен рік ми стаємо все ближче і ближче до асимптоте.
Асимптота?! Думаєш, є верхня межа технологій розробки програмного забезпечення?
Впевнений. Більше того, я думаю, що ми зараз настільки близькі до цієї межі, що будь-яке подальше зусилля марно. Ми вже пройшли кордон, падіння ефективності.
Що? Це звучить безглуздо! І пригнічує!
Я розумію. Але це тому, що ми звикли до швидкого зростання. Це були п'янкі дні, і ми хочемо повернути їх. Але вони пішли, і ми повинні визнати той факт, що ми витрачаємо час і зусилля в масовому масштабі, намагаючись відтворити їх.
Але якщо ми не будемо впливати на майбутнє — ми ніколи не створимо його!
Повір, я безумовно хочу, щоб ми підганяли майбутнє. Але це не те, що ми робимо. Ми просто сумуємо за минулим.
Так якого ж майбутньому ми повинні прагнути?
До продуктивного. До майбутнього, яке не підпорядковане марнотратною маслоробці.
Що означає "марнотратний" в даному контексті?
Ти коли-небудь використовував IntelliJ або Eclipse для програмування на Java?
Звичайно.
Це неймовірно потужні інструменти. Досвідчений фахівець може бути надзвичайно продуктивним з цими інструментами. Рефакторинг! Уявлення! Зручності! Боже мій, ці інструменти вражають!
Тим не менше, кожен раз, коли виникає новий мову, ми відмовляємося від потужних інструментів, щоб перейти до НАСТУПНОГО НОВОЇ ШТУЦІ. І інструменти для нової мови програмування виглядають як рівень життя в країнах третього світу. Боже, часто там немає навіть банального "rename" рефакторінгу!
На створення пристойного набору інструментів йде час. Якщо ми будемо продовжувати переключатися з однієї мови на іншу, ми ніколи не забезпечимо їх надійним інструментарієм.
Але нові мови краще.
Так кинь! Вони відрізняються, але вони не краще, принаймні не настільки краще, щоб виправдати повернення набору інструментів назад у кам'яний вік.
А подумай про витрати на навчання для адаптації нової мови. Подумай скільки обходиться організаціям використання 84 різних мов тільки з-за того, що програмісти захоплюються новими блискучими речами кожні два тижні.
Нові блискучі речі? Звучить якось прикро, чи не так?
Вважаю, що так, але найчастіше все зводиться саме до цього. Нові мови не краще, вони просто блискучі. І пошук золотого руна у вигляді нової мови, або нового фреймворку, або нової парадигми, або нового процесу досяг точки, коли це стає непрофесійною.
Непрофесійним?
Так! Це непрофесійно. Нам потрібно усвідомити, що ми вперлися в асимптоту. Пора зупинити марнотратне спінювання мов і фреймворків, а також парадигм і процесів.
Настав час, щоб почати просто працювати.
Нам потрібно вибрати мову, або два, або три. Невеликий набір простих фреймворків. А потім вибудувати наші інструменти. Кристалізувати наші процеси. І стати справжніми професіоналами.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.