Алгоритми — це лише одна із змінних в рівнянні

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

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



Вся справа в тому, що розробка — це не просто алгоритми або мови.

1. По-перше, зводити все до знання тільки одних алгоритмів — це дохла ідея. Якщо програміст не розбирається, наприклад, у мережевих технологіях, не розуміє, як працює операційна система і тд — йому не допоможе знання quicksort і всіх структур даних.

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

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

Про нюанси, як ведуть себе Java / різні компілятори/інтерпретатори, можна прочитати десятки тисяч статей.

3. Без глобального мислення, розуміння роботи програми в цілому на всіх рівнях (не тільки в своїй пісочниці, але і в рамках осі/заліза/мережевої інфраструктури) програміст не може називати себе програмістом. Умовно кажучи, якщо веб-програміст думає тільки про те, як поставити нову либу на сервер, але зовсім не здивований тим, як адміни потім будуть оновлювати її на 200+ серверах (і що буде, якщо вона стане критичною для програми, а після чергового оновлення ОСІ виявиться, що вона не компиляется взагалі).

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

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

Що варто застосовувати? Залежить від кожного конкретного випадку, але нерідко інструмент більш обкатаний і поширений краще, ніж тільки що з'явився свіжий. Можу навести такий немодний мова Pure C, на якому написані драйвера, системи, Постгрес, і ще мільйон інших речей, що людям не подобається в силу негламурности (і складних покажчиків, з купою місць де можна вистрілити собі в ногу, визнаємо чесно — що накладає додаткові вимоги до разрабочтику), зате має довгу історію і накопичений досвід використання.

6. Проектування баз даних та оптимізація запитів. Всякі там нормальні форми проходять всі, а досвід вибору СУБД і створення масштабованої структури під реальні дані з подальшою оптимізацією роботи приходить тільки з практикою. Але ми ж не будемо називати неповноцінним знає червоно-чорні дерева і вирішального олімпіадні завдання програміста неповноцінним просто тому, що він не має досвіду і розуміння, як працює оптимізатор запитів в PostgreSQL, чому краще поставити такий індекс, а не сякий, і чому потрібно тонко налаштувати параметри сервера для поточного навантаження читання/запису.

7. Нарешті, ми не можемо не враховувати загального рівня інтелекту людей і soft skills, EQ/емпатія.
Приміром, якщо людина розумна і володіє здоровим глуздом, то він розуміє, що мова — це інструмент. І він не буде писати в реальній роботі на Джаві те, що відмінно пишеться на плюсах і працює без гальм і бубна (а також жирних серверів і дорогих колег).

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

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

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

ЗИ. Якщо ви відчули, що все-таки алгоритми будуть не зайвими — відмінний курс на Coursera: раз, два

Live long and prosper.

Джерело: Хабрахабр

0 коментарів

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