A kód elhízás egyre nagyobb veszélyt jelent a szoftvercégekre

Björn Fant

2018. május 18. · 4 perc olvasás

A telefonján és a számítógépén futó alkalmazások és szoftverek kérik, hogy naponta frissítsen a legújabb verzióra. Napi! Mikor jutottunk erre és miért történik ez most? Ezért csinálják a szoftvercégek, és valójában miért is fáj nekik.

fant

Először egy visszalépés a történelembe. Amikor a 80-as években nőttem fel, játékokat és szoftvereket vásároltunk a kiskereskedelmi üzletekben 1,44 MB hajlékonylemezen. Régen ültünk, és hajlékonylemezzel etettük a számítógép hajlékonylemezét, hogy telepítsük a legújabb jó játékot. A legnagyobb játék akkoriban 40 lemez körül volt (kb. 55 MB). Néha a játékok megszakadtak, és javító lemezt kellett beszereznie, de ez ritka volt. A javító lemez kiadásának terjesztési költségei magasak voltak a szoftvercégek számára, ezért az alaposan tesztelt szoftver kiadására összpontosítottak.

Gyors előre a mai napig. A számítógépek sokkal jobb teljesítményt és tárolási kapacitást értek el. Minden embernek több eszköze van, amelyek kapcsolódnak az internethez, és a szoftver a mindennapjaink integrált része, vagyis minden eddiginél jobban támaszkodunk a szoftverekre. A szoftverek terjesztése a szoftvercégek stratégiai döntéseitől kezdve heti egy gombnyomásra vált a technológiai csoport telepítési menedzsere vagy egy önálló vállalkozó alkalmazás-fejlesztő részéről. Könnyebb folytatni a telepített termék frissítéseinek folytatását, mint újrakezdeni azzal, hogy az embereket új alkalmazás letöltésére, értékelésekre, marketingre stb.

Ha a terjesztés megoldódott, csak ezer fejlesztőt kell felvennünk a siker érdekében, igaz? A frissítéseket tartalmazó szoftverek végül felduzzadnak, ami lassabbá, túl bonyolulttá teszi használatukat, és túl sok helyet foglal el a lemezen. Három hónappal ezelőtt a gyerekem panaszkodott a 16 GB-os iPad alacsony tárhelyére. Kiderült, hogy a legutóbbi Angry Birds frissítés 450 MB volt. Biztos módja volt a játék végleges törlésének.

Még egy. Itt van egy képernyőkép a Mac-ről, amely azt mondja, hogy frissítsem a Microsoft irodát.

Ok, beismerem. Körülbelül egy hónapig nem frissítettem az MS Office-t, de ez őrület! A Word használatával gépelem. Mit adhat hozzá a Microsoft ehhez az élményhez 1,0 GB-ban? És ritkán használom a Powerpoint-ot. Mire szolgál az extra 716,6 MB? Nem lehetnek kritikus biztonsági javítások.

Amíg itt tartunk, beszéljünk az üzenetküldésről. A telefonomon lévő alkalmazás arra kér, hogy töltsem le a legújabb, 35 MB-os verziót a kiadási megjegyzésekkel: „különféle hibajavítások”. Félelmetes, ettől nagyon meg akarok nézni az új verzióval. Értem, néha ki kell adni a hibajavításokat, és ha kritikus, akkor néhány szegény fejlesztőnek általában nincs ideje valami csodálatos dolgot írni. De ez legyen a kivétel, nem a szabály. De talán nincs szükségünk kényszerítő értékesítési érvekre. Az emberek egyébként frissíteni fognak? Megkockáztatja alkalmazásának végleges törlését?

Tehát a szoftver felfújása nem jó dolog. A szoftvercégeknek legalább 1/10 fejlesztőnek kell aggódnia a puffadás és a teljesítmény miatt, és ellenőriznie kell, hogy ez nem történik-e meg. A felfúvódás a technikai adóssághoz is 100% -ban kapcsolódik. A duzzadt kódbázist nehezebb tovább fejleszteni. Ha egy szoftvercég vezetője vagy, tedd fel ezt a kérdést a fejlesztőidnek: „Mennyi időt töltöttél a kódolással szemben, és azt kutattad, hogyan illeszkedne a kód az utolsó projekted jelenlegi kódbázisához?”A kutatás több mint 30% -a rossz jel.
Ha a szoftver túl bonyolult a frissítéshez, és közelednek a határidők, akkor a fejlesztő számára könnyű a legkönnyebb utat megtenni; „Nincs időm megérteni azt a régi örökölt kódot. Helyette írok egy új modult!Az eredmény az, hogy a kód most két különálló modul, amelyek szinte ugyanazt csinálják, növelve a puffadást, és abszolút megzavarják a következő fejlesztőt, amely megérinti a kódot. A szoftver felhasználói élménye is veszélyben van. A funkciók másképp kezdenek kinézni és működni.

Tehát hogyan kell kezelni a kód elhízását. Mint minden fogyási erőfeszítésnél, ritkán működik alkalmanként diéta. Életmódváltásra van szükség. Talán szüksége van egy személyi edzőre. De az első lépés az, hogy minden csapatba egy-egy embert vagy 1/10-es fejlesztőt kell felvenni, aki a többi csapat edzéséért felel, és a sprintre alkalmas építési szabályzatban szerepel. Ne felejtse el hozzáadni a megfelelő KPI-ket. Itt nincs helyes válasz, de itt van három példa:
• A kódolás és a kódkutatás aránya (például a korábbi példa)
• Átl. súlynövekedés vagy -csökkenés felszabadulásonként
• A soha nem használt szoftvereszközök súlya

Vonja be az egész vállalatot a jobb használhatóság kialakításába azzal a kérdéssel, hogy „mi az, amit eltávolíthatunk, hogy valaki gyorsabban használja a termékünket vagy jobban élvezze azt?”. Ütemezze a kódoptimalizálást, mint bármely más fizikai gyakorlat esetén. Használja a felhőalapú tárolást és szolgáltatásokat, ha nem támaszkodik a gyenge mobilinternet-kapcsolatokra. És valóban szüksége van arra a 4K felbontású bemutatkozó videóra az alkalmazás kezdőképernyőjén?

Büszke arra, hogy rendelkezik megfelelő kódbázissal, és ne feledje, hogy még a nagyvállalatok is hibáznak. Az IBM az általuk írt kódsorokkal szokott fizetni a fejlesztőknek.