Не забудьте поширити ❤️
Блогер з ніком SeattleDataGuy в своїй колонці на Medium розповів про сім навичок, якими повинен володіти хороший програміст.
1. Уміння читати чужий код
Всі крім вас огидно пишуть код. Тому відмінний навик, який принесе вам тільки користь – навчитися читати чужий код. Неважливо, наскільки неохайно і непродумано він виглядає, вам все одно потрібно його зрозуміти. Зрештою, це ваша робота.
Чому це корисна навичка? По-перше, здатність розуміти чужий код – відмінна можливість побачити, що означає погане проектування. Аналізуючи чужу роботу, ви розумієте, що виходить, а що – ні. Більш того, ви усвідомлюєте, який код легше розуміти іншим розробникам, а який – навпаки.
Здатність читати безладний код також спрощує процес створення оновлень в разі потреби.
2. “Чуйка” на погані проекти
Ще один важливий навик – розуміти, які проекти не має сенсу розвивати. У великих компаніях завжди розробляється багато проектів, велика частина їх не доводиться до кінця. Є безглузді проекти в плані бізнесу, є проекти просто з поганим керівництвом. Звичайно, це не означає, що ви повинні відразу відмовлятися від ідеї, якщо ви з нею не згодні. Однак якщо керівництво не може нормально пояснити, що вони будуть робити з кінцевим результатом, можливо, на їх пропозицію не варто витрачати свої сили.
Також деякі проекти іноді настільки фокусуються на технології, а не на рішенні, що з самого початку може бути зрозуміло, що вони не будуть успішними. Щоб розвинути цей навик, потрібно набити шишки на поганих проектах, тільки тоді ви зможете їх відрізняти.
3. Уникнення нарад
Фото: Medium
Неважливо, ким ви працюєте – розробником або аналітиком даних, наради і зустрічі є необхідністю, тому що вам потрібно бути «на одній хвилі» з менеджерами, кінцевими користувачами і клієнтами. Проте, у таких зборів є тенденція захоплювати весь ваш робочий графік. Тому важливо навчитися уникати деякі з них.
Найпоширеніший метод – просто блокувати по дві години кожен день в розкладі на нараду. Ще один спосіб – приходити на роботу раніше за всіх, щоб встигнути зробити роботу в тиші і спокої і не відволікатися.
4. Уміння користуватися Github
Деякі студенти інформатики почали використовувати GitHub мало не з пелюшок. Інші вперше стикаються з GitHub на першій роботі. Для них він здається темним лісом з дивними командами і процесами. Вони ніколи не впевнені на 100%, що роблять.
Фото: Medium
Незалежно від того, яку систему використовує ваша компанія, вона перетворюється у велику перешкоду, якщо використовувати її неправильно. Простий push або commit можуть привести до того, що ви годинами будете намагатися розплутати павутину з безлічі бранчів і ФОРКОМ. На додаток до цього, якщо ви забудете про команду pull і не поновите останню версію сховища, вам доведеться вирішувати різні конфлікти злиття, що навряд чи можна назвати цікавим заняттям.
5. Написання простого робочого коду
Серед молодих інженерів є одна тенденція – спроби імплементувати все, що вони знають, в одному рішенні. Існує бажання взяти розуміння об’єктно-орієнтованого програмування, структур даних і нових технологій і використовувати його в кожному біті свого коду. Але цього робити не варто, ви просто створюєте таким чином додаткову і непотрібну складність.
Є баланс між складними концепціями проектування і простим кодом. Шаблони проектування і об’єктно-орієнтоване проектування повинні спрощувати код в загальній схемі речей. Однак чим більше процес абстрагується, інкапсулюється і поміщається в чорний ящик, тим складніше його налагоджувати.
6. Уміння говорити «ні» і розставляти пріоритети
Насправді це стосується будь-якої посади. Але зокрема здається, що від співробітників-технарів завжди всім щось треба.
Пріоритезація і вміння говорити «ні» – тісно пов’язані один з одним навички. Розставляти пріоритети – значить приділяти час на завдання, які найбільше вплинуть на компанію. Говорити «ні» – значить уникати роботи, яку повинна робити інша команда.
Цієї навички досить складно навчитися, особливо якщо ви тільки що випустилися з університету. Ви не хочете нікого засмучувати, тому берете на себе зайві зобов’язання. Проте, роботи завжди багато, і потрібно навчитися говорити «ні».
7. Дизайн-мислення
Навик, який складно протестувати під час співбесіди і яким складно навчитися в університеті – вміння розуміти, як кінцевий користувач може неправильно використовувати ваш софт.
Наприклад, оскільки основна частина програмування – це підтримка, це означає, що часто доводиться міняти заплутаний код іншим. Навіть проста зміна вимагає відстеження кожної можливої відсилання на об’єкт, метод і / або API. Інакше ви можете випадково зламати прив’язані модулі, про існування яких не знали. Навіть якщо ви просто міняєте тип даних в базі даних.
Це також включає продумування крайніх випадків і всього високорівневого проектування перед початком розробки.
У більш складних ситуаціях, коли ви розробляєте нові модулі або мікросервіси, важливо продумати операційні сценарії того, що ви розробляєте. Подумайте про те, як майбутнім користувачам потрібно буде використовувати ваш новий модуль, коли вони будуть використовувати його неправильно, які параметри знадобляться і чи є можливість, що іншому програмісту знадобиться ваш код.
Програмування – це лише частина проблеми. Неважко створити софт, який буде добре працювати на вашому комп’ютері. Але є безліч різних варіантів розвитку подій, коли деплой коду може піти не за планом. А в продакшені вже складно сказати, як він буде використовуватися і який інший код буде до нього прив’язаний. Через п’ять років майбутнього програміста можуть засмутити обмеження вашого коду.
Ми у соцмережах: