Joel: But, I feel like if a team really did have 100% code coverage of their unit tests, there'd be a couple of problems. One, they would have spent an awful lot of time writing unit tests, and they wouldn't necessarily be able to pay for that time in improved quality. I mean, they'd have some improved quality, and they'd have the ability to change things in their code with the confidence that they don't break anything, but that's it.
Ok.. Zgadzam się z powyższym - ale jeśli ktoś ma choć trochę oleju w głowie, zawsze - ale to zawsze - zgodzi się z jakąkolwiek krytyką skrajności. Skrajność jest zła !! ZŁAAAA! "Being extreme is evil and wrong. EOF" - to idealna odpowiedź, dyskusja z głupotą ją nobilituje..
But the real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests. Sometimes you will make a change to your code that, somehow, breaks 10% of your unit tests. Intentionally. Because you've changed the design of something...
Ok.. to ma sens.. zdarzają się zmiany które puszczą z dymem 10% testów jednostkowych. Pomijając fakt, że przy poprawnie napisanych unit testach najpewniej będzie to zmiana archiektury, istotnej dla projektu technologii albo jakaś hiper-istotna zmiana biznesowa - zdarza się.
you've moved a menu, and now everything that relied on that menu being there... the menu is now elsewhere. And so all those tests now break. And you have to be able to go in and recreate those tests to reflect the new reality of the code.
MENU !?! ok.. wtf ? jakie menu ?! testy jednostkowe i menu ? .. no sorry, ale po gościu który jest autorytetem w IT spodziewam się conajmniej zrozumienia róznicy między testami jednostkowymi, a innymi - te też mylę nigdy nie wiem czy testy UI to integracyjne, akceptacyjne czy jakie tam, ale _na pewno_ nie jednostkowe!
So the end result is that, as your project gets bigger and bigger, if you really have a lot of unit tests, the amount of investment you'll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.
Zgadzam się.
Jeff:
I think that's a great point. Although, I do think if you're working on older code bases that don't have a lot of churn, ...
Joel:
Yeah.
Jeff:
To me it's about churn. If you're working on an old code base that isn't going to have that much churn, and you want to change it where you can't break anything, where if you break anything it's really really bad, then it's probably worth your time to go in and develop a bunch of unit tests. You're building scaffolding around this grand old building, this classic old building that's not going to change for another 200 years, so sure, build a bunch of scaffolding around the building.
Ok.. gdyby te testy tam były "in the first place" to byśmy mogli zmienić i mieli spokój. Co więcej napisanie testów do istniejącego kodu - którego nie znasz - jest na moje oko przynajmniej rząd trudniejsze. Oczywiście po raz kolejny ważny jest zdrowy rozsądek, bo trzeba mieć wyczucie kiedy testy pisać bardziej, ile tych testów, umieć wyczuć kiedy implementacja się stabilizuje itp., itd. miałem nie pisać o rzeczach oczywistych - ale jak widać Jeff Atwood albo sobie żartuje albo ich nie rozumie.
Joel:
Yeah. They work really for things like a compiler, where the design is not going to change because the language is fixed.
Ok. To idealnie pokazuje ile wspólnego ma Joel z oprogramowaniem biznesowym :P Kompilator ..
Jeff:
That's right.
Joel:
I might do more black-box tests, sort of like unit tests but more from the perspective of "does this compile all code correctly," with enormous numbers of tests, than just the internal, "does this particular function work in this particular way at all times."
W językach obiektowych mamy metody i to je testujemy. Dla mnie to niesamowicie duża różnica konceptualna bo metody służą do komunikacji między obiektami podczas gdy funkcje obliczają wynik.
Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (That's a real easy-to-Google term!) It's object-oriented design, and they're calling it agile design, which it really, really isn't. It's principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
And here I am ranting against somebody that doesn't have a chance to respond. But just to give you one example, a part of the SOLID principles was that if you write a class, that class has contracts with all the other classes that it interacts with, and those contracts should be expressed in interfaces [PDF]. So you shouldn't just interact with the class, because that class may change. If you have a particular class that you need to use, you should make a custom interface just for what you're going to use in that class. That interface, then, never has to change. And the interface is the only thing that you have to #include.
Does that make sense? So, you've got some class, with 40 different little methods on it, and I'm only going to use six of them, so I should make an interface with those six things that I can use, and the class will implement that interface, and that's my contract with the class, that those are the only six things I'm going to use.
Dla mnie osobiście to podejście Uncle Bob'a brzmi akurat niesamowicie rozsądnie ...
People that say things like this have just never written a heck of a lot of code.
Pozwolę sobie skontrować słowami znanego autorytetu w dziedzinie IT: "People that say things like this have just never written a heck of a lot of code. ".
Because what they're doing is spending an enormous amount of time writing a lot of extra code, a lot of verbiage, a lot of files, and a million little classes that don't do anything and thousands of little interface classes and a lot of robustness to make each of these classes individually armed to go out into the world alone and do things, and you're not going to need it. You're spending a lot of time in advance writing code that is just not going to be relevant, it's not going to be important. It could, theoretically, protect you against things, but, how about waiting until those things happen before you protect yourself against them?
This seems to be where a lot of the Object Oriented Design community went, and if anybody has any strong feelings about this, call in and tell me what you think--tell me if I'm totally off track here--but it seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake. It doesn't seem like you could actually get any code written if you're spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces. They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense.
Ok.. tu zaczynają mnie ponosić emocje i chciałoby się podsumować "Blablablabla". Powiem jedno.. jeśli Joel nie rozumie projektowanie zorientowanego obiektowo to ja straciłem nadzieję w ludzi - albo po prostu on jest dobrze ukrywającym się w przebraniu programisty bardzo dobrym biznesmenem. A już byłem pełen optymizmu gdy na ostatniej konferencji JAOO usłyszałem słowa: "Ludzie [programiści, projektanci, architekci, etc.] zaczynają wreszcie po 30 latach rozumieć o co chodzi w programowaniu obiektowym".
Jeff:
Well, there are places where that level of testing makes sense. If you're working at Microsoft and you're working on the .NET Framework...
M$ SUUUX !!! :P Przepraszam za brak profesjonalizmu ;) Nie mogłem sobie darować :D
Joel:
Yeah.
Jeff:
... you have a totally different set of obligations to your public ...
Joel:
Correct.
Jeff:
... Your code's going to be used millions and millions of times.
W przypadku oprogramowania biznesowego: "Your code's going to be SEEN millions and millions of times."
Joel:
Yeah. In fact, if you're making any kind of API, a plug in API, it is very important to separate things into interfaces and be very very contractual, and tightly engineered. Just like you want to put a lot of effort into your user interface, you also want to put a lot of effort into your API that people are calling... it's just an interface, and you want it to be good and solid and robust. And that's fine.
But this idea that every single class in your code, all these classes interacting with each other, should be so tightly defined ...
Listening to this interview on Hanselminutes, there seemed to be an intense obsession with creating lots and lots of little classes that all did one particular thing...
One of the SOLID principles, and I'm totally butchering this, but, one of the principles was that you shouldn't have two things in the same class that would be changed for a different reason [PDF]. Like, you don't want to have an Employee class, because it's got his name which might get changed if he gets married, and it has his salary, which might get changed if he gets a raise. Those have to be two separate classes, because they get changed under different circumstances.
Amm .. ok.. dobra bo nie kumam - co jest dziwnego w osobnym trzymaniu Employee i Salary.. czyli mam naćpać wszystkie algorytmy obliczania ZUS'ów, progów podatkowych, urlopów do klasy Employee ? Zresztą, w każdym sensownym systemie kadrowym byłoby jak najbardziej wskazane te dwie klasy wyróżnić. No chyba że to portal WEB 2.0 w którym zarobki to zwykły prymitywny float... ale to skrajny przykład (patrz wyżej na temat skrajności).
Nie wspomnę już o tym, że Joel (albo ja) absolutnie nie zrozumiał na czym polega Single Responsibility Principle. Podczas gdy on mówi o zmianie stanu obiektu Uncle Bob wyraźnie pisze o zmianie klasy !! Obiekt a klasa .. no proszę, mnie na 2 roku uczyli je rozróżniać.
And you wind up with millions of tiny little classes, like the EmployeeSalary class, and it's just... (laughs) idiotic! You can't build software that way!
Racja, ah Ci głupi zwolennicy OO. Assembler ROX !
The way real software works is that you create these very imperfect things, and they work great.
.. jak problem roku 2000.
They really do.
.. really do make people rich. (vide programiści systemów bankowych w roku 1999 :P).
And then you have a little problem, and you go and you fix the little problem, because it's code, and you have an editor, and you edit it.
.. jak problem roku 2000. khy khy
These classes are not going to go wander off flying in the universe all by themselves and need to work perfectly and unchanged until the end of time.
Jeff:
Right. The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code.
A w restauracji Twoim jedynym obowiązkiem jest obsługiwać klientów. Naczynia się posprzątają same.
To me that's what it's all about. Anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative. If that means using Ruby, or having lots of unit tests: whatever's working for you: do that. But if it's getting in the way, if it becomes friction, like, "I'd love to have this great new feature but I'd have to have 1000 unit tests," that's a negative.
Kwestia balansu oczywiście... ale do tego trzeba hmmm.. myśleć ?
Joel:
Yeah. And the worst thing that happens is that you get people that just stop thinking about what they're doing.
.. and saying - vide ta dyskusja Joela z Jeffem.
Reszta rozmowy dostępna jest na blogu Joela bo ja naprawdę nie mam siły... Przyznaję, że kilka razy zastosowałem trochę nieczyste chwyty (np. z przykładem problemu roku 2000), ale ogólnie opinie Joela i Jeffa mocno mnie zdenerwowały. Nie spodziewałem się że inteligentni i świadomi (jak sądziłem) programiści będą pier.. wygadywać takie głup.. niemądre rzeczy.
Pozostawiam tę ichnią rozmowę do Waszej rozwagi.
P.S. Jeśli Joel z Jeffem po prostu "robili sobie jaja" (co jest bardzo prawdopodobne) proszę mnie powiadomić abym mógł zdjąć tego posta lub odpowiednio go zkorygować. :P
eee ooo!
ReplyDeleteMysle, ze musisz posta skorygowac. :-P
Przeczytałem nie tylko rozmowę, ale też odpowiedź Kenta, Wujka Boba i komentarze.
ReplyDeleteMuszę rzec, że komentarze pod odpowiedzią Kenta są paskudne. Nieźle to podsumował w swoim późniejszym wpisie na blogu, przeczytałem pół setki tych komentarzy i po prostu przykro się to czyta.
LAFK