Java tanulás

Múlt héten kezdődött a szorgalmi időszak. Azóta ismerkedek a java-val. Próbálok itthon minél többet gyakorolni ( ez a módszer C-ben bevált). A tanár közölte, hogy a C-vel ellentétben itt már nem lesz kötelező az előadások rendszeres látogatása. Úgy érzem mégis jobban járok ha ott vagyok az előadásokon. A gyakorlatok meg természetesen kötelezőek. Még nem sikerült mindent felfognom, nagyon C-ben gondolkozok még (azt hogy számot csak konvertálva tudok beolvasni és hogy ezt hogy tudom kivitelezni kb két óra volt felfogni), viszont a dinamikus memóriafoglalás egyszerűsége nagyon tetszik.

( Hevi v | 2014. 02. 26., sze – 22:13 )

Nem egy nagy ördöngősség a Java, igazából az OOP-t kell felfogni, utána meg Design Patterneket nézegetni, hogy ne találd fel feleslegesen a melegvizet. Bár mondjuk ez utóbbi nem feltétlenül első féléves Java. Mindenesetre, ha tudod (és az előadó is tudja), akkor próbáld rábeszélni a Unit Test-ekre is, elég gáz, hogy emberek úgy jöhetnek ki egyetemről (köztük én is, ha befejeztem volna), hogy soha nem hallottak róla.

+1
Ugyanahhoz a feladathoz több kódot kell írni, rutinszerzéshez kiváló. Nagyobb feladatoknál a teszt kód már azelőtt használni kezdi friss kódot, mielőtt a program többi részét megírnád hozzá, hamar kiderülnek a design-beli hiányosságok is. Akkor jöhet a refactoring. Minél előbb rutinná válik a tesztírás, annál jobb. Ráadásul bármilyen nyelven programozol, unit tesztek nélkül csak vakrepülés.

Komoly :D De hogy miért msc-n? Majd biztos a kutató-fejlesztő fog csak teszteket irogatni, a kódoló-kulimunkás nem :)

Szerk: ezeket amúgy valahogy 1.-2. félév BSc körül tudnám elépzelni.

Amúgy mintha egyik kolléga járna BME-re pont teszteléssel kapcsolatban előadni, majd rákérdezek megint.

Szerk2: A TDD-t már meg se merem említeni...

BME-n a BSc-n is vannak szakirányok, igaz csak a 6. félévtől (ez szerencsére változni fog, egy félévvel előbb kezdődnek majd).

BME mérnök infó bsc-n nagyjából a képzés fele szól szoftverfejlesztésről, és csak a másik fele minden másról, gondolom máshol is hasonló az arány.

"Miért tanítanának ilyet mindenkinek aki informatikával foglalkozik, ráadásul kötelező jelleggel"

Talán mert a munkaerőpiacon erre van a legnagyobb igény.
Csak ez a képzés még mindig kevés, épp ezért nem jelent olyan nagyon sokat ha van papírod egy egyetemi képzésről, vagy nincs.

De az IT nem kizárólag szoftverfejlesztésről szól, csak azoknak érdekes ez amiről szó van.
Ilyen kimutatást meg még sosem láttam, hogy a munkaerőpiacon a szoftverfejlesztőkre van a legnagyobb igény az IT szektoron belül. Viszont nagyon kiváncsi lennék rá, ha nem csak hasraütésből írtad hanem alá tudod támasztani valamivel.

http://www.portfolio.hu/gazdasag/vegtelen_szamban_tudunk_programozokat_…

Profession:
IT Fejlesztés, Programozás: 902 állás
IT üzemeltetés: 325 állás

Azaz az IT állások közel 75%-a szoftverfejlesztés a legnagyobb állásportálon.

Munkaügyi hivatal (nagyon kevés állás van itt, de ezek nagy része is fejlesztő):
https://vmp.munka.hu/allas/talalatok?kulcsszo=&helyseg=&kategoria=13&ti…

A portfolios cikket sajnos nem tudom megnézni mert előfizetés kéne hozzá.

A professionön valóban sok az állás abban a kategóriában, de azért azt tegyük hozzá, hogy ott nem csak a fejlesztői állások vannak, hanem az adminisztrátori, supportos, tesztelői és projektvezetői állások is. (de az első 10 oldalt átnézve látszólag a fejlesztői állások vannak túlsúlyban)

Én meg tudom nézni, előfizetés nélkül is. Google-ből rákeresve a cikk címére, simán elérhető a tartalom.

A releváns mondatok:
"P.: Vannak olyan területek, ahol munkaerőhiány van, vagy erre számíthatunk 2014-ben?

F.T.: Itthon továbbra is az IT, szinte végtelen számban tudnánk még programozókat elhelyezni a piacon. "

Design Pattern témakörben merre érdemes elindulni? Mondjuk ha koordináltabban szeretném tanulni, minthogy fejest ugorjak a Google-ba.

Egyébként ha már Unit test, ez is érdekelne.
Kb. annyit sikerült a lejjebb linkelt gyakorlat során felfognom belőle, hogy egyes függvényeknek jó előre meghatározom az adott bemenethez elvárt kimenetét. Pl.: ha nem találja, amit meg akarok nyitni, dobjon exceptiont; ha nem tudja megnyitni, dobjon exceptiont; ha megnyitja, akkor meg olvassa be a 142. sorának 69. karakterét. S akkor odarakok egy fájlt, amiben a 142. sor 69. karaktere 'x', az összes többi 'a', s boldog vagyok, ha tényleg azt olvasta be.
De van egy olyan érzésem, hogy nem „éreztem rá az ízére”, mert ez így, hát, hogy is mondjam... Olyan fapados.
--
blogom

Design Pattern:

Jó kezdés a wiki. Innen is, montjuk a Creational Patterns, ami kezdetben érdekes lehet :) Meg a Gang of Four - Design Patterns könyve :)

Unit Test: a te példád az inkább már Intergation Test, nem Unit Test. A Unit Test lényege az, hogy csak az adott osztályt / adott kódrészletet teszteled, de semmi függősége nem lehet, mert az befolyásolhatja az eredményt. Ha a példádnál maradunk, akkor a file műveletekért felelős osztály ki kell Mockolni. A mock az egy dummy osztály, amit legenerál neked a Mocking framework, csak annyit kell megmondanod neki, hogy "ha ezt csinálom, akkor ezt adja vissza". Ld. EasyMock, vagy preferáltabban Mockito.

Ezáltal függetlenedsz pl. a file rendszertől, meg úgy egyáltalán, hordozható lesz a teszt kódod, nem kell mindenkinél ugyanott lenni a teszt file-nak, hiszen nem is kell, hogy legyen, az az objektum, amit használnál, az fake, ki van mockolva. Általában amúgy azt szoktuk mondani, hogy nem kell kimocolni a Java által szállított containereket (de ha egyszerűbb, akkor persze lehet), pl. Array, Map, Set, stb., a domain objecteket, amiben nincs logika, csak tárol valamit, illetve a (megbízhatónak mondott) framework által szállított containereket se.

Bármi mást, ami logikát tartalmaz, legyen saját kód, vagy külső, azokat illik mockolni, hiszen, ha nem mockolod, akkor előbb fel kell konfigurálni az adott osztályt, amitől függ a te kódod, amit tesztelsz, másrészt akkor már nem csak a saját kódodat, hanem a másikat is teszteled. Ezáltal nem lesz megjósolható a pass/fail, hiszen ha elbukik egy Unit Test, ami dependál másra, ott akkor nálad van a gond, vagy a másik osztályban? Oké, általában triviális a dolog, de a Unit Testben pont azt szeretjük, hogy egyértelműen megmondja, mi a gond.

Ezért is van az az ököl szabály, hogy egy UT metódusban csak egy valamit tesztelünk. Unit Testben nincs helye pl. if-else-nek, mert akkor az két külön teszt eset. Hiszen így marad egyértelmű a hiba, ha valami fail-el.

Szerk: és így van, a Unit test "fapados". Abban az értelemben, hogy csak a tesztelt osztály/metódus logikáját teszteli. Ha az osztályod feladata az, hogy kezelje a hibákat, illetve ha az X. sor Y. betűje 'a', akkor azt cserélje ki 'b'-re, akkor azt kell tesztelned, hogy a hibákat jól kezeli-e, illetve, hogy az X. sor Y. betűjét lecserélte-e 'b-re', viszont az X. sor Y-1. betűjét és az X. sor Y+1. betűjét (+ esetleg az X-re is lehet teszteseteket írni, követelmény függvényében) nem cserélte le 'b'-re -> ezek is lehetnek külön test metódusok.

Szóval annál jobb az osztályod/metódusod, minél fapadosabb a unit tested, hiszen ezáltal sikerül betartani a Single responsibility principle-t :)

Szerk2:

Ezért jó a TDD, mert ha túl összetett a unit tested, az azt jelentheti, hogy sérted az SRP-t, tehát be tudsz vezetni rögtön egy külön osztályt, amit mockolsz és később majd azt is implementálod.

Ezáltal függetlenedsz pl. a file rendszertől, meg úgy egyáltalán, hordozható lesz a teszt kódod

Tegnap blogmarkolták a weblaboron Robert C. Martin - Clean Architecture and Design c. előadását (érdemes megnézni, nagyon a vége felé van szó benne unit testelésről és tdd-ről), amiben pont ezt a példát hozta (fájl rendszer / adatbázis mockolás), legnagyobb előnynek a sebességet hozva: ha nincs tényleges I/O, akkor a teszt gyorsan fut, ezért a tesztet le is fogják futtatni :)

Szerk.: az Andy Hunt - Dave Thomas féle Pragmatic Unit Testing könyv érdekes lehet a témában, a kugli a címére keresve 3. találként kidob egy PDF-et.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A unit testinget jUnit-tal pont emiatt kezdeném el rögtön. Egyszerű koncepció, egyszerű framework. Plusz később hálás leszel magadnak, hogy berögzült szokássá tetted a unit testinget.
Nem vagyok híve a 100% code coverate at all cost dogmának, de amíg 50-80%-ra lefedsz egy kódot tesztekkel egy csomó hasznos dologra tudsz bukkani a saját kódodban: visszatérő hibák, rossz tervezés, stb.