Зміст
- 01. Кодування більше не вирізати
- Ширина і глибина
- 02. Велике застереження
- 03. Що говорить Інтернет
- Зрозумійте середовище
- 04. Те, з чим ми будуємо
- 05. Поглинає
- Зрозумійте стек
- Таємнича робота
- Підручні інструменти
- 06. Дев виправить це ... можливо
- Налагодження
- 07. Що хочуть користувачі
- Конкурентний ринок
- 08. Малювання та письмо
- 09. Насолоджуйся
- 10. Залишайтеся гострими
- Сподобалось? Прочитайте це!
Розробники повинні бути більше, ніж кодуючими робкими робітниками. Ми очікуємо більше нашого цифрового життя, і саме ці хлопці будують його, то що найкращі розробники повинні знати? Ось речі, які, на мою думку, відсутні у занадто багатьох розробників. Це не вичерпно, але саме ці якості перетворюють розумного кодера на чудового розробника.
Але це не одне, і особливо ніколи не вдається проаналізувати XML або оптимізувати код. Це дивовижна колекція навичок, яких не вивчають книги про написання коду. Вони трохи зайве.
Чому такий отвір? Оскільки розвиток має значення, але розробники надто часто потрапляють в інший світ, не завжди їхній власний розвиток. Це ніколи не працює. Розробка - будь-що технічне - завжди процвітає, коли ті, хто володіє ноу-хау, розуміють не тільки код.
01. Кодування більше не вирізати
Ми потрапили у світ, де кодування стає менш вражаючим. Усі створюють сайти, деякі з них кодують, але вам не потрібно. Це вже не просто ботанік, який може створювати сайти, програми та функції.
З тих пір, як з’явилася павутина, і люди могли навчити себе, розробники-самоучки були. Але навіть випускники знаходяться під загрозою. Я отримую резюме з людьми, які мають наукові ступені, курси ШІ, різні засоби масової інформації та кодування, але все ще чогось не вистачає. Іноді багато чого бракує.
Я не перший сказав це. „Кодування більше не вирізати” - це назва розділу 3 Пристрасний програміст, який поряд із книгами типу Прагматичне мислення та навчання закликати програмістів вдосконалюватися поза кодом; стати чуйними та цілком людськими членами команди.
Ширина і глибина
Розробники повинні бути кращими у двох напрямках: широта та глибина. Вони повинні розуміти широту людських взаємодій у своїй команді та з тим, що вони будують. Вони повинні розуміти глибину системи, з якою працюють, аж до O / S.
І читати ці матеріали повинні не лише розробники. Якщо ви працюєте з розробниками, я думаю, вам слід очікувати від них більше. Змусіть їх намалювати, про що вони говорять. Попросіть їх пояснити зображеннями, предметами та (це працює) вирізати людей, якою саме буде система для людей, які її використовують.
02. Велике застереження
Я буду говорити негативно про розробників, але, думаю, мені це дозволено, бо я такий. Також тому, що принаймні одне, про що я тут розповідаю, стосується багатьох розробників, яких я зустрічаю. Хоча їх робота чудова і вони знають свій код, часи конкурентні. Ви повинні мати край, а це:
- бути більш технічним
і
- бути багато більш людські
03. Що говорить Інтернет
Прогугливаючи "необхідні навички веб-розробки", ви отримуєте те, чого ви очікували. Фреймворкові знання, x-браузер, CSS та JS. Вони перелічують основи, які ви повинні знати, платформи, для яких ви повинні писати, та нові тенденції, на які ви повинні стежити.
Це наші ЗМІ. Це те, з чим ми будуємо, але це не те, що дає успіх проекту. Розробник може зрозуміти кожну деталь системи, розповісти вам кожну функцію API та нову технологію CSS, але все одно створити щось непридатне для використання.
Зрозумійте середовище
Розробники, як і всі, повинні розуміти своє середовище - але вони також повинні розуміти аудиторію, будь то користувачі, команда або інші розробники. Вони повинні розуміти, як їх середовище вписується у світ (іншими словами, виробниче середовище) і який ефект він має (як люди його використовують).
Я бачив, що це описується як "широка і глибока" людина. Широкий, тому що потрібно розуміти світ як людину, яка працює з іншими людьми. Глибоко, тому що вам потрібні ґрунтовні технічні знання нижче рівня вашої частини проекту. Ці розробники дають вашому проекту величезний поштовх і змінюють темп проекту, без чого ви знайдете нетехнічного персоналу, заплутаного в нудних деталях, що переливається від технічної команди.
04. Те, з чим ми будуємо
Нещодавно я записав перелік усього, що ми використовуємо для створення сайтів, управління хостингом та виконання речей, щоб люди, які приєднуються, могли отримати шпаргалку з технологіями для вивчення протягом перших кількох тижнів. Ми сприймали як прочитане, що люди знають ці речі, тому, щоб дати новобранцям швидкий старт, ми перелічимо все, що ми використовуємо щодня.
Я очікував півдюжини технологій, але в підсумку набагато більше. Цей список - «те, що ми використовуємо» - включає звичайні CMS, мови програмування та браузерні технології, а також купу інструментів, які команда навіть не пам’ятала, що використовувала. Це все була м’язова пам’ять. Набравши в командному рядку «git», «phing», «thor», ми навіть не думали, що хтось може цього не зробити.
Побудувати інструменти; ДІ; git для контролю версій сприймалися як само собою зрозуміле, але озираючись назад на резюме, вони навряд чи з'являлися. Модні з’являлися б (і чи цинічно, що, на мою думку, деякі агенції додають їх ?!), але часто без конкретного досвіду.
Ці інструменти важливі для пришвидшення розробки проектів, тому переконайтеся, що у вас є набагато багатший набір інструментів, ніж ваша мова, система управління вмістом і кілька фреймворків. Вам потрібно розгортання, тестування, CI, сильний контроль версій (у командах - не самостійно), і вам потрібно зрозуміти основні поняття цих, а не лише декілька навчальних посібників.
05. Поглинає
Ці додаткові інструменти та хитрощі чудово вписуються в те, що люди називають „девоп”. Розвиває мух перед двома традиційними елеваторами: виробництво, яке підтримує роботу, і розвиток, який створює нові речі (і часто зупиняє їх). В результаті силосів виникають два табори, де симпатії один до одного незначні.
Розробники без виробничих знань частіше виробляють код, який не підходить для виробництва, використовуючи конфігурацію або функції, які ще не є у виробничому стеку. Оскільки вони не обізнані з проблемами виробничого середовища, вони кодують для завершення функції, а не для її розгортання у виробництві.
Ці дрібні деталі можуть спричинити хворобливі затримки, що посилюються тенденцією відправлення управління сервером за кордон.
Зрозумійте стек
Devops - це величезне поле саме по собі, яке охоплює постійне розгортання та багато автоматизації. Це широкий підсумок, але ключове, що повинні розуміти розробники, - це стек, на якому вони працюють. Недостатньо делегувати це адміністратору сервера, ви повинні розуміти наслідки, які має платформа для вашого коду.
Якщо ви працюєте над Rails, прочитайте код Rails і знайте, як Apache виконує Ruby. Якщо ви працюєте на Java, знайте про параметри конфігурації. Якщо ви використовуєте Perl, зрозумійте, як встановлювати модулі Perl та налаштовувати їх.
Таємнича робота
Список «те, що ми використовуємо» містить багато цього, і хороші розробники переходять до цього, щоб зрозуміти, як виконується вся ця загадкова робота. І як тільки вони це отримують, розгортання йдуть швидше, робота розгортається більш плавно, і всі стають просто щасливішими.
Постійне розгортання та пов’язані з цим практики devops стають настільки стандартними, що будь-який розробник або компанія, яка не практикує цього, налаштовується на випередження. Хтось інший почне це робити, і тоді вони будуть швидшими за вас.
Підручні інструменти
Погугливши «devops», ви уявляєте інструменти, якими користуються ці хлопці. Йдеться не про PHP та MySQL, ані про Rails. Йдеться про доставку програмного забезпечення та безпеку ризикованих проектів. Вони концентруються на розгортанні, автоматизації та підтримці роботи конвеєра від розробника до виробничого середовища якомога швидше.
Ви виявите, що такий стиль розробки дає вам розробників, які краще працюють між собою та з іншими підрозділами та компаніями. Якщо вони працюють із API третьої сторони, вони зрозуміють проблеми, які можуть виникнути з іншого боку. Працюючи з адміністраторами серверів, вони розумітимуть, що їм потрібно встановити, і знатимуть, як їх програмне забезпечення розміщується на робочих серверах. Зворотне це може бути болючим ...
06. Дев виправить це ... можливо
Цей пошук “основних навичок веб-розробника” приносить приємну відповідь від Майкла Грира (технічного директора The Onion) на Quora:
- Лінощі: відмовляється робити щось двічі: пише сценарій або альго для нього.
- Боягузтво: Думає перевірити, турбується про навантаження та вплив коду
- Нерозсудливість: постійно пробує нові речі, запускає ідеї того ж дня
Боягузтво - це приємний спосіб сформулювати «увагу до деталей». Налагодження та тестування - це 99 відсотків життя розробника, про які ніхто не згадував, коли вони потрапляли в W3Schools або починали курс обчислень 101.
Можливість виправлення програм вимагає чудових навичок вирішення проблем, але не просто налагодження коду. Іноді рішення для користувачів, які не можуть завантажити рахунки-фактури, полягає в тому, щоб зробити сторінку для друку, а не витрачати день на створення PDF-файлів. Іноді посилання може замінити тиждень розробки, але цього елегантного рішення не станеться, якщо розробники вирішують проблеми виключно шляхом написання великої кількості рядків коду.
Тестування є прекрасним місцем для багатьох розробників, незважаючи на безліч інструментів. Використовуйте модульні тести, селен, тестування на навантаження та інструменти профілювання, такі як xhprof. Аналіз таких речей, як New Relic, щоб розмір додатка був невеликим. І розгляньте все це частиною роботи розробника: це ваш код, переконайтесь, що ви знаєте, що він працює належним чином, а не сподіваєтесь, що він працює.
Налагодження
Налагодження також є хворобливим моментом. Не як користуватися налагоджувачем, а як налагоджувати проблему - тому я додав би до списку Майкла Грира:
- Нетерпіння: агресивно ігнорує неактуальну інформацію, щоб знайти та вирішити справжню проблему
Це наріжний камінь усіх методів налагодження. Ігнорування недоречного та пошук значення у відповідному. На жаль, багато хто схильний до рабського забивання непотрібного годинами чи днями, виправляючи проблему, спробуючи те саме 10 разів.
Це багато книг (на жаль, не тієї, яку я передав видавцю, яку я не буду називати) про налагодження, і кожен розробник повинен прочитати їх усі. Дійсно розробник може налагоджувати проблеми в системі, не бачачи рядка коду.
07. Що хочуть користувачі
Зрозумійте, що намагаються робити люди навколо вас. Насолоджуйтесь кодом - любите мистецтво ідеально відступати файли CSS або оптимізувати програму для рейок, але пам’ятайте, що це все для своєї мети.
Розробники повинні розуміти бізнес, операції та бізнес-процеси, тому що їх речі допомагають ним керувати. Розробники цих знань здатні створювати програмне забезпечення та додатки, які допомагають користувачам, але вони часто здаються надзвичайно продуктивними. Можливо, це пов’язано з швидким набором тексту або надзвичайним знанням стека, але це, швидше за все, через їх знання того, чого хочуть користувачі.
Конкурентний ринок
Повертаючись до моєї початкової точки зору, що розробка стає простішою, а ринок для великих розробників є більш конкурентоспроможним. Будь-який розробник, який зможе зрозуміти вимоги бізнесу та запропонувати щось чудове для їх задоволення, матиме перевагу. Зрозуміти ринок, клієнтів і те, чому вони розлучаються з грошима, все допомагає.
Зрозумійте дані та те, як вони будуть змінюватися з часом. На думку розробника, вони повинні поєднувати нові технології з викликами, які ви маєте сьогодні або бачите, що настають. Таким чином, коли ви пропонуєте фантастичну нову ідею доктору медицини або клієнту, вона буде базуватися на тому, що справді хочуть клієнти, і ви отримаєте на це бюджет / час. (На відміну від цього, найгірше, що можна засвідчити, це те, що розробники використовують свою нову улюблену технологію як рішення для всіх наших бід.)
Розробники мають великий контроль - чи потрібно їм знати, що означає кожне поле в базі даних для кінцевого користувача? Якщо ми змінимо дані, що побачать користувачі? Чи є кращий спосіб допомогти користувачам? Дуже часто думка адміністраторів БД полягає в тому, що світ є поганим відображенням їх бази даних, а не їх база даних є поганим відображенням реального світу. Світ безладний і напрочуд повний надзвичайних випадків. Розбирайтеся з цим, адміністратори БД.
08. Малювання та письмо
Малювання - це найпряміший спосіб спілкування, якими будуть речі. Розробники повинні вміти малювати свої ідеї на дошках, папері та пивних килимках.
Розробники повинні мати можливість створювати зразки на папері, друкувати скріншоти та писати на них, щоб лише повідомити про свій намір. Не довіряйте розробнику, який киває, каже, що він зрозумів і відкрив свій редактор.
Не вдається дешево: найкраще кодування починається з малювання як швидкого прототипу. Частіше зазнавайте невдач і переконайтеся, що всі розробники навколо вас роблять те саме, оскільки ви, швидше за все, досягнете успіху таким чином.
09. Насолоджуйся
А що, якщо вам доведеться витратити 10 годин на вирішення проблеми, пересуваючи посилання? Насолоджуйтесь - навіть якщо це лише проблема, як пройти через роботу.
Найгірше ставлення розробників (або когось іншого) - це апатія до того, що намагається досягти команда. На жаль, це поширене явище, оскільки розробники бачать себе поза межами того, чого домагається команда. (Пристрасний програміст ставить запитання: «наскільки ще цікавіше ви могли б зробити свою роботу?» - спробуйте.)
І будьте готові показати свою роботу, як зворотне на цьому: не розширюйте, випробувавши кілька підручників з Ruby, на «Досвід Ruby»!
Розробка Інтернету та додатків - все ще молода професія, але набір навичок, який справді дуже потрібен розробникам, розширюється. Кожному слід очікувати більшої кількості розробників, оскільки чим швидше ми всі вийдемо з неприємної кімнати і залучимося до творчого процесу, тим кращими будуть результати.
10. Залишайтеся гострими
Щоб довести це до гарного раунду 10, я додаю ще одну останню річ. Залишайтеся гострими. Знайдіть конкуренцію. Найгірший вид будь-чого - це ізольовано.
"Завжди будь найгіршим хлопцем у кожній групі, в якій ти є".
Найгірше - насправді, дуже погане - програмісти, програмісти, дизайнери вивчають свої речі і відпочивають на досягнутому. Без кардіостимулятора занадто легко сповільнити рух, і, не бачачи конкуренції, стає звичним бачити себе вище середнього.
Тож будьте найгіршим із можливих, знаходячи кращого. Приєднуйтесь до проектів поза роботою, робіть внески та шукайте зворотного зв'язку та критики, оскільки чим більше критики ви отримаєте, тим менше людей дадуть вам у майбутньому. Коли ви здогадуєтесь, чого вони хочуть краще, ніж вони є, тоді ви розробник ніндзя, якого хочуть усі.
Ден Фрост є технічним директором веб-компанії з повним спектром послуг 3EV, офіційним партнером AWS. Він працює у розробці CMS та розробці веб-додатків протягом семи років.
Сподобалось? Прочитайте це!
- Як створити додаток
- Найкращі безкоштовні веб-шрифти для дизайнерів
- Дізнайтеся, що буде далі з доповненою реальністю
