Задаволены
- 01. Кадаванне больш не скарачае
- Шырыня і глыбіня
- 02. Вялікая агаворка
- 03. Што кажа Інтэрнэт
- Зразумець асяроддзе
- 04. Рэчы, з якімі мы будуем
- 05. Паглыбляецца
- Зразумець стэк
- Загадкавая праца
- Зручныя інструменты
- 06. Дэв выправіць ... магчыма
- Адладка
- 07. Чаго хочуць карыстальнікі
- Канкурэнтны рынак
- 08. Маляванне і пісьмо
- 09. Атрымлівайце асалоду ад сябе
- 10. Заставайцеся вострымі
- Спадабалася гэта? Прачытайце гэтыя!
Распрацоўшчыкі павінны быць не толькі стваральнікамі кода. Мы чакаем большага ад нашага лічбавага жыцця, і менавіта гэтыя хлопцы ствараюць яго, так што ж трэба ведаць лепшым распрацоўшчыкам? Вось чаго я бачу, адсутнічае ў занадта вялікай колькасці распрацоўшчыкаў. Гэта не вычарпальна, але менавіта гэтыя якасці ператвараюць разумнага праграміста ў цудоўнага распрацоўшчыка.
Але гэта не адно, і асабліва ніколі нельга аналізаваць XML альбо аптымізаваць код. Гэта дзіўная калекцыя навыкаў, якім не вучаць кнігі па напісанні кода. Яны маленькае нешта дадатковае.
Навошта аддушвацца так? Паколькі распрацоўка мае значэнне, але распрацоўшчыкі занадта часта накіроўваюцца ў іншы свет, не заўсёды іх стварэнне. Гэта ніколі не працуе. Распрацоўка - што заўгодна тэхнічнае - заўсёды квітнее, калі тыя, хто ведае, разумеюць не толькі код.
01. Кадаванне больш не скарачае
Мы знаходзімся ў свеце, дзе кадаванне становіцца менш уражлівым. Усе ствараюць сайты, некаторыя з іх кодуюць, але вам не трэба. Ствараць сайты, праграмы і функцыі можа ўжо не толькі недарэк.
З таго часу, як з'явіўся Інтэрнэт і людзі маглі вучыць сябе, распрацоўшчыкі-самавукі з'явіліся. Але нават выпускнікі знаходзяцца пад пагрозай. Я атрымліваю рэзюмэ з людзьмі, якія маюць дыплом інфарматыкі, курсы ІІ, розныя носьбіты і кадоўкі, але чагосьці яшчэ не хапае. Часам шмат чаго не хапае.
Я не першы кажу гэта. «Кадаванне больш не скарачае» - гэта назва раздзела 3 Гарачы праграміст, які разам з такімі кнігамі, як Прагматычнае мысленне і навучанне заклікаць праграмістаў удасканальвацца за межамі кода; стаць адказам і цалкам чалавечымі членамі каманды.
Шырыня і глыбіня
Распрацоўшчыкі павінны быць лепш двума спосабамі: шырынёй і глыбінёй. Яны павінны разумець шырыню чалавечага ўзаемадзеяння ў сваёй камандзе і з тым, што яны будуюць. Яны павінны разумець глыбіню сістэмы, з якой працуюць, аж да А / С.
І чытаць гэтыя матэрыялы павінны не толькі распрацоўшчыкі. Калі вы працуеце са распрацоўшчыкамі, думаю, вам варта чакаць большага. Зрабіце так, каб яны накідалі, пра што яны кажуць. Зрабіце так, каб яны растлумачылі малюнкамі, прадметамі і (гэта працуе) выразалі людзям, якой менавіта будзе сістэма для людзей, якія яе выкарыстоўваюць.
02. Вялікая агаворка
Я буду гаварыць негатыўна пра распрацоўшчыкаў, але, думаю, мне гэта дазволена, бо я адзін. Таксама таму, што як мінімум адно, пра што я тут кажу, справядліва ў дачыненні да многіх распрацоўшчыкаў, якіх я сустракаю. І хаця іх праца выдатная і яны ведаюць свой код, часы канкурэнтныя. Вы павінны мець перавагу, і гэта:
- быць больш тэхнічным
і
- быць шмат больш чалавечны
03. Што кажа Інтэрнэт
Пошук у "неабходных навыках вэб-распрацоўкі" дазваляе даведацца пра тое, чаго вы чакаеце. Рамачныя веды, x-аглядальнік, CSS і JS. Яны пералічваюць асновы, якія вы павінны ведаць, платформы, на якія вы павінны пісаць, і новыя тэндэнцыі, на якія вы павінны сачыць.
Гэта нашы СМІ. З іх мы ствараем рэчы, але яны не тое, што дае поспех праекту. Распрацоўшчык можа зразумець кожную дэталь сістэмы, расказаць вам пра кожную асаблівасць API і новую тэхналогію CSS, але пры гэтым вырабіць нешта непрыдатнае для выкарыстання.
Зразумець асяроддзе
Распрацоўшчыкі, як і ўсе, павінны разумець сваё асяроддзе - але яны таксама павінны разумець аўдыторыю, няхай гэта будзе карыстальнікі, каманда ці іншыя распрацоўшчыкі. Яны павінны разумець, як іх носьбіт упісваецца ў свет (іншымі словамі, вытворчае асяроддзе) і які эфект ён аказвае (як людзі яго выкарыстоўваюць).
Я бачыў, што гэтага апісваюць як "шырокага і глыбокага" чалавека. Шырокі, таму што трэба разумець свет як чалавека, які працуе з іншымі людзьмі. Глыбока, таму што вам патрэбныя грунтоўныя тэхнічныя веды ніжэй за ўзровень вашай часткі праекта. Гэтыя распрацоўшчыкі даюць вашаму праекту велізарны штуршок і змяняюць тэмпы праекта, без чаго вы знойдзеце нетэхнічнага персаналу, забітага ў нудныя дэталі, якія пераліваюцца ад тэхнічнай каманды.
04. Рэчы, з якімі мы будуем
Нядаўна я запісаў спіс усяго, што мы выкарыстоўваем для стварэння сайтаў, кіравання хостынгам і выканання спраў, каб людзі, якія далучаюцца, маглі атрымаць шпаргалку з тэхналогіямі, каб навучыцца ў першыя некалькі тыдняў. Мы прымалі як прачытанае, што людзі ведаюць гэтыя рэчы, таму, каб пачаць прызыўнікоў, мы пералічым усё, чым мы карыстаемся кожны дзень.
Я чакаў паўтузіна тэхналогій, але ў выніку куды больш. Гэты спіс - «тое, што мы выкарыстоўваем» - уключае звычайныя CMS, мовы праграмавання і браўзэрныя тэхналогіі, але таксама мноства інструментаў, якія каманда нават не памятала. Усё гэта была цягліцавая памяць. Набраўшы ў камандным радку "git", "phing", "thor", мы нават не думалі, што хтосьці можа гэтага не зрабіць.
Будаваць інструменты; ДІ; git для кантролю версій успрымаліся як належнае, але аглядаючы рэзюмэ, яны наўрад ці з'яўляліся. З'яўляюцца модныя (і цінічна, што, думаю, некаторыя агенцтвы дадаюць іх ?!), але часта без канкрэтнага досведу.
Гэтыя інструменты важныя для паскарэння распрацоўкі праекта, таму пераканайцеся, што ў вас ёсць нашмат больш багаты набор інструментаў, чым ваша мова, CMS і некалькі рамак. Вам патрэбна разгортванне, тэставанне, 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. Аналіз такіх рэчаў, як "Новая рэліквія", каб захаваць невялікі адбітак вашага прыкладання. І ўлічыце гэта ўсё часткай працы распрацоўшчыка: гэта ваш код, пераканайцеся, што вы ведаеце, што ён працуе, як задумана, а не спадзяйцеся, што ён працуе.
Адладка
Адладка таксама з'яўляецца балючым момантам. Не як карыстацца адладчыкам, а як адладжваць праблему - таму я б дадаў у спіс Майкла Грыра:
- Нецярплівасць: агрэсіўна ігнаруе недарэчную інфармацыю, каб знайсці і вырашыць сапраўдную праблему
Гэта краевугольны камень усіх метадаў адладкі. Ігнараванне недарэчнага і пошук сэнсу ў адпаведным. На жаль, многія схільныя па-рабску забіваць непатрэбнае гадзінамі ці днямі, выпраўляючы праблему, спрабуючы тое самае 10 разоў.
Ёсць шмат кніг (на жаль, не той, якую я выдаў выдавецтву, якую я не назаву), прысвечанай адладцы, і кожны распрацоўшчык павінен іх прачытаць. Сапраўды выдатны распрацоўшчык можа адладжваць праблемы ў сістэме, не бачачы радка кода.
07. Чаго хочуць карыстальнікі
Зразумейце, што спрабуюць рабіць людзі вакол вас. Атрымлівайце асалоду ад кода - любіце мастацтва выдатна рабіць водступы CSS альбо аптымізаваць прыкладанне rails - але памятайце, што ўсё гэта мае мэту.
Распрацоўшчыкі павінны разумець бізнес, аперацыі і бізнес-працэсы, таму што іх рэчы дапамагаюць ім кіраваць. Распрацоўшчыкі, якія валодаюць гэтымі ведамі, могуць ствараць праграмнае забеспячэнне і дадаткі, якія дапамагаюць карыстальнікам, але яны часта здаюцца незвычайна прадуктыўнымі. Гэта можа быць звязана з хуткім наборам тэксту альбо дзіўным веданнем стэка, але, хутчэй за ўсё, з-за іх ведаў пра тое, чаго хочуць карыстальнікі.
Канкурэнтны рынак
Вяртаючыся да маёй першапачатковай думкі, распрацоўка становіцца прасцейшай, а рынак выдатных распрацоўшчыкаў з'яўляецца больш канкурэнтаздольным. Любы распрацоўшчык, які здольны зразумець бізнес-патрабаванні і прывесці нешта выдатнае для іх, будзе мець перавагу. Зразумець рынак, кліентаў і тое, чаму яны разлучаюцца з грашыма, усё дапамагае.
Зразумець дадзеныя і тое, як яны будуць змяняцца з цягам часу. На думку распрацоўшчыка, яны павінны выбудоўваць новыя тэхналогіі з тымі праблемамі, якія стаяць перад вамі сёння ці якія вы чакаеце. Такім чынам, калі вы прапануеце фантазію новай ідэі для доктара медыцыны ці кліента, яна будзе грунтавацца на тым, што кліенты сапраўды хочуць, і вы атрымаеце на гэта бюджэт / час. (У адрозненне ад гэтага, найгоршае, што можна назіраць, - гэта тое, што распрацоўшчыкі разглядаюць сваю новую любімую тэхналогію як рашэнне для ўсіх нашых бед.)
Распрацоўшчыкі маюць шмат кантролю - ці трэба ім ведаць, што азначае кожнае поле ў базе дадзеных для канчатковага карыстальніка? Калі мы зменім дадзеныя, што ўбачаць карыстальнікі? Ці існуе лепшы спосаб дапамагчы карыстальнікам? Занадта часта меркаванне адміністратараў БД заключаецца ў тым, што свет дрэнна адлюстроўвае іх базу дадзеных, а не базу дадзеных, якая дрэнна ўяўляе рэальны свет. Свет бязладны і дзіўна поўны выпадкаў. Рабіце гэта, адміністратары БД.
08. Маляванне і пісьмо
Маляванне - гэта самы непасрэдны спосаб паведамлення, якімі будуць рэчы. Распрацоўшчыкі павінны мець магчымасць маляваць свае ідэі на дошках, папяровых і піўных кілімках.
Распрацоўшчыкі павінны мець магчымасць ствараць прататыпы на паперы, друкаваць скрыншоты і пісаць на іх проста для паведамлення пра свае намеры. Не давярайце распрацоўшчыку, які ківае галавой, кажа, што разумее і адкрывае свой рэдактар.
Не атрымліваецца танна: лепшае кадзіраванне пачынаецца з малявання як хуткага прататыпа. Часцей церпіце няўдачы і пераканайцеся, што ўсе распрацоўшчыкі вакол вас робяць тое ж самае, бо хутчэй за ўсё даможацеся поспеху.
09. Атрымлівайце асалоду ад сябе
А што, калі вам прыйдзецца выдаткаваць 10 гадзін на рашэнне праблемы, перамяшчаючы спасылку? Атрымлівайце асалоду - нават калі гэта проста праблема, калі прайсці працу.
Самае дрэннае стаўленне распрацоўшчыкаў (ці каго-небудзь іншага) - гэта апатыя да таго, што каманда спрабуе дасягнуць. На жаль, гэта распаўсюджана, бо распрацоўшчыкі бачаць сябе па-за межамі таго, чаго дамагаецца каманда. (Гарачы праграміст ставіць пытанне: "наколькі больш цікавым вы маглі б зрабіць сваю працу?" - паспрабуйце.)
І будзьце гатовыя паказаць сваю працу, як адваротнае на гэтым: не пашырайце, паспрабаваўшы некалькі падручнікаў па Ruby да «Вопыт Ruby»!
Распрацоўка Інтэрнэту і праграм па-ранейшаму маладая прафесія, але набор навыкаў, сапраўды неабходны распрацоўнікам, пашыраецца. Кожны павінен чакаць большай колькасці распрацоўшчыкаў, таму што чым хутчэй мы ўсе выйдзем з непрыемнага кутка і ўключымся ў творчы працэс, тым лепшыя будуць вынікі.
10. Заставайцеся вострымі
Каб давесці гэта да прыемнага тура 10, я дадам яшчэ адну рэч. Заставайцеся вострымі. Знайдзіце канкурэнцыю. Горшы выгляд усяго - адзінкавы.
"Заўсёды будзь горшым хлопцам у кожнай групе, у якой ты ўдзельнічаеш".
Горшае - сапраўды, вельмі дрэннае - праграмісты, праграмісты, дызайнеры вучацца іх справам і адпачываюць на дасягнутым. Без кардыёстымулятара занадта проста замарудзіць і, не бачачы канкурэнцыі, становіцца звычайным бачыць сябе вышэй за сярэдні.
Такім чынам, будзьце горшым, чым толькі можаце, знайшоўшы лепшае. Далучайцеся да праектаў па-за працай, далучайцеся і шукайце водгукі і крытыку, таму што чым больш крытыкі вы атрымаеце, тым менш людзей дасць вам у будучыні. Калі вы адгадаеце, чаго яны хочуць лепш, чым яны ёсць, вы распрацоўшчык ніндзя, якога хочуць усе.
Дэн Фрост з'яўляецца тэхнічным дырэктарам вэб-кампаніі з поўным наборам паслуг 3EV, афіцыйным партнёрам AWS. Ён працуе ў CMS і распрацоўцы вэб-праграм на працягу сямі гадоў.
Спадабалася гэта? Прачытайце гэтыя!
- Як стварыць прыкладанне
- Лепшыя бясплатныя вэб-шрыфты для дызайнераў
- Даведайцеся, што чакае дапоўненая рэальнасць
