Elsore annyit tudok csak mondani, hogy egy Main-Class: definicio a manifestben elegansabba tudna tenni a dolgot.
Kossz, igaz, javitottam is.
Masreszt meg: pontosan mire is jo ez? Milyen szituacioban hasznal az ember egy ilyen progit?
Azt nem allitom, hogy a program a jelenlegi kezdetleges formajaban ezekre alkalmas, de a celom ezzel az egyelore inkab kiserletezgetessel az lenne, hogy erdemes legyen egy ilyen programot lefuttatni a kovetkezo szituaciokban:
- Segithet kiszurni egy esetleges rossz design-t. Ha tul sok dependency-t jelento vonal van, az gaz, vagy elso ranezesre kiderulhet, hogy valami kozvetlenul ossze van kotve valamivel, amivel nem szabadna. (Ilyen design hiba sokszor nem derul ki a kodra ranezve.) Foleg altalanos framework irasakor kell kinosan ugyelni arra, hogy melyik kod altalanos,es lehet a framework resze, es melyik specialisan egy adott alkalmazasra jellemzo.
- Ugyanez, amikor egy programozo csinal egy gyors review-t egy kezdo programozo designjan/kodjan
- Amikor egy komplex szoftver felepiteset probalja elmagyarazni valaki egy meetingen valakinek, egy kinyomtatott papirt felhasznalva. Foleg ha az utobbi a fonok, vagy egy manager, akinek a forraskodot megsem akarod mutogatni, de azert erdeklodik, hogy miert fizet olyan regota olyan sokat, stb...
- Amikor nem tudtok megegyezni, hogy milyen posztert rakjatok ki az iroda falara, es a realizmus mint muveszeti agazat hivei vagytok, tehat az eredeti design UML diagramjai stilusidegennnek hatnak.:)
- Amikor erofeszites nelkul akarod novelni a dokumentacio mennyiseget:)
Egy pelda feature, amin gondolkodok pl meg, ami nincs a szoftverben.:
Erdemes-e a dependency grafban az iranyitott koroket pirossal kiemelni. Olvastam olyat, hogy a kor valoszinuleg design hiba.
