Sisältö
- 01. Koodaus ei enää leikkaa sitä
- Leveys ja syvyys
- 02. Suuri huomautus
- 03. Mitä Internet sanoo
- Ymmärrä väliaine
- 04. Asiat, joihin rakennamme
- 05. Devops
- Ymmärrä pino
- Salaperäinen työ
- Kätevät työkalut
- 06. Dev korjaa sen ... ehkä
- Virheenkorjaus
- 07. Mitä käyttäjät haluavat
- Kilpailulliset markkinat
- 08. Piirustus ja kirjoittaminen
- 09. Nauti itsestäsi
- 10. Pysy terävänä
- Piditkö tästä? Lue nämä!
Kehittäjien on oltava enemmän kuin koodia tuottavia murheellisia työntekijöitä. Odotamme enemmän digitaalisesta elämästämme, ja juuri nämä kaverit rakentavat sen, joten mitä parhaiden kehittäjien on tiedettävä? Tässä on asioita, jotka näen puuttuvan liian monelta kehittäjältä. Tämä ei ole tyhjentävä, mutta juuri nämä ominaisuudet tekevät kohtuullisesta kooderista hämmästyttävän kehittäjän.
Mutta se ei ole yksi asia, eikä se ole koskaan kyky jäsentää XML: ää tai optimoida koodia. Se on yllättävä kokoelma taitoja, joita ei opeteta koodin kirjoittamista koskevissa kirjoissa. Ne ovat vähän jotain ylimääräistä.
Miksi tuulettaa näin? Koska kehityksellä on merkitystä, mutta kehittäjät lähetetään liian usein toiseen maailmaan, ei aina heidän tekemäänsä. Tämä ei koskaan toimi. Kehitys - mikä tahansa tekninen - menestyy aina, kun osaavat ymmärtävät muutakin kuin vain koodin.
01. Koodaus ei enää leikkaa sitä
Olemme maailmassa, jossa koodaaminen on vähemmän vaikuttavaa. Kaikki rakentavat sivustoja, joista osa koodaa, mutta sinun ei tarvitse. Sivustoja, sovelluksia ja ominaisuuksia ei voi enää luoda vain nörtti.
Siitä lähtien, kun verkko tuli ja ihmiset voisivat opettaa itseään, on ollut itseopiskelijoita. Mutta jopa valmistuneet ovat uhattuna. Saan ansioluetteloita henkilöiden kanssa, joilla on tietojenkäsittelytieteen tutkinto, tekoälykursseja, erilaisia medioita ja koodauksia heidän vyönsä alla, mutta jotain puuttuu vielä. Joskus paljon puuttuu.
En ole ensimmäinen, joka sanoi tämän. "Koodaaminen ei enää leikkaa sitä" on luvun 3 otsikko Intohimoinen ohjelmoija, joka yhdessä kirjojen, kuten Pragmaattinen ajattelu ja oppiminen kehottaa ohjelmoijia parantamaan itseään koodin ulkopuolella; tulla vastuullisiksi ja täysin ihmisryhmän jäseniksi.
Leveys ja syvyys
Kehittäjien on oltava parempia kahdella tavalla: leveys ja syvyys. Heidän on ymmärrettävä ihmisten vuorovaikutuksen laajuus tiimissä ja rakentamissa asioissa. Heidän on ymmärrettävä työskentelemänsä järjestelmän syvyys O / S: ään saakka.
Eikä pelkästään kehittäjien pitäisi lukea näitä juttuja. Jos työskentelet kehittäjien kanssa, mielestäni sinun pitäisi odottaa enemmän heitä. Anna heidän luonnostella, mistä he puhuvat. Pyydä heitä selittämään kuvilla, esineillä ja (se toimii) leikkaamaan ihmisistä tarkalleen, millainen järjestelmä on sitä käyttäville ihmisille.
02. Suuri huomautus
Aion puhua negatiivisesti kehittäjistä, mutta luulen, että saan sen sallia, koska olen sellainen. Myös siksi, että ainakin yksi asia, josta puhun täällä, pätee useisiin tapaamiini kehittäjiin. Vaikka heidän työnsä on hienoa ja he tietävät koodinsa, ajat ovat kilpailukykyisiä. Sinulla on oltava reuna, ja tämä on:
- olla ketterämpi
ja
- olla paljon inhimillisempi
03. Mitä Internet sanoo
Googlen hakeminen "välttämättömistä verkkokehitystaidoista" tuo esiin odotuksesi. Kehystieto, x-selain, CSS ja JS. Niissä luetellaan kehykset, jotka sinun pitäisi tietää, alustat, joihin sinun on kirjoitettava, ja uudet suuntaukset, joita sinun pitäisi pitää silmällä.
Nämä ovat mediamme. Ne ovat asioita, joista rakennamme, mutta ne eivät anna projektille menestystä. Kehittäjä voi ymmärtää järjestelmän kaikki yksityiskohdat, kertoa sinulle kaikki sovellusliittymän ja uuden CSS-tekniikan ominaisuudet, mutta tuottaa silti jotain käyttökelvottomaa.
Ymmärrä väliaine
Kehittäjien, kuten kaikkienkin, on ymmärrettävä välineensä - mutta heidän on myös ymmärrettävä yleisö, olipa kyseessä käyttäjät, tiimi tai muut kehittäjät. Heidän on ymmärrettävä, kuinka heidän välineensä sopii maailmaan (toisin sanoen tuotantoympäristöön) ja mitä vaikutuksia sillä on (miten ihmiset käyttävät sitä).
Olen nähnyt tämän kuvaavan "laajaksi ja syväksi" henkilöksi. Laaja, koska sinun on ymmärrettävä maailma ihmisenä, joka työskentelee muiden ihmisten kanssa. Syvä, koska tarvitset perusteellista teknistä tietämystä alle projektisi osan. Nämä kehittäjät antavat projektillesi valtavan sysäyksen ja muuttavat projektin vauhtia. Ilman muuta huomaat, että muu kuin tekninen henkilöstö on tukkeutunut ikäviin yksityiskohtiin, jotka täyttävät teknisen tiimin.
04. Asiat, joihin rakennamme
Kirjoitin äskettäin luettelon kaikesta, mitä käytämme sivustojen rakentamiseen, isännöinnin hallintaan ja asioiden tekemiseen, jotta liittyneillä ihmisillä olisi huijauslehti tekniikoista, joita heidän on opittava ensimmäisten viikkojensa aikana. Pidimme luettuna, että ihmiset tiesivät nämä asiat, joten jotta voimme antaa uusille rekrytoijille mahdollisuuden aloittaa, listasimme kaiken, mitä käytämme joka päivä.
Odotin puoli tusinaa tekniikkaa, mutta päädyin paljon enemmän. Tämä luettelo - "mitä käytämme" - sisältää tavalliset CMS: t, ohjelmointikielet ja selainteknologiat, mutta myös joukon työkaluja, joita tiimi ei edes muista itsestään. Se oli kaikki lihasmuistia. Kirjoittamalla komentoriville 'git', 'phing', 'thor' emme edes ajatelleet, että joku ei ehkä.
Rakenna työkaluja; CI; versionhallinnan git pidettiin itsestäänselvyytenä, mutta ansioluetteloita tarkasteltaessa niitä tuskin esiintyi. Trendikkäät esiintyisivät (ja onko kyynistä, että mielestäni tietyt virastot lisäävät ne ?!), mutta usein ilman konkreettista kokemusta.
Nämä työkalut ovat tärkeitä projektikehityksen nopeuttamiseksi, joten varmista, että sinulla on paljon rikkaampi työkalu kuin kielesi, CMS ja muutama kehys. Tarvitset käyttöönoton, testauksen, käyttöliittymän, vahvan versionhallinnan (tiimeissä - ei yksin), ja sinun on ymmärrettävä näiden peruskäsitteet muutaman opetusohjelman sijaan.
05. Devops
Nämä ylimääräiset työkalut ja temput sopivat siististi siihen, mitä ihmiset kutsuvat "devopsiksi". Devops lentää kahden perinteisen siilon edessä: tuotanto, joka pitää asiat käynnissä, ja kehitys, joka tekee uusia juttuja (ja usein pysäyttää asiat). Siilot johtavat kahteen leiriin, joissa ei ole paljon myötätuntoa toisiaan kohtaan.
Kehittäjät, joilla ei ole tuotantotietoa, tuottavat useammin koodia, joka ei sovellu tuotantoon, käyttämällä kokoonpanoa tai ominaisuuksia, joita ei vielä ole tuotantopinossa. Koska he eivät ole tietoisia tuotantoympäristön ongelmista, he koodaavat ominaisuuden täydentämistä sen sijaan, että se otettaisiin käyttöön tuotannossa.
Nämä pienet yksityiskohdat voivat aiheuttaa tuskallisia viivästyksiä, joita palvelimen hallinnan lähettäminen ulkomaille pahentaa.
Ymmärrä pino
Devops on sinänsä valtava kenttä, joka kattaa jatkuvan käyttöönoton ja paljon automaatiota. Tämä on laaja yhteenveto, mutta tärkein asia, jonka kehittäjien on ymmärrettävä, on juokseva pino. Ei riitä, että delegoit tämän palvelimen järjestelmänvalvojalle, sinun on ymmärrettävä alustan vaikutukset koodiin.
Jos työskentelet Railsilla, lue Rails-koodi ja tiedä kuinka Apache suorittaa Rubyn. Jos työskentelet Java-ohjelmassa, tiedä kokoonpanovaihtoehdot. Jos käytät Perliä, ymmärrä miten Perl-moduulit asennetaan ja määritetään.
Salaperäinen työ
"Mitä käytämme" -luettelo sisältää paljon tätä tavaraa, ja hyvät kehittäjät hyppäävät siihen ymmärtääkseen, miten tämä salaperäinen työ tehdään. Ja kun he saavat sen, käyttöönotto sujuu nopeammin, työ on sujuvampaa ja kaikki ovat vain onnellisempia.
Devopsin jatkuvasta käyttöönotosta ja siihen liittyvistä käytännöistä on tulossa niin vakiintuneita, että kaikki kehittäjät tai yritykset, jotka eivät harjoittele tätä, asettavat itsensä ohitettaviksi. Joku muu alkaa tehdä sitä ja sitten hän on nopeampi kuin sinä.
Kätevät työkalut
Googling for “devops” antaa sinulle käsityksen työkaluista, joita nämä kaverit käyttävät. Kyse ei ole PHP: stä ja MySQL: stä tai Railsistä. Kyse on ohjelmistojen toimittamisesta ja projektien riskialttiiden osien pitämisestä riskittömistä. Ne keskittyvät käyttöönottoon, automatisointiin ja putkilinjan pitämiseen kehittäjältä tuotantoympäristöön mahdollisimman nopeasti.
Huomaat, että tämä kehitystyyli antaa sinulle kehittäjiä, jotka työskentelevät paremmin keskenään sekä muiden osastojen ja yritysten kanssa. Jos he työskentelevät kolmannen osapuolen sovellusliittymän kanssa, he ymmärtävät ongelmat, joita todennäköisesti tulee toisella puolella. Työskennellessään palvelimen järjestelmänvalvojien kanssa he ymmärtävät, mitä heidän on asennettava, ja tietävät, kuinka heidän ohjelmistosivustonsa tuotantopalvelimilla. Tämän käänteinen voi olla tuskallista ...
06. Dev korjaa sen ... ehkä
Tämä haku 'välttämättömille verkkokehittäjätaidoille' tuo mukavan vastauksen Michael Greeriltä (The Onion's CTO) Quorasta:
- Laisuus: Kieltäytyy tekemästä mitään kahdesti: kirjoittaa sen käsikirjoituksen tai algon.
- Pelkuruus: Ajattelee testata, huoli kuormituksesta ja koodin vaikutuksesta
- Holtittomuus: Kokeilee jatkuvasti uusia asioita, lanseeraa saman päivän ideoita
Arkuus on hieno tapa ilmaista "huomiota yksityiskohtiin". Virheenkorjaus ja testaus ovat 99 prosenttia kehittäjän elämästä, jota kukaan ei maininnut, kun he osuivat W3Schools-ohjelmaan tai aloittivat laskennallisen 101-kurssin.
Kyky korjata sovelluksia vaatii erinomaisia ongelmanratkaisutaitoja, mutta ei vain koodin virheenkorjausta. Joskus ratkaisu käyttäjille, jotka eivät voi ladata laskujaan, on tehdä sivu tulostettavaksi sen sijaan, että viettäisivät päivän PDF-tiedostojen luomiseen. Joskus linkki voi korvata viikon kehityksen, mutta tyylikästä ratkaisua ei tapahdu, jos kehittäjät ratkaisevat ongelmia puhtaasti kirjoittamalla paljon koodirivejä.
Testaus on hieno sokkopiste monille kehittäjille huolimatta monista työkaluista. Käytä yksikkö-, seleeni-, kuormitustestaus- ja profilointityökaluja, kuten xhprof. Analyysi esimerkiksi New Relicistä, jotta sovelluksesi jalanjälki pysyy pienenä. Pidä tämä kaikki osa kehittäjän työtä: se on koodisi, varmista, että tiedät, että se toimii tarkoitetulla tavalla, eikä toivoa.
Virheenkorjaus
Virheenkorjaus on myös arka kohta. Ei kuinka käyttää virheenkorjainta, vaan kuinka korjata ongelma - joten haluaisin lisätä Michael Greerin luetteloon:
- Kärsimättömyys: aggressiivisesti jätetään huomiotta merkityksetön tieto todellisen ongelman löytämiseksi ja ratkaisemiseksi
Tämä on kaikkien virheenkorjaustekniikoiden kulmakivi. Ohittaa merkityksetön ja löytää merkityksen asiaankuuluvasta. Valitettavasti monet ovat taipuvaisia iskemään epäolennaisia orjaisesti tuntikausia tai päiviä ja korjaamaan ongelman kokeilemalla samaa 10 kertaa.
Nämä ovat monia kirjoja (valitettavasti, ei kirjaa, jonka luovutin julkaisijalle, jota en nimeä) virheenkorjauksesta, ja jokaisen kehittäjän tulisi lukea ne kaikki. Todella hieno kehittäjä voi virheenkorjata järjestelmän ongelmia näkemättä koodiriviä.
07. Mitä käyttäjät haluavat
Ymmärrä, mitä ihmiset ympärilläsi yrittävät tehdä. Nauti koodista - rakastat CSS-tiedostojen sisennyksen taitoa tai kiskosovelluksen optimointia - mutta muista, että kaikki on tarkoitusta varten.
Kehittäjien on ymmärrettävä liiketoiminta, toiminta ja liiketoimintaprosessit, koska heidän tavaransa auttavat sitä hoitamaan. Kehittäjät, joilla on tämä tieto, pystyvät rakentamaan ohjelmistoja ja sovelluksia, jotka auttavat käyttäjiä, mutta ne näyttävät usein epätavallisen tuottavilta. Tämä voi johtua heidän valaistuksestaan nopeasti kirjoittamisesta tai hämmästyttävästä pinon tuntemuksesta, mutta se johtuu todennäköisesti heidän tietämyksestään käyttäjien haluamista.
Kilpailulliset markkinat
Palatakseni alkuperäiseen huomautukseeni, kehitys on entistä helpompaa ja suurten kehittäjien markkinat ovat kilpailukykyisemmät jokaiselle kehittäjälle, joka pystyy ymmärtämään liiketoiminnan vaatimukset ja tuomaan jotain erinomaista vastaamaan niihin, tulee olemaan etu. Ymmärtää markkinat, asiakkaat ja miksi he jakavat rahaa - kaikki auttaa.
Ymmärrä tiedot ja miten ne muuttuvat ajan myötä. Kehittäjän mielessä heidän tulisi yhdistää uusi tekniikka haasteisiin, jotka sinulla on tänään tai joita olet tulossa. Tällä tavalla, kun ehdotat hienoa uutta ideaa MD: lle tai asiakkaalle, se perustuu siihen, mitä asiakkaat todella haluavat, ja saat budjetin / ajan siihen. (Sitä vastoin pahinta on todistaa, että kehittäjät käyttävät uutta suosikkitekniikkaansa ratkaisuna kaikkiin haitoihimme.)
Kehittäjillä on paljon hallintaa - onko heidän tiedettävä, mitä tietokannan kukin kenttä tarkoittaa loppukäyttäjälle? Jos muutamme tietoja, mitä käyttäjät näkevät? Onko olemassa parempaa tapaa auttaa käyttäjiä? Liian usein DB-järjestelmänvalvojien näkemys on, että maailma heijastaa heidän tietokantaansa huonosti sen sijaan, että heidän tietokantansa olisi huono esitys todellisesta maailmasta. Maailma on sotkuinen ja yllättävän täynnä reunatapauksia. Käsittele sitä, DB-järjestelmänvalvojat.
08. Piirustus ja kirjoittaminen
Piirustus on suorin tapa kommunikoida mistä tulee. Kehittäjien on kyettävä piirtämään ideoitaan taululle, paperille ja olutmatoille.
Kehittäjien on kyettävä prototyypiksi paperille, tulostamaan kuvakaappauksia ja piirtämään niitä vain ilmoittaakseen aikomuksestaan. Älä luota kehittäjään, joka nyökkää, sanoo ymmärtävänsä ja avaavansa toimittajan.
Epäonnistuu halvalla: paras koodaus alkaa piirtämisestä nopeaksi prototyypiksi. Epäonnistuu useammin ja varmista, että kaikki ympärilläsi olevat kehittäjät tekevät samoin kuin todennäköisemmin onnistut tällä tavalla.
09. Nauti itsestäsi
Entä jos joudut viettämään 10 tuntia ongelman ratkaisemisessa siirtämällä linkkiä? Nauti siitä - vaikka se olisikin vain työn läpikäymisen haaste.
Kehittäjien (tai kenenkään) pahin asenne on apatia kohtaan, mitä tiimi yrittää saavuttaa. Valitettavasti tämä on yleistä, koska kehittäjät kokevat itsensä ulkopuolelle tiimin saavutuksia. (Intohimoinen ohjelmoija esittää kysymyksen: 'Kuinka paljon hauskempaa voisit tehdä työstäsi?' - kokeile sitä.)
Ja ole valmis näyttämään työsi, kun tämä on päinvastainen asia: älä laajene kokeillessasi pari Ruby-opastusta 'Experience of Ruby'!
Verkko- ja sovelluskehitys on edelleen nuori ammatti, mutta taitopaketin todella suuri kehittäjien tarve kasvaa. Kaikkien tulisi odottaa enemmän kehittäjiä, koska mitä nopeammin me kaikki tulemme ikävästä takahuoneesta ja osallistumme luovaan prosessiin, sitä paremmat tulokset ovat.
10. Pysy terävänä
Lisätään vielä viimeinen asia, jotta tämä olisi mukava 10. kierros. Pysyä terävänä. Löydä kilpailu. Pahin mikä tahansa on erillään.
"Ole aina pahin kaveri jokaisessa bändissä, jossa olet."
Pahin - todella, erittäin huono - ohjelmoija, kooderi, suunnittelija oppii tavaransa ja lepää laakereillaan. Ilman sydämentahdistinta on liian helppo hidastaa ja kilpailua näkemättä tulee tapana nähdä itsesi keskiarvon yläpuolella.
Joten, ole pahin mitä voit löytää paremmalla. Liity työhön liittyviin projekteihin, osallistu ja etsi palautetta ja kritiikkiä, koska mitä enemmän kritiikkiä saat, sitä vähemmän ihmiset antavat sinulle tulevaisuudessa. Kun arvaat, mitä he haluavat paremmin kuin ovat, olet ninja-kehittäjä, jota kaikki haluavat.
Dan Frost on täyden palvelun verkkoyrityksen 3EV tekninen johtaja, virallinen AWS-kumppani. Hän on työskennellyt CMS: n ja verkkosovellusten kehittämisessä seitsemän vuotta.
Piditkö tästä? Lue nämä!
- Kuinka rakentaa sovellus
- Parhaat ilmaiset web-fontit suunnittelijoille
- Tutustu laajennetun todellisuuden seuraaviin vaiheisiin
