A Microsoftot alapvetően hibás Windows 10 fejlesztési folyamattal vádolják

Mára már mindannyian tisztában vagyunk a kudarccal, amely a Windows 10 2018. októberi frissítésének kiadása volt, de valószínűleg már elfelejtettük, hogy a 2018. áprilisi frissítés is késett a későn feltörő hibák miatt, amelyek egyes számítógépeken kék képernyőt okoztak.

Az Ars Technica közelebbről megvizsgálta a Windows fejlesztését, és úgy vélik, hogy a Microsoft operációs rendszerük fejlesztési folyamata a kezdetektől fogva hibás volt, egészen a Windows 7-ig.

Megjegyzik, hogy a Microsoftnak az a folyamata, hogy valójában csak néhány hétig ír kódot az új funkciókhoz, majd a fennmaradó időt (több hónapot) a szoftver integrálásával, majd a kiadás előtt kijavítja a hibákat. Ez azt jelentette, hogy rossz minőségű, megbízhatatlan szoftvereket vezettek be a Windows 10 kódbázisába, és ha nem találnak problémákat, a végfelhasználóhoz szállították.

Párosul a nem hatékony tesztelési rendszerrel, részben amiatt, hogy a Microsoft 2014-ben kirúgta az SDT-ket, és nagyobb felelősséget rótt a fejlesztőkre saját kódjuk tesztelésében, valamint az amatőrök által alkalmazott Windows 10 Insider folyamat, amely nem volt átfogó, és amely nem szállított professzionális hibajelentéseket, többet jelentett annál, mint hogy a hibák méltányos részét végül kiszállítsák.

Az Ars Technica azt is megerősítette, hogy a Windows-fejlesztők mindenféle tesztelés nélkül integrálhattak kódot, bár remélhetőleg ez volt a kivétel.

Változást szorgalmaztak a Microsoft fejlesztési folyamatában, és azt kérték, hogy az új szoftvereket jól teszteljék az integráció előtt olyan modern technikákkal, mint az automatizált tesztelés, ami azt jelenti, hogy még az Insider buildek is jó minőségű, jól tesztelt kóddal rendelkezzenek, „ismert problémák” nélkül.

Megjegyzik:

Előfordulhat, hogy egy új funkció instabil lesz a fejlesztés során, de ahhoz, hogy ezt a funkciót be lehessen vonni a gyártási kódba, nagyon jó minőségi korlátnak kell megfelelnie. A Microsoft „most egyesítjük a hibákat, mi később kijavítjuk” megközelítése helyett az a megközelítés, hogy a kód a lehető leghibamentesebb legyen. előtt összevonódik.

Megállapítják:

Ha elfogadnánk azt az elvet, hogy a Windows-kódnak mindig szállítási minőségűnek kell lennie – nem „néhány hónapos javítás után”, hanem „most, bármikor” –, óriási változás lenne. De ez egy szükséges. A Microsoftnak olyan helyzetben kell lennie, hogy minden új frissítés az első naptól kezdve gyártási minőséget jelentsen; egy olyan világ, ahol a legújabb és legjobb kiadásra való frissítés nem probléma, olyan választás, amelyet magabiztosan meg lehet tenni. A funkciófrissítéseknek nem eseményeknek kell lenniük, és a felhasználók alig veszik észre őket.

Az Ars Technica a Google Chrome-csapatát olyan vállalatként tartja fenn, amely jól csinálja, és mivel a ChromeOS egyre életképesebb megoldássá válik, a Microsoft biztosan nem engedheti meg magának, hogy elveszítse a végfelhasználók bizalmát.

Mit gondolnak az olvasóink? Tájékoztassa velünk alább.