- néhány kiosztott feladatnál én vagyok a reviewer (elsősorban olyan feladatoknál, ahol nem az API használat a lényeges, hanem bizonyos algoritmikus / üzleti megoldások, így ugyanis, hogy napi szinten nem kódolok, a forráskód elviségét tudom elsősorban áttekinteni és véleményezni, nem a helyes külső API paraméterezéseket)
- főleg nagy átadások során (akár UAT, akár éles átadás után), ahol az első hetekben azért sok apróság tekintetében jön visszajelzés, egy-egy, az adott projektnél teljesen "lokális" probléma esetén én végzem el a javítást (szintén általában ott, ahol elvi probléma volt a korábbi megvalósítással, és nem valamilyen rossz paraméterezés)
- időről időre felmerül kisebb, belső használatú, vagy projektnél egyszer lefutó kis utility-k készítése, ahol messze nem feszítő a határidő, azok közül is van, amit még bevállalok
- van egy nagy álmom is :) bár alapvetően a projektjeink dokumentálva vannak, még érzek "fehér foltokat" kifejezetten a belső fejlesztői dokumentáció tekintetében (azaz, kellene egy olyan anyag, ami mélyebb/más jellegű, mint az ügyfelek felé átadott informatikai specifikáció, viszont továbbra is főleg a felső szintű áttekintést biztosítja, viszont ezt fejlesztői oldalról, segítve az adott projektben új embereket a minél gyorsabb bekapcsolódásban)
Persze, amellett, hogy igyekszem azért "kódközelben maradni", viszonylag rendszeresen figyelem azokat a változásokat, újításokat, amelyek segítségével az eszköztárunkat hatékonyan lehet bővíteni / fejleszteni. Mi JVM alapú rendszereket készítünk, középméretű (néhány százezer "saját kódsor") nagyvállalati szoftvereket, ahol vagy webszolgáltatás alapú API-t biztosítunk, vagy webes felhasználói felületet, és jellemzően kell más rendszerekkel kommunikálni, ill. oda kell figyelni a nagyvállalati biztonsági és egyéb előírásokra. Java-ban (most már a 8-as verzióban is), illetve Spring keretrendszer, Hibernate, JOOQ viszonylag nagy tapasztalattal rendelkezünk, de, mivel a projektek közül sok már jó néhány éve kezdődött és azóta is működik (rendszeres finomítással/továbbfejlesztéssel), már sok külső könyvtárral ismerkedtünk meg, amelyeknél most már vannak ügyesebbek / jobbak / "teljesebbek".
Ha most, 2018 év végén, 2019-ben kellene új rendszert kezdeni a fenti területen, akkor szívem szerint a következő technológiai stack-et használnám (amiről úgy érzem, hogy nem hátráltatna, és a mostanában nálunk futó nagyvállalati projektkörnyezetben is kiválóan alkalmazható lenne):
- Futtatókörnyezet: JVM, Java 8 vagy Java 11
- Programozási nyelv: Kotlin 1.2
- Felhasznált 3rd party keretrendszerek, könyvtárak:
- Egyszerűbb esetekben:
- DB kezelés: Spring JDBC vagy, ha csak alapok kellenek, akkor Exposed (https://github.com/JetBrains/Exposed)
- Web API: Ktor (http://ktor.io/)
- Kiegészítések a standard Java / Kotlin osztálykönyvtárakhoz:
- Eclipse Collections (https://github.com/eclipse/eclipse-collections/)
- Spring Framework (IOC konténerhez)
- Ha nagyobb/bonyolultabb dolog kell / web GUI kell hozzá, akkor a fentiekhez kiegészítésképpen:
- Web GUI: követelményektől / körülményektől függően ReactJS (+PrimeReact: https://www.primefaces.org/primereact/#/) vagy JSF (PrimeFaces: https://www.primefaces.org/showcase/)
- Backend: Spring Boot 2 (https://spring.io/projects/spring-boot) és függőségei
- Unit és integrációs tesztelés: JUnit 5 és Mockk (a https://blog.philipphauer.de/best-practices-unit-testing-kotlin/ cikk alapján)
- Fejlesztőkörnyezet: IntelliJ IDEA Ultimate :)
- Build és CI környezet (amennyire lehet, Docker konténer alapokon összeállítva :) ):
- kódtár: Mercurial (BitBucket-en keresztül) - tudom-tudom, nem Git, de ebben sokkal nagyobb a tapasztalatunk és nem érezzük egyelőre a saját munkamenetünkben, hogy a kódtár sajátosságai miatt hátrányos helyzetben lennénk
- build környezet: Gradle (https://gradle.org/)
- CI környezet: Jenkins LTS (https://jenkins.io/) + SonarQube LTS (https://www.sonarqube.org/) a Sonar-Kotlin kiegészítéssel (https://github.com/arturbosch/sonar-kotlin)
A közeljövőben jobban bele szeretném / fogom ásni magam a Kotlin és a kapcsolódó eszköztár környezetbe, hogy lássam, mennyire jól mértem fel, hogy ezzel a nyelvvel hatékonyan előreléphetünk a JVM alapú feljesztésben a Java-hoz képest :)
Nincsenek megjegyzések:
Megjegyzés küldése