| dbo:abstract
|
- A próba-szerencse programozás a számítógép-programozás egy antimintája. Lényege, hogy a programozó apró változásokat visz véghez, remélve, hogy ezzel kijavít egy hibát. Közben rendszerint nem használja a verziókezelést, emiatt a megelőző változat elveszhet. Az apró változtatásokat, sorok megcserélésének eredményét teszteli is, bár ez a tesztelés nem kimerítő. Oka, hogy a programozó nem érti a hibát és a kódot. Ezzel a módszerrel olyan új hibákat vezethetnek be, melyeket a teszteléssel nem vesznek észre, így legfeljebb csak akkor derülnek ki, amikor a programozó úgy ítéli, hogy sikerült kijavítania a hibát, és a projekt gépezete működésbe lendül. A taktika nem produktív, ha:
* Nincsenek könnyen végrehajtható , amelyek lefedik a kódbázist.
* Nincs tesztvezérelt fejlesztés, így tapasztalati teszteléssel nehéz megállapítani, hogy a releváns esetek többségében működik-e.
* Nincs verziókezelés , nincs elmentett megelőző állapot, nincsenek közben mentések sem, így a legrosszabb esetben a régi állapot elvész, pedig lehet, hogy az lenne a legjobb. Sok hibás indítás és javítás történik, mielőtt eléri a megnyugtató végpontot. hiányában a kód minősége nem biztosított. Oka, hogy a programozó nem érti a hibát, nem érti, hogy miért csinálja a kód azt, amit. Ennek oka lehet az API nem megfelelő dokumentációja. Mások a referencia kódot másolják át, amiről azt hiszik, hogy korrekt, pedig lehet, hogy az is próba-szerencse módon készült. Bizonyos esetekben a programozó tudja igazolni, hogy a többi lehetséges permutáció, változat közül az egyiknek működnie kell, akkor megtalálhatja azt a változatot, amiről utólag igazolhatja, hogy az a legjobb. (hu)
- A próba-szerencse programozás a számítógép-programozás egy antimintája. Lényege, hogy a programozó apró változásokat visz véghez, remélve, hogy ezzel kijavít egy hibát. Közben rendszerint nem használja a verziókezelést, emiatt a megelőző változat elveszhet. Az apró változtatásokat, sorok megcserélésének eredményét teszteli is, bár ez a tesztelés nem kimerítő. Oka, hogy a programozó nem érti a hibát és a kódot. Ezzel a módszerrel olyan új hibákat vezethetnek be, melyeket a teszteléssel nem vesznek észre, így legfeljebb csak akkor derülnek ki, amikor a programozó úgy ítéli, hogy sikerült kijavítania a hibát, és a projekt gépezete működésbe lendül. A taktika nem produktív, ha:
* Nincsenek könnyen végrehajtható , amelyek lefedik a kódbázist.
* Nincs tesztvezérelt fejlesztés, így tapasztalati teszteléssel nehéz megállapítani, hogy a releváns esetek többségében működik-e.
* Nincs verziókezelés , nincs elmentett megelőző állapot, nincsenek közben mentések sem, így a legrosszabb esetben a régi állapot elvész, pedig lehet, hogy az lenne a legjobb. Sok hibás indítás és javítás történik, mielőtt eléri a megnyugtató végpontot. hiányában a kód minősége nem biztosított. Oka, hogy a programozó nem érti a hibát, nem érti, hogy miért csinálja a kód azt, amit. Ennek oka lehet az API nem megfelelő dokumentációja. Mások a referencia kódot másolják át, amiről azt hiszik, hogy korrekt, pedig lehet, hogy az is próba-szerencse módon készült. Bizonyos esetekben a programozó tudja igazolni, hogy a többi lehetséges permutáció, változat közül az egyiknek működnie kell, akkor megtalálhatja azt a változatot, amiről utólag igazolhatja, hogy az a legjobb. (hu)
|
