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