Új hozzászólás Aktív témák
-
bambano
titán
én üzemeltetőnek tartom magam, aki akkor programoz valamit, ha az üzemeltetéshez kell. tehát programozok is, csak nem életvitelszerűen. a vezetőség olyan kérdésekben dönt, amilyen kérdések elé kerülnek. ami nem kerül elé, abban értelemszerűen nem dönt.
neked például mennyivel több idő olyan kódot írni, ami legalább nem elvi hibás? például ha c-ben programozol, mennyivel több idő az sprintf helyett snprintf-et írni (meg a plusz argumentumot és egy plusz vesszőt)?
"az optimalizálásnak a komplett munkafolyamat részévé kell válnia": nem kell, KELLETT VOLNA. hogyan akarsz rendes programot kiadni a kezedből úgy, hogy az optimalizálás nem alapértelmezetten része a munkafolyamatnak? ha még nem is optimalizálsz, akkor hogy lesz minőségirányítás integrálva a folyamataidba? pláne és kifejezetten és magas szintűen hogy lesz biztonságtudatos a fejlesztési folyamatod? hint: sehogy.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Pernyo
csendes tag
A Te kommentedre írok, mivel egyetértek ezzel és kiegészítem egy kicsit. Leegyszerűsítve az agilis szoftverfejlesztés kilépési pontja nem a kész termék, hanem az idő. Általában 2 hetes sprintek vannak, ami alatt be kell valamit szállítani a termékbe.
Sokan írják, hogy tanuljanak meg a programozók kódot írni. Tudnak, csak mivel nem mindenki robot és másképp gondolkodik, bizonyos komponensek más "gondolkodásmóddal" készülnek.
Én tesztelőként dolgozom, és a kódminőség megfelelő, csak a együtt nem működnek a komponensek, ezt nagyon nehéz kijavítan, mivel messze nem 1 fejlesztőcsapat dolgozik ezeken (30-40, helyileg sincsenek egy helyen), ez pedig nehezíti a kommunikációt.
Nem akarok senkit megsérteni, de találkoztam már olyan fejlesztővel, aki nagyon jó fejlesztő, de nem egy komplex rendszert fejleszt és ebből indul ki. Egy számlázó program és egy IMS (Internet Protocol Multimedia Subsystems) között nem kis különbség van.
Új hozzászólás Aktív témák
it A Linux atyja két hardveres problémát lát kicsúcsosodni a DevOps csapatok előtt.
