Hogyan lehet megérteni bármilyen programozási feladatot

Végre elérkezett a nap. Ez az első nap a munkádban, vagy tíz éve csinálod ezt? Nem számít. Végül mindannyian találunk olyan feladatot, amelyet egyszerűen nem értünk.

Tehát mit kell tennie? Csak nekilátna, és remélje, hogy működik? Azonnal szóljon a főnökének, hogy ezt nem teheti meg, mert nem érti?

Úgy képzelem, hogy tudja, hogy a válasz egyik sem!

A programozásban, mint bármely más szakmában, azt is tapasztaltam, hogy szinte lehetetlen egy hétet (sőt néha még egy napot sem) átélni anélkül, hogy valami problémát találnék, amit nem értek.

De ne izgulj! Remek híreim vannak. Nemcsak kijavíthatja ezt a problémát, de jó dolog is lehet.

Ez azt jelenti, hogy valamilyen módon kibővíti képességeit és tudását azon túl, amit korábban tett és ismert.

A következő bekezdésekben részletesen bemutatom, hogyan lehet áthidalni a szakadékot az átadott követelmények és a kapott feladat elvégzéséhez szükséges ismeretek között.

A „követelményekről”

Talán észrevette, hogy a „követelmények” szót használtam. Ennek a szónak bizonyos konnotációi lehetnek, attól függően, hogy hol dolgozik.

Tapasztalatom szerint a nagyvállalatok szeretik a követelményeket, a kisvállalkozások pedig néha „nem teljesítik a követelményeket”. Úgy gondolom, hogy ez tökéletesen megfelel itteni céljainknak.

Ennek az az oka, hogy a szoftver mérnököként végül csak a problémákat oldjuk meg.

Kiterjedt száz oldalas jelentést kaphat arról, hogyan oldja meg a problémát (egyszer volt egy órás találkozóm a gomb szövegéről). Vagy talán a vezérigazgató kanyarog az asztalához, és lazán megkérdezi, hogy péntekig meg tudja-e oldani a problémát.

Akárhogy is legyen - kaptál egy feladatot, és meg kell győződnöd arról, hogy teljesen megérted-e a problémát, hogy helyesen kezelhesd!

A lépésekről

Az alábbiakban megadott lépések nem minden esetben szükségesek. Csak a legnehezebben megértett problémák megkövetelhetik, hogy gondosan végezze el a cikkben tárgyalt összes lépést.

Előfordulhat, hogy sok kérdés nem felel meg az Ön által támasztott követelményeknek, vagy csak személyes tapasztalatainak köszönhetően.

Lehet, hogy kérdeznie kell más fejlesztőktől, a csapat vezetőjétől, a termék tulajdonosától, az üzleti elemzőtől vagy akár a nagymamától. Talán mindet meg kell kérdezned, mire elkészültél!

Pedig rendben van. Ez azt jelenti, hogy szétszórt tudást fogsz felhasználni, és egy helyre fogod sűríteni. Ez a hely önmagadban van, és most a lehető legjobb eredményt tudod elérni!

Utolsó figyelmeztetés, mielőtt megtanulná a lépéseket: ne formálja túl a folyamatot. A lényeg itt az, hogy segítsena probléma gyors megértésében. Nem szabadna akadályokat vagy bürokráciát teremteni! Ehelyett szisztematikus tervet kell készítenie egy olyan probléma megoldására, amelyet nem ért.

Az első lépés: A feladat elemzése

Ebben a lépésben arra törekszik, hogy megértse, mire kérték. Még nem próbálja kitalálni, hogyan kell csinálni!

A megkülönböztetés itt fontos. Veszélyes lehet egyenesen áttérni a megvalósításra, anélkül, hogy végiggondolná az összes következményt, vagy ami még rosszabb, anélkül, hogy pontosan azonosítaná, mire kérték.

Besorolja a feladatot

Egy feladat besorolása azt jelenti, hogy meghatározzuk, milyen munkát fog végezni a probléma megoldása érdekében. Íme néhány példa a feladatok típusaira:

  • Hibajavítás
  • Új funkció
  • Új alkalmazás
  • Kutatási feladat
  • Teljesítmény fejlődés

Ne feledje, hogy ezek nem minden lehetséges lehetőség.

A cél itt az, hogy meghatározzák, milyen munkát végeznek tőled. Ez azért fontos, mert közvetlen hatással van arra, hogy milyen munkát végez.

Ez a lépés különösen fontos a homályos követelmények esetén. Példa egy homályos követelményre: "Szükségünk van arra, hogy megtisztítsuk ügyfeleink gyorsítótárát a webhely frissítése után."

Néhány lehetséges értelmezés lehetséges.

  1. Azonnal végre kell hajtania néhány gyorsítótár-kiürítési mechanizmust, hogy az ügyfelek mindig láthassák a legújabb frissítéseket.
  2. Meg kell vizsgálnia az ügyfelek gyorsítótárainak összes tárolási módját, és meg kell határoznia a gyorsítótárak lebontásának legjobb módját vagy módjait a webhely minden frissítése után.
  3. Az ügyfelek gyorsítótárait már törölni kell, és meg kell találnia és kijavítania azt a hibát, amely megakadályozza őket a törlésben.

Ezen a ponton, ha nem biztos abban, hogy melyik jelentést használja, akkor a folytatás előtt kérjen magyarázatot.

Mondja el, mi a feladat, egy-két egyszerű mondatban.

Foglalja össze a bonyolult követelményeket, mintha megkérdezték volna, min dolgozik ma. Talán nem lesz ilyen egyszerű, de képesnek kell lennie leforrázni egy-két mondatra.

Ha nem tudja összefoglalni a feladatot, az valószínűleg azt jelenti, hogy fel kell osztania több feladatra. Tehát lényegében ez a lépés válik lakmuszpróbává annak megállapítására, hogy elég kicsi darabokra rendezte-e a feladatait.

Íme egy jó példa egy összefoglalóra: "A webhely frissítésekor egyedi számot fűzünk a fájlokhoz, hogy a böngésző tudja, hogy a legújabb kódot kell használnia."

Ez a feladat megfelel az egyszerűséges lakmusz tesztnek, és valószínűleg nem kell több feladatot létrehoznia.

Egy rossz példa a következőképpen nézhet ki: A webhely frissítésekor egyedi számot fűzünk a fájlokhoz, hogy a böngésző tudja, hogy a legújabb kódot kell használnia. Üzenetet kell küldenünk a CDN-nek is, amelyben közöljük vele, hogy frissítenie kell a fájlokat. Az IOS és az Android alkalmazásoknak is frissítést kell küldeniük az alkalmazásboltba. Szintén…"

Ez egyértelműen nem sikerül a teszten. Nagyon sok a munka, és szükség lehet külön azonosításra és nyomon követésre.

Vázolja a főbb részeket

Bármilyen formában a legkényelmesebb az Ön számára, most össze kell állítania a főbb tennivalókat.

Ezeknek továbbra is nagyon egyszerű összefoglalóknak kell lenniük az egyes nagyobb lépésekről.

Ezek nem lehetnek lépésről lépésre vagy részletes útmutató a probléma megoldására.

Ne feledje, hogy még mindig elemzi a kapott feladatot. Javasolnám valahogy ezeket leírni. Személyesen rögzítem őket a Notes alkalmazásomban.

Gyorsítótárazási feladatunk nagyon egyszerű, és lehet, hogy valójában nincs szükség körvonalra. Ebben a példában egy összetettebb kérdést fogunk megvizsgálni.

A következő feladatunk egy új funkció: „Minden felhasználónak meg kell jelenítenie egy belső termék célzott hirdetését. Ezt a hirdetést az általunk összegyűjtött adatok alapján kell egyedi igényeiknek megfelelően alakítani. "

A főbb részek vázolásához világosan át kell gondolnia, hogy a követelmény egyes részei mit fognak csinálni.

  • A jelenlegi hirdetéseinket úgy kell lebontani, hogy azok korrelálhassanak valamilyen konkrét felhasználói mutatóval.
  • Marketing csapatunknak módot kell adnia arra, hogy új hirdetéseket feltérképezzen egy vagy több felhasználói adatra (kódolás nélkül!)
  • A rendszernek összesítenie kell egy felhasználó mutatóit, amelyek relevánsak a hirdetéseink szempontjából.
  • Végül létre kell hoznia valamiféle rendszert, amely megkapja a felhasználói azonosítót és kiad egy hirdetést.

Egy ilyen lista szépsége, hogy fel lehet használni a csapat vagy a főnök gyors igazolására! Tehát ebben a példában talán a csapat vezetője vezette, és úgy döntött, hogy még egy fő darabra van szükség:

  • A felhasználóknak meg kell tudniuk mondani nekünk, hogy mikor akarnak többet látni bizonyos hirdetéseket.

Mert végül is nem akarjuk bosszantani szeretett felhasználóinkat! Azzal, hogy csak néhány percet szánunk arra, hogy csak néhány percig gondolkodjunk a feladatunkon, később órákon vagy napokon át megtakarítottuk a fájdalmat azáltal, hogy azonosítottunk és megterveztünk egy fontos feladatot, mielőtt belekezdtünk a kódolásba.

Mielőtt továbblépnénk, szeretnék egy esetleges kritikát felvetni, amely esetleg felmerül benned.

Gondolhatja: „Egy megfelelő vállalkozásnál ezt a munkát kell elvégezni, mielőtt a követelmények valaha is elérnék a fejlesztőt”, és határozottan egyetértek veled!

Sajnos azonban nem egy tökéletes világban élünk. Előfordul, hogy a követelmények nem mindig teljesülnek teljes mértékben, mielőtt egy fejlesztőhöz kerülnének. Ez azt jelenti, hogy a fejlesztés megkezdése előtt mindannyiunknak meg kell tennünk a követelmények megfelelő értékelését.

Határozza meg azt a problémát vagy problémákat, amelyeket megpróbál megoldani.

Válaszoljon a kérdésre: „Miért fogja ezt valaki használni?”, Vagy „Milyen valós vagy vélt valós problémát próbálok megoldani?”

Remélhetőleg a válasz nyilvánvaló. Gyorsítótár példánkban azt mondhatja, hogy "a felhasználók mindig látják a legújabb frissítéseket". A hirdetési példa esetében „a felhasználók releváns hirdetéseket fognak látni a nem érdekelt hirdetések helyett.”

Ha a válasz nem nyilvánvaló, akkor valószínűleg ideje megkérdezni valakit, miért végzi ezt a feladatot! Ennek a kérdésnek a feltevése azt fogja eredményezni, hogy vagy tisztábban érti a feladatot, vagy újragondolja, hogy mit is kértek tőle.

Remélhetőleg látja ezeknek a válaszoknak az előnyeit! A probléma és a cél mélyebb megismerése lehetővé teszi, hogy olyan döntéseket hozzon a megvalósításban, amelyek valóban az üzleti célokat szolgálják. Ha nincs értelme a rossz megoldásoknak vagy problémáknak, akkor elkerülhető a munkára fordított erőfeszítés, amely végül soha nem oldana meg egy problémát.

A második lépés: A követelmények értelmezése és értékelése

Ezen a ponton meg kell értened, hogy mit fogsz csinálni, és miért csinálod.

A következő lépés annak megértése, hogy mit csinálsz, hogyan várható el tőled, és miért csinálod így.

Tisztázza a feladattal kapcsolatos összes fontos kifejezést.

Megállapíthatja, hogy ez a lépés fontosabb, ha új fejlesztő vagy a csapatban, vagy ha nagy cégnél dolgozik. Mindkét helyzet valószínűsíti, hogy ismeretlen kifejezéseket talál a követelményeiben.

A kifejezések lehetnek üzleti feltételek, például a termékek, az ügyfelek vagy a folyamatok neve. Lehetnek olyan fejlesztési kifejezések is, mint az eszközök, alkalmazások, modellek, szolgáltatások vagy könyvtárak neve.

Biztosnak kell lennie abban, hogy minden fontos fogalmat megért, homályosság nélkül, hogy biztos lehessen benne, hogy helyesen hajtja végre feladatát.

Lehet, hogy megértette, hogy létre kell hoznia az összesített felhasználói információk elérésének módját, de megérti-e, mit jelent hozzáadni a „dao” -hoz?

Lehet, hogy megértette, hogy formáznia kell a hirdetési adatokat, de megértette-e, mi az a „MADF” (A hirdetési adattáblázat jelölése)?

Én sem.

Ezért meg kell határoznia és meg kell határoznia az összes fontos kifejezést. Nagyobb esélye van a feladat helytelen végrehajtására, ha rosszul értelmezi a definíciókat.

Határozza meg, hogyan kell elvégezni a feladatot

Ezen a ponton most el kell kezdenie vizsgálni, hogyan kell elvégezni a feladatot. Ez a lépés nagyban változhat attól függően, hogy hol dolgozik, és az adott feladattól.

Néhány csapatnál nem fogják megmondani, hogy miként hajtsák végre a követelményeket, csak azt mondják el, hogy milyen funkciókkal kell végződnie.

Mások részletezik minden lépését, amelyet meg kell tennie.

Valószínűleg a tapasztalata valahol a közepén esik.

Ha csapata nem adott utasításokat, akkor nem sokat tehet ebben a lépésben. Ha kapott utasításokat, akkor ezen a ponton kezdje el megismerni a szükséges lépéseket.

Ez a lépés elég kézenfekvőnek tűnik, de a beérkezés sorrendjére különös figyelmet kell fordítania.

A természetes hajlam az lehet, hogy elmélyülünk a feladat minden részletében, mielőtt megbizonyosodnánk a feladat céljának megértéséről.

Mivel időt szánt arra, hogy először megismerje feladatát, most egyértelműbb célt fog szem előtt tartani a megteendő lépések értékelésekor.

Határozza meg, hogy a problémák megoldódtak-e

Itt jön össze az elemzési szakasz és az értelmezési szakasz. Az elemzési szakaszban a nagy kép célkitűzéseire és eredményeire, a mire és miért koncentrált .

Az értelmezés lépésben középpontjában a részleteket, a hogyan .

Értelmezésnek és értékelésnek hívják azt, hogy most összehasonlítja a hogyan és mit és miért elemét. A részleteket a nagyobb kép figyelembevételével értelmezi. Értékelni fogja a részleteket, és megállapítja, hogy megoldódott-e az eredeti probléma.

Kérdezd meg magadtól: Az általam megadott lépések azt az eredményt eredményezik-e, amelyet a feladatod célja volt? Vajon ez az eredmény valóban megoldja az eredeti problémát?

Ha biztos benne, hogy minden probléma megoldódott, és minden részletnek van értelme, akkor készen áll a munkája megkezdésére! Ellenkező esetben a konfliktusok megoldásához a harmadik szakaszba kell lépnie.

A harmadik lépés: Gondolkodj kritikusan

Ebben a szakaszban magabiztosan ki kell tudni jelenteni, hogy megérti a problémát és a megoldást. A legutolsó lépés annak biztosítása, hogy megfelelő megoldást találjon.

A lehető legjobb termék létrehozása érdekében mindannyian úgy érezzük, hogy felelősségünk van megszólalni, ha valaminek éppen nincs értelme.

Másrészt nem akarunk soron kívül nem érteni egyet. Nem szabad mondani, hogy valami nincs rendben, mert „rosszul érzi magát” vagy azért, mert „nem szeretem”. Biztos konkrét és jól átgondolt okai vannak.

Tehát tegyünk le néhány alapszabályt a nézeteltérésekről.

Tudja, mikor nem ért egyet

  • Ne értsen egyet, amíg nem érti meg teljesen.

Soha ne mondd, hogy valami nincs rendben, amíg nem vagy teljesen biztos abban, hogy megérted, miben nem értesz egyet.

Ha nem tudja magabiztosan megfogalmazni a problémát és a tervezett megoldást, akkor nem szabad egyet nem érteni. Ha még nem ellenőrizte megértését, akkor nem szabad ellentmondania. Csak akkor kezdjen el egyet nem érteni, ha tudja, hogy a lehető legteljesebb megértéssel rendelkezik.

Ha úgy találja, hogy nem rendelkezik minden szükséges információval, akkor itt az ideje, hogy megálljon és áttekintsen az előző lépések bármelyikén, mielőtt elmondja valakinek, hogy a követelmények helytelenek.

  • Ne nézzen egyet a szubjektív kérdésekben. Koncentráljon a tényleges lehetséges problémákra.

A „nem szeretem, hogyan történik ez” szubjektív. "Ez teljesítményproblémákat fog okozni az érintett műveletek száma miatt." objektív ok. A szubjektív okok további példái a következők lehetnek: "Nem így tettem máshol" és "Ezt a megoldást kissé másképp terveztem volna, de csak a személyes preferenciák miatt."

  • Készítsen jól megalapozott magyarázatokat nézeteltéréseire, amelyeket előadhat.

Ha nem tudja megmagyarázni, hogy miért nincs rendben valami, akkor valóban azt mondhatja, hogy valóban tudja, hogy baj van? Azt javaslom, írja le azokat az okokat, amelyek miatt valami nincs rendben, és mit lehetne tenni annak kijavítására.

Alternatív megoldásként, ha nincs megoldása a javításra, az elején egyértelműen állítsa, hogy nem tudja.

Legyen óvatos, ha nem ért egyet másokkal. Időjének nagy részét megértésre és hallgatásra kell fordítani, mielőtt nem ért egyet.

Ha minden lépést betartott eddig a pontig, akkor nagy valószínűséggel jó megértése van. De nagyon ügyeljen arra, hogy nyitott legyen, hogy esetleg elmulasztott valamit!

Szeretem a beszélgetéseket azzal kezdeni, hogy: "Nem értek egyet veled, csak nem értem." Később jön a nézeteltérés, ha szükséges, de remélhetőleg soha megértés előtt.

Tudja, hogyan nem ért egyet

Annak érdekében, hogy objektív nézeteltérésünk legyen, az alábbiakban bemutatunk néhány intézkedést, amelyek segítenek megállapítani, hogy egyet nem értése érvényes-e.

Objektív nézeteltérések az alábbiak közül egyet vagy többet tesznek:

  • Mutassa meg, hogy a megoldás tájékozatlan.
  • Mutassa meg, hogy a megoldás téves.
  • Mutassa meg, hogy a probléma vagy a megoldás logikátlan.
  • Mutassa meg, hogy a megoldás hiányos.

A tájékozatlanság nem sértés, hanem azt jelenti, hogy a megoldás létrehozásakor hiányoztak az információk. Talán nem tudtak egy olyan rendszerről, amely jelenleg létezik, és képes végrehajtani a szükséges műveleteket.

Téves tájékoztatás azt jelenti, hogy a megoldás helytelen információkból származott.

Ebben az esetben azt gondolhatják, hogy egy létező rendszer olyasmit tesz, amit valójában nem. Például a SEO (keresőmotor-optimalizálás) csapata kérte, hogy a Google indexelje a bejelentkezett oldalt az alkalmazásában. A Google ezt nem tudja megtenni. Tévesen tájékoztatták őket arról, hogy mit csinál a Google robotja.

Az logikátlan probléma vagy megoldás olyan, amelynek egyszerűen nincs értelme. Fejlesztőként úgy gondolom, hogy egy általános logikátlan kérés egy olyan szolgáltatásra vonatkozik, amely megtörheti egy másik funkciót. Ezt logikátlannak lehetne tenni, mert ez inkább ártana, mintsem segítene.

A hiányos megoldás valóban célja lehet. A szoftverfejlesztésben gyakran egy MVP (minimum életképes termék) elkészítésével próbálunk indulni. Ez azt jelenti, hogy eleinte szándékosan elhagyhatunk olyan funkciókat, amelyek nem feltétlenül szükségesek.

Ehelyett csak akkor tekintheti hiányosnak a megoldást, ha az nem oldja meg az azonnali problémát, amelyet kértek tőle, vagy ha a megadott lépések nem elegendőek egy működő termék vagy szolgáltatás létrehozásához.

Összegzés

Ne feledje, ne formalizálja ezt a folyamatot túlzottan. Gyorsnak kell lennie, és valószínűleg abból áll, hogy feljegyez néhány gondolatot a Notes alkalmazásban. Ez esetleg pár beszélgetéshez vezethet a munkatársaival annak tisztázására, hogy mit kellene tennie. Ez minden!

Íme a lépések egyszerűsített listája:

1. lépés - Elemzés

  • Osztályozás
  • Összegzés
  • Vázlat
  • Határozza meg a problémát

2. lépés - Értelmezés és értékelés

  • Tisztázza a feltételeket
  • Határozza meg a feladatokat
  • Határozza meg, hogy a probléma megoldódik-e

3. lépés - Gondolkodj kritikusan

  • Tudja, mikor nem ért egyet
  • Tudja, hogyan nem ért egyet

Szia, Justin Fuller vagyok. Nagyon örülök, hogy elolvastad a hozzászólásomat! Meg kell, hogy tudd, hogy minden, amit írtam itt van a saját véleménye, és nem célja, hogy képviselje az én munkáltató semmilyen módon. Az összes kódminta saját, és teljesen nem kapcsolódik a Bank Of America kódjához.

Szívesen értesülnék rólad, kérem lépjen kapcsolatba velem a LinkedIn, a Github vagy a Medium webhelyen. Még egyszer köszönöm, hogy elolvastad!