>Ha valakinek az jó, hogy helyette megírják a kódot, legyen, de hogy annak mi értelme fogalmam sincs.
Pl. ez:
>Persze 3th partykat használok egy az egyben, nem fogok mindent az ősrobbanástól kiprogramozni, mert arra kevés egy élet.

Szerintem egymást (is) segítenék a szakik is, azáltal, hogy kevesebbet kellene gúúúglizni, mert komplexebb dolgokra is lennének alternatívák. Mert azért valljuk be: a programozás nagy része google-zásból áll.

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Sziasztok c# és visual studióba tudtok segíteni ?
Azt szeretném elérni programból hogy xy programot kitudjak tűzni a tálcára.

Amivel próbálkoztam: Link
Ez fél siker volt mert le venni letudtam a tálcáról de felhelyezni már nem.
Rá jöttem miért mert a verb.Name nem tartalmazza a "Rögzítés a tálcán" funkciót. Olvasások alapján törölték pár windows frissítéssel ezelőtt.

Aztán rátaláltam erre : Link
Gyors átolvasás alapján pont ez kell nekem szerintem de nem tudom mit hogyan kell a visual studioba behívni hogy működjön vagy mit kell letölteni .


Bárkinek van ötlete hogyan lehetne ezt megoldani vagy más módon azt szívesen meghallgatnám.
Segítségeteket előre köszönöm.

A programozásnak pont a lényege komplex kódok alkotása...

Kis szőrözés, és lehet, hogy amúgy erre gondoltál, de szerintem a programozás lényege a legegyszerűbb működő megoldás szállítása az adott - jellemzően üzleti, de nem feltétlenül - problémára. Amennyire látom, a fejlődés pont abba az irányba megy, hogy minél kevésbé legyen komplex a kód. Ugye a magas szintű nyelvek éppen erről szólnak. De cáfoljatok meg, én már csak a pálya széléről ugatok.

Persze most nem a pmonitor által elképzeld dolgokról beszélek, hanem a ténylegesen leszállított kódok 99,99%-áról.

[ Szerkesztve ]

Én a komplex kódot azonnal dobom vissza review során. Max. 10 sor, lehet darabolni mindenkinek jó lesz

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Ez butasag. A komplex koddal akkor van baj, ha komplexebb, mint amire szukseg van. Komplex problemara komplex lesz a megoldas is, jo esellyel.

Eleve ugy kene review-zni, hogy az atnezendo kodrol el lehessen donteni, hogy valojaban megoldja-e a problemat, vagy sem. Ennel fogva atlagos/normalis esetben 1 user story-hoz 1 review tartozik, ahol az atnezendo kod tartalmazza 1) az implementaciot 2) a teszteket, amik bizonyitjak, hogy az implementacio tenyleg megvalositja az user story-t. A review meg ugy megy, hogy
- atnezed, h milyen tesztek vannak, azok megfelelnek-e az user story-nak
- ha a tesztek nem fedik le az user story-t, akkor veget is er a review
- utana megnezzuk, hogy a design megfelelo-e (skalazodik-e, stb.)
- vegul coding style, stb.

Szerintem ez egy jol mukodo megkozelites.

> Amennyire látom, a fejlődés pont abba az irányba megy, hogy minél kevésbé legyen komplex a kód.

Nem. Ez csak egy inga, ami ide-oda leng.

Valojaban az van, hogy a komplexitast csokkenteni kell, de ez alapvetoen az architekturanal erdekes, hiszen egy elbonyolitott 100 soros fuggvenyt kb. barki ki tud takaritani, az nem kihivas. Nem szeretjuk a tulbonyolitott fuggvenyeket, de ha szembejon egy, akkor max. refaktoraljuk. Architekturat refaktoralni sajnos legtobbszor lehetetlen (mert az uzleti oldal nem viseli el a koltseget).

Szoval az van, hogy ha egy problema komplex megoldast igenyel, akkor az a komplexitas valahol meglesz. Vagy a fuggvenyek lesznek komplexek (C++/Haskell/Clojure hackerek, szevasztok!), vagy a kepernyodon levo kod trivialisan olvashato, de 3000 osztaly, amik ugy vannak osszehuzalozva, hogy azon kell atragnod magad (Enterprise Java/Spring hekkerek, szevasztok!).

Ergo a lenyeg sose az, szerintem, hogy szep fasza fuggvenyeink legyenek, hanem hogy a szoftver koncepcionalisan a leheto legelegansabban legyen kitalalva.

Mondok par peldat: peldaul az LMAX elegans. Kitalaltak, h hogy lehet nagy sebesseggel streaming adatokat feldolgozni, szep. Tokmindegy, hogy vannak a fuggvenyek lekodolva, onnan, hogy erted a nagy kepet, mar ki lehet silabizalni. A Datomic elegans. Rich Hickey ravilagitott, hogy az objektumorientalt vilag oriasi tevedese, hogy osszemossa az identitast az ertekkel, es tervezett egy adatbazist, ahol ez szetvalik -- gyonyoru.

> szerintem a programozás lényege a legegyszerűbb működő megoldás

Ebben majdnem igazad van.
1) fontos, hogy a legegyszerubb nem egyenlo azzal, amit az adott pillanatban legkonnyebb osszetakolni -- nagyon ajanlom: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md
2) sokszor az elvarasoknak resze, hogy reagalni tudjunk a jovobeli valtoztatasokra is -- szoval valami egyensuly kell a YAGNI meg az overengineering kozott

[ Szerkesztve ]

while (!sleep) sheep++;

Valami ilyesmi? Introductions To TaskBarManager Class In UWP (c-sharpcorner.com)

Én kérek elnézést!

Én is szerettem volna válaszolni, hogy ez a "max 10 sor különben már dobom is vissza a review-t", így kijelentve hülyeség.
De sokkal szebben összeszedted, mint ahogy én terveztem

Én kérek elnézést!

Egy példát írnék. Ki szeretnéd listázni a ROT bejegyzéseit név és típus szerint.
1.: Az első google kör során rosszabb esetben megtalálsz 1 ehhez hasonlót(amiben nincs típus). Jobb esetben belefutsz pl. egy ilyenbe.
2.: A második google körre nagy valószínűséggel azért kerül sor, mert a C#-osok nem igazán szeretik a Microsoft.VisualBasic névteret. Legalábbis a prog.hu ászai nem szerették. Előbb-utóbb rábukkansz pl. erre az oldalra.
3.: A harmadik google kört pl. akkor futhatod, ha az ügyfél felveszi veled a kapcsolatot, hogy ha admin-ként futtatja a programod, akkor nem működik. Ezen google kör során megtalálod pl. ezt az oldalt.

De ha valahol szerepelne pl. 1 ehhez hasonló "összegző" leírás, akkor mennyi google-tól megkímélné magát az emberke? Ebből a példából is látszik, hogy 1 látszólag 1szerű probléma is lehet komplex. Ezért írtam ezt:
>Szerintem egymást (is) segítenék a szakik is,

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Igen ilyesmire .
A srác videóba nem mutatja mi módon rögzíti tálcán de gondolom bal alulra rögzíti az exet vagy parancsikont.
Consolba kesztem el csinálni a c# kódot ezt hogy lehet behívni ??
Vagy mindenképp gombbal lehet csak elindítani? (Automatizálni szeretném)

Uhh, nem akartam én ennyire mélyen belemenni. Tömören próbáltam megfogalmazni alapvető trendeket, amiket látok. Nyilván nem a gányolásra gondoltam az egyszerűség alatt, hanem arra, hogy az üzleti igényre nem a pmonitor által folyamatosan pedzegetett elv a válasz, hanem a peremfeltételek mellett (fenntarthatóság, stabilitás, fejleszthetőség, biztonság, stb.) az egyszerű és gyors implementáció. Egy AI leletező szoftver kódbázisa nyilván komplexebb lesz, mint egy random Java weboldalé. De amúgy nincs köztünk vita semmiben.

Fogalmam sincs, desktop fejlesztéssel lassan évtizedek óta nem foglalkozok C#-on belül.
Tippre, mivel ez a feature UWP-hez van, Console Appból nem fog működni.

Én kérek elnézést!

Ez erősen függ a kontextől, egy microservice is lehet komplex, hiába állnak a részegységek 10-20 sorból. De mondjuk egy bonyolult sql lekérdezést van, hogy nem tudsz megoldani 1000 sor alatt, ha meggörbülsz sem. Nem attól lesz egy kód rossz, hogy hosszú, hanem ha spagetti, felesleges köröket tartalmazz. Egyébként egy 20 soros kód is lehet komplex az én olvasatomba, hiszen egy problémára add választ, ami egyébként további több 100 20 soros kódból áll össze. Nem egy konkrét eljárásra gondolok, hiszen a fealdat megoldása komplex, és te hiába mész oda vele egy idegen fórumra, hogy adjanak rá választ, mert nem létezik rá kész válasz. Azt neked kell megtalálni. Minden más meg 10 perc gugli használat, csak a legtöbben nem tudnak keresni, lusták vagy csak szimplán fogalmuk sincs mit is akarnak csinálni. Szóval az én olvasatomba például egy prog.hu 95%-a olyan kérdésből áll, amit bárki megoldhatna gugli segítségével is, a maradék 5%-ra meg jó eséllyel nincs abban a formában megoldás.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Értem én, hogy villanymozdony, de mi hajtsa?

Magyarul: akkor mi szükség is van fórum(ok)ra?

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Értem én, hogy nem érted, de akkor ezek szerint fórum nélkül nincs szakács, autószerelő, asztalos, meg építész?

Nem azt mondtam, hogy nem lehet, hogy tilos megosztani, megcsinálni vagy segíteni, azt mondtam, hogy aki e nélkül nem tud programozni, az inkább ne csinálja.

Felmész udemyre és mindent megkapsz, amire szükséged lehet az induláshoz, a többi csak a belerakott munka kérdése, mint bármelyik más szakma esetében.

Az asztalost sem bszom le, hogy nem rak fel komplett youtube tutoriált arról hogyan rakja össze a konyhabútoromat. Ha akar csinál, ha nem akar nem, de nem ettől leszel asztalos vagy sem.

Ennyi.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

De mondjuk egy bonyolult sql lekérdezést van, hogy nem tudsz megoldani 1000 sor alatt, ha meggörbülsz sem.

Abban egészen biztos vagyok, hogy ez nem jó. Ilyen esetben át kell variálni a DB-t, kiforgatni, köztes absztakciós réteget beiktatni, bármit. 1000 soros, de akár 100 soros SQL is kerülendő.

Nem attól lesz egy kód rossz, hogy hosszú, hanem ha spagetti, felesleges köröket tartalmazz.

Semmi konkrétumot nem mondtam a kódminőségről . Sőt, igazándiból gyakran a hosszabb kód az egyszerűbb. És persze, emvy leírta, hogy az egyszerű fogalom milyen nehezen megfogható.

Persze sok mindent lehet, kérdés mire van lehetőség és idő, nem mindenki hobbiból készít programot, hanem mondjuk van 3 napja egy feladatra, ott te nem forgatsz semmit sehova, át meg pláne nem variálsz egy kiadott és működő db-t. Sajnos a legacy kód sokszor nagy úr.

De én spec inkább írok 1000 soros tárolt eljárást, mintsem szétszedjem az egészet 20részre, aztán 1 év múlva egy debuggolás egy rémálom lesz.

Persze ezek már sok tényezős dolgok, mekkora cég, mi a history, mennyi munkatárs, milyen policy stb, itt aztán már lehet minden is.

Mondjuk legutóbb kellett csinálnom egy excel exportot 1xx oszloposat, ami tényleg mindenhonnan szedett össze adatokat, különbőző számításokat végzett a különbőző adatrétegek között, szépen meg lehetett csinálni egy darab tárolt eljárással, pár temp táblával és sok tagolással, hogy később olvasható maradjon.

De ha olyan a feladat, hogy egy részfeladatot érdemes kiemelni, akkor arra inkább csinálok egy általános megoldást és kiszervezem a kódot, szóval elég speciális az, hogy mikor mi a jó megoldás.

Sqlben egyébként is a hasznos kód sokszor nagyon kevés, mert éppen én úgy szeretem formázni mondjuk az inserteket, hogy egy sor egy mező, hopp máris a fél kód insertekből áll.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Ahhj, szóval riportingra gondoltál! Hát, azt inkább hagyjuk is.

Persze, egy rest api hívás kiszolgálására nem kell 20 sornál több, ott én is kapnék a fejemre egy 100 soros kódnál.

Szoktam is kapni, amikor a js kód feleslegesen hosszú, értsd nem 5 sor.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Jókat írsz, pár random gondolat:

- A fejlesztők többsége nem tud különbséget tenni az essential és az accidental complexity fogalmak között, és ez meg is látszik a munkájuk minőségén.

- Nekem a szoftveres komplexitás nagy kedvenc interjú témám, sajnos nagyon ritka az a versenyző, akivel egyáltalán eljutok ide. Tényleg, ti nem vettétek észre, hogy a diplomás, profi, sok év tapasztalattal rendelkező programozók többsége egyszerűen nem tud programozni?

- Ez a Datomic nagyon szexi. Igazából eddig is tudtunk hasonló, objektum-history alapú adatstruktúrákat csinálni pucér sql-el, de na, ígéretes.

- A YAGNI elv lényege pont az, hogy ha valamire jövő hónapban lesz szükséged, akkor jövő hónapban írod meg. Falra tudok mászni attól, amikor a fejlesztők előre gondolkoznak és általánosítanak, 10-ből 9 alkalommal az lesz belőle, hogy kiderül, segg hülyék az üzleti igényekhez, és fogalmuk sincs, milyen absztrakciókra lesz szükség a jövőben.

Falra tudok mászni attól, amikor a fejlesztők előre gondolkoznak és általánosítanak

A másik véglet sem jobb, amikor olyan fasza a design (mivel hülyék az üzleti igényekhez), hogy a jövő hónapban egy apró igény miatt lehet szétbarmolni az egész kódot.

>nem mindenki hobbiból készít programot
De én igen! Szóval én elvileg azzal foglalkozom, ami érdekel. Sajnos csak elvileg, mert az állapotom miatt csak nagyon kis töredékét tudok vele foglalkozni. Dehát ez van...

De pl. martonx ugyebár csak szórakozásból jár ide. Ahány emberke(nick), annyiféle indok. Van olyan téma, ami az egyiknek nevetséges, a másik meg komolyan veszi. Aztán van, hogy ez megfordul.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

De te most melyik irányból nézed a dolgokat? Igen is nem jó dolog ha egy kód komplex. Komplexitását ne a mennyisége adja hanem az összetettsége szerintem. Egy komplex kód és én itt most a töb 100 soros függvények összeségéről beszélek, vagy próbáltam beszélni nem jó.

És ez nem butaság. Szerintem a coding style és a "teszt lefedettség" - itt megint mit értünk nem a code review része. Annak előtte kell megtörténnie normál esetben automatikusan (pl. sonar qube + egyéb linter).

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Hogy egy rendszer mennyire rugalmas a jövőbeli igények szempontjából, az alapvetően architekturális kérdés.
Az ideális szituáció, hogy az architektúrád rugalmas, és ott figyelsz arra, hogy mik lesznek a rendszer fix részei, és melyek fognak a jövőben mozogni.

Egy ilyen setup-ban a programozók dolga a kódolás, és lényegesen kissebb a hibázási lehetőség is.

[ Szerkesztve ]

Na hát akkor a kedvenc interjú-témámon te is elvéreznél . Szóval a komplexitás nem azt jelenti, hogy te épp mit gondolsz, hanem elég jól definiált fogalomhalmaz - érthető, a nagy komplexitás termelékenység-csökkenést okoz, a fejlesztők pedig nagyon drágák.

Szóval mivel épp ráérek, némi támpont, hogy pongyolán megfogalmazva. (nem mindenre tudok magyar kifejezést)
essential complexity - az a komplexitás, ami nélkülözhetetlen. más szóval a megrendelő üzleti igényei. Ha a webshop 16 féle fizetést támogat, akkor az annyi.
accidental complexity - minden, ami nem essential.
ciklomatikus komplexitás - számolt érték, nagyjából a kód futás közben bejárható útvonalainak a száma. Tesztelhetőség szempontjából fontos.
kognitív komplexitás - számolt érték, azt akarja reprezentálni, hogy mennyire nehezen érthető a kód egy ember számára.
loc - ez a függvény sorainak száma, amiről beszéltél. Ha túl magas, az gyanús.
space and time - ez van valahogy magyarul is, de nem ugrik be. ez az amit az iskolában tanítanak, n-es, négyzetes, exponenciális, stb.

És ezeken kívül még van a szubjektív komplexitás érzés. Van olyan kód, amit úgy olvasol, mint az újságot, és van olyan, amivel szenvedsz.
Hiába jók a metrikák a Sonárban, ha szembejön egy ProductFactoryProviderManager nevű osztály. Ilyenek még - rossz nevezéktan, inkonzisztens struktúrák, nevek, stb.

[ Szerkesztve ]

Mindkét fogalom létezik, legalábbis az én értelmezésemben.
Az incidental kimaradt, bár ahogy értem, az inkább ilyen tágabban értelmezett dolog. Értheted alatta a kódban található haszontalan dolgokat, és a kód környezetét is, mondjuk a tooling nehézségeit.

Valóban de teszt lefedettséget mér. Én azért hiszek a kollégáimnak ha azt mondja tesztelt elhiszem. Linter pedig konkrétan formáz githookra. De ezt te is tudod

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nem is akarok nálad interjúzni. Amit felsoroltal így van, de én ennek egy rész halmazáról beszéltem.

/shrug

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Az látszik, hogy elméletből nagyon top-on vagy. Ez már itt is látszott. Nagyon csücskös!
Csak sajnos ettől a komplexebb problémák nem fognak megoldódni. Pl. NP-teljes problémák emberi futásidő alatti megoldása sem oldódik meg azzal, ha vki. keni-vágja az elméletet. Szóval én inkább akkor érezném jobban magam, ha vki(k). gyakorlatból lennének jók ÉS ezt a tudásukat hajlandók lennének megosztani(magyarul segítőkészek IS lennének).

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Space and time az az asymptotic.
Essentialt meg meg intrinsicnek is szokas szinten nevezni.

Btw. en olyan helyen dolgozom, ahol tovabbra sincs code review. Es az elejen majdnem sokkot kaptam ettol az informaciotol, de tovabbra is ugy latszik, hogy megis mukodik. Nagyon ritka a nagy sev/prio bug. Hogy meg furabb legyen a helyzet, van jopar microservice, aminek jelenleg 0 a test coverage. Bar a test coverage eleve nem mond sokat. Ha nagyon merni kell automatizaltan a teszt josagat, akkor mutation testinget lehet csinalni, de az altalaban tul sokat dob a tesztek futasi idejen. Lehet azert mukodik ez nalunk, mert a median tapasztalat 10 ev korul van, 10 fo alatti csapatnal.

Most van ilyen celunk, hogy legyen minden birtokolt modulon legalabb 80% lefedettseg, igy tudom edzeni a Mockito kepessegeimet. :D Kezdek atszokni a unit testekre a Spring integration tesztek helyett. Mar az Application context elidulasanak az idoigenye is zavar. :D De persze vannak dolgok, amiket ertelmesen unit tesztelni "nehez". Pl. Repository-k perverz sql-lel, Controllerek access controllal.

I am having fun staying poor.

Latom neked csak a kodsor szamit: imhol
mod: ja bocsanat, hogy sajat kodot linkeltem, azt hittem az altalad linkeltet is te alkottad...

A noname nicket meg nem nagyon ertem, hacsak nem teged monitor peternek hivnak...

Magyar ugyfelekre meg - mondjuk en szemely lesz@rom a magyar ugyfeleket - egy multinak dolgozom, egy ideje mar kulfoldrol, nekem nincsenek kozvetlen ugyfeleim.
En nem az ugyfelek kedveert forumozok, ugyfel meg vsz ugysem egy IT forumot fog koptatni, mivel a technikai megvalositas sem erdekli, csak hogy "menjen" a program vagy a weboldal.
Amugy nem akarlak elkeseriteni, de nem csak magyar nyelvu forumokon vagyok jelen, hanem angol nyelvun is - persze birom a szemelyeskedest, de vsz ezt legfeljebb csak megmosolyogom. Amugy nem ertem ezt a sertodottseget - miert kene fizetest kapni a forumtol mert irunk ide - csak azert, mert nem ertunk veled egyet?

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Nem bántásból, de az a baj, hogy van egy elképzelésed erről a szakmáról, ami köszönő viszonyban sincs a valósággal.

Amiket írtam, azok mind a való életben szembejövő kérdések-problémák. Mindegyik fogalom szembejött már a munkám során ilyen-olyan formában.

Ezzel szemben az NP-teljesség kérdése alapvetően kívül esik a szoftverfejlesztők mindennapi munkáján. Ilyen kérdésekkel a számítástudomány foglalkozik, jellemzően kutatási téma akadémikusoknak, a vizsgálata pedig matematikai módszerekkel történik.

Értékelem az igyekezetet, de ha a mindennapokban, gyakorlatban fontos fogalmakról beszélünk, akkor erre az NP-teljesség a létező legrosszabb példa, amit kitalálhattál.

>Mindegyik fogalom szembejött már a munkám során ilyen-olyan formában
1 vagy 2 konkrét, gyakorlati esetet tudnál írni?

#17984:
>mondjuk en szemely lesz@rom a magyar ugyfeleket
Javasold nyugodtan ezt FeniX- ismerősének. Azzal együtt, hogy saját, vagy cégnevével vállalja fel ezt ezt a véleményét.

Vagy én vagyok fordítva összerakva, vagy ti...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Megválaszolom: te vagy.

Ha tudtok írni olyan gyakorlati példát, amit nem lehet az ittenke lévő fogalmak ismerete nélkül megcsinálni, csak akkor, ha ezeket a fogalmakat ismeri valaki, akkor elismerem, hogy én vagyok fordítva összerakva...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Írok neked gyakorlati példát: elémész egy céghez dolgozni, ahol rajtad kívül még másik 20 programozó kalapálja ugyanazt a kódot. Szívesen.

essential complexity - megbíznak egy projektel, az ügyfél szeretne fűt, fát, te meghallgatod, gyököt vonsz, összekalapálod egy matematikai modell mentén értelmezhető változatba, ami olyan, hogy meg is valósítható a projekt idő és pénz keretén belül.

ciklomatikus komplexitás - mennyire bonyolult a funkciónalitás, minél egyenesebb, annál jobb, nincsenen felesleges flikk-flakkok benne.

kognitív komplexitás - kedvencem, amikor valamit csak azért beleerőszakolnak egy nyelvben egy sor kódba, hogy egy sor legyen. Értelmezni meg csak 2 hét alatt tudod. Egyébként a projekt felépítése, eljárásai hogyan vannak megírva, logikusan, szépen katonásan követik-e egymás, vagy egy szemétdomb az egész.

Szóval ezek ilyen céges dolgok, ahol sok embernek kell ugyanazt a házat építenie.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

És ez hogy hasonlítható össze a legacy kóddal? Legacy esetében ismerték ezeket a fogalmakat? Ha nem, akkor mégis hogy csináltak 1 működő kódot? Pedig ott is cégről van szó. Tehát egy feladat megcsinálható ezen fogalmak ismerete nélkül is(még cég esetében is). Vagy ha ismerték ezeket a fogalmakat, akkor szándékosan rúgták fel az ezek mögött álló tartalmakat? Mert te magad írtad:
>Sajnos a legacy kód sokszor nagy úr.

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

mukodo kod != minosegi kod
a ketto kozott kell kihozni az eredmenyt az ido/budget/elvarasok es kepessegek fuggvenyeben. Termeszetesen a jelolteknel fontos, hogy kepes legyen minodsegi kodot is kesziteni, ne csak mukodot, mert elkepzelheto, hogy a megrendelo nem csak mukodo, hanem a minosegi kodot is megfizeti (es megkoveteli).

- by Captain Obvious

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Ezzel hobbistaként is egyetértek.

Hadd kérdezzek vmit.. Neked az itt lévő, vagy az itt lévő megvalósítás jobb C#-ban, és miért?

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Mármint melyik számít minőségi kódnak? Mielőtt vmi. csapdát sejtenél, elmondom, hogy én nem tudom eldönteni(fogalmam sincs).

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Hát úgy, hogy amikor indult a cég, 1996-ban, egyszemélyes vállalkozás volt. Aztán az idő során volt jónéhány technológia váltás is, sokkszor úgy, hogy gyakorlatilag úgy kellett összerakni a kódokat, hogy közben az ügyfél dolgozott vele (repülés közben szereltük össze a gépet). Ilyenkor persze nincs idő sokmindenre. Na meg közben jöttek-mentek az emberek is. Meg sokminden úgymond el is lett bszva, meg közben az ember is változik folyamatosan. Amit 3 éve írtam, az lehet ma már nem úgy írnám. Stb, stb, stb.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Először is - a komplexitás fogalmát ott érdemes tárgyalni, ahol nagy méretű kódbázisról van szó. Egy tök átlagos, jávában/c#-ban írt céges ügyviteli szoftverben lesz több száz, vagy akár több ezer osztály, amit éveken át írt több csapat, ilyen-olyan tudásszinttel, folyamatosan változó üzleti igényekkel.

Az essential complexity főleg tervezésnél fontos. Tudod, mi tartozik ide, tudod, hogy ideálisan ez stateless van implementálva, tudod, hogy erre akarsz tuti 100% test coverage-et, akár más tesztek kárára is. Ha DDD-t csinálsz, akkor ezt a komplexitást definiálod. Ha BPMN-t akkor szintén. Arra is jó, hogy rájöjj, ha a juniorabb kolléga refaktorálási ötletei valóban hasznosak-e, vagy csak arra jók, hogy a komplexitást átrakd az egyik zsebedből a másikba.

Ciklomatikus komplexitást arra használod, hogy jelzi, melyik részei tesztelhetetlenek a programodnak. Ezek azok a részek, amelyek sürgős refaktorra szorulnak, mielőtt bárki azon gondolkozna, hogy teszt lefedettség.

Kognitív komplexitás metrika szintén a problémás részek azonosítására szolgál.

LOC esetenként lehet hasznos, ugye megmondja, hol vannak hosszú függvények a kódban. De ugye önmagában ha hosszú a kód, az nem jelent gondot. Az jelent gondot, hogy várhatóan ha hosszú a kód, akkor nehéz lesz tesztelni.

Aszimptotikus komplexitást jól mérni nem nagyon lehet, ott jön elő nagyon, amikor nagy mennyiségű adattal dolgozol. Mittomén, minden éjjel ütemezettem riportokat gyártasz. Ha 5 perc egy riport legyártása, az nem gond, ha 3-at kell megcsinálj, de gond, ha 3000-et.

Vannak más szempontok és technikák is, de meghagyom mindenkinek az örömöt, hogy olvassa el magának a Clean Architecture-t.

[ Szerkesztve ]