https://mecanik.dev/hu/tags/software-engineering/Recent content in Szoftvertervezés on [ MECANIK DEV ]Hugo -- gohugo.iohuSzerzői jog © 2020-{year}, [MECANIK DEV]. Minden jog fenntartva.Tue, 01 Sep 2026 07:00:00 +0100https://mecanik.dev/hu/posts/postmortem/Tue, 01 Sep 2026 07:00:00 +0100https://mecanik.dev/hu/posts/postmortem/Egy posztmortemet könnyű összehívni, és nehéz hasznossá tenni. Megvan az értekezlet, elkészül a dokumentum, rögzítenek négy feladatot, majd hat hónappal később ugyanaz a hiba újra bekövetkezik, miközben valaki éppen mást keresve akad rá a régi dokumentumra. A hibáztatásmentesség kapja a legtöbb figyelmet, amikor erről esik szó, és tényleg fontos is, de nem ott van a hiba. Rengeteg szervezet vezet szigorúan hibáztatásmentes elemzéseket, amelyek semmit nem változtatnak, mert magát az elemzést tekintették eredménynek, nem pedig annak, ami eredményt termel.https://mecanik.dev/hu/posts/technical-documentation/Sat, 29 Aug 2026 07:00:00 +0100https://mecanik.dev/hu/posts/technical-documentation/A műszaki dokumentáció mindig ugyanolyan, jól kiszámítható módon mond csődöt. Valaki két nyugodt hét alatt nagyon sokat ír belőle, aztán a rendszer megváltozik, senki nem frissíti, és egy éven belül a dokumentum teljes meggyőződéssel állít valótlant. Ettől a ponttól kezdve rosszabb, mint a semmi, mert aki hisz neki, olyan információ alapján cselekszik, ami már régen nem igaz. A szokásos válasz erre az, hogy írjunk még többet, ez viszont csak felgyorsítja ugyanazt a kudarcot.https://mecanik.dev/hu/posts/developer-onboarding/Fri, 28 Aug 2026 19:00:00 +0100https://mecanik.dev/hu/posts/developer-onboarding/A fejlesztői onboardingot rendszerint azzal mérik, meddig tart a formális beléptetés, ez viszont a probléma rossz vége. Az a szám számít, hogy mennyi idő telik el addig, amíg egy új mérnök meg tud változtatni valamit úgy, hogy biztos lehet benne: semmi mást nem tört el. A legtöbb csapatnál ez hónapokban mérhető, nem napokban. A késés ritkán az emberen múlik. Azon múlik, hogy a rendszerből mennyi létezik kizárólag mások fejében, és hogy az első két hétből mennyi megy el arra, hogy ezt egyenként, megszakításról megszakításra kiszedjék onnan.https://mecanik.dev/hu/posts/software-testing-strategies/Sat, 22 Aug 2026 19:00:00 +0100https://mecanik.dev/hu/posts/software-testing-strategies/A szoftvertesztelési stratégiákat szinte mindig a lefedettséggel írják le, pedig a lefedettség a legkevésbé informatív szám az egész szakterületen. Egy kilencven százalékon álló kódbázis is kiszállíthat hibát a legtöbbet használt útvonalán, mert a lefedettség azt méri, mely sorok futottak le egy tesztfuttatás alatt, nem pedig azt, hogy állítottunk-e róluk bármi értelmeset. Azok a csapatok, amelyek megbíznak a tesztkészletükben, nem a legmagasabb százalékkal rendelkeznek. Ők azok, akiknek a tesztjei akkor buknak el, amikor tényleg elromlott valami, egyébként pedig csendben maradnak, és ez a tulajdonság sokkal nehezebben vásárolható meg.https://mecanik.dev/hu/posts/software-licensing-models-enterprise-applications/Thu, 30 Jul 2026 07:00:00 +0100https://mecanik.dev/hu/posts/software-licensing-models-enterprise-applications/A megfelelő szoftver licencmodellek kiválasztása az egyik legfontosabb stratégiai döntés, amelyet az alapítóknak meg kell hozniuk vállalati alkalmazások építésekor 2026-ban. Ha rossz szerződési formátumot választ, korlátozhatja a terjesztési lehetőségeket, akadályozhatja a SaaS-skálázódást, vagy akár arra is kényszerülhet, hogy nyilvánosságra hozza saját egyedi forráskódját. Az alapítóknak ezért egyensúlyt kell teremteniük a szellemi tulajdonuk (IP) védelme és a működési árrések tisztán tartása között. Ez az útmutató bemutatja a vállalati szoftverek licenceléséhez használt jogi struktúrákat, az open source korlátokat és a tulajdonosi (proprietary) feltételeket.https://mecanik.dev/hu/posts/legacy-php-modernisation-guide/Tue, 14 Jul 2026 07:00:00 +0100https://mecanik.dev/hu/posts/legacy-php-modernisation-guide/Egy legacy PHP alkalmazás gyakran egy tucatszor bővített épület szoftveres megfelelője: működik, a vállalkozás függ tőle, és senki sem akar hozzányúlni. A régi PHP verziók, a tesztek hiánya, az összemosódott felelősségek és az évek alatt felhalmozott kényszermegoldások minden változtatást kockázatossá tesznek. A jó hír, hogy a legacy PHP modernizáció nem igényel big-bang újraírást, ami rendszerint a legkockázatosabb megoldás mind közül. Ez az útmutató egy biztonságosabb, fokozatos utat vázol fel. TL;DRhttps://mecanik.dev/hu/posts/the-software-development-life-cycle-explained-in-2026/Wed, 01 Jul 2026 07:00:00 +0100https://mecanik.dev/hu/posts/the-software-development-life-cycle-explained-in-2026/A szoftverfejlesztési életciklus, amelyet általában SDLC-ként rövidítenek, az a strukturált folyamat, amelyet a csapatok követnek, hogy a szoftvert egy ötlettől egy működő, karbantartott termékig vigyék. Megértése fontos, akár szoftvert fejleszt, akár megrendel, mivel a folyamat minősége nagymértékben meghatározza az eredmény minőségét, költségét és időszerűségét. Ez az útmutató világosan elmagyarázza a szoftverfejlesztési életciklust: minden fázist és azt, mi történik benne, az Agile és a Waterfall megközelítések közötti különbséget, hol szoknak a projektek elromlani, és hogyan tartja kézben a jó folyamat a költségeket és kockázatokat.https://mecanik.dev/hu/posts/what-is-software-development-a-2026-guide/Sun, 28 Jun 2026 07:00:00 +0100https://mecanik.dev/hu/posts/what-is-software-development-a-2026-guide/Mi a szoftverfejlesztés? Legegyszerűbben fogalmazva: a szoftverfejlesztés a számítógépeken, telefonokon, szervereken és eszközökön futó programok tervezésének, felépítésének, tesztelésének és karbantartásának folyamata. Ez az a módszer, ahogyan egy ötletből működő alkalmazás lesz. Ez az egysoros meghatározás azonban sokat elrejt, és ha Ön olyan vállalkozó, aki szoftvert rendel meg, vagy valaki, aki fontolgatja ezt a területet, a részletek a fontosak. Ez az útmutató elmagyarázza, mit jelent a szoftverfejlesztés valójában 2026-ban, a főbb típusokat, a mögöttük álló nyelveket és szerepeket, és hogy a munka hogyan halad az ötlettől az indításig.https://mecanik.dev/hu/posts/cobol-to-c++-migration/Tue, 24 Feb 2026 18:00:00 +0100https://mecanik.dev/hu/posts/cobol-to-c++-migration/A COBOL-ról C++-ra migráció az egyik legnagyobb hatású modernizációs projekt, amit egy szervezet elvállalhat, és egyben az egyik legkevésbé kiszolgált terület. Jelenleg is nagyjából 220 milliárd sornyi COBOL kód fut éles környezetben. Bankok billiónyi dollárt dolgoznak fel rajta. Kormányzatok nyugdíjrendszereket, adóbeszedést és egészségügyi rendszereket üzemeltetnek rajta. Légitársaságok foglalnak vele repülőjegyeket. Es minden évben azok az emberek, akik karban tudják tartani ezeket a kódokat, egyre közelebb kerülnek a nyugdíjhoz, miközben szinte senki nem jön utánuk.https://mecanik.dev/hu/posts/c++-vs-rust-memory-safety-practical-examples-with-modern-c++/Sun, 15 Feb 2026 20:00:00 +0100https://mecanik.dev/hu/posts/c++-vs-rust-memory-safety-practical-examples-with-modern-c++/A C++ és a Rust közötti memóriabiztonsági vita a szoftverfejlesztés egyik legaktívabb témájává vált. Kormányzati szervek is állást foglaltak, konferencia-előadásokat szentelnek neki, és mindkét oldalon erősek a vélemények. Hadd legyek őszinte: a Rust kiváló nyelv. Az ownership modellje és a borrow checker-e valóban innovatív, és teljes hibakategóriákat szűr ki fordítási időben. Ha új projektet indítasz, és a Rust illik a csapatodhoz és az ökoszisztémádhoz, az remek választás. Ugyanakkor a C++ továbbra is a világ leginkább teljesítménykritikus szoftvereinek gerince: operációs rendszer kernelek, játékmotorok, böngészők, adatbázisok és pénzügyi rendszerek.