Ускладнювачи або оверінженерінг

Це переклад одного цікавого коротенького запису від Alex Papadimoulis, засновника «The Daily WTF».
Написано трохи в англійському гумористичному стилі — неспішно і сатирично.

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

  • По-перше, небезпеку становлять новачки, які абияк змогли отримати своє перше місце роботи, прочитавши «Програмування для чайників» напередодні співбесіди.
  • По-друге, нам загрожують кар’єристи-початківці, які змогли вдало влаштуватися після завершення першого контракту (тобто отримали гроші, а клієнт не засудив їх за розробку марного продукту). Іноді навіть вдається побудувати кар’єру, примудрившись повторити цей шлях декілька разів.
  • Нарешті, є «Ускладнювачи», або «ОверІнженери» (знайти вдалий переклад слова «Complicators», не вдалося, але є поширений термін оверінженерінг, тому — Оверінженери — прим. перекладача), ще одна сторона, яка заманює кращих з нас приєднатися до цієї стежки, навіть всього на один або два мікро-проекти.

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

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

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

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

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

Одного разу, один розробник, сеньйор архітектор з офісу зі східного узбережжя, запостив наступне:

[Off-Topic] Апгрейд велосипеду
Сьогодні я добирався на роботу на велосипеді, і спитав сам у себе — ну чому, чому ніхто не придумав велосипед із підігрівом керма?
Через ці новоанглійські ранкові морози, мої руки льодіють, і страшенно ниють суглоби!
Хтось чув щось про такі речі?

Перша відповідь була від розробника, який працював у відділі Майка, і відповідав за найзаплутаніший і найдивніший компонент у їхньому додатку:

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

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

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

На щастя, у компанії Майка працював як мінімум один адекватний розробник, який вступив в обговорення анонімно і запостив наступне.

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

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

Тож суть цієї статті можно перевести в маленьку пораду:
Наступного разу, коли ви розроблятимете новий продукт, стережіться «Оверінженерів», і коли ви вже готові почати безпосередньо розробку, подивиться ще раз на ваш дизайн проекта та подумки промовте «рукавички»

Посилання на оригінал «The Complicator’s Gloves»

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

За терміном оверінжиніринг та купою беззмістовних абривіатур типу kiss, yagni і тп частіше ховається виправдання відсутністості не те що архітектури, а взагалі відсутність розумніння про те, що буде на наступному тижні. А overcompicating — просто форма поганої інженерії

Ой-йой, зачепили за живе, працював я колись з одним оверінженером... Тяжко було))
Зате в черговий раз спрацювала фраза: «Деякі люди допомагають зрозуміти тобі, якою людиною ти хочеш стати. А інші допомогають зрозуміти тобі, якою людиною ти НЕ хочеш ставати»)

Невеличке доповнення, частково оффтопік. Коли тобі дають запрос на розробку — завжди гарна ідея запитати «а яку проблему (потребу) ви хочете цим вирішити?». Бо дуже часто не професіонал щос вже собі надумав і створив ТЗ на розробку дрона з ШІ для розпізнавання маршруту та оминанння перешкод для доставки компонентів піци між частинами кухні, не уявляючі, що є транспортери — більш надійні та дешеві, стандартні рішення. Наприклад.

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

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

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

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

розробка ПЗ це не інженерія

Нє, ну вьорстка у фігма — так, не інженерія. А в цілому — цілком інженерія.

ага, десь як доктор з економіки і терапевт, і той і той доктор

Ну якщо хочете пограти в слова, то терапевт то є лікар, а не доктор. ;)

А щодо «доктора з економіки», то науковий ступінь, а саме звання «доктора», пішло історично з латини — (лат.: doceō , я навчаю (будь-кого)) з’явилося у середні віки як дозвіл викладати (латинь: licentia docendi) у середньовічних університетах. (з вікі)

медицина взагалі-то досі користується латиною і до наших широт це «доктор» дійшло скоріше як визнання вченості (вміння лікувати).

Інжене́рія (від лат. ingenium — здібність, винахідливість; син.) — це практика використання природничих наук, математики та процесу інженерного проектування для вирішення технічних і технологічних задач, підвищення ефективності та продуктивності і вдосконалення систем.

Я можу погодитись, що деякі «розробники» — не інженери. Але розробник (без дужок) — це інженер. І розробка ПЗ — то є розділ інженерії.

CS — кампутер сайєнс, найди тут слово інженер, навіть граючись в слова, гагага

Наука — то про відкриття нових теорій, законів природи, якщо хочете. CS — то про математику. А не про розробку працюючих систем.

з квори на загальнозрозумілому:
===
Computer science is not engineering. Nor is computing or programming engineering. Anyone can write software with no qualifications and that is a good thing. But you should not build bridges without knowing what you are doing — bridges can fall down and kill people (even engineers get it wrong sometimes).

Now that is not to say that critical software does not exist and should be done by qualified professionals. I still would not call them engineers.

Yes, there should be more discipline in programming and computing. Unfortunately many people who consider themselves professionals and even call themselves engineers defend insecure systems and ways of software development. Lack of security means hackers can gain access to systems to steal money, personal details, and even sabotage infrastructure.

Let’s look at what engineering is. Engineering maps structures onto physical resources with physical materials. Engineers must know the characteristics of those materials.

In computing the characteristics physical resources is handled in operating systems and drivers. Those characteristics do not matter to applications programmers — their programs should only consider the characteristics of the problems, not of the machine.

This is a fundamental principle of computer science, but is little understood by many who say programmers should know how the machine works and program ‘close to the metal’.

Now there is one physical resource that computing is concerned with — time. Can we run a computation in reasonable time (or for security can we have keys that cannot be cracked in reasonable time). Everything in physical resources is about time — more and faster processors, more and faster memory, developing more efficient algorithms.

Thus computing should not be seen as engineering or aspire to be engineering. It absolutely should aspire to be more disciplined — at least for professional development. Engineering is about analogue physical resources with foibles, but computing about idealised digital logical resources — that is the power of computing.

Ну так, квора то є база :D:D:D:D:D

Ну якщо більше нема що сказати, то бугага і лол

Obviously there IS truth to Astrology- otherwise it would not have survived for so long.

www.quora.com/...​-be-proved-scientifically

Бугага, лол, ну дійсно-ж.

Розробка ПЗ — то є наука

Астрологія — працює.

Ну так-то мені дійсно більше нема чого сказати. Чо тут скажеж-то...

розробка ПЗ то скоріше «прикладна математика»

Якщо це розробка нових мов програмування чи математичних методів — то це є наука (те саме CS). якщо це використання наявних методів та мов програмування для побудови систем автоматизації чи управління (тобто 99% розробки) — то це інженерія.

Прикладна математика це все-ж таки математика. Розробники ПЗ не розробляють нових математичних методів та теорій — це роблять науковці-математики.

Інакше бухгалтер-користувач Excel — вже IT-шник, майже CS ;)

А бухгалтеру (при всій до цій професії повазі) і до доктора економічних наук недалеко! Як медсестрі до доктора медичних наук ;)

бухгалтер-користувач Excel — вже IT-шник

якщо щось в бейсіку екселить — то мабуть в принципі має право програмером назватись не менше ніж вебпрограмінг, чи вайбпрограмінг, чи може навіть аі-програмінг)

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

розробка це більш ніж кодування, а скажімо «прикладна логіка» далеко не вся математика

В тому ж Stanfordі CS йде під амбрелою Stanford Engineering. Не думаю що буде великою помилкою маcштабувати engineering і на цей напрямок, імхо

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

Програмування написання кодів поведінки системи, подібно як до написання депутатами ВРУ законів/кодексів, отже депутати є інженери, так як іх діяльність містить інжиніринг.
Л — логіка
п.с.
програміст заварює каву отже він кухар, а ще він у WC зливає, то є сантехнік

забезпечення інфраструктури

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

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

код з розрахунком на інфраструктуру та оптимізацію між швидкістю виконання та оптимізацією використання ресурсів

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

а оптимізація ресурсів не заліза а фінансовових витрат

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

Я б безсумнівно віддав перевагу літаку, софт у якому розробляли справжні інженери, ніж «науковці», «митці» та інші вайб-кодери.

То то я думаю чого в мене спеціальність називалась «Інженерія ПЗ» :)

на заборі пише х.й, а там дрова

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

приїхав, руки вийняв, все зробив, засунув назад і поїхав далі

Это как у нас на стадионе в подсобку к сторожу провели телевизор и камеру чтоб он видел ворота и открывал их когда подъезжает авто.
Начались блэкауты. Денег в бюджете естественно на систему беспроводного питания нет. Пока местные активисты считали и агитировали народ купить инвертор и аккумы сторож взял шуруповерт и повесил таки зеркальце :-)

на різноманітних електрозасобах ... примотують здоровезні теплі міхові рукавиці

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

при чому геть неінженери

Людина може бути інженером, а доставщиком працювати для души...

Підписатись на коментарі