Як стати відмінним front-end-розробником
Нещодавно я отримав листа від читача мого блогу, який з якоїсь причини змусив мене замислитися. Лист говорив:
Привіт Філіпе, можна запитати, як ти став чудовим front-end-розробником? Можеш дати пораду?
Зізнатися, я був здивований тим, що подібне питання задають мені, тому що я ніколи не вважав себе «відмінним» front-end-розробником. Насправді, я не впевнений, що був достатньо кваліфікований для всього, за що брався, коли тільки-но починав працювати в цій сфері. Я подавав заявки на роботу тільки тому, що не розумів, як мало я знаю, а отримував її, бо люди, на співбесіду до яких я приходив, не знали, які запитання ставити.
Однак я зрештою справлявся з кожною зі своїх ролей і ставав цінним членом команди. Коли я збирався йти (за новими викликами, до яких я також не був підготовлений), мене просили підібрати собі заміну. Озираючись назад і згадуючи ті інтерв'ю, я дивуюся, як багато значення я надавав знанням - незважаючи на те, що спочатку мені їх не вистачало. Нинішній я, мабуть, не найняв би минулого себе, хоча тепер я знаю, що теоретично успіх можливий.
Чим довше я працюю у web-сфері, тим більше розумію, що основна відмінність хороших і дуже хороших фахівців полягає не в обсязі їх знань, а в тому, як вони мислять. Зрозуміло, знання важливі, іноді навіть дуже, але в середовищі, яке змінюється настільки швидко, здатність отримувати нові знання завжди переважує (принаймні у довгостроковій перспективі) ті знання, якими ви вже володієте. Але найголовніше те, як ви використовуєте ці знання для вирішення щоденних завдань.
Існує безліч статей, в яких розповідається про мови, фреймворки та інструменти, необхідні для отриманняроботи. Я хотів застосувати інший підхід. У цій статті я збираюся розповісти про склад розуму front-end-розробника і сподіваюся, що зможу дати найбільш повну та розгорнуту відповідь на запитання: «Як стати відмінним розробником?»
Не просто вирішуйте проблеми - намагайтеся зрозуміти, що насправді відбувається з вашим кодом
Я часто питаю: "Чому ви додали сюди float: left?" або "overflow: hidden дійсно тут необхідний?" У відповідь на це часто звучить фраза: "Я не знаю, але якщо я приберу це, то нічого не заробить".
Я розумію, що є ситуації, коли вам потрібно, щоби щось працювало, причому негайно. Але якщо ви не будете витрачати час на те, щоб розібратися у своїй проблемі, то продовжуйте наступати на ті самі граблі.
Ви можете вважати, що намагатися зрозуміти, чому ваш спосіб вирішення проблеми спрацював – це марнування часу, але я обіцяю, що це допоможе вам зберегти час у майбутньому. Якщо ви повністю розібралися в системі, з якою працюєте, то при вирішенні проблем не вгадуватимете, але розумітимете, чому потрібно зробити так, а не інакше.
Вчитеся передбачати майбутні зміни технологій
Одна з головних відмінностей front-end і back-end коду полягає в тому, що back-end код найчастіше виконується в середовищі, яке знаходиться під вашим контролем. Front-end, навпаки, перебуває поза вашого контролю. Платформа або пристрій користувача може повністю змінитися в будь-який момент, тому ваш код повинен вміти невимушено справлятися з цим.
У цьому випадку код обробляв усі версії IE старше шостої, але як тільки вийшла версія IE10, значні частини нашої програми повністю перестали працювати.
Я розумію, що в реальному світі feature detection не дає 100% гарантій і іноді вам доводитьсявраховувати неправильну поведінку браузерів і зважати на ті з них, у яких feature detection помилково повертає позитивні (або негативні) значення. Але якщо ви робите це, потрібно гарантувати таке майбутнє, де ці баги більше не виявляться.
Код, який ми пишемо сьогодні, буде ще довго – навіть після того, як ми підемо з поточної роботи. Частина коду, який я писав понад 8 років тому, все ще працює на великих сайтах – ця думка одночасно дає привід для гордості та занепокоєння.
Читайте специфікації
Баги в браузерах були, є і будуть, але коли два браузери обробляють один і той же код по-різному, люди часто припускають, ніяк не перевіряючи, що так званий «хороший браузер» правий, а «поганий» неправий. Але це не завжди так, і якщо таке припущення виявиться помилковим, будь-які зміни, що вносяться вами, практично напевно приведуть до краху в майбутньому.
Злободенним прикладом цього може бути стандартний розмір flex-елементів. На підставі специфікації, початкові значення min-width і min-height для flex-елементів дорівнюють auto (але не нулю), а це означає, що за умовчанням вони не повинні ставати менше мінімального розміру їхнього вмісту. Останні вісім місяців FireFox був єдиним браузером, у якому було реалізовано коректно [1].
Якби ви зіткнулися з такою крос-браузерною несумісністю і помітили, що ваш сайт виглядає однаково в Chrome, IE, Opera і Safari, але по-іншому Firefox, то, ймовірно, припустили б, що FireFox неправий. Насправді я стикався з подібним багато разів. Мені часто писали, що мій проект Flexbugs має проблему подібної несумісності, але якби я намагався якось це обійти і впровадив кілька рішень, то все б порушилося буквально два тижні.назад з виходом Chrome 44. Можливі вирішення проблеми не так відповідали вимогам специфікацій, скільки намагалися компенсувати (насправді) правильну роботу браузера [2].
Коли два браузери відображають один і той же код по-різному, вам потрібно витратити час і зрозуміти, який з них працює правильно, щоб у відповідності з цим правити свій код. Тоді в майбутньому нічого не доведеться переробляти.
Додам, що так звані «відмінні» front-end-розробники – це люди, які перебувають на передовій, адаптують нові технології до того, як ті стануть популярними, і навіть роблять свій внесок у їх розробку. Якщо ви розвинете в собі звичку заглядати в специфікації і уявляти, як працюватиме технологія ще до появи в усіх браузерах, то станете частиною обраної групи і зможете розуміти і впливати на розробку специфікації.
Читайте код, написаний іншими
Читання коду інших людей для розваги, ймовірно, не те, чим ви хочете займатися суботнім вечором, але це, поза всяким сумнівом, один із найкращих способів покращити свої навички розробника.
Я вважаю, що одна з найбільших помилок, яку роблять компанії під час найму нових інженерів, полягає в тому, що вони просять їх написати код – новий код, з нуля. Я ніколи не був на інтерв'ю, де мене попросили б оцінити існуючий код, знайти в ньому помилки і виправити їх. Це дуже погано, тому що більшу частину часу інженера займає доповнення або зміну існуючої бази. Дуже рідко ви створюєте щось із нуля.
Працюйте з тими, хто розумніший за вас
Проблема тут у тому, що, займаючись самоосвітою і працюючи на себе, ви не отримуєте вигод і досвіду від роботи з людьми, які розумніші за вас. Вам нема з ким обговорити ідею чи код. Я рекомендую хоча б напочатковому етапі своєї кар'єри попрацювати в команді, де люди розумніші і досвідченіші за вас.
Якщо ви в якийсь момент почнете працювати на себе, станьте (або залиштеся) частиною відкритих проектів. Активна участь у подібних речах дасть вам ті ж переваги, що й робота в команді, а іноді навіть більше.
Винаходьте велосипед
Винаходити велосипед погано для справи, але добре для навчання. Ви можете спокуситись і схопити типовий віджет або бібліотеку делегування подій з npm, але тільки уявіть, наскільки більше ви дізнаєтесь, намагаючись написати ці речі самостійно.
Я впевнений, що частина читачів цієї статті зараз заперечуватиме. Але не зрозумійте мене неправильно. Я не говорю, що ви не повинні використовувати готовий код. Використання відмінних та перевірених бібліотек, баги яких виправлені, а переваги підтверджені кількома роками тестувань, практично завжди дуже гарне рішення.
Але в цій статті я говорю про те, як з хорошого розробника перетворитися на відмінного. Більшість людей у цій індустрії, яких я вважаю великими, самі створили або допомогли за допомогою дуже популярних бібліотек, які я постійно використовую.
Пишіть про те, що дізналися
І останнє, але не за значенням: пишіть, що дізналися. Є безліч причин, з яких цим варто займатися, але найголовніша полягає в тому, що це змушує вас краще розбиратися в питанні. Якщо ви нездатні пояснити, як щось працює, є шанс, що ви самі погано собі це уявляєте. Дуже часто ви навіть не знаєте, що не до кінця розібралися, поки не намагаєтесь висловити свої слова на папері.
З власного досвіду скажу, що написання статей, спілкування та створення моделей – це найкращі способи змусити себе поринути і повністюрозібратися у якомусь питанні. Навіть якщо ніхто не читає те, що ви пишете, нехай так – важливий процес.