Legjobb válasz
Érdekes kérdés. Számomra a “kézművesség” kifejezés magában foglal valamit a tényleges kód írásmódjában, nem pedig a magasabb szintű rendszer kialakításában. Azt mondanám, hogy a jól kidolgozott kód a következőket teszi:
- követi a külső szabványokat
- követi a belső szabványokat
- jó mintákat használ
- olvasható
A külső szabványokat követi. Ha csoportjának vannak kódolási szabványai, kövesse azokat. Ha nem ” tetszik a szabványoknak, továbbra is kövesse őket.
A belső szabványokat követi. Ez azt jelenti, hogy a kódnak belsőleg konzisztensnek kell lennie. A hasonló dolgokat végző módszereket ugyanúgy kell meghatározni. Ha az egyik módszer a mintát követi:
if (success) {
doSomething();
} else {
handleError();
}
“Ne használjon másik metódust, amely kezdődik:
if (!success)
{
handleError();
Jó mintákat használ. Ez alatt a minták kódolását értem, nem pedig a Tervezési mintákat. A kódnak a nyelvnek megfelelő idiómákat kell használnia. (Használjon scoped\_ptrs memóriakezeléshez például a C ++ nyelven.) El kell kerülnie a nyilvánvaló hatékonyságot, például a C ++ iterátorok utólagos növelését, vagy a létrehozását. azokat az objektumokat, amelyeket nem használnak minden kódúton.
Olvasható. Más mérnökök elolvassák a kódot, és Ön újra elolvassa egy év múlva. A kódnak a lehető legkönnyebben érthetőnek kell lennie. A fent említett elemek mindegyike elsősorban az olvashatósággal és a váratlan elemek minimalizálásával foglalkozik. Olvasóinak a kód logikájával kell foglalkoznia, nem pedig azzal, hogy megpróbálja kideríteni, miért használtak egy nem szabványos konstrukciót. Ha van egy nem szabványos konstrukció, akkor olvasóinak tudnia kell, hogy okkal van ott, nem azért, mert hibáztál. (Úgy gondolja, hogy a kódja olyan, mint egy bútordarab. A felülete legyen sima, és ne ragadjon meg szilánkot, ha végighúzza rajta a kezét. Minden szabálytalanságnak okkal kell lennie.)
Az olvashatóságot ésszerű módszer és változónevek, valamint megfelelő megjegyzések is javítják. Ne essen túlzásba a kommentelésnél. Ha ez nyilvánvaló, ne törődjön azzal, hogy elmagyarázza. De legyen valamilyen áttekintés, hogy az olvasó ismerje a kontextust. (Nyilvánvaló lehet, hogy a kód az X bemenetet Y kimeneté alakítja, de segít, ha az olvasónak van valamilyen fogalma arról, hogy miért van erre szükség.)
Válasz
A menedzserek olyanok, mint kisgyermekek. Azt akarják, amit akarnak, és akarják MOST ! De a kisgyermekekkel ellentétben a vezetők félig emlékeztek Harvard Business Review cikkekre, amelyeket idéznek (hivatkozások megadása nélkül), hogy igazolják igényeiket. Megtanultak egy olyan argumentumkészletet, amely néhány fejlesztőt megbuktat.
Azt mondják: „Nem engedhetjük meg magunknak , hogy ezt helyesen csináljuk. A piacon kell beszereznünk MOST ! ”. Nem igaz, tudod. Ha a gyártásba sielik spagettikódjukat, esélyt kapnak arra, hogy most feldühítsék az indító ügyfeleket, de a kód nem méretezhető. Ez csak azt jelenti, hogy üzleti tevékenységük egy darabig összeomlik, mielőtt összeomlanak.
Azt mondják: „Bétát adunk ki az induló ügyfeleinknek.” Arra gondolnak, hogy azt akarják, hogy a tökéletes, az ügyfeleknek tetsző kódot hamarabb bocsássa ki, mint egyébként, csak azért, mert beleegyeztek, hogy béta teszt programnak hívják. Varázslatos gondolkodás, akárcsak a Mikulásban való hinés.
Azt mondják: „Ígérem, hogy később átírjuk a kódot, ha elengeded a vacak, félkész kódodat MOST ! ” Nem úgy hangzik, hogy “később megtisztítom a szobámat, apa, ha tévét nézhetek és cukros falatokat fogyaszthatok MOST ?” A probléma az, hogy később soha nem jön el. A menedzser minden nap választhat, hogy új funkciókat vesz fel, vagy megtisztítja a rendetlen szobát, amely a kódja. Találd ki, hogy melyeknek adnak elsőbbséget. És találd ki, a szoba egyre rendetlenebb lesz, így egyre hosszabb ideig tart a takarítás. Az összes rendetlenség miatt is nehezebb dolgozni (új funkciók létrehozása).
Végül azt mondják: „Túl sokat fektettünk ebbe a kódbázisba. Túl sokáig tart átírni. Szükségünk van funkciókra MOST ! ” Csak minden funkció kétszer-háromszor annyi időt vesz igénybe a kódolás, mert a rendetlen szoba miatt a szoftverfejlesztők technikai adósságnak nevezik.
A jó fejlesztőknek, mint a türelmes és szerető szülőknek, meg kell állítaniuk az őrületet. Határozottan ragaszkodniuk kell hozzá: „Bocsánat szerelmem, de HBR cikked azt mondja:” A bevétel hamarabb jobb, minden más dolog egyenlő . ”Alaposabban el kell olvasnia.Minden más dolog nem egyenlő, ha technikai adósságot halmoz fel. Mi lenne, ha prioritásként kezeljük a funkciókat, és talán lesz valami, amit korábban eladhatna. ”
Felnőttnek kell lenned, és el kell engedned nekik, hogy nincs olyan, hogy Mikulás, és nincs például tökéletes, vevőnek tetsző kód mindaddig, amíg az összes hibát el nem távolítják és az összes funkciót be nem hajtják.
Meg kell mondani nekik: „Nem engedhetjük meg magunknak nem a bevált gyakorlatok alkalmazásához. Élünk, vagy meghalunk, de bizonyos dolgokat meg kell tennünk azért, hogy éljünk, például teszteket és dokumentációt kell írni. Ez nem választható. ”
Mosolyogva kell mondanod:„ Ezt a kódot soha nem fogjuk átírni. Tudom, hogy jól érted, de amikor a kód javításáról vagy új funkciók hozzáadásáról van szó, tudom, mit fogsz mondani. Ez az, amit mindig mondasz. ”
Azzal, hogy határozott szülő vagy, segíted a menedzserednek felnőni olyan üzleti vezetővé, mint te dolgozni akarna.