Szoftverfejlesztéssel foglalkozó kisvállalat döntéshozójaként, kit alkalmaznál fejlesztőnek?

Egyéb

A kódert, aki semmiből gyorsan, töménytelen, jó kódot ír, csak dokumentálni és karbantartani ne kelljen.
13% (65 szavazat)
A programozót, aki specifikációból, szép, karbantartható kódot ír elfogadható sebességgel, kommentezve.
70% (351 szavazat)
A szoftvermérnököt, aki az alapoktól kezdve a dokumentációig megtervezi a rendszert, de csak lassan.
17% (86 szavazat)
Összes szavazat: 502

( uid_17720 | 2011. 04. 14., cs – 13:11 )

Ez nagyon feladatspecifikus szerintem.

Akkor is függne a döntésem attól, hogy a cég rendelkezik-e már konkrét elképzelésekkel, egy projektre kell-e alkalmazni az új munkatársat, vagy esetleg hosszú távra, mennyire sürgős az alkalmazás átadása, stb.

Tipikusan az ilyen emberek után kell NAGYON-nagyon sok szemetet eltakarítani. Mert megoldotta az éppen aktuális problémát. De csak azt.

Bár hozzá teszem, a kérdésben az szerepelt, hogy jó kódot ír. Na most tipikusan ezek az emberek nem szoktak jó kódot írni.

----------------
Lvl86 Troll

Nem tudom, bennem eleg sok van az elso variansbol. Az en kodjaim (ez masok velemenye) szepek, atlathatok. Szerintem meg volna hova fejlodnom, sem a dokumentacioiras, sem a teszteles nem az erossegem, es idonkent szerintem csunya kodot irok.

Szerintem ez habitusfuggo. En azert probalok gyors munkaban is szep kodot irni, mert feledekeny vagyok, es egy osszevissza kodot nem biztos, hogy holnap is erteni fogok. Vannak olyan esetek, amikor nagyon-nagyon tomeny es csunya kodot irok, de olyankor egyreszt el szoktam vonulni a sarokba szegyelleni magam, masreszt ha van idom ra - es erdemes -, akkor atirom szebb formaba. Tipikusan az ilyen "egyszer kell, soha tobbet" cimu kodokat szoktam ugy hagyni, ahogy van. Bar, most van egy formedvenyem, amit aktivan hasznalok, es mar nagyon bantja a csoromet, hogy nincs idom letisztazni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( szilard_ v | 2011. 04. 14., cs – 13:46 )

Olyat, aki számonkérhető, megtalálható. Nem mindig sikerült.

( dii | 2011. 04. 14., cs – 13:57 )

A megrendelők jó ha az (A) esetet hajlandóak kifizetni, mert elég ha a dolog "működik". Több pénzt nem áldoznak rá. A kódolás + doksi mellé pedig még szükség van minőségbiztosításra, unit tesztekre, supportra stb. Általában pénz nem jut rá.

Idióta ügyfélnél. Aki hosszú távon szeretne egy alkalmazást, annak muszáj belátnia, hogy meg kell venni a dokumentációt, a támogatást és a "minőséget" (ami hát ügye nem (csak) tesztelés, de jó tesztekből általában jó minőség születik). Vagyis számonkérhető legyen az, amiért fizetett.

sajnos a legtöbb ügyfél az. nem érdekli a forrás, az sem hogy van-e kommentezve. működjön ahogy kérte. ha meg bugot talál, vagy bővíteni kell, nyekereg telefonon.
a papírtéma a legtöbbször akkor fontos, ha a vevő nagyobb cég, és van külön minőségbiztosítási szervezete, azoknak mindig számít.
---
Why use Windows, if you have open doors… to Linux

A legtöbb üzleti életben ügyködő fejes nem látja át ennek a jelentőségét. Csúnya kifejezéssel mondhatnám azt is, hogy jó, ha az excel kezeléséhez viszonylag értenek. Ilyen megrendelő nem nagyon fogja átérezni, hogy mit jelent a dokumentáció léte, vagy nem léte, csak azt fogja látni, hogy egyik 500ezer+ÁFÁ-t kér, a másik meg kihozza 120-ból.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

És nem csak első körben nem fogja fel, hanem amikor tisztán látszik a termékcsapda, meg hogy az olcsó egyedi sz@r valójában sokszorosába kerül, mint az elsőre drágább, de jól dokumentált, számon kérhető módon fejlesztett megoldás - emiatt sz0pnak még sokan Clipperben összegányolt könyvelőprogikkal és hasonló okádmányokkal...

( Exit | 2011. 04. 14., cs – 14:03 )

Na de milyen specifikáció? Felhasználói igényeket tartalmazó doksi vagy rendszerterv. Mert ha az előbbi akkor nem úszod meg a programtervezőt. Ha az utóbbi akkor elég lehet egy programozó is, de akkor már valaki elvégezte a programtervező feladatát.

Huh, dinamikusabb kornyezetben hogy elszallnak ezek a szep gondolatok :). Az a mokas, amikor minden ilyesmi nelkul kell karbantarthato kodot irni, gyorsan.

Ugyanis a rendszerterv alatt annyi ido elmehet, ami utan mar nem versenykepes a termek (pl. egy arazasi algoritmus).

----------------------
while (!sleep) sheep++;

Rendszerterv mindig van csak a mérete eltérő. Kisebb feladatnál lehet, hogy le se írják, mert olyan egyszerű. Vagy a megrendelő olyan igényes doksit ad, hogy abból gyakorlatilag látszik a rendszerterv is.

A lényeg, hogy valaki mindig elvégzi a program megtervezését. Egy bizonyos feladatméret után viszont az A meg a B ezt a feladatot nem fogja tudni ellátni. Viszont lekódolni ettől függetlenül még lehet, hogy ők fogják.

Mondjuk én nem hiszem, hogy kerülök ilyen helyzetbe, amiről a kérdés szól, de ha ez a választék és a feladat bonyolultsága nem ismert én C-t ajánlom (mert neki valószínűleg meg van a tudása minden fajta problémához) és ha van keret, vagy bővíteni kell, akkor A-kat alá/mellé. Aztán majd üti C A fejét, hogy dokumentáljon. :)

( GES | 2011. 04. 14., cs – 14:04 )

76 boss két óra alatt!
És akkor ki dolgozik? ;)

( asch v | 2011. 04. 14., cs – 14:13 )

Úgy látszik a szavazásnál a vágyak kaptak szerepet a valóság helyett :-). A kódert csak 15% választotta, a valóságban biztosan nagyobb az arányuk.

( uid_15426 | 2011. 04. 14., cs – 14:16 )

Feladatspecifikus, hogy A-t vagy B-t, de C-t soha. Get the job done, man!

Sehol a vilagon nincs szukseg 'jo' vagy 'szep' kodra. 'Eleg jo' es 'eleg szep' kodra van szukseg, ha valaki ezt nem erti meg, akkor csokkenti a munkaltatoja beveteleit. Mindennek van opportunity cost-ja.

----------------------
while (!sleep) sheep++;

( kikke | 2011. 04. 14., cs – 14:23 )

"Újabb értelmetlen szavazás" volt már?

( creativex | 2011. 04. 14., cs – 14:49 )

Az 'A' a nyertes típus, mert annak a kihívás élvezet, tuti hogy megold mindent.

Én nem tartom magamat 'A'-nak, inkább 'B'-nek, vagy ha szükséges, egyes feladatoknál 'C'-nek, de számomra is élvezet, és kihívás, pedig megtalálnak néha elég meredek kérésekkel. Eddig mindent megoldottam.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( lgb | 2011. 04. 14., cs – 15:22 )

Ha van ra keret stb akkor A+B+C :) Ha az "A" esetben a koder tenyleg jo, nagy a valoszinuseg, hogy nem hulyegyerek, es nem is most kezdte a dolgot. Viszont ha van eleg ido ra, lehet, nem vele csinaltatnam meg, hanem "nem ir doksit ide vagy oda" kipreselnek belole infot, hogy mit gondol, amit input-nak odaadok a "B" esetre. Ha tenyleg van eleg ido akkor a "C"-nek. Vagy kombinacios dolgokkal team-et csinalni beloluk :)

Amugy nagyon feladat fuggo. Van olyan project is ami SOS, es esetleg nem is hosszu tavra kell, akkor pl az A is tekeletes lehet. Van amikor viszont magaban csak az A elfogadhatatlan, mert pl masnak kell aztan tovabbfejlesztenie stb, es mi van ha nincs se doksi, se comment se semmi, es teli van egyedi megoldasokkal ...

( nrgie | 2011. 04. 14., cs – 15:34 )

Kár volt a időtényezőt belevinni az opciókba.
Valódi fejlesztés a kóderektől jön.

"A sw életciklusa nem ott kezdődik, hogy fogom a fejlesztőeszközt, és nyitok benne egy új projektet, és elkezdem vele f0sni a kódot."

Persze, egy k+1-edik szamlazoprograme, vagy CMS-e nem. De ha valami olyasmit akarsz csinalni, amit eddig meg soha senki, akkor az nehezen fog menni prototyping nelkul.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( emberk | 2011. 04. 14., cs – 16:13 )

Van egy kollegám, aki a C, és A kombinációja. Eszméletlen lassan dolgozik, de se dokumentum, se komment se semmi. :D Antikóder :)

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( Oldman (nem ellenőrzött) | 2011. 04. 14., cs – 16:44 )

Ez tipikusan a nem jól megfogalmazott kérdésre csak hülye válaszok tudnak jönni esete...

Egyetlen egy programozót akarunk felvenni, vagy nulláról akarunk egy több fős programozó teamet felépíteni? Egyáltalán nem mindegy mi a végcél. Egyáltalán akarunk fizetni nekik valamit? :-)

( Aadaam v | 2011. 04. 14., cs – 17:02 )

Olvassatok Beautiful Team-et O'reilly-bol

Mindegyikbol egyet, ugy, hogy eleg diszjunkt teruletekhez ertsenek.

(En btw leginkabb C vagyok, igaz, en gyorsan tudok tervezni, es utana kozepgyorsan irok szoftvert, karbantarthatoan :)

( yetii | 2011. 04. 14., cs – 17:33 )

Az A opció el van rontva. Ha valami jó kód, akkor az könnyen karbantartható, ha nem tartható könnyen karban, akkor nem jó a kód. Egyébként ez a típus általában olyan kódot ír, ami jól karbantartható, mert ők tipikusan a szép megoldásokat keresik. A dokumentáció viszont tényleg olyan, amit az ilyenek nem szeretnek, mert abban nincs kihívás.

( lzrd | 2011. 04. 14., cs – 17:52 )

A-t semmiképp. Az én akarok lenni, mint tulajdonos :)
Ha nincs karbantartva a kód, nincs dokumentálva, akkor az a fejlesztés halott (lesz). A fejlesztőnek nem kell szépen lassan megterveznie semmit. Pláne nem az ún. "fejlesztőmérnök"-nek. Majd az architect megtervezi. B-re pedig nyugodt szívvel rá lehet bízni a kódolást, mert rendben meg fogja csinálni és biztonságban leszünk, mert le is dokumentálja. Így az idő múltával is bármikor tudható lesz, hogy az adott kód mit is csinál.
--
unix -- több, mint kód. filozófia.
Life is feudal

( arpi_esp v | 2011. 04. 14., cs – 18:20 )

az A tipus is szokott kommentezni, de persze nem az i=5; tipusu sorokat, csak ahol szukseget erzi (trukkozesek, nem trivialis reszek).

szerintem A tipusbol kell 1db, de max 1db, mert tobb nem nagyon fer meg egymas mellett. 1 visoznt kell, ha B es C nem tudnak megoldani egy problemat...

A'rpi

No igen... Bár a be fog sz@rni helyett van, ahol a hibásan fog működni a korrekt megfogalmazás :-) Meg persze egy FIXME is, hogy a kódban könnyen megtalálható legyen, ha már nem kell ötnek lennie (vagy épp 42-re kell változtatni) Bár az ilyen fix bedrótozott mágikus konstansoknak nem a bugH^H^Hkódhalmazban van szerintem a helye, hanem valahol egy header-ben/include-ban/konfigurációs állományban, azaz pl: 


bughalom_konstansok.h
// Ha ez nem ot, akkor semmi nem mukodik jol FIXME
#define MAGIKUS_I    5

bughalmaz.c
#include "bughalom_konstansok.h"

...
// FIXME
i=MAGIKUS_I;

Az elvekről próbáltam megemlékezni: pl. arról, hogy a 3456 soros foo.c forrásfájl 234. és 562. sorában nem használunkmágikus konstansokat, hogy működjön a program, hanem ezeket szépen kigyűjtjük egy include-ba, akárhova, és azokra hivatkozunk a kódban. Ha hibásműködés-gátlás a mágikus konstans oka, akkor az include-ban, és a használat helyén is illik FIXME-t rakni.

( szipka | 2011. 04. 14., cs – 19:36 )

Erdekes feltetelezes, hogy gyors szoftvermernok nincs. Egyebkent en is arra szavazok, hogy projectfuggo de egy 60% B 40 %C idealis lehet.

( uid_17626 | 2011. 04. 14., cs – 20:39 )

Ciki, nem ciki én "A" vagyok, de szerencsére senkinek nem kell elszámolnom. :)
Doksi elvből nem készül nálam, hiszen aki a forrásból és a kommentekből nem vágja mi miért van az ne is nyúljon hozzá.
A GUI-hot dettó nem készül doksi, mert az a GUI amit magyarázni kell az inkább API. :)

ps.: nem vagyok IT szakember, autodidakta műfajkedvelőnek mondanám magamat

"aki a forrásból és a kommentekből nem vágja mi miért van az ne is nyúljon hozzá"
Ez sajnos csak néhány 1000 sorig működik. Lehet hogy a kódból és a kommentből kiderül, hogy az adott helyen mi történik, de valahogy az adott helyre is el kell jutni, nagy projektnél már nem lehet megtenni, hogy az elején elindulok ...

Eddig csak a "nincs rá pénz, nincs rá idő, nem szeretem csinálni" volt a kifogás a dokumentáció ellen. De látom alakul már az ideológia is mögé.

Véleményem szerint A típusú embernél (tisztelet a kivételnek) könnyen függőségi viszonyba kerülhet a kedves megbízó (tekintheti akár új családtagnak is). Ha a kóder úgy akarja bebiztosíthatja a munkahelyét egy életre, hiszen nem lesz aki át tudná venni tőle a kódbázist, ami önmagát dokumentálja, azaz csak az eredeti szerzője érti hogyan működik. Tapasztalat, láttam már ilyet. A kedves munkaadó csak évekkel később döbbent rá, hogy a cége gyakorlatilag egy embertől függ (és az nem ő), aki csak úgy kiváltható, ha drágán teljesen újraíratja, dokumentálja az évek alatt összehordott kódbázist (és nem egy másik kóderrel).

Igen, tenyleg latszik hogy autodidakta vagy. Komolyabb munkanal az egyik legfontosabb informacio az, hogy adott megoldasok _miert_ kerultek bele a kodba, ami magaban hordoz egy halom olyan tapasztalatot, korabban bebukott koncepciot aminek ofkoz mar nyoma sincs a kodban. Tehat igazad van, a kodbol kiderul _mit_ csinal, de az mar nem, hogy _miert_ pont az a megoldas lett valasztva. Egy magas szintu osszefoglalonak, ami tartalmazza a fejlesztesi szempontok prioritasait is feltetlenul leteznie kell. Kodot magyarazni ertelemszeruen felesleges kulon leirasban.

Ezzel max a rendszertervet úszod meg. Bizonyos méretig.

A _feladatot_ (!= rendszerterv) márpedig le kell fektetni, normálisan, kidolgozva, fogalomtárral, folyamatok egyértelmű (egyszerű humanoid számára értelmezhető) levezetésével, különben szét fog folyni az egész fejlesztés, mert nem egyértelmű a cél.

Nálunk, pl. első X fejezet fix egy speckóba:

1. Tartalom
2. Projekt célja
3. Rendszer felhasználói
4. Fogalomjegyzék
5. Rendszer futási környezete
6. Folyamatok nagy vonalakban
7. Innen kezdve változó, általában az egyes részegységek, folyamatok részletes kifejtése, akár GUI vázlatokkal.

És ez még nem rendszerterv, ez csak a feladat leírása. Bár ilyen összeszedett dokumentumból nagyságrendekkel egyszerűbb rendszertervet készíteni (meg időt/költséget becsülni).

----------------
Lvl86 Troll

No ez az, ami elméletben valóban így van, és az egyemisták kapják rá az ötösöket. Gyakorlatban egyszer volt alkalmam ehhez konvergáló dolgot látni, amikor egy közbeszerzési pályázaton elnyert projektet kellett végignyomni. Akkor amíg mi szépen elmélkedtünk a dolgokon és gyártottuk azokat a doksikat, amivel majd a seggünket tudjuk védeni, a nagyok elindultak közbe szerezni...

Volt egy másik élményem is ezzel kapcsolatban, amikor a rendszerterveket arra használták fel, hogy szabályszerű háborút vívjon a megrendelő a kivitelezővel.

Ellenben a hétköznapokban fél nap alatt kell adni becsléseket, és záros ktgvetés miatt még a tesztelésre sem jut igazán idő. De az elv szép lenne.

Nah, a közbesz az egy külön állatfaj a kategórián belül.

"amikor a rendszerterveket arra használták fel,"

Mondom: funkcionális specifikáció. NEM rendszerterv.

Funkcspec: mit kell csinálni?
Rendszerterv: hogyan valósítsuk meg azt?

Naaagyon messze van a kettő egymástól.

"hogy szabályszerű háborút vívjon a megrendelő a kivitelezővel."

Nah, a probléma az, hogy néha muszáj. Pl. mikor előjön az, hogy a megrendelő úgy gondolta meg úgy értelmezte... Ezeket jobb az elején letisztázni.

----------------
Lvl86 Troll

Konkret pelda: munkatars tegnap kapott meg egy kisebb projektet karbantartasra. Szokasos semmi doksi, "a forraskod+komment a doksi" style kod. Egyebkent kollega szerint nagyon jol ossze van rakva a cucc (Konnyen atlathato, modosithato, stb.).

Problema akkor volt, amikor eljutott oda, hogy ez mind szep es jo, de hogy is kellene ennek mukodnie?

----------------
Lvl86 Troll

En ezert programozok be mindig valami failback dolgot a programjaimba, peldaul parameter nelkul hivva helpet ad, vagy ha parameter nelkul is van ertelme, akkor valami parszavas leiras van az elejen.

Egyebkent mondjuk kerdes a "hogyan mukodik" kerdes aspektusa. Ha valami jol atlathato, akkor az is latszik belole, hogy ez most sql-bol szedi elo az adatokat, ez most json-t bizgat, etc. valszinuleg lehetett volna atlathatobb is a kod.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Azt leszogezhetjuk, hogy a kod mindig jol mukodik, kiveve ha compiler bugos. De a kerdes az, hogy a sepcifikacionak megfelel-e. Van-e egyaltalan specifikacio. A konkret megoldassal egyaltal lefedheto-e teljesen a specifikacio, stb. Na ez az, ami a kodbol es a kodkommentekbol soha nem fog kiderulni, sem egyeb helpekbol, stb. Max. a kis barkacsszkriptek vilagaban.

A komuves nem veletelnul nem tud hazat epiteni. A komuves falat tud rakni (remelhetoleg azt rendesen). Persze tudjuk, hogy az emeberek nagy tobbsege meg mindig azt hiszi, hogy a komuves epiti a hazat, de ma mar hala istennek ez tobbnyire nem igy van. Letezik tervezo, statikus, epuletgepesz, stb. Talan ez nem veletelen. De ha azt modnanam, hogy a komuves legyen kedves egy viaduktot epiteni, akkor ugye mar rogton ertehto a kulonbseg. Ami barkacsolas elmegy kicsiben az ugye nem nagyon megy nagyban. Erre mar a 60-as 70-es evekben raebredtek a szoftver iparban. Persze erdemi valtozas csak evtizedek mulva allt be.

Ami vicces, hogy meg most is vitatkozni kell (ld. pl. ezt a topicot) annak szuksegesegen, hogy kell-e kovetelmenyelemzes, architekturalis tervezes, design, verifikacio es validacio. Na es persze mindez tisztessegesen dokumentalva. Meg most is sokan gondoljak, hogy a koddal kezdodik es fejezodik be a munka. Hat egy disznoolat meg lehet igy epiteni, de ma mar a kor kovetelmenyeinek megfelelo csaladi hazat egeszen biztosan nem, hogy nagyobb letesitmenyrol ne is beszeljunk. Ugyanez igaz a szoftveriparban is.

"Ami vicces, hogy meg most is vitatkozni kell (ld. pl. ezt a topicot) annak szuksegesegen, hogy kell-e kovetelmenyelemzes, architekturalis tervezes, design, verifikacio es validacio."
Ami ennél is szomorúbb, hogy előfordul, hogy ún. "szoftverfejlesztő" cég vezetőségével sem sikerül ezt megértetni.
--
unix -- több, mint kód. filozófia.
Life is feudal

Na egy kicsit elkanyarodtunk az eredeti felvetéstől, és véletlenül arról kezdtünk el beszélni, hogy követelmény specifikáció, meg rendszerterv, amihez a szoftver_fejlesztő_nek jó esetben kevés köze van, nem ő készíti. "Kisvállalat"nál semmiképpen, kisebb cégnél inkább. A kód dokumentálása meg nem a rendszerterv, de még csak nem is a követelmény specifikáció.

Másrészt ütötte itt valaki a dolgot, hogy a sw életciklusa _elméletben_ hol kezdődik. Kérdem én: melyik szoftver, és mikor hogy. Sok ma rendkívül népszerű framework pontosan, hogy úgy kezdődött, hogy a _kóder_ elkezdett valami ötletével szöszölni/bohóckodni, aztán jött egy másik agyas, és összedugták a kócos fejüket. Van olyan is, amikor egy konkrét PoC kód kelti fel egy-két kliens érdeklődését.

Csak az a fránya egyetem... IT-témakörben egyemista képzést csak úgy engednék, hogy előtte elvégez egy hasonló szakot a delikvens főiskolán is ;] Tisztán SRS-SDS alapú fejlesztést eddig csak a t-systemsnél láttam -- bár ott politikával kezdődött a sw életciklusa -- de néha körbe szaladgálta őket is egy kisebb cég, ahol a dokumentáció másodlagos volt. Ez van.

Azert nem kezdenem el szidni egybol "az egyetemistakat" (ide ertve most a foiskolasokat is).

Egy belso(bb) projektnel megertem, hogy ezek enyhebbek (ld. frameworkos pelda feljebb, nalunk is ugy alakult ki, hogy egyik projekt alapjat alakitottuk at, viszont ott is volt azert egy hevenyeszett lista, hogy megis miket szeretnenk elerni. A konkretumokat meg kidolgoztuk akkor, amikor elkezdtunk azzal a resszel foglalkozni. Persze, ez itt-ott meg is latszik a kodon kisse).

Azonban azokat, akik azzal jonnek, hogy ez csak elmelet es gyakorlatban ilyeneket soha nem keszitenek meg csak megkozelitoleg se, azokat nem ertem: hogy es mi alapjan adnak szerzodest? Valamilyen funkcspecnek nyilvan resze kell lennie a szerzodesnek. Kis cegnel meg nyilvan nincs kulon ember csak specifikacio irasara.

----------------
Lvl86 Troll

Nem szidom, csak kicsit naivan fekete-fehérben látják a világot (és hajlamosak osztani is az észt), miközben sokszor kék-zöld-hupilila. Valamilyen specifikáció mindig lesz, ha nem is részletes, de ez sokszor csak követelmény-szintű. Abból meg nem nagyon fogsz szerelgetni egy elcseszett ws/struts/spring/hibernate struktúrát, max annyit látsz, hogy mit kéne csinálnia.

Amikor terveznem kell (no spec, csak ábrák, dobozok és folyamatok)
Ha nem konkrét feladatra kell írnom valamit, hanem kreatív lehetek, akkor:
általában megálmodom az ERP új moduljait abból kiindulva, hogy a jelenlegi adatbázisból/ban milyen új összefüggéseket és kimutatásokat/elemzéseket készíthetek, amelyeket felhasználva tudom növelni a profitot/termelékenységet vagy csökkenteni a humán tényezőt. Ez igazából nem egyértelműen programozói/rendszertervezői munka. Nekem a programozás egy eszköz a célomhoz, mint ácsnak a szekerce. (Szerintem minden cégvezetőnek jót tenne, ha megtanulna programozni, mert segít abban, hogy megtanulj rendszerezni, amelyre pedig minden vállalatnak hatalmas szüksége van/lenne.)
Kedvenc programozási feladataimmal:
1. Egyszerűsítek
2. Kényelmesebbé teszem az életet magamnak és a környezetemnek
3. Profitot növelek vagy költséget csökkentek
4. Versenyelőnyre teszek szert
5. Élvezettel csinálom, mert olyan dologra jöttem rá, amit más nem is lát sem problémának nekem pedig már megoldásom is van rá

Amikor már kódolnom kell:
Én első lépésben csak a UI-val törődöm, amit interakciókra bontok, így:

1) Mit lásson a felhasználó?
2) Mit csináljon/csinálhasson a felhasználó?
3) Mit kapjon a felhasználó interakció után?
4) goto 1

Második lépésben a hogyan-t lekódolom, törekedve arra, hogy az újrahasznosítható részeket függvényekbe rakjam (nem használok OOP-t*).
Lekódolás előtt elkészítem a hiányzó SQL részeket.

*Sokat olvastam az OOP-ről azt keresve, hogy miért jó nekem. Nem találtam meg, így maradt ez az oldschool függvényezési módszerem.

ps.: Autodidakta kódernek tartom magam és ha döntenem kellene, akkor nem vennék fel senkit sem a helyemre, hanem vennék egy nagy cégtől valami stabil megoldást. Ha meghalok akkor remélem az örököseim ezt teszik, feltéve, hogy ők nem akarnak megtanulni kódolni. Mindenesetre ezt már javasoltam nekik.

( zolpet | 2011. 04. 14., cs – 21:19 )

Egyszerű.

Ha tegnapelőttre kellett volna demózni a projectet, akkor A. Ha ráérünk normális kódot csináltatni, akkor B. Ha még igazából nem is tudjuk 100%-osan pontosan, mit és hogy szeretnénk, akkor C. Ha B vagy C elakad, akkor határidő előtt pár nappal jöhet A.

A dolog ugy nez ki, hogy eloszor jon "A" es alaposan elb....a. Majd miutan a megrendelonek / managementnek mar nincs penze, se turelme, meg hat vegulis majdnem jol is mukodik, csak hat egy "kicsit" kene meg rajta ugye javitani (igen, az a kicsi az pont azert hianyzik belole, mert azzal a ganyolassal, amit A csinal, mar nem volt megoldhato.), akkor hozzak "B"-t vagy "C"-t, akivel megprobaljuk a dolgot rendbetetetetni,

1. eset:
"A" a lenghangosabban pofazik es vedi a baromsagait es "B"-nek vagy "C"-nek orokos kuzdelem lesz az "A" altal beleganyolt elegans es zsenialis megoldasoktol megszabadulni. Valoszinuleg ha "A" tamogatast elvez a cegben "B" vagy "C" hamarosan odeball.

2. eset:
"A" az egojaval aranyos fizetesi igenyeinek negativ elbiralasa miatt lelep. Mostantol persze "B" ill. "C" mar megcsinalahatna akar jol is, de az ujrairasra / refaktoralasra a megrendelo / management nem biztosit eleg ido- es penzkeretet.. Ezert aztan egyutt szivnak meg evekig az "A" altal osszeganyolt spagetti kod miatt, amit persze toldozni foldozni kell, es idorol idore a legegzotikusabb hibakat produkalja.

( crypton | 2011. 04. 14., cs – 22:24 )

D: Olyat aki gyorsan és jól tud önmagát dokumentáló beszédes kódot írni, némi kommentezéssel ott ahol erre szükség vagy mert szükségét érzi. Ezenkívül lássa át az egész projectet és tartsa mindig a célkeresztben az egész rendszer működését, gyorsaságát, megbízhatóságát, alapelveket (pl. KISS).

( utesroes | 2011. 04. 15., p – 07:26 )

sziasztok!

azt szoktam mondani munkával kapcsolatban, h. a következő képen tudok dolgozni: jól, gyorsan, olcsón, de ebből csak kettőt választhatsz

(nem csak a szoftverfejlesztésre igaz)

G.

( tzp | 2011. 04. 15., p – 09:12 )

Igazi ojjektív közvéleménykutatás kereskedelmi média módra...

Mivel csak a 2. válaszban nincs pejoratívum, ezért valahogy az az érzésem, hogy már eleve megvan a jó válasz, amit hallani akar a kérdező, ld. szavazás eredmények :)

en peldaul azert valasztottam a 2. valaszt mert magam tanacsado vagyok, nem azert mert az az egyetlen ami nem pejorativ (ezzel egyebkent egyet ertek). amit elkeszitunk megvalosithatosagi tanulmany az magaban foglal olyan fejezeteket ami alapjan a 2. tipusu ember remekul tud dolgozni. ott mar nincs szukseg a 3. tipusra mert o csak a sajat szajize szerint modositana (tobbszor az ugyfel akarata ellenere) a megoldasi javaslatot. 1. tipusu emberrel kapcsolatban pedig egyet ertek tobb elottem szoloval. tobb kart csinal mint hasznot hosszu tavon.

( kubi | 2011. 04. 15., p – 10:05 )

Valakit, aki legalabb irni es olvasni tud? Esetleg meg angolul is.
Meg mondjuk legalabb alapszinten elsajatitotta az angol-WC hasznalatat.

A tobbibe majd csak belejon...

De komolyan. Hogy lehet, hogy ezek meg gondot okoznak egy foiskola vagy netan egyetem elvegzese utan?

De komolyan. Hogy lehet, hogy ezek meg gondot okoznak egy foiskola vagy netan egyetem elvegzese utan?

Kollégiumban (BP - börmények, jogászok, műszakiak, zeneakadémikubikosak) rendszeresen ébredtem fel takinénik 120 dB-es reggeli "csatindulójára":

- Ezek EGYETEMISTÁK!? EZEK ÁLLATOK!!!

Kezdve a konyhában! lányok által szétdobált véres tamponoktól, összeszart fiú zuhanyzóig minden előfordult.

Diploma (soha) nem helyettesíti a nevelést, kultúrát, észt.
--
Solaris Express, Opera, OpenOffice.org, Yebol

( Botond | 2011. 04. 15., p – 11:20 )

Munkaerőpiacon "C" opció nincsen. A doksihegyeket gyártó szoftvermérnökök egy nagyobb cég rendszerében dolgoznak. Ha más cégnél más a rendszer, vagy egyáltalán nincs, akkor a "C" opció egyenértékű a "B"-vel.
Amúgy az ilyen kérdésekre az általános válasz: attól függ. Ha van egy kis időd, és van tapasztalatod model vezérelt szoftverfejlesztésben, akkor egy "B" helyett vegyél föl két "A"-t, és törd be őket! Ugyanannyi pénzért 2-szer, 3-szor annyi munkát fogsz kapni. Sajnos a két "A" típusú fejlesztőd előbb-utóbb el fog menni, de addig is sokkal jobban jársz velük. A multik ugyanezt csinálják.

Ahogy én látom, az A-ból elég kevés van, hiszen feltétel volt, hogy jó minőségű kódot írjon gyorsan.
Ebből az következik, hogy ez az ember qrva sokba fog kerülni. (jót, olcsón, gyorsan, a 3-ból kettőt válassz)

Ami közelebb áll a valós helyzethez:

Van A, aki lassan ír, meg nem is annyira jót, és nem is tud nagyban gondolkozni, de legalább olcsó (junior fejlesztő). Általában az ő munkájával a végén 2x annyi meló van. Ha szerencsénk van, akkor beletanul, és lehet belőle B, vagy kiderül, hogy akár C-re is jó.

Van a B, aki mivel rendszerben gondolkozik, ritkán esik pofára, és nem kell újraírnia a kódot from scratch. Jobb esetben gondol arra is, hogy az általa csinált kódot tesztelni is kell majd, és ennek megfelelően fejleszt. A kód minősége az elfogadhatótól a nagyon jóig terjed. Sebessége egyén függvénye, lehet, hogy lassabban kódol, de közben ír unit teszteket, doksit, meg architekturális leírást is. Inkább az ő kódját szeretném karban tartani.

Van a C, ami inkább egy gondolkozásmód. Lehet akár csapnivaló programozó is, de ha át tud látni üzleti folyamatokat, akkor egy csomó plusz körtől, újrafejlesztéstől meg tudja kímélni a programozókat. A legjobb, ha ő egy senior fejlesztő, mert akkor nem csak az üzleti folyamatokat képes átlátni, hanem arra is alkalmas, hogy a megrendelő igényeit a fejlesztők számára megfelelő (technikailag megvalósítható, megfelelő teljesítménnyel kivitelezhető) formára kalapálja át, így azok még hatékonyabban tudnak dolgozni. Az ő munkája azonban odáig tart, hogy van egy specifikáció, utána "csak" figyelemmel kell tartania, hogy amit csinálnak, és ami a cél, az fedi-e egymást. Ebben a fázisban ő általában senior fejlesztőként működik közbe.

Egy kis cég esetén inkább egyedi megbízással vennék fel C-t, egyébként senior fejlesztőkkel dolgoztatnék, és csak a legritkább esetben junior-okkal.

Nem fekete és fehér.

Képzelj el egy esetet: Megmondod, hogy X programot kell írni grafikus felülettel

- egyik kóder gyorsan nekiugrik, éjt nappallá téve dolgozik és 2 hét múlva be is fejezi
- a másik kóder teázik, kávézgat, netezik. Elolvassa, hogy mások hogyan szokták csinálni, esetleg nincsenek-e lib-ek, vagy felhasználható komponensek. Tovább teázgat, kávézik és a megfelelő libek használatával 1 hét alatt megírja, de úgy, hogy közben még a bevásárlást is elintézi a felesége számára.

Azt hiszem informatikában ez tipikus példa. Ha olvasol, úgy kódolsz, nem biztos, hogy lassabb leszel.

Láttam már indiai kódot, a mottójuk az volt, hogy "Halál a string.h-ra!"

Megmutatták, hogy a burzsuj nyugati világ hívságai nem kellettek nekik. Ők bizony újraírták az strcpy-t, a memcpy-t, az strlen-t, a memset-t, többször is. Minden C fájljukban volt legalább egy memcpy implementáció. Tiszteletben tartották a másságot, mindenki olyan memset-et írt, ami neki jólesett.

Így fordulhatott elő a következő megvalósítás is:

int a = 2 << b;

Indiaiul:

int a = (int)(exp( (double)b * log( 2.0 ) )) + (int)(0.5);

Nekem a leginkább a 0.5 int-re kasztolása tetszett, amit hozzáad, hogy a kerekítési problémát megoldja. Felér egy sleep-pel.

:)

( hrgy84 | 2011. 04. 15., p – 23:18 )

B-t jeloltem, de igazabol egy A+B kombinacio az igazi. Ha a projekt jol van megtervezve, akkor jut ido a dokumentalasra, tesztelesre. Az A altalaban vagy azert nem dokumental, mert nem hagynak neki idot ra, vagy irrealis igenyek vannak a dokumentalas teruleten. Szerintem egy max 5-8 soros fuggvenyt peldaul nem feltetlen kell dokumentalni, mert ugyis valami olyasmi sulne ki belole, hogy: 


/**
 * counts spaces
 */
int countSpace(char *s) {
   int c = 0;
   for(char *p = s; *p != '\0'; p++) {
      c += (*p == ' ');
   }
   return c;
}

Es egyreszt a fuggvenynev beszedes, ezt kommentben megismetelni felesleges, masreszt a komment nem tesz hozza semmit a dokumentaciohoz, aminthogy nincs is mit. Nyilvan egy ennel bonyolultabb lelkivilagu fuggvenyt illik, de az mar ugyis tul fog logni az 5-8 soron.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha a rendelkezesre allo idot kitolti maga a fejlesztes, akkor nincs hova tervezni. Ha van egy kethetes munka, amit egy-masfel het alatt kell elvegezni, akkor rohadtul nincs ido semmire. A nincsbol nem lehet idot szakitani.

Hidd el, az alapelvekkel en is tisztaban vagyok, mindossze en ugy latom, a valosag nagyon sokszor nem hagy teret az elveknek. Mert minden azonnal kell, lehetoleg mar ket hettel ezelottre.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A kéthetes munka számomra tervezés-implementálás-tesztelés időtartamot jelent. Lehet rá másfél, sőt, akár egy hetet is tervezni - a munka akkor lesz kész, akkor lesz release érett, ha a tervezés során kialakított teszteseteken is végigmentünk, és jónak találtuk az eredményt.

Legutóbb megkérdezték tőlem, hogy mennyi idő implementálni valamit.

Osztozzam, szoroztam, kinyögtem, hogy másfél hét. Ezután 3 nap múlva működött minden.

Amikor a főnök megkérdezte, hogy nem becsültem-e fölé az időt:
- nem, mert nem volt semmilyen hátráltató dolog: áramszünet, napi 3 értekezlet, sürgősen megoldandó egyéb dolog
- nem találtam olyan hibát, ami lehetetlenné teszi a megvalósítást és 4-5 nap a hiba javítása

A másfél hetes becslésem azt jelentette, hogy ez az az időpont, amikor már 99%, hogy működni fog.

Erre en is egy peldat hoztam magammal. A legutobbi projektemnel megkerdeztek, mikorra gondolom, hogy kesz lesz. En ket hetet mondtam ra, a fonokom adott egyet. Mikor jeleztem, hogy ez biztos nem fog menni, leven meg at is kell neznem a projektet (a feladat egy meglevo projekt atalakitasa volt), a "menni fog ez" cimszoval lettem elhajtva. Megcsinaltam egy het alatt a projektet, mert a ceg mar elvallalta, de nem vagyok ra buszke.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( hacksagon | 2011. 04. 16., szo – 00:04 )

A google-n menjetek rá az oldal forrására. Szerintem miután föleszméltetek a sokkból, senkinek a munkájára nem mondjátok majd, hogy csúnya kód...
---
O Fortuna! Velut luna! Statu variabilis! --- műűvelt aláírás http://bit.ly/gut42V

Pedig valószínűleg így van. Az utóbbi években egyre többen tömörítik (és nem csak gzip-pel) a különböző http-n utazó tartalmakat: js-t, css-t és a html-t is. Ezeket természetesen nem kézzel teszik hanem erre szolgáló célprogramokkal. A cél az oldalbetöltés sebességének növelése és az adatforgalom csökkentése.
Ha valakit érdekel ez a téma Steve Souders (régebben a Yahoo-nál, most a Google-nél dolgozik) több könyvet is írt a témában.