Одна з найбільш перевантажених ідіотами спеціальностей - менеджери, які керують програмістами. Не всі, а ті, які самі програмістами зроду не були. Ті, що думають, що можна «підвищувати» ефективність (чи підвищувати «ефективність»?) методами з книжок. Навіть не знайшовши часу ці самі книжки прочитати — адосик є циганський.
Ті, що ніколи не писали код. Ті, для яких знімають голлівудські фільми про програмістів, ну, ті, де електронну пошту командним рядком дивляться. Ті, яким не цікаво нічого, окрім показників, термінів та власної зарплати.
Ті, яких більшість.
Але ідіоти вони з іншої причини. Вони хочуть ефективності, чи хоча б результативності (давай, менеджер, гуглі, у чому різниця), не розбираючись ні в тому, ні в іншому. Взагалі не розуміючи суті процесу отримання результату, втрат, що відбуваються в цьому процесі, витрат на розробку. Коротше, працюючи з програмістом, як із чорною скринькою.
Понабігли в управління програмістами з однієї причини: тут хайп, гроші, ринок і купа таких же ідіотів. Є де загубитися.
Був би хайп у механозбірному виробництві – побігли б туди. Універсали хронові. Не здивуюсь, що чувак, який продає у грудні ялинки у нашому кварталі, це ІТ-менеджер у відпустці.
Коротше, якщо є можливість, женіть цих хлопців у шию. Не хвилюйтеся, вони знайдуть собі роботу. Ніхто з них ніколи не зробить нічого пристойного, поки сам не стане програмістом. Тому що не розуміє суті, механізму, логіки процесу, яким керує.
Ну все, вистачить про менеджерів. Тепер у справі для програмістів. Як підвищити ефективність розробки, навчившись писати якісний код
Щоб підвищити ефективність, треба якнайшвидше вирішувати завдання, не втрачаючи якості. Щоб швидше вирішувати завдання, треба вміти одразу писати якісний код. І «якісний», і «писати», і «відразу». Поясню метафорою.
Писати якісний код - це як грамотно говорити іноземною мовою. Коли мови не знаєш, витрачаєш багато часу на те, щоб сформулювати на ньому свої думки.
Якщо сказати треба терміново, просто наліпиш якихось слів, найчастіше не тих, що треба, забудеш про артиклі, правильний порядок слів, не кажучи вже про часи дієслів і убого вимову.
Якщо є час на формулювання відповіді, доведеться відкривати словник, або інтернет-перекладач, і витрачати купу часу на формулювання своїх думок. Почуття, правда, все одно буде неприємне: відповідь кажеш, і не знаєш, правильна вона чи ні. Аналогічно з кодом – начебто написав, начебто працює, а якісний він чи ні – ХЗ.
Виходить подвійна втрата часу. На те, щоб вигадати відповідь, йде час. На те, щоб цю відповідь сформулювати, теж йде час – причому не так вже й мало.
Якщо ж навичка написання якісного коду є, то відповідь можна формулювати відразу, як тільки вона дозріла в голові, не витрачаючи додатковий час на переклад.
Навичка написання якісного коду допомагає під час проектування архітектури. Ти просто не розглядатимеш у голові неправильні, нереалізовані чи рукожопі варіанти.
Резюмуючи: навичка написання якісного коду суттєво прискорює вирішення завдань.
Але це не все. Завдяки валянкам-менеджерам, є одна загвоздка - так у нас немає приводу писати якісний код. Менеджер код не дивиться, клієнт код не дивиться. Один одному ми код показуємо рідко, іноді, в деяких проектах, де є призначений «перевіряльник» коду або періодичний рефакторинг.
Виходить, у більшості випадків говнокод йде у продакшн або клієнту. У людини, яка написала говнокод, формується стійкий нейронний зв'язок – говнокод писати не тільки можна, а й потрібно – його приймають, та ще й платять за це.
У результаті, навичка написання якісного коду взагалі не має шансів розвинутися. Код, написаний умовним співробітником, не перевіряє ніхто ніколи. Єдина причина, через яку він навчиться нормально програмувати – внутрішня мотивація.
Але ця внутрішня мотивація вступає у протиріччя з планами та вимогами щодо ефективності та продуктивності. Вирішується ця суперечність явно не на користь якісного коду, адже за говнокод навіть не лають. А за невиконання плану ще як.
Як бути? Я бачу та пропоную два шляхи, які можна поєднувати.
Перший – показувати свій код комусь усередині компанії. Не реактивно (коли просять/примушують), а проактивно (е, чувак, глянь мій код, пжлста). Тут головне - не розвішувати цукрові соплі, не намагатися вдягнути критику коду у ввічливу форму. Якщо код гівно, ми так і кажемо: код гівно. З поясненнями, зрозуміло, і рекомендаціями, як зробити його кращим.
Але цей шлях теж такий собі. Його застосування залежить від точки, в якій відбувся контакт. Якщо робота вже потрапила в продакшн, і з'ясувалося, що код – гівно, переробляти його вже немає сенсу. Точніше, приводу ще й метрики просядуть. Набігають менеджери та задавлять вимогами до ефективності. І навіть не намагайся їм пояснити, що говнокод обов'язково повернеться у вигляді багів — тобі ж боком вийде. Можна лише взяти на себе зобов'язання більше не робити.
Якщо робота ще не здана, або тільки розпочата, то поливання коду (або його проекту, задумки) говном може мати цілком собі практичний сенс - людина зробить нормально.
Другий шлях, найкрутіший – зайнятися опенсорс-розробкою у неробочий час. Адже мета мета: щоб купа програмістів, саме програмістів, побачили твій код і висловилися про нього. Усередині компанії всім ніколи. А програмістам усього світу все одно зайнятися нічим, і якщо ти напишеш корисну з прикладної точки зору штуку, то вони обов'язково зазирнути всередину.
Головна фішка, на мій погляд – це написання коду в неробочий час, тому що не працюватиме протиріччя якості коду та швидкості видачі результату. Хоч рік пиши свою розробку. На тебе не тиснуть ні терміни, ні ТЗ, ні гроші, ні начальник. Повна свобода та творчість.
Тільки у вільній творчості ти зрозумієш і відчуєш, що таке класний код, побачиш красу ЯП та технологій, відчуєш принадність бізнес-завдань. Ну і навчишся писати якісний код.
Щоправда, це вимагатиме від тебе витрат особистого часу. Як і, власне, будь-який інший розвиток. Розглядай це не як витрату, бо як інвестицію – в себе.
Джерело: habr.com