Хабр сповнений прогнозів та порад про те, що робити наступного року — які мови вчити, в які сфери згортати, як чинити зі своїм здоров'ям. Звучить надихаюче! Але у будь-якої медалі дві сторони, і ми спотикаємося не тільки в чомусь новому, а здебільшого в тому, що робимо щодня. «Ну чому мене ніхто не попередив!», — роздратовано вигукуємо ми, зазвичай звертаючись до себе. Викликаємо вогонь на себе — ми зібрали для вас список того, що НЕ варто робити 2020 року (а може й завжди).
А гравітацію-то й не спитали
Нам би дуже хотілося розставити антирекомендації по порядку, від найважливішого до незначного. Але вони настільки поширені, рівнозначні і знайомі чи не кожному, що писатимемо вроздріб. Ну що, прочекаємо список?
Не треба йти в айті, якщо все добре
Не вивчайте нові технології, щоб змінити професію або почати з нуля. Наш час чудовий тим, що можна навчатися, змінювати роботу, докорінно змінювати сферу — і так хоч до самої пенсії. Це класна, спокуслива штука. Але якщо вам більше 28-30, не варто кидати все заради того, щоб увійти в IT або піти в новий стек (наприклад, ви пишете високо навантажені системи Java і раптово вирішуєте піти в нейромережі на Python). Причина проста: вам буде непросто. По-перше, висока конкуренція з боку фахівців, які «сидять» на цьому стеку з початку своєї кар'єри, по-друге, вам доведеться знову стати джуніором із низькою зарплатою, по-третє, вам морально непросто стати підлеглим найнижчого рівня ієрархії. Тому, якщо хочете рухатися в інший бік, намагайтеся це робити або в руслі поточної роботи та поточних завдань, або розвивайте нове знання як хобі, пиляйте пет-проект, щоб прийти на нову роботу вже не джуніором.
Стек на стек міняти - тільки час гаяти
Не кидайтеся між стеками технологій для своєї розробки. Якщо ви пишете проект однією мовою, використовуєте певний фреймворк і бібліотеки, не варто кидати все до біса і переписувати на Dart, тільки тому, що він здався вам цікавим. Візьміть за правило знайти обґрунтування для зміни технології — не лише на рівні «хочу-не можу», а й на фінансовому та інженерному рівні.
Не потрібно стояти на своєму і бронзовіти
Впиратися в одну мову чи технологію і не вивчати нове — така ж крайність, як міняти стек із кожною новою технологією. Обов'язково вивчайте нові бібліотеки та фреймворки, не будьте впертими у свідомості того, що все краще придумано до вас і допилено виключно вами. Практично для кожної мови постійно виходять оновлення, які іноді можуть покращити ваш проект. Не лінуйтеся стежити за динамікою вашого стека і, як тільки знайдете щось круте і корисне, сміливо тягніть у проект!
Своя голова добре, завжди добре
Не думайте чужими головами, своя краще. На жаль, деякі розробники сидять і чекають, коли надійде завдання кодувати від попереднього error-а і до end-а, не намагаючись внести в проект щось своє, розробити нову функцію, протестувати і запропонувати в продакшен. Навіщо турбуватися, коли є голова тимліда чи керівника компанії, які самі все вирішать? Якщо ви впізнали себе, то ми маємо погані новини: пасивна позиція не допоможе ні в кар'єрі, ні в розвитку. У вас є шанс спробувати свої сили інженера-розробника, а не кодера в цьому бойовому проекті і зрозуміти, куди рухатися, чого не вистачає, але ви вважаєте за краще витратити свій час на щось інше і робити рівно «від цих до цих». Такі в сучасному айті виживають все гірше, виходьте з анабіозу.
Користувачі - страшні люди
Не переоцінюйте користувачів вашого програмного забезпечення: якщо ви пишете не для програмістів, розраховуйте на те, що програма зіткнеться з нерозумним нерозумінням. Перші кілька днів або тижнів користувач ненавидить ваш софт, тому що «старий був не такий тупий». Щоб цього уникнути, робіть класну документацію та навчальні матеріали. При встановленні або купівлі дуже нав'язливо натякніть, що мануали варто читати до початку роботи з програмою, а не після краху бази, втрати пароля та самоконтролю.
Недооцінювати користувачів теж не варто: вони хитріші, розумніші та цікавіші, ніж ви думаєте. Якщо ви вважаєте, що той баг з форматом змінної та ексепшен на 138-му натисканні Enter з інтервалом в секунду не спливуть, ви помиляєтеся - спливуть і вплинуть на роботу вашого додатка найхимернішим чином. Працює правило дилетанта: саме він справляється з тестуванням найкраще. Але користувачам чомусь не подобається знаходити баги на продакшені — жодної в них айтішної солідарності. Загалом, що більше ви впевнені у своєму ПЗ — то краще. Зрештою, краще затримати реліз деяких функцій, ніж додати їх у працюючу програму і зробити його раптово сирим.
Досить гуглити!
Перестаньте звертатися до одного лише Google. Навіть сперечатися не будемо - у сфері розробки прямим запитом до пошукової системи можна знайти дуже багато. Чим глибше ви закопаєтеся в пошуках інформації, тим більше «бічних» даних ви отримаєте і більше дізнаєтесь, тому що дізнаватиметеся щось нове, не пов'язане з вашим запитом, але ймовірно потрібне в майбутньому. Звертайтеся до повноцінних матеріалів, книг, статей тощо. У мов та бібліотек є специфікації, ком'юніті, how to і таким чином ви отримуєте найнадійніший спосіб розвивати навички програміста — просто читати документацію, а не шукати чужі локальні рішення та фрагменти коду. А раптом ваше рішення буде оптимальнішим, швидшим і крутішим?
Довіряй, але перевіряй
Не використовуйте бібліотеки та фреймворки, створені сторонніми розробниками, не перевіряючи код та не адаптуючи його до своїх цілей. У вас немає жодних підстав беззастережно довіряти цьому автору коду, якого ви взагалі не знаєте. Так, різні навмисні шкідливі елементи в сторонньому коді зустрічаються не так часто і параної страждати не варто, але сліпе копіювання готових частин програмного забезпечення в свій проект може призвести до непередбачуваних наслідків. Тому обов'язково читайте та аналізуйте код перед використанням та проводьте тестування після імплементації коду.
Робіть бекапи!
Припиніть не робити бекапи або тримати їх на тих же сторонніх серверах, де ваш проект хоститься. Думаєте, смішна та марна порада? А ось понад 700 учасників чату в Телеграмі, які потрапили в недавню неприємну ситуацію із зупинкою одного відомого дата-центру, так не думали — чого там не було: від пет-проектів до великих сайтів держ. органів та корпоративних баз 1С та білінгу. Значна частина - без бекапів або з бекапами там же. Так що розподіляйте ризики і зберігайте бекап як мінімум на основному хостингу, на якомусь надійному VDS і у себе на локальному сервері. Зрештою це вийде набагато дешевше.
Досить проносити своє на шкоду проекту
Не робіть у робочому проекті те, що вам хочеться, а робіть те, що потрібно клієнтам. Так, дуже цікаво і здорово створити свою нейронну мережу, навчити її і впровадити в свій софт, але якщо вашим клієнтам потрібен простий контакт-менеджер, це буде надмірність, що подорожчає. Подивіться, як працює проект, прочитайте документацію, прочитайте відгуки та заявки від клієнтів та реалізуйте те, що надасть проекту бізнес-цінність. Якщо хочеться творити щось наукове чи понад складне, почніть із власного проекту.
Не код, а грудка нервів
Не пишіть нечитаний та недокументований код. Нам знайома ця фішка: розробник пише код як бог на душу покладе, спеціально його трохи заплутує, щоб ніхто з колег не міг розібратися в написаному така своєрідна профілактична помста до того, як щось сталося. Проте ви ризикуєте не тільки компанію (яка вам платить гроші за роботу), а й самого себе: цілком імовірно, що ви самі не згадаєте, що хотіли сказати цією ненавмисною обфускацією. Те саме з недокументованим кодом: покладаючись на свою логіку іменування змінних і функцій і гарну пам'ять, через кілька років ви можете не згадати, чому вибрали саме цей цикл, метод, патерн і т.д. Документування коду та хороша його структура — крута послуга колегам, роботодавцю і насамперед собі.
Будь простим, дурний
Не ускладнюйте код, рішення та проекти. Не треба городити складну структуру та плодити сутності без особливої значущості. Чим складніший ваш код, тим більше ви стаєте його заручником – вам буде максимально складно його підтримувати та розвивати. Звичайно, знаменитий принцип KISS («Keep it simple, stupid») підходить не завжди, але він створений недаремно: простота та витонченість коду - запорука успішного його застосування та перевикористання.
Остерігайтесь
Не ігноруйте безпеку - 2020 року це буквально злочинно. Навіть якщо ваша компанія, розробка і ви не цікаві зловмисникам, вас можуть торкнутися проблеми, пов'язані з ураженням якогось сегменту мережі, хостинг-провайдера, з атакою на дата-центр, з розкраданням паролів пошти та з небезпечною поведінкою співробітників, які можуть вкрасти дані з компанії, відвести клієнтів чи програмний код всього проекту. Якщо це у ваших силах і стосується зони компетенції, постарайтеся захистити ті проекти, з якими працюєте. Ну і самі дотримуйтесь інформаційної безпеки, це ще нікому не заважало.
Не плюйте в колодязь
Не гадайте своєму роботодавцю. На сьогоднішній день комунікації досягли такого рівня, що, наприклад, усі HR-и міста заочно знайомі між собою і можуть обмінятися будь-якою інформацією в чатах та закритих групах (як допомогти працевлаштуватися, так і написати «Василю Іванову, системному архітектору, перед тим, як піти, убив усі облікові записи, затер бекапи та відключив мережу, відновлення зайняло 3 доби. Не беріть його на роботу»). Таким чином, ваша поведінка зіграє виключно проти вас, і іноді не допоможе навіть релокація в інше місто чи столицю. Навіть якщо ви йдете з образою, немає краще помсти, ніж стати корисним та класним співробітником конкурента 🙂 А головне, повністю безкарно.
Так робити також не варто. Але, як показує досвід, не перестанемо
А взагалі, друзі, читайте поради, але робіть так, як вам здається найкращим, адже справжні відкриття відбуваються тоді, коли ми сумніваємося в уже відкритих істинах. Вітаємо вас із Новим Роком, нехай ваші проекти будуть успішними, кар'єра — ненудною, колеги та керівники — адекватними, а життя загалом вдається. Загалом, за Новий Рік та за новий код!
З любов'ю,
команда RegionSoft Developer Studio
У новому році ми продовжимо працювати для вас та розвивати потужну десктопну CRM-систему і простий та зручний хелпдеск та тикет-систему .
Джерело: habr.com