Google: Három halálos bűn, amit elkövethetsz a szoftvertervezés során
2014-04-17T14:36:56+02:00
2014-04-26T13:37:25+02:00
2022-07-22T20:51:28+02:00
  • Ne etesd a trollt!
    Mutasd a teljes hozzászólást!
  • Látszik, frusztrált vagy

    A mondat "filozofiáját" értsd meg, akkor nem destruál, hanem távlatokat nyit.

    Nem az az érdekes, hogy hányat készítesz (adott minőségben), hanem hogy legyen (akár csak egyetlen) egy, de az értékes mű legyen.

    És itt párhuzam van valóban a programozással.
    Mutasd a teljes hozzászólást!
  • Ööö, a szabályokra értette, nem a programokra
    Mutasd a teljes hozzászólást!
  • Bírom ezeket a partvonalon túlról jövő nagyon okos beszólásokat. Alkalmazzuk ezt az elvedet a programozásra : Ezentúl minden programozó csak egy azaz 1 programot írjon egész élete során, de az aztán olyan is legyen!

    Aki pedig egynél többet ír, az eszerint tutira csak fércműveket gányolhatott, nem is igazi szakember, és satöbbi.

    Mármint a te elved szerint.
    Mutasd a teljes hozzászólást!
  • Matematikailag a "legfontosabb" valóban kizárja a többes "jelölést".

    De a dolgoknak a valóságban nincs 'legfontosabb' (értsd az egyedül fontos) tulajdonsága.

    Sok jellemzője van a dolgoknak, ezek súlyozódnak és sorrendbe szedhetőek. Bár a lista első eleme lehet domináns, de az nem elég.

    Pl. a 80-20-as szabály.

    Egy bolt miért nem csak a 80% bevételt hozó 20% árút tartja?
    Olyan logikus lenne a lépés.

    Csak nem működik.

    Mint ahogy hiába a "legfontosabb" egy 'ma összetákoljuk, mert sürgős', de ettől holnap ez nagyon költséges lesz és további tákolást követel meg. [meg üzembiztonsági kérdések tömegét hozza elő]

    Ezért nem értettem soha, hogy egy "menő" cég (amelyik megteheti, kellően profitábilis) miért nem készít tisztességes terméket.
    A kicsi szerencsétlent, akinek nincs pénze rá megértem.
    Bár mintha ott meg gyakrabban kerülne elő a szakmai önérzet, hogy ilyen trágyához nem adja a nevét (nincs fényes márkaneve és sok-sok marketingese, hogy kimossa a hírnevét)

    Hát igen... Big Mac és a meztelen séf
    Mutasd a teljes hozzászólást!
  • "Regénye válogatja, de ha ötvennél is több regényt írtál, az szintén nem művészet"


    Valami (nem ugrik be a neve) komoly embert plagizálva:

    Egyet kell írni, de az olyan legyen
    Mutasd a teljes hozzászólást!
  • Azért a két dolog nem zárja ki egymást

    Egyszerre nem lehet két dolog "legfontosabb", mert akkor születnek azok a listák, amelyeken van tíz Top1 feladat.
    Mutasd a teljes hozzászólást!
  • De hiszen rég eldöntöttem már, hogy művész akarok lenni!

    Akkor ne keverd az ipari munkát a művészettel...

    Eddig írtam ötvennél is több regényt, meg egy csomó "apróságot"...

    Regénye válogatja, de ha ötvennél is több regényt írtál, az szintén nem művészet, hanem ipar, csak másik üzletág...

    Amúgy, ha a kód nem hibátlen, akkor nem is szép, szerintem. Azaz a szépségbe én beleértem a hibátlanságot is. Viszont ami hibátlan, még nem okvetlenül szép...

    Ez azért így eléggé szubjektív... mindenki mást tart szépnek, a hibátlanság viszont objektív. :)
    Mutasd a teljes hozzászólást!
  • csak éppen nem az a nagy szám hogy meg tudsz írni egy kódot szépen strukturálva és formázva.

    a kérdés az, hogy ha kevés időd van rá, folyton változik hogy mit kell csinálni, stresszes vagy és rosszak a munkakörülmények, akkor mit tudsz kihozni a kódból. alighanem nem lesz tökéletes.

    de vajon inkább szép lesz, vagy inkább működni fog, ha csak az egyikre van időd?



    (és megtippelheted, hogy a szakma szerint jó programozóknál mi a válasz)
    Mutasd a teljes hozzászólást!
  • De hiszen rég eldöntöttem már, hogy művész akarok lenni! Az is vagyok. Író. Eddig írtam ötvennél is több regényt, meg egy csomó "apróságot"...

    Amúgy, ha a kód nem hibátlen, akkor nem is szép, szerintem. Azaz a szépségbe én beleértem a hibátlanságot is. Viszont ami hibátlan, még nem okvetlenül szép...
    Mutasd a teljes hozzászólást!
  • "Egyébként miért nem a hibátlansága a legfontosabb?"


    Azért a két dolog nem zárja ki egymást

    Még erősítő építéskor (rég volt, akkor ha valami igazán jót akart az ember és nem volt milliomos, akkor magának építette), tanultam egy "mesteremtől" (ami igaz nyáklapi elrendezésről szólt, de érvényes a programkódra is):

    "ami szép, az jó is".

    Persze kissé összetettebb a dolog, de bon mot-nak nem rossz.
    Mindenesetre egy szellemes megoldás, egy szépen strukturált és formázott kód lényegesen nagyobb eséllyel működik jól, mint egy "szalmakazal" erőltetett algoritmusokkal.

    Mutasd a teljes hozzászólást!
  • Én azért írok meg egy függvényt, hogy majd használjam. Amiről úgy érzem, hogy nagy valószínűséggel szükség lesz. De ha nem tudom megindokolni, hogy hol, mikor akarom használni, akkor nem írom meg. 
    Valószínűleg akkor lehet gond, ha az ember túlságosan előre gondolkodik. Olyan függvényeket is ír, amit bőven elég lenne akkor megírni, amikor félig kész van a program, weboldal. Valószínűleg menet közben is nagyon sokminden változik és kiderül, hogy például ezt felesleges volt megírni.
    Mutasd a teljes hozzászólást!
  • Egyébként érdemes megnézni a témával kapcsolatban például a SonarQube szoftvert, mert nem csak három halálos bűnt jelez előre... :)

    Alapvetően Java nyelvre találták ki, de már ismer jó pár egyéb programozási nyelvet és pont arra jó, hogy a forráskódot minősítse, részben a szépsége, részben a többi paramétere alapján (például a SIG koordináta rendszerbe az Analysability, Changeability, Stability, Testability tengelyek mentén).

    Csütörtökön lesz (angol nyelvű) előadás is a SonarQube működéséről, akit érdekel, jelentkezhet:
    javaforum.hu
    Mutasd a teljes hozzászólást!
  • A dolog annyira igaz, hogy hiába nőtt ifjúkorom óta a számítógépek hardwerének teljesítőképessége a sokezerszeresére, valójában nem úgy veszem észre, hogy olyan nagyon sokkal több mindent nyújtanának a mai programok, mint régen!

    Azért figyeljük meg azt az apróságot, hogy a 320x200 felbontású és két bites színmélységű kijelzőről (~16kB) felmentünk 1920x1080 felbontásra és 32 bites színmélységre (~8MB), ami csak önmagában kb. 500-szoros teljesítményigény-növekedés. Tehát amit régen elvitt egy 1MHz-es CPU/GPU, ahhoz most 0,5GHz kell. És ez csak a grafikus felület...

    Így igaz, a programozás legfontosabb jelentősége a számomra a SZÉPSÉGE.


    Egyébként miért nem a hibátlansága a legfontosabb? Döntsd el, hogy művész akarsz lenni vagy mérnök... :)
    Mutasd a teljes hozzászólást!
  • Egyébként Google csak maga nevében nyilatkozhat, hogy mi vált be nála és mi nem.

    Ezek nem annyira Google specifikus dolgok... a dead code store egy igen jó metrika: ha nem tudsz egy kódrészletre olyan tesztet írni, amelyik megmozgatja azt, akkor töröld, mert nem fog futni soha, csak térfogatnövelő.

    Csak ezen a három metrikán kívül van még sok-sok, amelyek külön-külön mind értelmesek és néhol bizony el kell dönteni, hogy melyik ujját harapja meg az ember. :)
    Mutasd a teljes hozzászólást!
  • "Amúgy dolgozzunk sima felhasználói fiókból. És máris védve vagyunk."

    Egyik programozási filozófiai tétel, még erősen ge. korból (nem ie. hanem gugli előtt)

    "Minden döntést halassz el ameddig lehet, de soha ne tovább, mint szükséges"

    Vagyis ne vitelezz ki (szükségtelen) kódot idő előtt, mert akkor korábban hoztál döntést, mint hogy a lehetséges változási igények mind beérkeznek.

    Ugyanakkor értelemszerűen tudd, hogy szükséges lehet ilyen kód és készítsd fel rá a rendszert.

    Pl. a save példánál, ha volt egy read() és az állapot változhat (ami akár logikus lenne, ha tárolásra is kerül), akkor megírható egy dummy save(), ami nem csinál semmit, de a destruktor (vagy akár többminden a kódban) futtatja, mert ha egyszer valaki ténylegesen megírja, akkor ne legyen az gond, hogy mégegyszer gondolja át a teljes működési algoritmust.

    Mondjuk ilyen esetben erősen javallt pl. egy TODO bejegyzést tenni a Save() törzsébe és esetlegesen privattá tenni, kommentezve, hogy akkor lehet public, ha megírják a törzsét.

    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • A dolog életútját tovább vizsgájuk, te megírtad SaveXy()- t. Tegyük fel hogy jól. (Bár az sem biztos ) Akkor jön valaki akinek az a feladata, hogy a valahogy máshogy legyen. Átírja a Load-ot, és mivel a határidő mindig szorít. A save-t már nem. (Vagy az is tartsuk karban??? Az meg mennyi + munka már egy tök nem használt faterre karbantartása.  ) Szóval nem tarjuk karban nincs rá teszt, rossz is lesz. Aztán tényleg használva lesz és 1 hétig keresed a hibát, hogy mi a hiba.

    Szóval az alatt + idő alatt inkább néz a csajokat de ne kódolj
    Mutasd a teljes hozzászólást!
  • Így igaz, a programozás legfontosabb jelentősége a számomra a SZÉPSÉGE.

    Ezt annak ellenére vagy épp azért mondom, mert nem vagyok hivatásos programozó. Egy kis ideig az voltam, de aztán másképp alakult az életem... Eleinte bántam is ezt, nagyon, de most már sokkal inkább örülök neki. Manapság nagyon más a programozói munka, mint az én fiatalkoromban. Ahogy te mondtad is, ROBOTTÁ VÁLT a legtöbb helyen. Többnyire már nincsenek is programozók, csak KÓDEREK, ezekből több, akiknek valamiféle szoftvermenedzser (vagy más nevű illető, tökmindegy) kiad bizonyos részfeladatokat, s azokat kell megoldaniuk. Azaz, team-munkák vannak többnyire, nem egyéni "művészi alkotások". És közben alkalmazkodni kell mindenki máshoz, meg elfuserált interfész-szabványokhoz/protokollokhoz, s akkor még nem is beszéltünk az ügyfelek idióta kívánságairól. És ráadásul mindent gyorsan, gyorsan, kapkodva!

    A programozás manapság már a legtöbb helyen tehát nem művészet, hanem TÖMEGTERMELÉS. Ez meg nekem nem kell és nem hiányzik.

    A dolog annyira igaz, hogy hiába nőtt ifjúkorom óta a számítógépek hardwerének teljesítőképessége a sokezerszeresére, valójában nem úgy veszem észre, hogy olyan nagyon sokkal több mindent nyújtanának a mai programok, mint régen! Jó, mondjuk ne a C-64 -el vessük őket össze, de én még jól emlékszem mondjuk a Word 6.0-ra. Gyakorlatilag amit egy átlagos szövegszerkesztőnek tudnia kellett, azt mind tudta is. Manapság mennyivel jobbak a szövegszerkesztők?! Mindenfelé mindenben csak mindenféle bloatware ótvar szutykok pöfögnek, zabálva az erőforrásokat, amiket kizárólag azért írtak meg hogy belepakoljanak mindenféle olyan látszatfejlesztést, amiről előre tudták hogy úgyse kell csak a reménybeli userek 0.0000001%-ának lesz jó, de igazából ők is tudnák nélkülözni. Mégis megcsinálják, aztán beharangozzák világrengető újításként, mert másképp nem tudnák eladni az új terméket. Közben meg az új igazából még rosszabb is mint a régi, nem is elsősorban azért mert benne van ez az igazából felesleges cucc, hanem mert ezt már nem úgy írták meg mint a régit, hanem mindenféle "köztes rétegekre" építve, "absztrakciókat alkalmazva", amik elfedik a "konkrét hardware egyedi jellegzetességeit", stb, plusz egy csomó funkciót valamiféle scriptnyelven ugye, és mindezek miatt ez a bitszeméthalom tök lassú szutyok lesz egy Core i7 procis 16 gigás gépen is. De akkor is így írják meg, mert így a program megírása GYORSABB.

    Lehet hogy ez üzleti szempontból jó koncepció tényleg, de az is biztos hogy aki ezt így megírja, a szememben nem programozó, hanem csak bitkalapáló biológiai robotgép.

    Szóval ezért nem bánom, hogy manapság nem vagyok hivatásos "programozó". Kicsi ugyanis az esélye annak, hogy nem valami efféle munkahelyet fognék ki. Jobb akkor már nekem, ha a programozás megmaradt hobbynak, úgy legalább azt csinálom amit akarok, és úgy, ahogyan azt szeretem.

    A fentiek miatt is van az főleg (bár nem kizárólag) hogy messze jobban szeretem a Linuxot mint a Windowst, általában a nyílt forráskódú progikat. Ott még azért nem uralkodott el ennyire ez a szemlélet, bár meg kell valljam, erősen lecsökkent az utóbbi időben az a lángoló fanatizmusom, amivel korábban a Linux-érát istenítettem. Igazából mostanában inkább már csak a Microsoft számomra etikailag gusztustalan üzleti és jogi húzásai miatt utálkozom attól a szoftver-ökoszisztémától, ami azonban a szoftverek minőségét illeti, ezt illetően immár erős kételyeim vannak, tényleg istenbizony jobbak-e az opensource termékek.

    Néhány tuti, az biztos. De hogy ezt úgy általánosságban szabad-e mondani... Mert ne is azt vegyük hogy mondjuk egy hozzám hasonló hobbysta mit kalapál össze. De ugye, a Linuxos világban például az X, az egy abszolút alapvető valami. Na és hát én nemrég kissé beleástam magamat a billentyűzetkezelésébe... Bár ne tettem volna! Ó, boldog tudatlanság! Azóta hogy azt láttam, akármiféle ordas disznóságokat is kész vagyok habozás nélkül elhinni minden FOSS programról. Nem is annyira az egyes konkrét kódrészletek minőségével van bajom különben, hanem az egész koncepcióval amit ott megvalósítottak, az egyes "rétegekkel", meg hogy összevissza indexelgetnek mindent, csak azért, hogy aztán a lehetséges variációk szánalmas töredékét megvalósítsák, s mindezt egy tökéletesen idióta, és "pilótavizsgával" is alig áttekinthető illogikus, ad-hoc összekalapált "interfészen" keresztül... Ó, anyám!

    Igazából azóta is azon gondolkodom, talán nem ártana megőrülnöm annyira, hogy teljesen saját billentyűzetkezelő rutint írok. Lehet hogy egyszer meg is teszem. Miért is ne, ez se lehet nehezebb mint az, hogy saját programnyelvet írjak, s azt is megcsináltam már...


    Mutasd a teljes hozzászólást!
  • Mindhárom pont üti egymást és mindegyik valójában ugyanarról beszél. Ti. hogy ne essünk túlzásokba semmilyen vonatkozásban sem, mert a szükséges mértékig alkalmazott formában kívánt és előnyös megoldások túlzó formában már hátrányossá és károssá válnak a kód és a projekt egészére is.

    A lényeg pont az, hogy az arany középutat - illetve egész pontosan a konkrétumok függvényében a legelőnyösebb kompromisszumot - kell megtalálni a felsorolt, egymásnak ellentmondó prioritások között. Ha ez sikerül, akkor a lehetőségekhez képest a legrövidebb idő alatt megírt, jól karbantartható és jól fejleszthető kódot kap az ember. És minél nagyobb túlzásokba esik valamelyik téren, annál jobban romlanak majd ezen mutatói.
    Mutasd a teljes hozzászólást!
  • Talán a 2-es és 3-as pont üti is egymást.


    Én is ezt akartam írni. 
    Mutasd a teljes hozzászólást!
  • Talán a 2-es és 3-as pont üti is egymást.

    Kicsit messzebbről nézve pedig nekem az út és az utazás a fontos, nem a megérkezés. A programozást nem pénzért csinálom (az is jól jön), hanem a szépsége miatt.

    A megvalósított és a megtervezett, "épített" osztályok között pont az a különbség, hogy a cél az ügyfél igény kielégítése vagy maga a szépen működő osztály.

    Minden programozói órába bele van kalkulálva 25-30%-nyi puffer. Ha valaki szépen halad, miért ne használná el a puffert a LoadXy() metódus mellett annak SaveXy() megvalósítására még akkor is, ha jelenleg nem használják. Sőt ez a metódus túlterhelésre is igaz: egy általános, világi paraméterhalmazra kell felkészíteni, nem pedig a konkrét célra.

    De ha valaki továbbra is coder-robot akar maradni és csak az 5Ft/perc-et akarja letudni napi 480 iterációban az maradhat úgy :)
    Mutasd a teljes hozzászólást!
  • Nem mondot újat. Vagyis nem jellemzők rám ezek a dolgok.
    Egyébként Google csak maga nevében nyilatkozhat, hogy mi vált be nála és mi nem. Programozónkénr, munkánként eltérhetnek ezek.
    Mutasd a teljes hozzászólást!
abcd