Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

HAVOC'S BLOG



Šta Je Bitno U Programiranju Softvera


havoc

Mnogo je saobraćaja na Twitter-u je o Steve Yegge-ovom postu koj definiše spektar "ideologije softvera". Myles Recny je sproveo istraživanje kako bi vam pomogao da pronađete svoje mesto u pomenutom spektru.

Razmišljajući o tome tokom vikenda, ne mogu da identifikujem sa ovim uokviravanjem softverskog programiranja. Ona anketna pitanja čini se da ne pokrivaju ono o čemu većinom mislim u mom vlastitom radu sa softverom; u stvari, bio bih malo zabrinut kada bih video da su kolege fokusirane na nešto od ovoga.

Evo što ja mislim o nečemu, što bi se moglo nazvati ideologijom

Ideološki Pregled 1: Rizik = Prosečno Pogoršanje
Bilo da govorimo o dijetama, finansijama, ili softveru, protoci su bitniji od akcija.

Rizik zbog kog brinem je: dodajete li greške brže nego što ih sređujete? Da li vaša tehnička zaduženost raste? Da li se ovaj kod pogoršava u proseku?

Ako je prosečan smer "gori" onda će pre ili kasnije vaš kod biti nerazumljiv, beznadna katastrofa koju niko neće hteti da dodirne. Rizik je silazak u neodržavani haos u kojem svi koji su uključeni mrze svoj ​​život i softver prestaje da se poboljšava. Bio sam tamo na posmrtnom maršu!

Nedostaci protiv Karakteristika: Kontekstualno Pitanje!
U svom postu Steve kaže da su konzervativci usmereni na sigurnost (greške u proizvodnji), dok su liberali usmereni na karakteristike. Nemam ideološki pogled na "greške u riziku proizvodnje", to je zavisno od teksta.

Na primer: Red Hat održava i Fedore i Enterprise Linux, dve grane istog softverskog projekta sa uglavnom istim timom, ali sa jasnim "greške u proizvodnji " profilima rizika i jasnim procesima kako bi se slagale. Red Hat koristi isti kod i iste ljude da bi podržao različite kompromise u različitim kontekstima. Možda su oni post-dobrovoljna kompanija?

Da sam ja radio na softveru za Marsovog rovera, ja bih se energičnije protivio kontinuiranom razvoju.(Možda bismo trebali da testiramo tu nadradnju softvera pre nego što je pošaljemo na Marsu?) Da sam radio na I Can Has Cheezburger,greške u proizvodnji mi ne bi smetale mnogo, tako da bih bio srećan kada bi proces održao laganim.

Ali u u oba slučaja ne želim da vidim da se kod pogoršava u proseku, pošto bih želeo u oba slučaja da održim u životu taj kod tokom godina. To je ideologija koja ostaje konstanta.

Projekt koji se pogoršava u prosjku neće ostvariti ni sigurnost ni mogućnosti. Zdrav projekt mogao bi imati oboje (iako ne u istoj struji objavljivanja)

Kako Izbeći Pogoršavanje
Da bi izbegli rizik od stalnog pogoršavanja, par pitanja se pojavi svaki put2:.

Ideološki Pogled2: Jasnoća i Jednostavnost Su Dobre
Može li Tim to da razume?

To je vezano za vaš tim. Ako vaš tum ne zna jezik XYZ ne možete pisati kod u tom jeziku. Ako je vaš API namenjen mainstream, opštim programerima, može biti pun Ničeovog žargona. Ako vaša tim ne govori nemački, ne možete pisati svoje komentare na nemačkom jeziku. Itd

Programeri softvera uče kako da naprave odlučujuće pozive o složenosti i nad-protiv pod-inženjeringa. Ovi pozivi su bezbrojni, kontekstualni, i uvek o ustupcima. Pitanja iskustva.

Definicija "kompetentnog programera softvera" sigurno uključuje:

  • da oni brinu o složenosti i mogu donositi odluke o tome kada se to isplati
  • mogu pisati i prozu i kod na takav način da ih ostatak ekipe razume


Nemaju svi timovi isti složen kapacitet, ali svi oni imaju neke granice, a oni dobri koristite ga mudro.

Ideološki Pogled 3: Proces: Imam Jedan
Video sam mnoge različite metodologije i procese rada. Optimiziraju se za različite timske veštine, ili za različite nivoe rizika"greške u proizvodnji". Moje uverenje je da vam treba neki način na vaše ​​ludilo, nešto drugačije od besplatno-za-sve. Primeri:

  • Dobar jedinični test pokrivanja sa obveznom pokrivenošću za novi kod.
  • ILI hardass kod ocena (Hardass = recenzent troši puno vremena, a većina zakrpa je teško bila revidirana najmanje jednom. Većina ocena neće biti "izgleda mi dobro.")
  • Ili samo jedan programer na codebase-u dovoljno malom da se čuva u jednoj glavi.
  • ILI Joel-ov pristup.


Ne treba vam sve to, ali vam treba barem jedna stvar kao što je to.Mora postojati neka dnevna navika ili strukturna postavka koja se suprodstavlja entropiji, bez obzira koliko su pametni pojedini članovi tima.

Kompanije mogu imati kulture bazirane na pravilu ili poverenju, i odabrati različite procese. Mnogo različitih pristupa može da funkcioniše.

Sažetak
Ideološke misli zapisane u pesku uokviruju moje mišljenje o razvoju softverazvoju

  • Rizik = projekat postaje tvrdoglav.
  • Preduslov da se izbegne rizik: Morate biti razumljivi i shvaćeni.
  • Proces za izbegavanje rizika: Imajte jedan i držite ga se.


Ako možete napisati jasan, održivi kod, i čuvati ga na taj način, koristeći svoj ​​OS, tekst editor, dinamičan jezik, statički jezik, XML-konfigurisan okvir, brz proces, ili šta god, onda sam otvoren za vaš pristup.

Ako stvarate složenost koja se ne isplati, ne dajući ikakav smisao ostatku ekipe, nemate radni proces, itd. onda sam ja protiv toga.

"Koliko grešaka u proizvodnji je u redu "," statički protiv dinamičkih jezika "," da li nam je potrebna spec. za ovo "," da li nam je potrebna šema ovde "," Kako da nazovem ovu funkciju ": to su pragmatičn, zavisna od konteksta pitanja. Sviđa mi se da ih razmatram slučaj po slučaj

Postskriptum:Ja ja ja
Mnogi od ovih primera "liberalno/konzervativno" izjava odaju utisak da su podstaknute egom. Izgledao bih loše ako dostavimo grešku, pametan sam i mogu da naučim, nikada ne pišem spor kod, uvek pišem mali kod, bla, bla.

Ne radi se o tebi.

Kada se slažete ili ne slažete sa "programeri su samo po;etnici neko vreme"-da li razmišljate o stvaranju softvera kao o IQ testu za programere? Cilj je ne "dumb down" kod ili da se dokaže da vama to ne treba.

Dopustite mi da predložim bolji okvir: Da li je ova složenost vredna toga (u kontekstu naših kupaca i našeg tima). Ako nastojimo maksimalno da uvećamo korisnost našeg softvera i naš tim može da se nosi sa određenim nivoom složenosti, trebamo li koristiti naše moždane vijuge u ovom delu koda ili nekom drugom delu?

Kada se slažete ili ne sa "softvera treba težiti da bude bez grešaka pre nego što se pokrene "-imate li isto mišljenje i o Mars lender-u i icanhascheezburger? Ako imate,možda ćete trebati da se preusmerite na spoljašnji svet koji bi naš softver trebao da opslužuje.




Published (Last edited): 06-12-2012 , source: http://blog.ometer.com/2012/08/13/what-matters-in-software-development/