[Javalist] Csatolások szoftverekben

[Zsombor]

2012/5/18 Auth Gábor <auth.gabor at javaforum.hu>

> Hi,
>
> On 2012. May 18. 21:22:57 Molnár Miklós wrote:
> > "Halott" az amiben nincs újabb release és/vagy kiváltásra kerül
> > (lecserélődik). A Nokia így lehet, hogy még nem halott (nem tudom).
>
>   A Symbian eléggé nem halott ebből a szempontból... :)
>
> > Szóval a szoftver öregszik/erodálódik, ha sokat változik, esélyesen
> > növekszik a hibák száma, ráadásul akár progresszíven/gyorsulóan. Ha nem
> tesz
> > ellene semmit az ember (értsd csak mindig az adott hibát javítja, és csak
> > mindig az aktuális problémát oldja meg, mondjuk agilisen), akkor
> > implikálódik, hogy esélyesen lesz olyan, hogy túl sok hiba lesz a
> > szotverben. Mindez kódminőségi problémakör. Ennyi és csak ennyi az
> állítás.
>
>   Értem, de emellé van még néhány fontos dimenziója a kód minőségének, mint
> például a test coverage vagy a code duplications ratio, hogy a két
> legfontosabbat említsem. Ha a tesztek során az összes releváns kódrészlet
> le
> van fedve -- ide értve az elágazásokat és a ciklusokat is, akkor lehet
> bármilyen komplex a kód, a módosítása során hamar kiderül, hogy valahol
> máshol
> ettől elromlott-e valami. Ugyanígy lehet a coupling nulla közeli, ha ezt a
> kód
> duplikálásával érte el a fejlesztő, akkor egy továbbfejleszthetetlen
> spagetti
> az adott szoftver forrása, és könnyen halott lehet a projekt, bár az
> elmélet(ed) szerint igencsak él és virul.
>
> >> A komplexitást egyéb tényezők is növelik, a komplexitás csökkentésével
> >> viszont nem csökken a coupling, sőt esélyes, hogy növekszik... :)
> > Érdekes módon az MTA-s délután konklúziója (számomra), hogy NEM. Meg is
> > lepődtem, illetve kicsit szkeptikusan is vettem az elméleti tudósoktól.
> De
> > nem kívánnék elmenni ebbe az irányba, kisebb a jelentősége (nekem
> > mindenképp), és a threadben való offtopik/ortogonális mivolta miatt sem.
>
>   Menjünk bele, hasznos mindenkinek. Előtte definiáljuk, hogy mit is értünk
> pontosan couplingon, mert érzésem szerint nem mindegy.
>
> > Nézegettem a Sonar-linkeket, de sokat nem tudtam kiolvasni, másrészt
> mondom,
> > hogy ők többet mást gondolnak a csatolásról (előrébb is vannak a kész
> > implementációknál, a program-slicing brutális fejlődése miatt). Másfelöl
> > "tapasztalat" alatt én azt értem, hogy van-e valakinek olyan
> tapasztalata,
> > hogy beazonosította, hogy kódminőség-gond miatt halt meg egy szoftver á
> lá
> > Nokia-példa.
>
>   Rossz kódminőség miatt nem láttam még meghalt projektet. Projekthalálnak
> ezernyi oka van, az utolsók között van valahol a rossz minőségű kód.
>


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

Zs
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120518/1a4edc8d/attachment.html>