Парадокси IT-освіти, або Навіщо програмістам читати класику

25 вересня
Андрій Булат, Senior .Net Developer
Парадокси IT-освіти, або Навіщо програмістам читати класику
Під час роботи я бачив програмістів різного рівня, викладав і проводив співбесіди, на яких різниця у підготовці особливо помітна.

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

Я бачив код, в якому один метод займав близько 150 рядків — це були просто перевірки. Якщо-якщо-якщо-якщо. І так сто разів.

Університети та курси

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

На початку серпня я був на захисті курсових у комп'ютерній академії “Шаг” і був приємно здивований:

а) знанням мови С ++, яку хлопці використовують дуже грамотно;

б) тим, які програми писали студенти. Три з них у текстовому режимі екрана написали справжні комп'ютерні ігри.

Але коли я дивився на структуру коду, хотілося плакати.

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

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

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

У школі ми вивчали рідну мову та літературу. Уроки мови були потрібні, щоб навчитися правильно писати слова та розставляти розділові знаки. А література — щоб навчитися правильно та лаконічно висловлювати свої думки.

Архітектура та код, що працює

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

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

У цій системі, щоб повністю перебудувати систему авторизації, ми змінили всього два типи!

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

Класична література

Загалом всі принципи роботи, які теоретично обґрунтовують хорошу структуру програми, були сформульовані дуже давно. Демарк писав наприкінці 1970-х, Барбара Лісков — на початку 1980-х, Бертран Мейєр — у середині 1980-х, Роберт Мартін — на початку 1990-х. Навіть Мартін Фаулер опублікував частину значущих для SOLID робіт 20–25 років тому.

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

Скажімо:

  • роботи, пов'язані з побудовою модульних систем і повторним використанням коду — це Демарк, Мейєр, Мартін;
  • шаблони проектування — перш за все, Банда чотирьох (Гамма, Хелм, Джонсон, Вліссідес) із “Шаблонами проектування” та Мартін Фаулер з “Шаблонами корпоративних додатків”;
  • “Чистий код” Роберта Мартіна.

Колись я сам проходив співбесіду, де на запитання про принцип SOLID просто перерахував прізвища розробників цих принципів. Мої співрозмовники мене зрозуміли не відразу. Всі користуються терміном Srum, але не всі читали книгу Роберта Мартіна (Uncle Bob) “Agile! Прекрасний, галасливий, жахливий”. Здається, що це не є таким важливим, але неважливою в цьому разі може здатися, наприклад, обов'язковість рефакторингу, якщо немає попереднього проектування при плануванні спринтів. З Agile Manifest, який був запропонований зокрема Мартіном, виріс Agile і Scrum. Той же Мартін написав і критику методології, вказавши на конкретні помилки, поширені при її застосуванні.

На жаль, отримати всю необхідну інформацію з книг серії “для чайників” не вийде. Якщо ви займаєтеся .NET, потрібно прочитати Ріхтера, якщо вивчаєте Entity Framework, читайте книги Джулії Лерман, якщо ASP.Net — Діно Еспозіто, якщо йдеться про рефакторинг — читайте книги та блог Мартіна Фаулера.

У хороших університетах прочитати необхідну літературу вас все ж змусять. Але чи цікавить це роботодавців?

Замовники та роботодавці

Хороший вуз навчає, що писати добре потрібно відразу. Якщо якийсь тип використовуватиметься по всьому вашому проекту, краще зробити для нього коротенький інтерфейс. Захочемо — пізніше щось змінимо і вже точно в будь-який момент зможемо знайти всі місця, де потрібно щось змінити (до речі, у цьому випадку нам допоможуть і спеціальні засоби для рефакторингу, наприклад, Resharper). Підготовлений програміст не повинен спеціально замислюватися над проектуванням, як начитана людина не замислюється над побудовою складнопідрядного речення: якщо потрібно створити об'єкт — значить, потрібно не викликати конструктор, а використовувати фабрику, DI-контейнер, що завгодно, але не new.

Чому цьому не приділяють уваги на комп'ютерних курсах? Причин дві, й авторів навчальних планів тут можна зрозуміти:

  1. Час. Обмежені терміни змушують від чогось відмовлятися. І вибір роблять на користь коду, якісного зовні, тобто здатного пройти необхідні тести. Що відбувається всередині, в цьому випадку залишається за кадром.
  2. Замовники. Як правило, суто прикладна підготовка відповідає вимогам бізнесу до програмістів. Власне, переконати багатьох клієнтів у необхідності рефакторингу теж буває непросто. Особливо, якщо йдеться про код, з яким вони жили довгі роки. Навіть якщо на підтримку коду після рефакторингу доведеться витратити лише 20 годин проти звичайних 100. І тут ми повертаємося до бази — переконати замовника в необхідності неочевидних для нього дій без певної академічної підготовки буде набагато складніше.

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

Національні стандарти

Важливо й те, які вимоги висувають до фахівця тієї чи іншої кваліфікації в різних країнах. Про це, до речі, самі фахівці замислюються рідко, вважаючи анахронізмом формальні вимоги контролерів, що виглядають цілком абстрактними. Можливо, дарма. Якщо подивитись американські сайти, наприклад, Bureau of Labor Statistics, можна побачити, скільки уваги там приділяється soft skills. Опис вимог до них часто займає такий же обсяг, що й частина, присвячена технічним знанням. Це передбачає більший обсяг командної роботи у процесі навчання та багато в чому забезпечує людям з фундаментальною підготовкою кар'єрне зростання, яке в обов'язковому порядку вимагає здатності до комунікації та керування.

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

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

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

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

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

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

Сила та слабкість Східної Європи

Радянська інженерна школа мала вузи двох категорій. Перша готувала бригадирів на будівництва, кожен з яких повинен був мати диплом про вищу освіту, нехай і з невідомою метою. Друга, власне, проектувала мости через Дніпро чи Єнісей. Перевага спеціальності в галузі інформаційних технологій — у тому, що до рівня підготовки майстрів і бригадирів у СРСР вона дійти не встигла, бо не було низового персоналу, за яким вони мали б доглядати. Саме тому в 1970–1980-х людей не вчили для майбутньої роботи в конкретній компанії або на конкретній позиції. Їх готували до необхідності постійно вчитися.

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

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

Отже, якщо ми хочемо зробити IT драйвером економіки, орієнтуватися потрібно зовсім не на двомісячний курс програмування у старших класах школи. Скільки коштуватиме наша робота, якщо оцінювати її будуть по людях зі шкільним дипломом, де і дійсно проставлена ​​оцінка з інформатики? Візьміть до уваги, в Індії зовсім не погані розробники для їх рейту, але крім мов програмування, всі вони прекрасно знають англійську.

Уже зараз нам необхідно звернути увагу на soft skills: вміння обґрунтувати власну точку зору та знайти слабкі сторони в позиції опонента, здатність виступати єдиним фронтом на переговорах. Мені легко говорити з замовниками, тому що я навчився доводити позицію студентам, прораховуючи їхні проекти на декілька кроків уперед. В Англії та США заняття з риторики починаються ще у середній школі. І жоден викладач не називає студента тупим за поставлене запитання та не пропонує пошукати готову відповідь у підручнику.

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

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

Висновок

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

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