Не в ногу з часом або інша сторона медалі

Дана замітка навіяна думками від прочитання статей «9 анти-патернів, про які повинен знати кожен програміст», «Сім смертних гріхів розробки» і багатьох інших схожої тематики. Мені завжди дуже цікаво і приємно дізнатися про те, як можна робити щось «добре», або навіть ще краще. Погодьтеся, адже це здорово! Здорово знати про дизайн-паттернах і вміти їх правильно застосовувати при проектуванні своєї програми; добре знати і про антипаттернах і вміти знаходити їх у своєму або чужому коді, вміти їх усувати. Здорово знати про тестування та оптимізацію, про рефакторинге і профілюванні та багато іншого, що робить програми більш швидкими, економними і ефективними, а програмістів і користувачів — щасливими.

Але з деяких пір маю деякий відторгнення (іноді навіть відраза) до подібного роду статей. І ось чому. Є дві сторони медалі, як би це не було банально — з одного її боку є десятки і сотні тисяч it-компаній так чи інакше пов'язаних з розробкою ПО, де процес розробки цього самого ПО — є процес «історично сформований», характерний тільки для однієї цієї компанії, і характеризується точніше все як «захід сонця вручну».

Тут немає систем контролю версій, або в кращому випадку використовується svn (або інша застаріла SCM) представляє з себе таку ж кодовою смітник, що і її відсутність, просто з більш окресленими кордонами, де кожен учасник розробки пише коміти так як йому заманеться — в будь-якому регістрі\відмінюванні і на будь-якій мові, і навіть взагалі без будь-якого повідомлення про зміни.

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

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

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

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

З іншого ж боку медалі, є відносно невелика кількість компаній, де топ-менеджери і тимлиды дійсно стурбовані реальною продуктивністю своєї команди, і вони впроваджують у свої бізнес-процеси такі елементи, як code review, code-style і code-convention, системи тестування та системи безперервної інтеграції і т. д. і т. п. Вони не заохочують і не допускають використання антипаттернов в своїх продуктах. Вони безперервно тестують свій код. Вони використовують Docker і розгортають свої інфраструктури в хмарах. Вони не тільки використовують git, але й виробляють чітку схему розгалуження проекту, іменування гілок і повідомлень комитов. Вони пишуть документацію на розроблюваний ними продукт, як для розробників, так і для користувачів продукту. Вони використовують баг-трекер та\або таск-менеджер для розподілу завдань всередині команди і контролю їх виконання, в кінці кінців вони використовують Slack (або інший подібний сервіс) — як для суто технічного спілкування, так і для неформального спілкування, що також не мало важливо і сприяє злагодженості команди. Але головне, — про все це або принаймні про що вони пишуть у свої особисті і корпоративні блоги, в тому числі і на хабр, що безумовно корисно і правильно. Але… Але, таким чином створюється враження, що той набір интрументов, технологій і методологій про яких вони пишуть, використовується, якщо не в усіх, то як мінімум в більшості компаній розробляють софт, а це, на жаль, не так.

І ось проста ситуація: є молодий програміст, який бажає працювати і розвиватися професійно. Він не тільки прочитав основні книги вибраного ним мови програмування, будь то Python, C++ або який-небудь інший, але також і такі фундаментальні речі, як «Досконалий код», «Алгоритми. Побудова і аналіз», «Прийоми ООП. Патерни проектування», «Проектування і рефакторинг», «Ідеальний програміст», «Екстремальне програмування. Розробка через тестування» і т. п. Він володіє основами git, тестування та документування коду, а головне — він дійсно хоче писати корисний і хороший код, використовуючи при цьому всі свої знання. І ось він приходить на роботу в компанію, де йому кажуть: ось ця 3-х гигова папка — наш проект, ну тобто тут не тільки проект, тут вся наша платформа, допоміжні утиліти і кілька десятків проектів, але що саме потрібно для того, щоб працювати над одним конкретним проектом — ніхто не знає, тому потрібно завантажити всі, інакше нічого не заведеться. А використовуємо ми З++98, Qt3, Python2 і WindowsXP. Так, проекту, як такого немає, тут просто татко c кількома тисячами файлів, яку можеш відкрити в vim і працювати з потрібною тобі файлом. Що? Яка ще IDE? який налагоджувач? Навіщо тобі все це!?

Зрозумійте правильно, — він не проти vim, він любить vim, але vim не IDE. Цвях можна забити і сокирою і плоскогубцями, але краще і правильніше — молотком. Він також не проти налагодження шляхом втыкания в потрібні місця різних put, debug() print(), printf() і console.log() — він віддає перевагу таким прийомам у 95% випадків, але іноді і стек подивитися треба, та чи мало ще що. Він зовсім не проти традицій, заведених у компанії, йому просто не зрозуміло — навіщо? Навіщо не використовувати можливості интегрироанных засобів розробки, інтерактивних дебагеров, профілювальником і т. п. Навіщо? Навіщо він так довго читав про те, як робити «добре», якщо робити «абияк» набагато легше, і нічого для цього не потрібно? Навіщо йому розуміти важливість тестування і не використовувати його? Навіщо?

Хтось скаже — він неправильно вибрав компанію, потрібно просто перейти в іншу, з тієї самої другої категорії. Тільки от компаній з першої категорії — більшість, чи я помиляюся? В крупну компанію рівня Yandex, JetBrains, Mail.ru і т. п. хіба беруть вчорашніх студентів? Беруть звичайно, але тільки якщо у вас в резюме раптом виявилося крім вчора отриманого диплома — 5+ років досвіду розробки у сфері комерційної. Та й диплом бажано мати з провідних Вузів», решта — пробачте, проходьте мимо, в крайньому випадку — «ми вам зателефонуємо», ага, чекаю…

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

Дана замітка теж вобщем-то — історія неуспіху. Такого неуспіху, про який не напише менеджер компанії, адже він навіть про неї не підозрює…

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

0 коментарів

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