Днями я проводив співбесіду з розробником JavaScript, який претендував на позицію сеніора. Колега, який також був присутній на співбесіді, попросив кандидата написати функцію, яка б виконувала HTTP запит і в разі невдачі повторювала спробу кілька разів.
Він писав код відразу на дошці, тому достатньо було б зобразити щось приблизне. Якби він просто показав, що добре розуміє, в чому суть справи, ми б залишилися цілком задоволені. Але, на жаль, йому не вдалося знайти вдалого рішення. Тоді ми, списавши це на хвилювання, вирішили трохи полегшити завдання та попросили його зробити з функції зі зворотними викликами функцію, побудовану на промісах.
Але нажаль. Так було очевидно, що подібний код зустрічався йому раніше. Він загалом знав, як там усе працює. Нам вистачило б нарис рішення, який демонстрував би розуміння концепту. Однак код, який кандидат писав на дошці, був повним безглуздям. У нього склалося вкрай туманне уявлення про те, що таке проміси в JavaScript і він не міг до пуття пояснити, навіщо вони потрібні. Для джуніора це було б ще пробачити, але на позицію сеніора вже не тягнуло. Як би цей розробник зумів усунути баги у складному ланцюжку з промісами та пояснити іншим, що саме він зробив?
Розробники вважають готовий код самоочевидним
У процесі розробки ми постійно стикаємося з матеріалами, що відтворюються. Ми переносимо фрагменти коду, щоб не доводилося щоразу прописувати їх заново. Відповідно, зосереджуючи всю увагу на ключових частинах, ми дивимося на готовий код, з яким працюємо як на щось самоочевидне – ми просто припускаємо, що в ньому все працюватиме як треба.
І зазвичай він справді працює, але коли виникають складнощі, розуміння його механіки більш ніж окупається.
Так, наш кандидат на позицію розробника-сеніора вважав самоочевидними об'єкти promise. Він, напевно, уявляв, як з ними керуватися, коли вони зустрічаються десь у чужому коді, але загальний принцип не розумів і не зміг сам його повторити на співбесіді. Можливо, він запам'ятав фрагмент напам'ять – це не так уже й складно:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Я теж так робив – та всі ми, мабуть, колись так робили. Просто заучували шматок коду, щоб потім використовувати його в роботі, при цьому тільки загалом уявляючи, як там усе влаштовано. Але якби розробник по-справжньому розумів концепт, запам'ятовувати йому нічого не довелося – він просто знав би, як це робиться, і легко відтворив би все необхідне в коді.
Звертайтесь до витоків
У 2012, коли ще не встановилося панування фреймворків фронтенду, світом правил jQuery, і я читав книгу автором якої був Джон Резіг, творець jQuery.
Книга вчить читача, як створити власну jQuery з нуля і дає унікальну можливість долучитися до ходу думки, яка привела до створення бібліотеки. В останні роки jQuery втратила свою колишню популярність, але книгу я таки дуже рекомендую. Що мене найбільше в ній вразило - це наполегливе почуття, що я міг би насамперед додуматися і сам. Кроки, які розписував автор, здавалися настільки логічними, настільки зрозумілими, що мені всерйоз почало здаватися, ніби і я міг запросто створити jQuery, якби тільки взявся за справу.
Зрозуміло, насправді нічого подібного я не подужав би – вирішив би, що це непідйомно важко. Власні рішення видалися б надто простими і наївними, щоб спрацювати, і я б опустив руки. Я відніс би jQuery до самоочевидних речей, в коректну роботу яких потрібно просто сліпо вірити. Згодом я навряд чи почав би витрачати час на те, щоб вникати в механіку цієї бібліотеки, а просто користувався б нею як чорним ящиком.
Але знайомство з цією книгою зробило мене іншою людиною. Я почав вчитуватися у вихідний код і виявив, що реалізація багатьох рішень насправді є дуже прозорою, навіть очевидною. Ні, звичайно, самому додуматися до подібного – це вже з іншої опери. Але саме вивчення чужого коду та відтворення вже існуючих рішень і допомагає нам вигадувати щось своє.
Натхнення, які ви почерпнете, та патерни, які почнете помічати, змінять вас як розробника. Ви виявите, що та чудова бібліотека, якою ви постійно користуєтеся і про яку звикли думати як про магічний артефакт, працює зовсім не на магії, а просто вирішує проблему лаконічно та винахідливо.
Іноді над кодом доведеться корпіти, розбираючи його крок за кроком, але саме так, просуваючись дрібними послідовними кроками, ви зможете повторити шлях автора до вирішення. Це дозволить вам глибше поринути у процес написання коду і дасть більше впевненості при пошуку власних рішень.
Коли я тільки-но почав працювати з промісами, мені здавалося, що це чиста магія. Потім я дізнався, що в їхній основі лежать ті ж самі зворотні виклики, і мій програмістський світ перекинувся. Тобто патерн, мета якого – позбавити нас зворотних викликів, сам реалізується за допомогою зворотних викликів?!
Це допомогло мені подивитись на справу іншими очима і усвідомити, що переді мною не якісь химерні шматки коду, надмірну складність які мені ніколи в житті не осягнути. Це лише патерни, у яких без проблем можна розібратися при належній допитливості і глибокому зануренні. Саме так люди навчаються програмувати та ростуть як розробники.
Винайдіть це колесо заново
Так що сміливо перевините колеса: самі пропишіть код для зв'язування даних, створіть доморощений проміс або навіть зробіть своїми руками рішення для керування станами.
Не має значення, що всім цим ніхто ніколи не користуватиметься – зате ви тепер це вмієте. А якщо у вас буде можливість згодом використовувати такі напрацювання у власних проектах, це взагалі здорово. Ви зможете їх розвивати і навчитеся ще чомусь.
Сенс тут не в тому, щоб відправити свій код до продакшну, а в тому, щоб освоїти щось нове. Самостійно прописувати реалізацію вже існуючого рішення – чудовий спосіб навчатися у найкращих програмістів і тим самим відточувати свою майстерність.
Джерело: habr.com