Szia 👋
Azért vagy itt, mert valaki erre a bejegyzésre irányított, miután javasoltál egy ötletet arról, hogyan lehetne fejleszteni az Exercism-öt?
Mielőtt a csapatunk időt fektetne az ötleted megvizsgálásába, abban bízik, hogy elolvasod ezt, és átgondolod, hogy vajon nem merült-e már fel korábban az ötleted, és milyen buktatókat rejthet.
Ha hozzáadod ezeket a szempontokat és lehetséges buktatókat a javaslatodhoz, és végiggondolod, miért nem valósulhatott meg eddig az ötleted, valószínűleg gyorsabb és pozitívabb választ kapsz.
Mit is jelent a „Chesterton kerítése”?
A Chesterton kerítése egy gondolat, amelyet G.K. Chesterton író 1929-es, The Thing című könyvének egyik idézete ihletett.
John F. Kennedy idézte, és ettől lett széles körben ismert.
Íme az eredeti idézet:
Ilyen esetben létezik egy bizonyos intézmény vagy törvény; mondjuk az egyszerűség kedvéért egy úttesten át emelt kerítést vagy kaput.
A reformátorok modernebb típusa vígan odasétál hozzá, és azt mondja: „Nem látom ennek hasznát; bontsuk le.”
Amire a reformátorok értelmesebb típusa jól teszi, ha azt válaszolja: »Ha te nem látod ennek hasznát, én bizony nem engedem, hogy lebontsd. Menj el, és gondolkodj. Aztán, ha visszajöhetsz, és elmondhatod, hogy látod a hasznát, talán megengedem, hogy elpusztítsd.«
A Chesterton kerítése lényege, hogy ha nem érted, miért van ott valami, akkor valószínűleg azt sem érted, miért kellene eltávolítani.
Ugyanígy, ha nem érted, miért nincs ott valami, akkor valószínűleg azt sem érted, miért maradt ki.
Egy egyszerű szabály, amit érdemes megjegyezni: „Ne bonts le egy kerítést, amíg nem tudod, miért állították fel eredetileg.”
Hogyan kapcsolódik mindez az Exercism-höz?
Az Exercism-nél szerencsések vagyunk, mert folyamatosan rengetegen csatlakoznak a közösségünkhöz, és osztják meg a gondolataikat és ötleteiket.
Sok ilyen ötlet új, innovatív, izgalmas, és áttöri a gondolkodásunk korlátait.
Szóval ha van egy ötleted vagy javaslatod, örömmel fogadjuk!
A gyakoribb azonban az, hogy olyan ötleteket írnak le az emberek, amelyeket már sokszor megvitattunk.
Ha ezekre az ötletekre válaszolunk, és újra meg újra elővesszük vagy újra megindokoljuk a döntéseinket, az rendkívül kimerítő lehet a csapatunk számára.
Ez a cikk abban szeretne segíteni, hogy megvédjük ezt az időt és energiát.
Az Exercism-öt több ezer nagyon tehetséges ember tervezte, alakította és építette fel.
Ez egy nagyon szándékos termék: a dolgok azért vannak ott, mert úgy tervezték, hogy ott legyenek, és gyakran azért hagynak ki dolgokat, mert úgy tervezték, hogy kimaradjanak.
Az Exercism-nél szinte mindent sokszor megvitattunk, megtárgyaltunk és újraterveztünk.
Tehát mielőtt leírod az ötletedet, kérdezd meg magadtól, hogy vajon nem gondoltunk-e már rá, és miért csinálhattuk másképp, mint ahogy te javasolod.
És ne feledd: minél nyilvánvalóbbnak tűnik az ötleted, annál valószínűbb, hogy már sokszor megvitatták, ezért amikor előadod, a lehetséges fenntartásokkal és buktatókkal együtt mutasd be.
Ha késztetést érzel arra, hogy azt mondd: „miért nem lehet csak ...”, akkor szinte biztosan ebbe a kategóriába tartozik.
Sose félj posztolni, de előtte azért gondold át alaposan!
Van példa is?
Gyakori bosszúság, hogy a tanulók olyan kódot küldenek be a mentoroknak, amely nem megy át a teszteken.
Ugyanilyen gyakori javaslat: „Miért nem futtatjuk le automatikusan a teszteket a CLI-ben, mielőtt valaki beküldi a kódját?”
Nagyszerű ötletnek tűnik: a CLI egyszerűen meghív egy parancsot, ami lefuttatja a teszteket, és nem engedi beküldeni a kódot a tanulónak, ha az elbukik.
Először is, mit is jelent az, hogy „egyszerűen meghívunk egy parancsot, ami lefuttatja a teszteket”?
Azt jelenti, hogy szkriptet kell írnunk mind az 52 nyelvhez az Exercism-ön, amely le tudja futtatni a teszteket és ellenőrzi az eredményt.
Ez nem kevés munka, de megoldható.
De azt is jelenti, hogy a szkript Windows, MacOSX és Linux alatt is fusson, méghozzá minden lehetséges verzióban és konfigurációban. Ez rengeteg (ha nem épp végtelen) munka.
„Miért kell minden konfiguráció?” kérdezheted?
Nos, azért, mert ezzel aktívan megakadályozol valakit abban, hogy használja az Exercism-öt, hacsak nem tudja futtatni ezt a szkriptet.
Ez azt is jelenti, hogy soha nem hibázhat.
Ha valamiért a szkript nem fut le, a tanuló teljesen elakad.
Ha az 52*3*n szkript valamelyikében hiba van, a tanuló többé nem tudja használni a kurzust azon az operációs rendszeren.
Hogyan tesztelnéd ezt?
Nem tudod.
De, mondhatod, egyszerűen hozzáadhatunk egy --skip-tests kapcsolót.
Ez jó javaslat, de visszavezet a kiindulópontunkhoz: az emberek bármikor úgy dönthetnek, hogy megkerülik a teszteket.
Csakhogy most olyan helyzetben vagyunk, ahol valamivel kisebb a valószínűsége annak, hogy elbukó teszteket küldenek be, így a mentorok is kevésbé számítanak rá, ami azt jelenti, hogy még zavaróbb és megdöbbentőbb, amikor a tesztek tényleg elbuknak.
„De az emberek általában nem tennének ilyet” érvelhetsz. Igaz, bizonyos nyelveknél, ahol 0,5 másodperc lefuttatni a teszteket.
De azoknál a nyelveknél, ahol 20 másodpercbe telik lefuttatni a teszteket, a plusz 20 másodperc várakozás a beküldés előtt hihetetlenül frusztráló a tanulóknak, így a záró tesztek kihagyása mindennapossá válna.
Függetlenül attól, hogy hova vezet ez a beszélgetés, világos, hogy sokkal több bonyolultság van itt, mint elsőre látszik. Vannak technikai kihívások, amelyeket figyelembe kell venni, munkafolyamat-problémák, amelyeken el kell gondolkodni, és ott a felismerés, hogy a kurzusok elég széles skálán különböznek ahhoz, hogy valami az egyiknél gyors és könnyű, a másiknál fájdalmas legyen.
Tehát ahelyett, hogy azt javasolnánk: „miért nem futtatjuk le a teszteket beküldés előtt?”, tegyük fel inkább a kérdést: „Miért írnak le az emberek olyan megoldásokat, amelyek nem mennek át a teszteken?”
És ekkor lesznek izgalmasak a dolgok.
Az általános válasz: azért, mert elakadtak vagy össze vannak zavarodva.
És segítségre van szükségük.
Ez azt jelenti, hogy az elbukó tesztek beküldése nagyon fontos támpont a mentoroknak arra, hogy a tanulónak segítségre van szüksége.
Igen, ez frusztráló, mert a mentorok nem tudják azonnal, hogy a kód „helyes”-e vagy sem. Viszont le tudják tölteni a kódot, és lefuttatva ellenőrizhetik (a legtöbb mentor ezt teszi a nem triviális megoldásoknál), és így 100%-os biztonsággal tudják, hogy helyes-e vagy sem.
És az elakadt, segítségre szoruló tanulók nem kerülnek még mélyebbre, nem lesz még nagyobb szükségük segítségre, hanem olyan mentorhoz jutnak, aki gyorsabban észreveszi és javasolja a javításokat.
Megjegyzés: ezt valójában úgy oldjuk meg, hogy a teszteket a szerver oldalán futtatjuk. Ez nagy és költséges vállalkozás, de megéri a fáradságot a jobb tanulói élményért, és ami a legfontosabb, időt és energiát spórol a mentorainknak.
Van még valami?
Három dolog:
-
Ez a cikk a Second Order Thinking oldalán jó olvasmány. A „Ne bonts le egy kerítést, amíg nem tudod, miért állították fel eredetileg” idézet ebből a bejegyzésből származik.
- G.K. Chesterton The Thing című könyve itt érhető el: https://archive.org/details/G.K.ChestertonTheThing.
- Lehet, hogy az ötleted tényleg új és nagyszerű. Ne félj és ne szégyelld előadni!
