<br><br><div class="gmail_quote">2012/5/18 Auth Gábor <span dir="ltr"><<a href="mailto:auth.gabor@javaforum.hu" target="_blank">auth.gabor@javaforum.hu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
On 2012. May 18. 21:22:57 Molnár Miklós wrote:<br>
> "Halott" az amiben nincs újabb release és/vagy kiváltásra kerül<br>
> (lecserélődik). A Nokia így lehet, hogy még nem halott (nem tudom).<br>
<br>
</div> A Symbian eléggé nem halott ebből a szempontból... :)<br>
<div class="im"><br>
> Szóval a szoftver öregszik/erodálódik, ha sokat változik, esélyesen<br>
> növekszik a hibák száma, ráadásul akár progresszíven/gyorsulóan. Ha nem tesz<br>
> ellene semmit az ember (értsd csak mindig az adott hibát javítja, és csak<br>
> mindig az aktuális problémát oldja meg, mondjuk agilisen), akkor<br>
> implikálódik, hogy esélyesen lesz olyan, hogy túl sok hiba lesz a<br>
> szotverben. Mindez kódminőségi problémakör. Ennyi és csak ennyi az állítás.<br>
<br>
</div> Értem, de emellé van még néhány fontos dimenziója a kód minőségének, mint<br>
például a test coverage vagy a code duplications ratio, hogy a két<br>
legfontosabbat említsem. Ha a tesztek során az összes releváns kódrészlet le<br>
van fedve -- ide értve az elágazásokat és a ciklusokat is, akkor lehet<br>
bármilyen komplex a kód, a módosítása során hamar kiderül, hogy valahol máshol<br>
ettől elromlott-e valami. Ugyanígy lehet a coupling nulla közeli, ha ezt a kód<br>
duplikálásával érte el a fejlesztő, akkor egy továbbfejleszthetetlen spagetti<br>
az adott szoftver forrása, és könnyen halott lehet a projekt, bár az<br>
elmélet(ed) szerint igencsak él és virul.<br>
<div class="im"><br>
>> A komplexitást egyéb tényezők is növelik, a komplexitás csökkentésével<br>
>> viszont nem csökken a coupling, sőt esélyes, hogy növekszik... :)<br>
> Érdekes módon az MTA-s délután konklúziója (számomra), hogy NEM. Meg is<br>
> lepődtem, illetve kicsit szkeptikusan is vettem az elméleti tudósoktól. De<br>
> nem kívánnék elmenni ebbe az irányba, kisebb a jelentősége (nekem<br>
> mindenképp), és a threadben való offtopik/ortogonális mivolta miatt sem.<br>
<br>
</div> Menjünk bele, hasznos mindenkinek. Előtte definiáljuk, hogy mit is értünk<br>
pontosan couplingon, mert érzésem szerint nem mindegy.<br>
<div class="im"><br>
> Nézegettem a Sonar-linkeket, de sokat nem tudtam kiolvasni, másrészt mondom,<br>
> hogy ők többet mást gondolnak a csatolásról (előrébb is vannak a kész<br>
> implementációknál, a program-slicing brutális fejlődése miatt). Másfelöl<br>
> "tapasztalat" alatt én azt értem, hogy van-e valakinek olyan tapasztalata,<br>
> hogy beazonosította, hogy kódminőség-gond miatt halt meg egy szoftver á lá<br>
> Nokia-példa.<br>
<br>
</div> Rossz kódminőség miatt nem láttam még meghalt projektet. Projekthalálnak<br>
ezernyi oka van, az utolsók között van valahol a rossz minőségű kód.<br></blockquote></div><br><br>Ez a rossz kódminőség a legritkább esetekben játszik szerintem szerepet. Ahhoz már nagyon rosszul kell valaminek ahhoz működnie, hogy megérje az egészet kidobni, és teljesen újat csinálni helyette, ami pont ugyanazt tudja, csak szebben. Azt már inkább el tudom képzelni, hogy idővel olyan szempontok kerülnek középpontba, amik korábban egyáltalán nem számítottak, és arra már nem húzható rá a korábbi rendszer.<br>
A Symbian/Nokia behalása érdekes kérdés, de biztos van a listán olyan ember aki jobban ismeri az adott céget / szoftvert mint én, de nekem külsőre inkább úgy tűnt, hogy egyszerűen rossz dolgokra fókuszáltak, nem hitték el, hogy lehet olyan tömeg telefont csinálni, amiért az emberek akár 150-200 eFt-t is boldogan kiadnak.<br>
<br>Zs<br>