Mis vahe on programmeerijal, arendajal, kodeerijal, häkkeril ja inseneril?


Vastus 1:

Programmeerija on keegi, kes suudab arvutikoodiga manipuleerimise abil probleeme lahendada. Neil võib olla lai valik oskuste taset - alates lihtsast skriptimisest "ok" kuni absoluutse nõiani ükskõik millise keelega. Häkker on keegi, kes asju valmistab. Selles kontekstis teeb keegi asju arvutite programmeerimisega. See on termini algupärane ja kõige puhtam määratlus, st et teil on idee ja "häkitsete" midagi koos, et see toimiks. See kehtib ka inimeste kohta, kes muudavad asju, et nende funktsionaalsust oluliselt muuta, kuid vähem nii. Arendaja on formaalselt koolitatud programmeerija. Nad ei lahenda ainult probleeme ega loo asju, vaid teevad seda vastavalt kujundamis- ja rakenduspõhimõtetele. Nende hulka kuuluvad näiteks jõudlus, hooldatavus, ulatus, vastupidavus ja (ideaaljuhul) turvalisus. Lühidalt öeldes lahendavad kõik kolm koodi abil probleeme. Programmeerija on katustermin, mis tähendab probleemilahendajat, häkker on looja / pakkuja ja arendaja on formaalselt koolitatud programmeerija, kes ei lahenda ainult probleeme, vaid teeb seda struktureeritud ja distsiplineeritud viisil, mida tõenäoliselt õpitakse formaalse hariduse osana .Kõik häkkerid ja arendajad on programmeerijadPaljud programmeerijad ja isegi arendajad pole piisavalt loovad, et neid häkkeriteks pidada. Paljud programmeerijad ja isegi häkkerid pole piisavalt haritud ega kogenud, et neid arendajaks pidada.


Vastus 2:

Ma ei usu, et nende pealkirjade vahel oleks mingit ametlikku määratlust. Tavaliselt on mõisted “programmeerija” ja “kodeerija” sünonüümid (peaaegu samad). Mõiste häkker tähendab minu jaoks kedagi, kes üritab koodi lahti murda või leida ootamatu (ja selleks ette valmistamata) viis siseneda hostimissüsteemi. Seda saab teha sotsiaalse inseneri kaudu või hulgaliselt muid võimalusi kasutades. Häkker võib koodivigade esiletoomisel olla positiivne eelis. Need võivad olla ka äärmiselt hävitavad. Ettevõttel, kus varem töötasin (mitte We Energies), oli grupp „MUG“. aka: pahatahtlike kasutajate rühm, mida kasutati saadetava koodi "kõvendamiseks".

Minu arvates kipub arendaja muretsema ühe rakenduse ja selle koostamise viisi pärast. Pidades meeles, et see võib mõjutada töökeskkonda. See võib hõlmata hulgaliselt tegureid, näiteks: võrk, tulemüürid, masina löök, mõju muudele rakendustele, mida nii füüsilises / virtuaalses keskkonnas hostitakse. Peamine on see, et arendaja on keskendunud rohkem rakendusele kui teistele teguritele. Ta on teistest tükkidest ja osadest teadlik, kuid see pole nende jaoks peamine fookus. Nad peavad saama rakenduse võimalikult korrektseks.

Insener on üldnimetus (nagu ka arendaja), kuid tarkvara osas kipuvad nad keskenduma esmalt üldisele keskkonnale ja teisele rakendusele. Kuid see pole raske ja kiire reegel.

Minu jaoks oli selle asja juures võtmeks see, kas insener on tarkvarakontseptsioonide ametliku väljaõppe saanud või on selle lihtsalt lennult õppinud. Olemas on palju keerulisi tabeleid, mille insenerid alustasid. Neil olid algoritmid, kuid nad ei saanud aru (või ei hoolinud), miks tuleks teatud asju teha kindlal viisil (kiiruse või laiendatavuse huvides). Need võivad olla hiilgavad, kuid rakendust oli äärmiselt keeruline hooldada.

Minu eelistus oli ehitada kõigepealt hooldatavuse ja laiendatavuse rakendused ning pärast seda kiirus, kui see oli vajalik. Hooldatavuse esikohale panemisel kulutasin rakendusele vähem aega ja järgmise laiendatavuse tõttu tegin selle parendamise lihtsaks. Seal on vana ütlus: alati saab osta suurema kasti ... (mitte nii, et tingimata tahetakse).


Vastus 3:

Ma ei usu, et nende pealkirjade vahel oleks mingit ametlikku määratlust. Tavaliselt on mõisted “programmeerija” ja “kodeerija” sünonüümid (peaaegu samad). Mõiste häkker tähendab minu jaoks kedagi, kes üritab koodi lahti murda või leida ootamatu (ja selleks ette valmistamata) viis siseneda hostimissüsteemi. Seda saab teha sotsiaalse inseneri kaudu või hulgaliselt muid võimalusi kasutades. Häkker võib koodivigade esiletoomisel olla positiivne eelis. Need võivad olla ka äärmiselt hävitavad. Ettevõttel, kus varem töötasin (mitte We Energies), oli grupp „MUG“. aka: pahatahtlike kasutajate rühm, mida kasutati saadetava koodi "kõvendamiseks".

Minu arvates kipub arendaja muretsema ühe rakenduse ja selle koostamise viisi pärast. Pidades meeles, et see võib mõjutada töökeskkonda. See võib hõlmata hulgaliselt tegureid, näiteks: võrk, tulemüürid, masina löök, mõju muudele rakendustele, mida nii füüsilises / virtuaalses keskkonnas hostitakse. Peamine on see, et arendaja on keskendunud rohkem rakendusele kui teistele teguritele. Ta on teistest tükkidest ja osadest teadlik, kuid see pole nende jaoks peamine fookus. Nad peavad saama rakenduse võimalikult korrektseks.

Insener on üldnimetus (nagu ka arendaja), kuid tarkvara osas kipuvad nad keskenduma esmalt üldisele keskkonnale ja teisele rakendusele. Kuid see pole raske ja kiire reegel.

Minu jaoks oli selle asja juures võtmeks see, kas insener on tarkvarakontseptsioonide ametliku väljaõppe saanud või on selle lihtsalt lennult õppinud. Olemas on palju keerulisi tabeleid, mille insenerid alustasid. Neil olid algoritmid, kuid nad ei saanud aru (või ei hoolinud), miks tuleks teatud asju teha kindlal viisil (kiiruse või laiendatavuse huvides). Need võivad olla hiilgavad, kuid rakendust oli äärmiselt keeruline hooldada.

Minu eelistus oli ehitada kõigepealt hooldatavuse ja laiendatavuse rakendused ning pärast seda kiirus, kui see oli vajalik. Hooldatavuse esikohale panemisel kulutasin rakendusele vähem aega ja järgmise laiendatavuse tõttu tegin selle parendamise lihtsaks. Seal on vana ütlus: alati saab osta suurema kasti ... (mitte nii, et tingimata tahetakse).