-
Opušteno
(
http://www.devprotalk.com/forumdisplay.php?f=16)
Heh 10 saveta koje ne treba da pratite
|
| bluesman |
27. 02. 2006. 12:36 |
Procitah prva 2, vec sa drugim se totalno ne slazem, mrzi me da citam dalje :)
|
| zextra |
27. 02. 2006. 14:30 |
Napomena: ako ste konzervativni, ne citajte tekst. |
| ivanhoe |
27. 02. 2006. 16:33 |
da, i meni je taj 2-gi upao u oci, a ima jos par bisera (recimo ono za komentare, sto je obicno lupetanje) , mada ima i par "pravila" sa kojima se slazem, npr. da su globalne i singltoni (skoro) isti qrac...
|
| kaizen |
27. 02. 2006. 17:17 |
Verujem da argument uz kritiku nikome ne bi smetao. Zamislite da je autor tog teksta samo citirao te savete i pored njih napisao - "ne slažem se", "lupetanje" i slično.
Ja bih se složio sa većinom stvari koje je napisao, osim što mislim da je kod Saveta br.5 promašio temu. Objekat ponekad i mora da daje informacije o svom stanju i tada je savet koji on kritikuje savršeno primeren. A on kritikuje OO dizajn kod kojeg objekat otkriva previše informacija o sebi, što nema nikakve veze sa savetom.
|
| bluesman |
27. 02. 2006. 18:11 |
Citat:
Originalno napisao zextra
Napomena: ako ste konzervativni, ne citajte tekst.
|
Jesi ti zato trazio taj bbkod da mozes da podjebavas? :)
Sta konzervativni? Pa procitaj malo tekst i razmisli o tome, ne uzimaj zdravo za gotovo. Covek prica da je komentarisanje koda bez veze, prica Exceptions su sranje ako ih ne catch-ujes... Pa i auto je sranje ako ne znas da vozis.
Glupo je i komentarisati ovaj "don't do" : 9) Use unsigned integers for values that can only be positive
Nije dovoljno samo mislite "drugacije", nego je potrebno i da si u pravu kada iznosis svoje misljenje. |
| kaizen |
27. 02. 2006. 19:02 |
Citat:
Originalno napisao bluesman
Covek prica da je komentarisanje koda bez veze,
|
Čovek to ne priča. Savet glasi: Write lots of comments. Dakle akcenat je na količini a ne na komentarima.
Citat:
Originalno napisao bluesman
prica Exceptions su sranje ako ih ne catch-ujes...
|
Mislim da ga opet nisi razumeo. Kritikuje Joelov pogled na izuzetke i njihovu alternativu - vraćanje error codea.
Citat:
Originalno napisao bluesman
Glupo je i komentarisati ovaj "don't do" : 9) Use unsigned integers for values that can only be positive
|
"Top Ten of Programming Advice to NOT follow" je naslov. Po ovome "don't do" vidim da si pogrešno shvatio članak. Autor ne kaže da treba raditi suprotno od saveta koje kritikuje već da se treba rukovoditi drugim principima, i nudi neke (koje btw nije on smislio). |
| Ilija Studen |
27. 02. 2006. 19:15 |
Citat:
Originalno napisao bluesman
Nije dovoljno samo mislite "drugacije", nego je potrebno i da si u pravu kada iznosis svoje misljenje.
|
Slažem se u potpunosti. U ovom tekstu ima pametnih... Doduše, prvi put kad sam ga čitao zvučao mi je jako čudno jer sam ga čitao kao niz DO saveta, ne ka niz DON'T saveta. |
| ivanhoe |
27. 02. 2006. 20:20 |
Citat:
Originalno napisao kaizen
Čovek to ne priča. Savet glasi: Write lots of comments. Dakle akcenat je na količini a ne na komentarima.
|
pa nije bas tako, on kaze "If you feel the need to write comments in your code, I suggest you try to refactor instead, so comments won't be needed."
prica o kodu koji je "self-explanatory" je mit i totalno je subjektivna stvar, jer ono sto je meni jasno, tebi moze skroz da se ne uklopi u nacin razmisljanja... jedan covek ima C background, drugi VB, treci Perl, daj im isti zadatak u php-u i garantovano ces dobiti 3 razlicita pristupa resenju...pa jos uvedi u jednacinu razlicite nivoe znanja, razlicite licnosti i sl. i dobices gomilu varijacija na temu... komentari su spas za to...
a cak i najjasniji kod na svetu je jos jasniji ako imas i komentar pride i ustedeci ti bar 1 milisekundu u provaljivanju koda... mislim, zaista ne vidim situaciju u kojoj komentari mogu da smetaju nekome ? Naravno da treba pisati jasan i jednostavan kod, ali ne vidim to kao nesto suprostavljeno komentarima...treba raditi i jedno i drugo... |
| kaizen |
27. 02. 2006. 21:11 |
Citat:
Originalno napisao ivanhoe
pa nije bas tako, on kaze "If you feel the need to write comments in your code, I suggest you try to refactor instead, so comments won't be needed."
|
... što smanjuje količinu komentara! Komentari su negde nezaobilazni(intefejsi, biblioteke koda, izuzeci, komplikovani algoritmi...)
Citat:
Originalno napisao ivanhoe
prica o kodu koji je "self-explanatory" je mit i totalno je subjektivna stvar, jer ono sto je meni jasno, tebi moze skroz da se ne uklopi u nacin razmisljanja... jedan covek ima C background, drugi VB, treci Perl, daj im isti zadatak u php-u i garantovano ces dobiti 3 razlicita pristupa resenju...
|
Hm, ja nekome ko nema php background i ne poznaje standardne php idiome, nikada ne bih dao da nešto uradi u phpu.
Citat:
Originalno napisao ivanhoe
a cak i najjasniji kod na svetu je jos jasniji ako imas i komentar pride i ustedeci ti bar 1 milisekundu u provaljivanju koda...
mislim, zaista ne vidim situaciju u kojoj komentari mogu da smetaju nekome ?
|
Problem sa nepotrebnim komentarima je:
1. troše vreme i energiju onome koji programira, a njih bi bilo bolje potrošiti na drugim, važnijim stvarima, kao npr. refactoring, testovi...
2. moraju se održavati sa promenama koda, pa se opet vraćamo na 1.
3. i najvažnije: ako se zaboravi 2. postaće out-of-sync što može potrošiti dosta vremena onome koji posle bude koristio taj kod |
| bluesman |
27. 02. 2006. 21:15 |
Citat:
Originalno napisao kaizen
Čovek to ne priča. Savet glasi: Write lots of comments. Dakle akcenat je na količini a ne na komentarima.
|
Očigledno nisi pročitao dobro. Njegov akcenat je tu na WHY a ne WHAT, i sa tim se slažem. Nije dovoljno napisati komentar "šta radiš", jer to svako ko ume da čita kod, ume i da rastumači. Slažem se sa tim da treba napisati "ZAŠTO" to radi.
Evo recimo primera. Za vikend sam radio jedan script za slanje SMS-a preko nekog austrijskog provajdera. I naravno, vidim u script (koji sam BTW ja radio pre 6 meseci) da stoji ovako:
PHP kôd:
$sms_text = utf8_decode($_POST['text']);
I sada, NIkome to nema logike, zašto bih slao sa UTF-8 strane tekst koji prvo utf8 dekodiram. Međutim stoji komentar pored da sam provajder konvertuje u UTF-8 (što gotovo niko ne radi već šalje "AS IS") i da jedino ako pošaljem dekodiran tekst, korisnik dobije ispravno nemačke karaktere ü i slično... Tako sam uštedeo vreme mozgajući zašto je to tako nelogično urađeno.
U tom slučaju ništa ne bi pomogao komentar "Ovde dekodiram utf8 string" već "Ovo mora tako zato što provajder ...".
Ja bih mogao i da se složim da ne treba pisati Lots of comments, jer čak i previše komentara smanjuje preglednost, ali to je u onom tekstu najmanji problem.
Citat:
Originalno napisao kaizen
"Top Ten of Programming Advice to NOT follow" je naslov. Po ovome "don't do" vidim da si pogrešno shvatio članak. Autor ne kaže da treba raditi suprotno od saveta koje kritikuje već da se treba rukovoditi drugim principima, i nudi neke (koje btw nije on smislio).
|
Ne razumem te, na osnovu čega si ti shvatio da sam ja to pogrešno shvatio? Ali nebitno... |
| kaizen |
27. 02. 2006. 22:55 |
Citat:
Originalno napisao bluesman
Očigledno nisi pročitao dobro. Njegov akcenat je tu na WHY a ne WHAT, i sa tim se slažem. Nije dovoljno napisati komentar "šta radiš", jer to svako ko ume da čita kod, ume i da rastumači. Slažem se sa tim da treba napisati "ZAŠTO" to radi.
|
Ja jesam dobro pročitao članak. Pričao sam o "akcentu" saveta, jer si ti njegovu kritiku tog saveta(Write lots of comments), iskomentarisao sa "Covek prica da je komentarisanje koda bez veze". Ja sam ti samo skrenuo pažnju koji deo tog saveta je problematičan. Dakle nije problem u komentarima, nego u količini komentara.
Ali dobro, sada vidim da si promenio prvobitno mišljenje pa ne vidim potrebu da se dalje ubeđujemo oko ovoga. |
| Milos Vukotic |
27. 02. 2006. 23:01 |
A na prvom mjestu, covjek "obara" savjet "Design first, then code". Ajde!?
Rezime onog sto je rekao mogao bi da se prevede u zidarsko/gradjevinarsku terminologiju ovako: "Nije tacno da morate prvo imati detaljan plan kuce koju treba zidati, dovoljno je da malo razmislite i pocnete nabacivati cigle, lijepa kuca ce doci sama od sebe". Slazem se da ne treba cjepidlaciti i trositi vrijeme na razmisljanje o dezenu plocica u kupatilu, ali ici u drugu krajnost i jos praviti savjet No 1. od toga... :-|
|
| zextra |
27. 02. 2006. 23:55 |
@blues: Joj sto bi bilo lepo citirati sve postove odjednom, bas mi fali ta opcija :)
Kroz ceo tekst se provlace ideje ekstremnog programiranja, pa su i saveti u skladu sa tim principima. Izmedju ostalog, podrazumeva se jednostavnost gde god je to moguce, refaktorisanje...
Pod konzervativnim nacinom programiranja smatram dobar deo saveta koje je on pokusao da opovrgne, a koji su uobicajena programerska praksa (komentarisanje zamrsenog koda recimo). Treba imati u vidu kontekst u kom on govori o odredjenim stvarima (konkretno br. 9 - smisao nije bas nikako ne koristiti unsigned int varijable, vec koja je poenta koristiti ih tamo gde nije moguce imati bilo kakvu korist od istih, u odnosu na signed int; konkretna korist je bacanje exception-a u njegovom slucaju).
@all: ako neko vec nije, neka procita tekst na koji se autor linkuje na kraju saveta br. 1, tekst govori o ekstremnom programiranju.
|
| bluesman |
27. 02. 2006. 23:55 |
Kaizen, nisam promenio mišljenje. Ti stalno vidiš negde nešto što ja nisam rekao. Ali nebitno.
|
| Ilija Studen |
28. 02. 2006. 00:29 |
Miloše, mislim da je savet br 1. sa kojim se ne slažeš možda najbolji savet u celom tekstu. On isključuje "školske" specifikacije koje uzimaju znatno više vremena od pisanja samog koda.
Citat:
You should think before you code. Go ahead, but think for hours, not days. Don't kid yourself into believing you can sketch an entire design document with UML diagrams and everything without making mistakes. At least, don't think you can do so any faster than you could have simply written the code.
|
I naravno:
Citat:
Short iterations, automated testing and frequent refactoring being the most important.
|
|
| Milos Vukotic |
28. 02. 2006. 07:56 |
Ilija, jednostavno se ne slazem :)
XP tj. extreme programming metode po kojima se prvo pisu testovi, zatim pravi cijeli program u uproscenoj varijanti su sasvim ok, ali bez dizajna se ne moze. Ne kazem ni ja da uml-ovati sve do detalja poput Help->About, ali blueprint je neophodan. Ja obicno skrabam na papiru, kruzim i krizam, ali mi je mnogo lakse kodirati kad znam kuda idem :)
Evo ti citat iz knjige "Code complete" od Steve McConnell-a:
Citat:
The image of “building” software is more useful than that of “writing” or“growing” software. It’s compatible with the idea of software accretion and provides more detailed guidance. Building software implies various stages of planning, preparation, and execution that vary in kind and degree depending on what’s being built.
When you explore the metaphor, you find many other parallels.
Building a 4-foot tower requires a steady hand, a level surface, and 10 undamaged beer cans. Building a tower 100 times that size doesn’t merely require 100 times as many beer cans. It requires a different kind of planning and construction altogether.
If you’re building a simple structure—a doghouse, say—you can drive to the lumber store and buy some wood and nails. By the end of the afternoon, you’ll have a new house for Fido. If you forget to provide for a door or make some other mistake, it’s not a big problem; you can fix it or even start over from the beginning. All you’ve wasted is part of an afternoon.
This loose approach is appropriate for small software projects too, If you use the wrong design for 1000 lines of code, you can refactor or start over completely without losing much. If you’re building a house, the building process is a more complicated, and so are the consequences of poor design. First you have to decide what kind of house you want to build—analogous in software development to problem definition. Then you and an architect have to come up with a general design and get it approved. This is similar to software architectural design. You draw detailed blueprints and hire a contractor. This is similar to detailed software design. You prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is similar to software construction. When most of the house is done, the landscapers and painters come in to make the best of your property and the home you’ve built. This is similar to software optimization.
...
Greater complexity and size imply greater consequences in both activities. In building a house, materials are somewhat expensive, but the main expense is labor. Ripping out a wall and moving it six inches is expensive not because you waste a lot of nails but because you have to pay the people for the extra time it takes to move the wall. You have to make the design as good as possible so that you don’t waste time fixing mistakes that could have been avoided. In building a software product, materials are even less expensive, but labor costs just as much. Changing a report format is just as expensive as moving a wall in a house because the main cost component in both cases is people’s time.
|
:1042: |
| kaizen |
28. 02. 2006. 09:43 |
Citat:
Originalno napisao bluesman
Kaizen, nisam promenio mišljenje. Ti stalno vidiš negde nešto što ja nisam rekao. Ali nebitno.
|
Evo ti citati. Svi su tvoji, iako mogu da se čitaju kao diskusija s obzirom da si drugi put malo bolje pročitao šta je čovek napisao.
Citat:
Covek prica da je komentarisanje koda bez veze
|
Citat:
Očigledno nisi pročitao dobro. Njegov akcenat je tu na WHY a ne WHAT, i sa tim se slažem.
|
Citat:
Ja bih mogao i da se složim da ne treba pisati Lots of comments, jer čak i previše komentara smanjuje preglednost
|
|
| kaizen |
28. 02. 2006. 10:05 |
Citat:
Originalno napisao Milos Vukotic
Ilija, jednostavno se ne slazem :)
XP tj. extreme programming metode po kojima se prvo pisu testovi, zatim pravi cijeli program u uproscenoj varijanti su sasvim ok, ali bez dizajna se ne moze. Ne kazem ni ja da uml-ovati sve do detalja poput Help->About, ali blueprint je neophodan. Ja obicno skrabam na papiru, kruzim i krizam, ali mi je mnogo lakse kodirati kad znam kuda idem :)
|
On kaže:
"You should think before you code. Go ahead, but think for hours, not days."
Pošto se ti ne slažeš sa njim da li to znači da ti danima dizajniraš?
Citat:
Originalno napisao Milos Vukotic
Evo ti citat iz knjige "Code complete" od Steve McConnell-a:
|
Uvek su mi bile smešne te metafore gde za programiranje uzimaju priče iz građevine, umetnosti i sl. Ako bi neko mogao da me uputi, koje su to sličnosti programiranja i tih delatnosti? |
| Milos Vukotic |
28. 02. 2006. 10:16 |
Programiranje je, sustinski, inzinjerski posao, tako da se mogu povuci analogije izmedju svih poslova koje rade inzinjeri. Dobijes zadatak, shvatis sto i kako treba da se radi i odradis to.
Za analogije s umjetnoscu ne samo sto ne znam vec se i unaprijed ne slazem s takvim analogijama... :)
|
| Gruja |
28. 02. 2006. 10:51 |
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
| kaizen |
28. 02. 2006. 11:20 |
Citat:
Originalno napisao Gruja
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
Lepo rečeno. |
| dinke |
28. 02. 2006. 11:25 |
Evo i ja da se ukljucim u ovu nadasve interesantnu diskusiju :)
Da budem iskren, ne slazem se sa vecinom "saveta" koje je ovaj lik naveo. Ajmo redom:
10) Use exceptions
Slazem se sa svim navedenim. Uopste ne razumem sta je Joel sa onim tekstom hteo da kaze.
9) (Don't) Use unsigned integers for values that can only be positive
Neki jezici zaista ne omogucavaju definisanje unsigned vrednosti (PHP, Java), ali tamo gde je to jezikom omoguceno (C/C++) treba ga koristiti. Ne samo da se tako kreira robusniji kod, vec se stedi i memorija. Mozda nebitno za danasnje programe, ali kod baza nije isto koristiti big int kada recimo int unsigned zavrsava posao (veca tabela = sporija tabela).
8) (Don't) Design classes parallel to their physical counterparts
Takodje se apsolutno slazem sa ovom tvrdnjom, narocito sa delom da je inheritance "overrated". Licno sam vidjao neke PHP bibliotete gde je klasa koju koristim "10-to koleno" od osnovne klase. Mislim da bi svi pocetnici u OOP dizajnu trebalo da malo citaju Bruce Eckela, koji jednostavno savetuje koriscenje kompozicije kad god niste sigurni da li koristiti nasledjivanje ili kompoziciju. car have engine, car is not engine.
7) (Don't)Make sure your team shares a common coding standard
Ocigledno da autor teksta nikada nije morao da edituje fajl na kome su radila 3 programera gde je svako koristio sopstveni koding standard. Sto se mene tice pravila su sledeca:
- Postoji definisan koding standard za celu kompaniju ili je deo specifikacije projekta
ili
- (losije resenje) Svaki developer koristi svoj stil ali se prilikom izmena vec napisanog koda postuje standard koriscen u fajlu (na taj nacin barem nemas 3 stila u jednom fajlu)
6) (Don't)Write lots of comments
Komentare treba pisati, tamo gde je to potrebno. Dakle ne:
//incrementing i
i++;
nego
//moving to next element
i++;
i sl.
Inace, ja narocito insistiram na kreiranju API dokumentacije, pa je phpdocumentor stil komentara (pandan javadoc kod Jave) standardni deo koding specifikacije koju sam pominjao gore.
5) (Don't)Use accessors or properties rather than public fields
Ovo je vec jeres :) Necu ni da komentarisem :)
|
| Milos Vukotic |
28. 02. 2006. 11:38 |
Citat:
Originalno napisao Gruja
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
To se moze reci i za sve discipline koje se ticu rjesavanja problema. Sve izuzev prava. |
| Ilija Studen |
28. 02. 2006. 11:38 |
Poenta saveta br1 je da se ne trudiš da sve živo smisliš unapred, već da razmisliš, nažvrljaš neke osnovne beleške sebe radi na papir i kreneš da radiš. To je mnogo brže nego da razmisliš i posvetiš X dana na razradu kompletnog dizajna na papiru (koji može i da ne radi jer si propustio nešto izuzetno bitno).
Ako si disciplinovan programer i imaš kvalitetne igračke lako možeš da izađeš na kraj i sa izuzetno kompleksnim promenama na sistemu za relativno kratko vreme. Samo su od toga napravili bauk...
---------------
Što se 5tice tiče meni se izuzetno sviđa Ruby koji polja maskira sa accessorima. Npr:
Kôd:
car.max_speed = 250;
print car.max_speed;
Iza ovga stoje sledeći accessori:
Kôd:
class Car
def max_speed
@max_speed
end
def max_speed=(new_value)
@max_speed = new_value
end
end
Postoji i pojednostavljenje za pisanje accessora, ali ovo je samo kao primer. |
| ivanhoe |
28. 02. 2006. 15:23 |
po meni accessori imaju smisla samo ako se unutar njih vrse neke provere vrednosti, formatiranje podataka, hvataju exceptioni ili tako nesto.. ako imas setter koji samo uradi property=value i nista drugo, koji mu je onda smisao? (a to se vrlo cesto vidja po raznim bibliotekama...)
|
| Petar Marić |
28. 02. 2006. 15:33 |
Amen.
Accessor abstrahuje pristup class member-u da se objekat ne bi doveo u nedozvoljeno/neodređeno stanje.
|
| Ilija Studen |
28. 02. 2006. 16:25 |
Svež primer. Imam reklamnu kampanju koja ima vlasnika. Tokom prvog dela razvoja owner_name je bio varchar polje koje je sadržalo samo ime jer je to bilo dozvoljno da bi se zadovoljila prva specifikacija (owner_name je korišćen samo za statistike). Međutim, tokom rada sam došao do toga da mi owneri trebaju odvojeno pošto se na osnovu njih vrše neke druge kalkulacije (potreba da se globalni cenovnik zameni cenovnikom na nivou vlasnika i slične stvarčice). Izmena je bila veoma jednostavna:
PHP kôd:
// Stari kod
class Campaign {
/**
* Return owner name
*
* @return string
*/
function getOwnerName() {
return $this->columnValue('owner_name');
}
}
// Novi kod, sitna izmena
class Campaign {
/**
* Return owner object
*
* @return CampaignOwner
*/
function getOwner() {
return CampaignOwners::findById($this->getOwnerId());
}
/**
* Return owner name
*
* @return string
*/
function getOwnerName() {
if($this->getOwner() instanceof CampaignOwner) {
return $this->getOwner()->getName();
} else {
throw new Exception('Owner is missing');
}
}
}
Da sam sve vreme tretirao owner_name kao klasično polje i pristupao mu sa $this->owner_name postojeći kod bez većih izmena ne bi mogao da odgovori na nove zahteve.
Accessori? Uvek! |
| bojan_bozovic |
04. 03. 2006. 14:28 |
Citat:
On kaže:
"You should think before you code. Go ahead, but think for hours, not days."
Pošto se ti ne slažeš sa njim da li to znači da ti danima dizajniraš?
|
Tako moze u perlu da se zvrlja. Molim, program u C++ ne mozes da napravis a da prvo ne dizajniras sve. Najobicniji search&replace u tekst editoru da napises - algoritam za search&replace moras da imas gotov. Sto se saveta tice, veze nemaju sa zivotom. |
| kaizen |
04. 03. 2006. 18:00 |
Citat:
Originalno napisao bojan_bozovic
program u C++ ne mozes da napravis a da prvo ne dizajniras sve.
|
Ma daj. Je si li ti uopšte c++ programer?
Citat:
Originalno napisao bojan_bozovic
Sto se saveta tice, veze nemaju sa zivotom.
|
Zašto nemaju veze sa životom? |
| kaizen |
04. 03. 2006. 18:49 |
Citat:
Originalno napisao dinke
9) (Don't) Use unsigned integers for values that can only be positive
Neki jezici zaista ne omogucavaju definisanje unsigned vrednosti (PHP, Java), ali tamo gde je to jezikom omoguceno (C/C++) treba ga koristiti. Ne samo da se tako kreira robusniji kod, vec se stedi i memorija. Mozda nebitno za danasnje programe, ali kod baza nije isto koristiti big int kada recimo int unsigned zavrsava posao (veca tabela = sporija tabela).
|
Možda su ti poznati ovi citati:
Citat:
Originalno napisao Donald Knuth
premature optimization is the root of all evil
|
Citat:
Originalno napisao Michael Jackson
The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.
|
Naravno, ponekad nerazmišljanje o optimizaciji na vreme može skupo koštati, ali ovaj primer sa unsigned vrednostima je savršen primer kada je potpuno neopravdano razmišljati o ranoj optimizaciji - ako se pokaže da je signed vrednost uzrok problema sa performansama, promeniti ga u unsigned i gotovo.
Citat:
Originalno napisao dinke
//moving to next element
i++;
|
Ja zaista ne vidim vrednost u komentaru koji si ovde demonstrirao.
Ako negde - liniju, dve ispred toga pocinje opseg za i, i za dve tri linije iza se zavrsava, i tu izmedju postoji nesto tipa foo = bar[i], zar u tom slucaju nije ocigledno, cak i pocetniku, sta se postize sa i++? |
| ivanhoe |
04. 03. 2006. 19:44 |
po meni komentar treba da opise sta se desava u logicki povezanim delovima koda, tako da bez provaljivanja koda mozes da nadjes deo koji ti treba, cisto gledajuci komentare...kao naslovi i podnaslovi u knjigama, i to, kao sto je Dinke napisao, opis funkcionalnosti, a ne opis koda...mislim da se na to odnosio primer, a ne da li je jasno da je sledeci element u pitanju...
|
| Petar Marić |
04. 03. 2006. 19:45 |
Moram se složiti sa Bojanom. U C++-u je attack programming možda i moguć, ali kako vreme prolazi rad sa tim kodom postaje sve manje i manje prijatan - što sam saznao na teži način ;)
|
| kaizen |
04. 03. 2006. 20:01 |
Citat:
Originalno napisao Petar Marić
Moram se složiti sa Bojanom. U C++-u je attack programming možda i moguć, ali kako vreme prolazi rad sa tim kodom postaje sve manje i manje prijatan - što sam saznao na teži način ;)
|
Šta je attack programming? |
| bojan_bozovic |
04. 03. 2006. 20:24 |
@kaizen
Bio sam C/C++ programer. Srecno sa algoritmima koje razvijas u letu, kad sednes pred IDE.
|
a tako mi nije namera bila da napravim ovaj flame war kad sam otvarao ovu temu ...
|
| kaizen |
04. 03. 2006. 21:11 |
Citat:
Originalno napisao bojan_bozovic
@kaizen
Bio sam C/C++ programer. Srecno sa algoritmima koje razvijas u letu, kad sednes pred IDE.
|
Možda će ovo biti šok za tebe, ali algoritmi danas nisu problem u razvoju ogromne većine softvera. Mnogi sistemi koriste iste algoritme, koji su poznati i dobro dokumentovani, pa čak i ponovo iskoristivi u vidu biblioteka kooda. Takođe alogoritmi imaju dobru podlogu u matematici i mogu se potpuno formalizovati.
Ovde uopšte nije reč o dizajnu algoritama, nego dizajnu softvera kao sistema(velikog), tačnije dizajnu veza(interfejsa) njegovih elemenata, najgrublje govoreći. |
| Petar Marić |
05. 03. 2006. 10:06 |
Većina softvera danas čak ne stigne ni da vidi svetlo dana.
IIRC pre neki dan smo na osnovama informacionih sistema i softverskog inženjerstva spominjali razlog neuspeha u razvoju softvera:
Po istraživanju koje je vođeno pre više od 10 godina (današnji podaci su još pesimističniji) od svih softverskih projekata koji su propali u oko 10% slučajeva razlog je bio nedostajanje (čak i neformalnog) plana razvoja - aka Attack Programming™.
|
| Ilija Studen |
05. 03. 2006. 12:22 |
Naleteo sam na savet da se preskoči pisanje komentara na još jednom mestu. U pitanju je knjiga Refaktorisanje, Martin Fowler (nisam ni znao da je prevedena na srpski dok slučajno ne naleteh na nju, bukvar :) ).
Fowler savetuje da kad god poželite da napišete komentar koji opisuje rad nekog koda razmislite da taj isti blok prebacite i od njega napravite funkciju. Vi na taj način izolujete ponašanje u funkciju koja ima ime (opusuje šta će funkcija "proizvesti", uraditi isto kao i sam komentar). Finalni kod je lakši za čitanje, nije masivan (mi volimo kratke funkcije) i bolje organizovan.
---
Petre, pogledaj tekstove o agilnom razvoju. Ne kažem da treba srljati i bez sekunda razmišljanja otvarati editor i početi sa kucanje (što mi se dešavalo), ali ne treba težiti ni drugoj krajnosti. U suštini, koliko vremena ćeš posvetiti dizajnu zavisi od tvog iskustva i iskustva ljudi sa kojima sarađuješ (što više iskustva, manje "papirologije").
Preveliko formalisanje jednostavno nije dovoljno fleksibilno. To skontaš kad počneš da radiš sa kiljentim i kad prvi put čuješ "A može li to ovako?" što ruši kompletan tvoj divni dizajn ili te tera da praviš prljave hackove da bi ugradio traženu funkcionalnost. Agilan pristup je prilagođen baš tim uslovima (mnogo sitnih izmena, konstantan feedback od korisnika / klijenta, testiranje...) ;)
---
Nixa, ne svađamo se. Možda tako izgleda ljudima koji nisu najbolje upućeni u programiranje, ali daleko od toga. Jedna od boljih diskusija IMO.
|
| Petar Marić |
05. 03. 2006. 12:52 |
Ilija, s obzirom da još uvek učim o tome ne mogu imati potpuno izgrađen (a ispravan) stav o određenim metodologijama ne bih ulazio u detaljniju diskusiju o prednostima/manama agile/waterfall/* metode.
Mada ti mogu savetovati da dolaziš kod Perišića na predavanja, čovek je genijalan! Pun znanja, odlično objašnjava i fenomenalan predavač.
PS: Kad bih mogao da ti "ukradem" Fowler-a?
|
| Vreme je GMT +2. Trenutno vreme je 16:36. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
