Автоматизація розробки ПО: чи зможе «програміст» перетворитися в «оператора ЕОМ»

image
Зображення з сайту vse-temu.org

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

Але якщо копнути глибше, виникнуть питання. Про яких саме програмістах мова? Про тих, хто проектує? Про тих, хто розробляє алгоритми? Про провідних розробників або простих «кодерах»? У будь-якому разі, однієї думки тут бути не може.

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

Точка відліку

сказав Михайло Густокашин на лекції в «Яндексі», давайте почнемо з самого початку:
на самому початку У комп'ютерів не було навіть клавіатури! Тобто все було дуже погано — у них не було ні клавіатури, ні екрану, були перфокарти (це такі штучечки з дірочками або з відсутністю дірочок).

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

Наприклад, асемблера (Assembler), який вже кілька полегшував життя. Ну, як він полегшував життя? Замість запам'ятовування того, що там якийсь «чарівний» код у команди, використовувалися всякі слова, схожі на «людський» англійська мова — які-небудь add або mov — ну і потім перераховувалися регістри або області пам'яті, змінні, з якими потрібно ці операції робити. Але ясна річ, що це взагалі-то теж вимагало чималої напруги розуму, щоб тримати у себе в голові, в якому регістрі у нас що лежить, де які змінні і що взагалі відбувається. Чому так відбувалося? Тому що комп'ютери були «дурні» і нічого більше «розумного» зрозуміти не могли.
image
Зображення з сайту devdelphi.ru

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

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

Рівень вище — нижче поріг

З появою мов програмування високого рівня життя програмістів ставала легше, а продуктивність – вище. Програми не потрібно було переписувати для кожної машини. З'явилися компілятори, середовища розробки. Fortran, Algol, а пізніше BASIC, PASCAL, C дійсно були більше схожі на «людську» мову.

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

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

Програмування — в маси

Поступово програмування перестало бути прерогативою хардкорних інженерів і математиків. Число проектів стрімко зростала, програмне забезпечення проникала в різноманітні сфери виробництва. Цьому також сприяло і розвиток систем управління базами даних. З'явилися навіть такі спеціалізації, як «оператор СУБД».

Поступово поняття «інженер-програміст» стало багатогранним: хтось займався алгоритмами, хто проектував інтерфейси, хтось просто займався кодуванням – тобто реалізовував у коді готові алгоритми своїх колег. Саме програмування стали ділити на дві великі групи – системне і прикладне: хто розробляв операційні системи та драйвери, а хтось писав програми для автоматизації бізнес-процесів на овочевій базі.

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

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

В результаті у програмістів закріпилася градація зразок [Junior-розробник, Senior/Middle, Team Lead Software Architect]. З одного боку, сучасний інструментарій розробки дозволяв менш кваліфікованим програмістам успішно справлятися з відносно простими завданнями, не маючи глибоких знань і серйозних навичок. З іншого боку, з кожною наступною сходинкою кар'єрних сходів поріг входження також ставав вище.

image
Зображення сайту

Але якщо фахівець затримувався в статусі початківця, він міг помітити одну особливість: бурхливо розвиваються технології розробки ПЗ ще сильніше знижували поріг входження, і середньостатистичний Junior врожаю N-го року знав і вмів ще менше, ніж його старший товариш — Junior (N — k)-го року.

Веб-розробка методом «тяп-ляп»

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

Після того як веб-розробка, почала набирати обертів лише в 90-х роках, зробила величезний стрибок у розвитку, Михайло Густокашин може вільно пускатися в подібні міркування:
Припустимо, ви хочете написати новий Facebook (соціальну мережу). На чому ви будете це писати? HTML, CSS — це дизайн, а ми хочемо, щоб там можна було додавати фотографії, друзів, залишати коментарі.

Для скриптовой частини — тобто те, що відбувається на стороні клієнта, — це JavaScript.

На диво, він написаний на PHP — і Facebook, і багато хто інші великі проекти. Довелося, звичайно, написати свої якісь речі, щоб це все-таки працювало нормально, а не так як «тяп-ляп» було зроблено, але вони впоралися.

Тут і зараз, ясна річ, з нуля вже для веба ніхто нічого не пише. Всі шукають який-небудь фреймворк або ще чогось. Інтернет-магазин? Завантажили фреймворк для інтернет-магазину — ну і все, написали інтернет-магазин.
Варто відзначити, що і спочатку поріг входження в веб-розробку був нижче, ніж в Desktop. Після появи фреймворків він знизився ще сильніше.

На хвилі автоматизації

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

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

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

Ми з'ясували, що з цього приводу думають експерти, представники ІТ-індустрії:



image
Олексій Бичко, старший реліз-менеджер (Percona), розробник проектів Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, викладач курсу «Системне адміністрування» в ІТ — Академії Олексія Сухорукова:

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

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

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

Але якщо у нас є завдання, яка конкретної процедурної системою, бібліотекою або середовищем вирішується погано або не вирішується зовсім (старші колеги пам'ятають, що буває, коли написаний в C++ Builder або Delphi текстовий редактор потрапляє великий файл – нічого не гортати і все гальмує, і це ніяк не поправити), то нам потрібно взяти «чисту» систему, яка дає більше свободи, і покликати програміста, який згоден не просто гуглити, а писати адекватне рішення самостійно з нуля.
image
Олег Бунін, засновник компанії «Онтико», організатор конференцій Highload++, РІТ, FrontendConf, RootConf, WhaleRider, AppConf, Backend Conf.
Як організатор найбільших в Росії конференцій для розробників я бачу спеціалізацію, спрощення рутинних процедур, але мізки і глибоке розуміння того, що відбувається затребувані не менше, а навіть більше, ніж раніше.

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

Звичайно, мова йде не про створення лендингов, а про розробку більш-менш серйозного проекту.
image
Макс Лапшин, творець ErlyVideo, творець Flussonic, розробник багатьох відомих рішень в області стрімінг відео.

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

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

Вся справа в тому, що індустрія йде вперед. Так, на комп'ютерах більше не 640 КБ пам'яті, і програмісту під Windows можна не хвилюватися про пам'яті взагалі. Але на заміну великим комп'ютерів прийшли маленькі, і їх багато.

Сьогодні все одно доводиться думати, як записати на прошивку IP-камери софт, упихнувшись в 200 КБ на диску. Доводиться думати, як упихнуть код в маленький IOT-сенсор, який має на своїй крихітній батареечке прожити рік з радіообміном.

Індустрія дуже стрімко розширюється, і в ній з'являється місце людям, які не дуже глибоко розбираються в деталях роботи ЕОМ, але безумовно: сьогодні людей, які знають, як працює, наприклад, DMA, потрібно більше, ніж 10 років тому просто тому, що індустрія досі росте.
image
Олександр Лямін, засновник і CEO компанії Qrator Labs, одного з провідних світових постачальників в області захисту від DDoS-атак.

Є такий жарт: відділ програмування — це такий завод з виробництва холодильників, в якому працює 10 чоловік, один з яких може робити зорельоти, а решта дев'ять осіб вміють клепати шпаківні.

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

У ряді випадків потрібно вже навіть не стільки програміст, скільки computer scientist — людина здібна не тільки, як мінімум, грамотно модифіковані алгоритми під потреби конкретної ситуації і задачі. Наступний рівень — це data scientist, хороший прикладний математик. Продовжуючи аналогію, шпаківня можна склепати із загальнодоступних будматеріалів, але сплави для ракети на будівельному ринку вже не купиш. На цьому рівні завдання вже починає виглядати приблизно так: ось проблема, ось масив даних, потрібні гіпотези-алгоритми-PoC і, як наслідок, постановка задачі для реалізації. Та в процесі створення дійсно хороших продуктів — рано чи пізно, так чи інакше — завдання нетривіальною обробки даних виникають неминуче.

Тобто людина-«кодер» вирішує лише частину проблем, що стоять перед розробкою.

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

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

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

Тому навряд чи коли-небудь кому-небудь вдасться перетворити програміста в оператора ЕОМ остаточно.
Джерело: Хабрахабр

0 коментарів

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