Szoftverfejlesztéskor alapesetben meddig vagy hajlandó tartani a patterneket és a konvenciókat?

Programozás

Amíg nem megy az olvashatóság / karbantarthatóság rovására.
7% (18 szavazat)
Amíg nem megy az optimális futásidő / memóriaigény rovására.
7% (18 szavazat)
Amíg nem megy az olvashatóság / karbantarthatóság VAGY az optimális futásidő / memóriaigény rovására.
11% (30 szavazat)
Amíg nem megy az olvashatóság / karbantarthatóság ÉS az optimális futásidő / memóriaigény rovására.
8% (20 szavazat)
Amíg nem tart sokkal tovább megírni úgy valamit, hogy tartom őket.
9% (24 szavazat)
Minden esetben tartom őket, bármi is az ára.
3% (7 szavazat)
Utolsó szempontjaim közt van, de ha tényleg semmi más rovására nem megy, tartom őket.
8% (20 szavazat)
Meg se próbálom tartani őket, inkább hallgatok a saját magam / a csapatunk józan eszére.
8% (20 szavazat)
Nem vagyok szoftverfejlesztő / nem találkoztam még patternekkel vagy konvenciókkal.
40% (104 szavazat)
Összes szavazat: 261

( saxus | 2014. 09. 23., k – 13:52 )

Egeszen addig, ameddig az adott pattern/konvencio nem eleg rossz ahhoz, hogy ne hasznaljam.

Miert? Mert (jobb esetben) kozismertek, ismertek az elonyok/hatranyok, es ne basszunk mar ki a masikkal rambokoderkedessel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Közismertek... sajnos inkább kevésbé, mint kellene. Rengetegszer találkoztam olyasmivel, hogy a készítők ismertek patterneket a nevük alapján, csak sajnos nem pont arra használták őket, ahogyan pl. a GoF-ban is szerepel, innentől kezdve jobb lett volna, ha nem annak hívják. Igen, korábban én is elkövettem ilyesmit.
Másik kedvencem, amikor a kód tekintélyes része nevesített pattern implementációkból áll, a lényeg meg nem látszik tőle.
Pl. nemrég volt szerencsém nézegetni az Apache Jackrabbit forrását, és amikor a factory factory-ját is factory-val állította elő, na ott dobta le az agyam az ékszíjat.

Hihi, jocucc, de van benne egy csomo ilyensmi, amitol agyfaszt kapok:


if (Babamfasza.faszababa(valami)) {
return true;
} else {
return false;
}

helyette:


return Babamfasza.faszababa(valami);

Meg nincsenek hozza valodi unit tesztek, csak egy integracios teszt, ami sokmindent atmozgat. ;^(

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

nem feltetlen ekvivalens a ketto:

"An if-then-else statement is executed by first evaluating the Expression. If the result is of type Boolean, it is subject to unboxing conversion (§5.1.8). If evaluation of the Expression or the subsequent unboxing conversion (if any) completes abruptly for some reason, then the if-then-else statement completes abruptly for the same reason. "

http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.9

Tudsz konkret peldat olyan esetre, ahol az en valtozatom mas eredmenyhez vezet? a "completes abruptly for some reason"-ra nekem csak a null ertek unboxolasa ugrik be, de az ugyanoda vezet, NPE.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

miert nem adunk vissza null-t? es mi van ha valaki megis szeretne null-t hasznalni kulonosen, ha tipusos null-rol van szo? miert kerulnek bele megis a programozasi nyelvekbe? van fogalmad mivel jar az egyes programozasi nyelvekben a kivetelkezeles?

A conclusion-t is elolvastad? A sima string manipulációs pár soros függvények kivételével mindenhol érdemes exception-t dobni.
És ez ráadásul 2005-ös cikk, majdnem 10 éves, ahhoz képest a .net valószínűleg még gyorsabb lett. Ha egy nyelv normálisan
támogat exception kezelést, akkor egyértelműen érdemes használni. Ha pedig performance probléma van, akkor azt MÉRJÜK aztán
OPTIMALIZÁLJUK. Csak amíg 30 eurós órabért számláznak az IT-ben, addig a mérnökóra az ami bazi drága.

OCaml-ben valoban nem koltseges az exception, igy eloszerettel hasznaljak, akar control-flow muveletekre is.

.NET-ben, es Java-ban a stack trace osszegyujtese draga muvelet, es esetenkent az objektum letrehozasa sem elfogadhato (pl.: numerikus kod kernel), de ugyes megoldasokkal ezek a muveletek sokszor megsporolhatok (pl.: javaban java.lang.Throwable::fillInStackTrace override eseten).

Kapcsolatos jvm opcio:

"The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag:
-XX:-OmitStackTraceInFastThrow."

.NET 4.5-be sem veletlenul kerult bele a ExceptionDispatchInfo.

https://connect.microsoft.com/VisualStudio/feedback/details/633822/allo…

Event-Based Programming without Inversion of Control Philipp Haller and Martin Odersky:

http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf

Az, hogy valami drága (megint csak mihez képest drága, egy i++-hoz nyilván), nem jelent semmit. A probléma akkor van, ha egy lassú művelet sokszor lefut. Exception viszont normális esetben nem fut le gyakran. Természetesen lehet olyan corner-case-t találni, amikor ez gondot okozhat, de a tipikus java fejlesztések 99.999999%-ban nem az exception kezelés fog bármiféle problémát okozni.

Cserébe ott van a normális hibakezelésbeni nyereség, amivel mérnökórák 100-ait lehet megspórolni.

Viszont ez a numerikus kód kernel, ez érdekelne... ez micsoda?

Az hogy mi szamit hibanak, feladata valogatja. Nem minden esetben a rendszer teljes "ateresztokepessege" a celfuggveny, egyre gyakrabban az alacsony es mindemellett garantalt maximalis valaszido szamit (wcet). Egy stack backtrace kibanyaszasa pedig eleg ritkan fog garantalt valaszidon belul tortenni. A numerikus kod kernel a program legmagasabb frekvenciaval vegrehajtott resze(i).
Az esetek nagy reszeben jo megoldas az exceptionkezeles, vagy meginkabb az option type hasznalata, de egyik sem univerzalis, mindenre jo megoldas.

soft realtime megoldasnal el lehet erni az alacsony kesleltetest "allocationless programming" technikaval, igy nincs szukseg gc-re. A memoria elore lefoglalva, aztan manualisan van kezelve, a treadmill-hez hasonlo hatassal. A hard real-time mar kemenyebb dio, de arra is szuletett mar par megoldas.

Henry G. Baker: The Treadmill: Real-Time Garbage Collection Without Motion Sickness:
http://www.pipeline.com/~hbaker1/NoMotionGC.html

csak egy pelda volt, nem csak java programozasi nyelv letezik, a real-time "tulajdonsagot" pedig sokszor nem abszolut ido ertelemben hasznaljak, hanem algoritmus szintjen nyujtjak a "garanciakat'. nyilvan messze nem tokeletes, de ki lehet probalni ki mit tud garantalni. Az igazi hard real-time egeszen mas alapokon es celfuggvennyel mukodik, pl.:
http://www.jopdesign.com/publications.html

( bAndie9100 | 2014. 09. 23., k – 14:02 )

Amíg nem megy az olvashatóság / karbantarthatóság rovására.

a patterneknek / konvencióknak nem épp az a lényege / értelme h könnyebben / egységesebben olvasható / karbantartható legyen / ne legyen?

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

vagy meginkabb programozasi nyelvi hianyossag elfedesere szolgal?

"The Expression Problem is a new name for an old problem.[2][3] The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)."

https://en.wikipedia.org/wiki/Expression_problem

"The Expression Problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)." - Philip Wadler

http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Laemmel-A…

De, csak egyesek szerint ez tobb kod (mert megprobal felkesziteni a kovetkezo problemara is a pattern), es akkor jajuristen mi van itt...

Amugy annak, aki nem ismeri a patternt es, hogy miert kell neha 1-2 plusz absztrakcios reteget bevezetni, annak elsore tenyleg olvashatatlanabb. Csak erre nem az a megoldas, hogy egy ronda hackel kikeruljuk a problemat, mondvan "igy is mukodik", hanem a patterneket kellene inkabb megtanitani/a konvencioknak kell utananezni normalisan.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( handler | 2014. 09. 23., k – 14:12 )

David Wheeler: "All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections."

( uid_17784 | 2014. 09. 23., k – 15:12 )

Ezek a nyavajak nem csak az olyan biszbaszokhoz kellenek , mint amilyen pl. a C++?

--
Python, mert csak

( fdavid | 2014. 09. 23., k – 16:57 )

(x) Egyeb: egyik valasz sem igazan talalo. Patterneket akkor hasznalom, amikor szukseg van ra, os ott, ahol szukseg van ra. A konvenciokat pedig szinte mindig, kiveva ha nyomos ok van a konvenciotol valo elteresre.

Hat, ez csak akkor lehet igaz, ha a projektbol egyaltalan kiderulnek ezek az infok. A kodformazast en is igyekszem igazitani, de sokszor nincs erdemi tampont a tobbire.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( Madman | 2014. 09. 23., k – 21:47 )

"Amíg nem megy az olvashatóság / karbantarthatóság rovására" - patternek pont ezeknek a javitasara szolgalnak, hogy mehet ezeknek a rovasara?

( sibidiba | 2014. 09. 24., sze – 03:40 )

Mindenki patternekben programozik, mert az agyunk programozás közben is mintákban működik. Elég ritka, hogy valaki valami alapvetően új és egyedi megoldással jöjjön elő. (Persze sokan azt hiszik, pedig csak az egójuk látja olyan szépnek a saját bűzös kódjukat.)

Az a kérdés persze h ki fekteti le a patterneket és hány van belőle. Cowboy script kiddie is patternekkel tolja, meg a lyukkártya lyukasztó is.

--
The Net is indeed vast and infinite...
http://gablog.eu

( current88 | 2014. 09. 25., cs – 08:32 )

Addig tarom amíg nem lesz túl közeli a leadási határidő.