Ne másolja be a kód beillesztését. Írja ki. ?

A kód beírása segíthet a tanulási gondolkodásmód kialakításában

Törni akar egy kódot? Változtassa meg igazán gyorsan, mielőtt megértené, mit csinál.

Most a Cargo Cult programozást gyakorolja - a szoftverfejlesztés egy olyan stílusát, amelyben figyelmen kívül hagyja a kódrész működését és annak viszonyát a körülötte lévő kóddal.

A rakománykultúra programozó kifejezés akkor alkalmazható, amikor egy számítógépes programozó, aki még nem jártas a problémában, másol egy kódot egyik helyről a másikra, alig vagy egyáltalán nem értve annak működését, vagy azt, hogy szükség van-e rá új pozíciójában.

- Cargo Cult programozás a Wikipédián

Amikor egy fejlesztő lemásol egy olyan kóddarabot, amelyet nem ért, és valamilyen probléma elhárításának reményében használja, akkor a Cargo Cult programozását gyakorolják. Ez növeli a nem kívánt mellékhatások kockázatát.

Amikor egy fejlesztő elolvas egy olyan kóddarabot, amelyet nem ért, és mégis megváltoztatja azt annak reményében, hogy megoldja a problémát, akkor a Cargo Cult programozását is gyakorolja.

A probléma ebben az esetben nem az, hogy a fejlesztő lemásol valamit. Bárki másolhat egy kódrészletet, megértheti azt, tanulhat belőle, használhatja, és még mindig kisebb a nem kívánt mellékhatások kockázata.

A Cargo Cult programozása viszont alapvető félreértést jelent a mások kódjából való tanulás bizonyított lépéseivel.

Itt van a leghatékonyabb módszer a tanulásra ebben az összefüggésben:

  1. Olvasson el egy darab kódot.
  2. Ismerje meg az ott használt nyelv összes jellemzőjét.
  3. Ismerje meg az ott használt könyvtárak / keretrendszerek összes tulajdonságát.
  4. Ismerje meg e könyvtárak / keretrendszerek alapjait.
  5. Megérteni, hogy minden sor mit csinál, és mi a könyvtárak / keretrendszerek célja az adott kódrész összefüggésében.

Annak, aki új nyelven kezd dolgozni, ez rendkívül nehéz lesz. Az információ mennyisége, amelyet az embernek meg kell őriznie ahhoz, hogy hatékonyan megértse akár egy kis kódrészletet is, olyan hatalmas, hogy azonnal elfelejthető. Amit tehetünk, hogy bizonyos bevált technikákkal kiaknázhatjuk bizonyos aspektusait annak, hogy az emberi agy hogyan szokott dolgokat tanulni - tudatosan vagy öntudatlanul.

Az egyik ilyen technika blokkolt gyakorlat. Alapvetően ott tanul, hogy „egyetlen képességet végezzen újra és újra, az ismétlés a legfontosabb”.

Pedig ez nem a legjobb módszer a tanulásra. Bebizonyosodott, hogy ha ugyanazon képesség különböző változatainak összevonásával tanul, akkor hatékonyabban fog tanulni.

A szoftvertervezésben mind a blokkolt, mind az egymást átlapoló tanulási gyakorlatokat kihasználhatjuk, amikor a kódot különböző kontextusba írjuk , ahelyett, hogy csak másolnánk és beillesztenénk .

A kivonatok beillesztésénél csak olvasunk (ha ezt még zavarjuk is). És az élmény kúpjának viszonya szerint előfordulhat, hogy az elfogyasztott információknak csak egy kis részét tanulhatjuk meg, mert túl elvontak.

Ezzel szembeállíthatja a jobb tanulást azzal, hogy valóban beírja azt a kóddarabot. Ez közvetlenebb és céltudatosabb élmény. Arra kényszeríti az agyadat, hogy megértse ezeket a különböző mintákat és hatékonyabban tanuljon.

A kód beírása a másolás beillesztése helyett jobb megtérüléshez vezet, mivel csak olvasás helyett gyakorolunk.

A dolgok elnevezését a programozás egyik legnehezebb aspektusának tartják. Ha másoljuk a kódot anélkül, hogy megértenénk, fennáll annak a veszélye, hogy valamit megszakítunk a változónevek, függvénynevek vagy osztályok felülírásával.

Ha először megértjük a kódot, majd a saját szavainkkal írjuk be, akkor átnevezhetjük a dolgokat az alkalmazásunknak megfelelő módon, és biztosítjuk, hogy ne legyenek névadási ütközéseink, még akkor is, ha a végeredmény funkcionálisan megegyezik a kódrészlet, amelyre alapozunk.

Emellett, ha átmásoljuk a kódot a kódalapunk egyik helyéről a másikra, akkor van esély arra, hogy szükségtelen tokenteket másolunk, vagy elfelejtjük megváltoztatni azokat a tokeneket, amelyeket meg kellett volna változtatni.

Vegyük például a következő HTML-kódrészletet:

Amikor másoljuk a kódot egy új bemenet létrehozása érdekében, valószínűleg elfelejtjük megváltoztatni a label elem for attribútumát , ami megtöri az új bemenet tervezett viselkedését.

Ez a példa érdekes, mert ez a fajta funkcionalitás, amelyet még vizuális regresszió esetén is nehéz tesztelni. Nagyban függ a statikus teszteléstől - például a kód felülvizsgálatától - annak biztosítása, hogy a kódot rendeltetésszerűen írták-e. (Ebben az esetben, szaporítására egéreseményeket bemenetére azonos id a címke a tulajdonság.)

Ugyanez történik a tesztekkel is. Ha egy már sikeres tesztet másolunk, ahelyett, hogy a semmiből létrehoznánk egy újat, akkor fennáll annak a veszélye, hogy nem változtatjuk meg a szükséges tokeneket, amelyek egyébként a teszt kudarcát okoznák.

Ebben az esetben azonban megakadályozhatjuk ezt a hibát a Test Driven Development használatával - egy gondolkodásmódon, amely először egy sikertelen teszt létrehozására épül, majd változtassuk meg az alkalmazás kódját, hogy az sikeres legyen. Ez a gondolkodásmód lehetővé teszi számunkra, hogy biztosak legyünk abban, hogy kevésbé valószínű, hogy valamit elmulasztunk vagy hamis pozitív eredményt hozunk létre.

Ahelyett, hogy másolná a kódot anélkül, hogy megértené, tanuljon mások kódjából, és gyakoroljon a tetején. Ez maximalizálja a tanulás megtérülését.

Végül is a fejlesztő legértékesebb erőforrása az agy - nem az ujjak.

Köszönöm, hogy elolvasta. Ha van visszajelzése, forduljon hozzám a Twitteren, a Facebookon vagy a Githubon.