Кава-брейк #54. Антипатерни, яких слід уникати у коді. Як навчитися вирішувати завдання на технічному інтерв'ю

Антипатерни, яких слід уникати в коді

Джерело: Free Code Camp Кожен розробник прагне писати структурований, добре спланований код із хорошими коментарями. Існує безліч шаблонів проектування з чіткими правилами, які потрібно слідувати, і структурою про яку потрібно пам'ятати. Тим не менш, ми все ще можемо знайти в софт антипаттерни. Особливо часто вони зустрічаються програмами, написаними давно або поспіхом. Безневинний базовий прийом, доданий для швидкого вирішення проблеми, може створити прецедент у вашій кодовій базі. Згодом його можуть скопіювати в кілька різних місць, що перетворить цей прийом на антипаттерн, з яким доведеться розбиратися.

Що таке антипаттерн?

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

Спагетті-код

Спагетті-код – найвідоміший антипаттерн. Це код із практично нульовою структурою. У ньому нічого не модулюється. Файли випадково розкидані по випадкових каталогах. Хід програми важко простежити, він повністю переплітається як спагетті. Зазвичай, така проблема виникає, коли хтось не продумав хід своєї програми заздалегідь і просто відразу почав писати код. Спагетті-код – це не лише кошмар у плані обслуговування. Він також практично не дає змоги додавати новий функціонал. У вас постійно щось ламатиметься. При внесенні змін ви ніколи не зможете точно сказати, які частини кодової бази ця зміна торкнеться. Через це ви не зможете точно прогнозувати час роботи, оскільки в такому коді неможливо передбачити появу незліченних проблем. Додатково почитати про спагетті-код можнатут .

Золотий молот

Уявіть собі такий сценарій: ваша команда розробників дуже добре розуміється на новій архітектурі Hammer. Вона фантастично підходила для всіх ваших попередніх завдань. Ви – найкраща у світі команда фахівців з архітектури Hammer. Але тепер завжди всі завдання закінчуються використанням цієї архітектури. Гвинт із плоскою головкою? Молоток. Гвинт із хрестоподібним шліцем? Молоток. Що? Вам потрібний шестигранний ключ? Ні, просто бийте молотком! Так ви починаєте скрізь застосовувати знайомий та улюблений архітектурний підхід. Так, він не для всіх випадків є оптимальним рішенням, але із завданням він справляється! Хоча за допомогою молотка ви писатимете код вдвічі довше, а програма в результаті стане менш продуктивною, але особисто вам молоток зручний, тому простіше взяти його. Проблема тут у тому, що золотий молот які завжди може бути універсальним рішенням. Різні мови мають і загальні підходи до вирішення завдань, і свої власні стандарти. І якщо ви успішно щось застосували, працюючи з однією мовою, це не означає, що так само добре обернеться в роботі з іншою. Не нехтуйте постійним навчанням протягом усієї своєї кар'єри. Для кожного проекту вибирайте найбільш підходящу мову. Продумуйте архітектуру і виходьте за межі звичайного. Досліджуйте та спробуйте в роботі нові інструменти та нові способи вирішення проблем. Про золотий молот можна почитати Не нехтуйте постійним навчанням протягом усієї своєї кар'єри. Для кожного проекту вибирайте найбільш підходящу мову. Продумуйте архітектуру і виходьте за межі звичайного. Досліджуйте та спробуйте в роботі нові інструменти та нові способи вирішення проблем. Про золотий молот можна почитати Не нехтуйте постійним навчанням протягом усієї своєї кар'єри. Для кожного проекту вибирайте найбільш підходящу мову. Продумуйте архітектуру і виходьте за межі звичайного. Досліджуйте та спробуйте в роботі нові інструменти та нові способи вирішення проблем. Про золотий молот можна почитатитут .

Човновий якір

Антипаттерн «човновий якір» передбачає, що програмісти залишають код у базі, що не використовується, тому що він може знадобитися їм пізніше. Наприклад, розробники написали щось трохи не за специфікацією, і цей код поки не потрібен, але вони впевнені, що наступного місяця він стане у пригоді. Тому розробники цей код не видаляють. Код вирушає у виробництво, щоб пізніше, коли він знадобиться, його можна було швидко використати. Але в результаті кодова база переповнюється зайвим кодом, а обслуговування цієї бази перетворюється на справжню проблему. Уявіть, що вам терміново потрібно внести деякі редагування. Ви намагаєтеся з'ясувати, яка саме частина коду відповідає за відправку даних карт клієнтів в API для виведення коштів з банку. У такій ситуації ви можете втратити дарма час, вичитуючи і виправляючи зайвий код, не усвідомлюючи при цьому, що навіть не там кодової бази. Зайвий або застарілий код збільшує час складання, а ви можете переплутати робочий та неробочий код, ненароком додавши останній у виробництво. Тепер ви, ймовірно, розумієте, чому цей антипаттерн називається човновим якорем: його важко нести (він збільшує технічний обов'язок) і при цьому він нічого не робить (код абсолютно марний, він не працює). Про антипаттерн «човновий якір» можна почитатитут .

Мертвий код

Чи доводилося вам колись бачити код, написаний кимось, хто більше не працює у вашій компанії? Наприклад, є функція, яка начебто б нічого не робить. Але вона викликається звідусіль! Ви питаєте про цю функцію у всіх, але ніхто не знає, що вона робить і тому її бояться видаляти. Іноді ви бачите, що робить той чи інший шмат коду, але не знаєте контексту. По суті, ви можете прочитати та зрозуміти цей код, але не розумієте, навіщо він тут. Такий код зазвичай називають мертвим. Найчастіше цей антипаттерн зустрічається у коді, який написали для перевірки концепції, а потім запустабо у виробництво. Цей код шкідливий, тому що не можна визначити, чи потрібен він для роботи програми, чи ні. Якось на одному з мітапів я зустрів хлопця, який мав саме таку проблему. У його проекті були тонни точно мертвого коду і багато можливо мертвого, але керівництво не дозволяло видаляти весь мертвий код. Цей хлопець назвав свій підхід «мавпячим тестуванням». За допомогою коментарів він почав вимикати все по черзі, щоб побачити, що зламається у виробництві. Так, це було трохи ризиковано! Якщо ви не хочете застосовувати "мавпяче тестування" у своїй роботі, спробуйте переконати керівництво, що технічний обов'язок - це ризик, і саме тому його потрібно впорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати але керівництво не дозволяло видаляти весь мертвий код. Цей хлопець назвав свій підхід «мавпячим тестуванням». За допомогою коментарів він почав вимикати все по черзі, щоб побачити, що зламається у виробництві. Так, це було трохи ризиковано! Якщо ви не хочете застосовувати "мавпяче тестування" у своїй роботі, спробуйте переконати керівництво, що технічний обов'язок - це ризик, і саме тому його потрібно впорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати але керівництво не дозволяло видаляти весь мертвий код. Цей хлопець назвав свій підхід «мавпячим тестуванням». За допомогою коментарів він почав вимикати все по черзі, щоб побачити, що зламається у виробництві. Так, це було трохи ризиковано! Якщо ви не хочете застосовувати "мавпяче тестування" у своїй роботі, спробуйте переконати керівництво, що технічний обов'язок - це ризик, і саме тому його потрібно впорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати За допомогою коментарів він почав вимикати все по черзі, щоб побачити, що зламається у виробництві. Так, це було трохи ризиковано! Якщо ви не хочете застосовувати "мавпяче тестування" у своїй роботі, спробуйте переконати керівництво, що технічний обов'язок - це ризик, і саме тому його потрібно впорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати За допомогою коментарів він почав вимикати все по черзі, щоб побачити, що зламається у виробництві. Так, це було трохи ризиковано! Якщо ви не хочете застосовувати "мавпяче тестування" у своїй роботі, спробуйте переконати керівництво, що технічний обов'язок - це ризик, і саме тому його потрібно впорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати спробуйте переконати керівництво, що технічний борг — це ризик, і саме тому його треба упорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитати спробуйте переконати керівництво, що технічний борг — це ризик, і саме тому його треба упорядкувати. Як альтернативу запишіть все, що робить модуль (розділ), який ви хочете переписати, і починайте видаляти мертвий код частинами, застосовуючи ітеративний підхід. При кожній ітерації перевіряйте, чи щось не зламалося. Так ви зрозумієте, яка частина коду є важливою, а потім видаліть непрацюючі частини. Про мертвий код можна почитатитут .

Розростання коду

Об'єкти чи модулі регулярно взаємодіють один з одним. Якщо у вас є чиста модульна кодова база, вам часто доведеться викликати окремі модулі та нові функції. Антипаттерн «розростання коду» передбачає наявність у кодовій базі об'єктів, які існують виключно для виклику інших, найважливіших об'єктів. Їх можна назвати "об'єкти-посередники". Наявність таких об'єктів додає непотрібний рівень абстракції і лише збиває з пантелику, коли необхідно розібратися в роботі програми. Найкраще рішення - просто видалити зайвий об'єкт. Перемістіть відповідальність за виклик необхідного об'єкта на об'єкт, що викликає. Про розростання коду можна почитати тут .

Божественний об'єкт

Якщо у вашій кодовій базі завжди потрібен доступ до одного об'єкта, цей об'єкт цілком може бути «божественним». Божественні об'єкти роблять надто багато. Наприклад, вони можуть одночасно відповідати за ідентифікатор користувача, ідентифікатор транзакції, ім'я та прізвище клієнта, загальну суму транзакції, товари, які купує користувач… Коротше ви зрозуміли. Такий антипаттерн іноді називають «швейцарським ножем», тому що фактично він вам потрібен тільки для того, щоб відрізати шматок мотузки, але при цьому в ньому є пилка для нігтів, пила, пара пінцетів, ножиці, пляшки та штопор. Якщо ви маєте такий божественний об'єкт, краще розділити його на окремі модулі. В об'єктно-орієнтованих мовах проблемі божественних об'єктів приділяється особлива увага. Щоб не допускати їх появи, слід дотримуватися принципів SOLID, які допомагають нам краще моделювати програмне забезпечення. Літера S в абревіатурі SOLID означає Single Responsibility - кожен клас або модуль відповідає за одну частину системи, а не декілька. Проблему «божественного об'єкта» можна побачити на наступному прикладі:

interface Animal {
        numOfLegs: string;
        weight: number;
        engine: string;
        model: string;
        sound: string;
        claws: boolean;
        wingspan: string;
        customerId: string;
}

Чи можете ви, швидко переглянувши цей код, визначити, що зона відповідальності тут занадто широка і потрібно рефакторинг? Тут ми спостерігаємо створення потенційного божественного об'єкта. Як щодо такої зміни?

interface Animal {
        numOfLegs: string;
        weight: number;
        sound: string;
        claws: boolean;
}

interface Car {
        engine: string;
        model: string;
}

interface Bird {
        wingspan: string;
}

interface Transaction {
        customerId: string;
}

Поділ інтерфейсів дозволить розробнику ясно побачити зону відповідальності кожного з них. Крім того, класам, яким потрібен тільки wingspan, не доведеться реалізувати також engine, customerId і model. Про божественні об'єкти можна почитати тут .

Висновок

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

Як навчитися вирішувати завдання на технічному інтерв'ю

Джерело: Codeburst «У вас є монети різного номіналу. Також ви знаєте загальну суму грошей. Напишіть програму для обчислення найменшої кількості монет, необхідної для складання цієї суми». Який код потрібно написати для вирішення цього завдання ? З чого ви взагалі почали б? Google, Amazon і всі великі компанії, що займаються розробкою програмного забезпечення, майже завжди використовують щось подібне під час найму нових співробітників. Не бійтеся, якщо ви не знаєте відповіді. Я досі його не знаю, як і 63% усіх програмістів, які бралися до цього завдання. Що вам дійсно потрібно для того, щоб зайняти позицію розробника, то це основа, принцип вирішення таких завдань, а також навички, які дозволять вирішити завдання, яке вам запропонують на технічному співбесіді. Півроку тому я влаштувався на свою першу роботу як full-stack веб-розробника в компанії зі списку Fortune 500. У процесі підготовки до співбесід я познайомився з безліччю завдань подібного типу і витратив незліченний годинник на їх вирішення. У цій статті я спробував викласти п'ять рекомендацій на основі особистого досвіду. Сподіваюся, вони допоможуть вам успішніше вирішувати завдання з програмування на технічному співбесіді.

1. Використовуйте таймер або секундомір

Подумайте, скільки часу ви хочете виділити собі на вирішення одного завдання, і дотримуйтесь цього плану. Ви можете вирішити задачу швидше, а можете і не вирішити її взагалі - у будь-якому випадку це не важливо . Як тільки час спливе, припиняйте працювати над завданням, яке вирішували, і переходьте до наступного. Я серйозно. Ваша мета – це отримання зеленої галочки або золотої зірочки. Залишіть цю нісенітницю «здав/не здав» для початкової школи , де їй саме місце. Натомість вашою метою має бути здобуття знань. Як вони купуються? Шляхом невдач та адаптації. Знову і знову. Для цього вам потрібно познайомитися з багатьма різними завданнями. Причому швидко. Коли я починав вирішувати завдання з програмування, я витрачав від 45 хвабон на годину на кожну і «провалював» майже все. Тепер на кожне завдання я витрачаю не більше 20 хвабон і вирішую 50-75% залежно від складності. Але забудьте про мене: подумайте про свій таймер і встановіть його так, як вам зручно. Згодом ви виявите, що почали вирішувати завдання на кілька хвабон швидше запланованого.

2. Щодня ставте перед собою цілі

Це допоможе вам зосередитися і позбутися деяких відволікаючих факторів. Звичайно, це звучить просто, адже поставити мету здатний кожен. Куди складніше досягати намічених цілей щодня. Тут важливо залишатись послідовним. Одна щоденна мета, яку ви досягаєте щодня, набагато краща, ніж досягти п'яти цілей у понеділок і не виконати жодної у вівторок. «Складні відсотки – восьме диво світу. Той, хто розбирається в них — заробляє, а хто не розбирається — платить», — Альберт Ейнштейн. У цій цитаті Ейнштейн мав на увазі відоме правило: гроші роблять гроші. Якщо ви згодом застосуєте ту саму ідею до свого зростання знань, вас просто не зупинити. Є ще одна річ, яка може виявитися вам корисною. Я помітив, що чудово виконую чужі інструкції та жахливо виконую свої власні. На щастя, я знайшов спосіб обійти це. Якщо у вас така сама проблема, запишіть увечері свої цілі на завтра. Покладіть їх на стіл та забудьте про них. Вранці ви прокинетеся з ясною головою, встанете та помітите на столі список завдань від дуже розумного та організованого незнайомця. Ще одна корисна порада: ставте перед собою невелику кількість легко досяжних цілей . Мотивація - ключ до успіху, а у вас набагато більше шансів вирішити три завдання, якщо ви планували вирішити дві, ніж якщо націлювалися на 30.

3. Дотримуйтесь певної системи

Коли я вирішував щоденні завдання щодо програмування, я по кожній писав нотатки. При наступному пошуку роботи моєю метою буде заповнити ще одну записну книжку . Я ділюся цим з вами з двох причин. По-перше, тому що на своїх курсах навчився дуже простої системи ведення нотаток, яка називається «UPER»:

• • U nderstand (зрозуміло)
• • P lan (спланувати)
• • E xecute (виконати)
• • R eview (перевірити)

Перші два кроки мають бути виконані ще до того, як ви напишете будь-який код. Щоб досягти чогось, ви повинні спланувати, як ви це зробите. Але перед цим вам потрібно переконатись, що ви розумієте, чого від вас хочуть. Наприклад, який тип введення отримає вашу функцію? Що буде на виході - рядок або, можливо, число з плаваючою комою? Вам бракує важливої ​​інформації? Виконайте кожен етап свого плану, визначивши змінні та написавши свої функції. Потім, нарешті, перевірте результат: що ви зробабо добре, що можна покращити і в чому ви не були впевнені. Я щиро переконаний, що завдання з програмування — один із найкращих способів покращити ваші навички. Так, вони забирають багато часу, і вам не потрібно бути такими одержимими щодо їх вирішення, але ці щоденні вправи дозволять вам піднятися на новий рівень. Ви багато дізнаєтеся про свою мову програмування і наростіть свої «аналітичні м'язи». А коли настане час щодня писати код на роботі, ці м'язи вам знадобляться .

4. Регулярно відпочивайте

Лікарі підтверджують, що наш мозок більше схильний до творчості, коли ми робимо часті перерви. Свіже повітря та фізичні вправи корисні не тільки для здоров'я. Коли ви застрягли на вирішенні якоїсь проблеми, усунення уваги на щось нове може бути найкращим способом просунутися вперед. Раптовий спалах творчого осяяння може виникнути звідки завгодно. Особливо часто такі спалахи трапляються, коли ви вийшли надвір подихати свіжим повітрям.

5. Навчайтеся в інших

При оволодінні нових навичок у малознайомій вам сфері діяльності найбільша складність полягає в тому, що ви багато чого не знаєте . Самостійно це визначити важко, тому що не знаючи контексту, ви просто не можете припустити, звідки почати. Ви не знаєте, що важливо, а що ні. Концепція функціонального програмування? Структури даних? Коли я вирішую завдання, завжди заглядаю в чужі рішення, навіть якщо сам вирішив завдання правильно. І обов'язково роблю позначки. Той факт, що ви вирішабо завдання, не означає, що вичерпали можливість стати кращими. Адже цілком може існувати елегантніший спосіб вирішення того ж завдання. Наприклад, із меншою кількістю рядків коду. Можливо, ви могли б написати більш ефективний алгоритм. Читання чужих рішень укладається до пункту «перевірка» системи UPER. Звертайте увагу, як пишуть код інші люди, і ви здивуєтеся, як багато нового дізнаєтесь про свою роботу.