Heh 10 saveta koje ne treba da pratite

[bluesman]

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.

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]

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]

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]

@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]

Kaizen, nisam promenio mišljenje. Ti stalno vidiš negde nešto što ja nisam rekao. Ali nebitno.

[Ilija Studen]

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.

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:

Short iterations, automated testing and frequent refactoring being the most important.

[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
Evo ti citat iz knjige "Code complete" od Steve McConnell-a:

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.

[kaizen]

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.

Covek prica da je komentarisanje koda bez veze

Očigledno nisi pročitao dobro. Njegov akcenat je tu na WHY a ne WHAT, i sa tim se slažem.

Ja bih mogao i da se složim da ne treba pisati Lots of comments, jer čak i previše komentara smanjuje preglednost

[kaizen]

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š?

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]

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...