- Microsoft Excel topic
- Mesterséges Intelligencia topik
- Xiaomi AX3600 WiFi 6 AIoT Router
- Linux kezdőknek
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Synology NAS
- Milyen routert?
- DIGI internet
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
Új hozzászólás Aktív témák
-
#25954560
törölt tag
kinek mit jelent a programozo. ki milyen feladatokra hasznalja. ki milyen programnyelvet hasznal. ki milyen szintre akar eljutni.
teny, hogy nagyon sok mindent meg lehet tanulni magadtol. ujabb es ujabb programnyelveket is akar. viszont nem art, ha van valami jo alapja az embernek, azt viszont idealis esetben tanitottak neki szisztematikusan es reszletesen, a szamitogepek mukodeset is beleertve. az is igaz, hogy a mindenfele keretrendszerek es konyvtarak sokszor lenyegesen konnyebbe es gyorsabba teszik egy program megirasat, szerintem minel jobban el van absztraktalva egy nyelv a hardvertol es kornyezettol, annal kevesebbet tudnak a hasznaloi arrol h igazibol mi is tortenik egy fuggveny hivasakor. ha ezt nem tanitjak meg az embernek, akkor a nagy tobbseg nem fog utanamenni es magatol megtanulni, mert legtobb esetben nem is erdekes.
az en gondolkodasom elegge be van szukulve a hatekonysagra, programozas szempontjabol sokmindent ezen a szemuvegen keresztul nezek. az a sajat tapasztalatom, hogy az utolagos optimalizacio mint olyan hasznos, de messze nem olyan eredmenyes, mintha mar eleve a hatekonysagot tartanank szem elott a program irasakor. marpedig ehhez folyamatosan fejlodni, olvasgatni es kiserletezni/tesztelgetni kell, ami megintcsak feltetelez bizonyos szintu alapokat.
amikor mar minden szamitogepeken fut es egyre tobb energiat esznek meg a letfontossagu, de foleg a kenyelmi szolgaltatasokat nyujto honlapok, felho szolgaltatasok, stb, akkor megintcsak erdekes lesz egyszer a hatekonysag, mindegy h optimalizacionak hivjuk, mint mar otven eve, energiahatekonysagnak mint az utobbi tiz evben vagy valami masnak. tehat mindegy, hogy arra gyurunk, hogy minel gyorsabbak legyenek a programjaink ugyanazon a vason vagy a fokabebiket akarjuk megmenteni, a jo programozasnak resze kene legyen a 'mi is tortenik a hatterben?' tipusu tudas. na _azt_ szerintem tanitani kene.
-
#25954560
törölt tag
van megegy terulet, ahol erdekes az optimalizacio: amikor olyan szoftvert fejlesztesz, amilyiknek egy vagy tobb versenytarsa is van. ilyenkor mindig el kell dontenie a vezetesnek, hogy most ficsorokkel akarnak operalni v sebesseggel, illetve a ketto milyen mixevel.
egyebkent ugy latom sokmindenben egyezik a velemenyunk. remeltem h nem vagyok egyedul
-
#25954560
törölt tag
nagyon sok helyen a szoftverek fejlesztese es tesztelese csak a pozitiv esetekre megy. ha azt tudja, akkor mukodonek lesz nyilvanitva.
ezzel szemben tesztelni kene a negativ esetekre is, amit mar kicsit kevesebben csinalnak meg, pedig ott mar johetnek ki vicces bugok. ami viszont gond a negativ esetekkel, hogy jol kell kitalalni mit adsz vissza hiba eseten. elsosorban nyilvanos API-knal jol kell kitalalni, mert ahogy az API-t hasznalo programozot segiti egy reszletes, mittomen hasznalhato bemeneti tartomanyokkal visszatero hibauzenet, ugy a tamadokat is.
a harmadik eset pedig amit szinten sokszor hanyagolnak, a 'corner case' tesztek (bocs, nemtom mi az elfogadott magyar kifejezes ra). ezeket az eseteket a legnehezebb egyaltalan kitalalni is, nem csak tesztelni. na ide kell fantazia es tipikusan a rosszfiuknak sokkal jobban raall erre az agya
egy-egy biztonsagi res hardverben vagy szoftverben nem feltetlenul azt jelenti, hogy akik terveztek vagy csinaltak hulyek voltak, hanem esetleg azt is, hogy 'upsz, erre nem gondoltunk'. ami nem feltetlenul hanyagsag, hanem mar-mar a talalmanyok szintje is.
-
#25954560
törölt tag
válasz Dr. Akula #178 üzenetére
nyilvan sokkal tobb a munka, mint a jo programozo. lehetoseg szerint azt kell elerni h minel tobb reszt a jok talaljanak ki.
ami szokott tudni mukodni az az, hogy a tetejen hozzaerto koderek vannak szeles latokorrel es kepesek gyorsan poc-ot generalni. a poc utan viszonylag ertelmesen le kell tudniuk dokumentalni h mit csinaltak es ehhez kepest mit csinaljon a vegleges kod, illetve mi kell meg, ami nem volt resze a poc-nak.
ha tul nagy a projekt, akkor reszletes dokumentacio kovetkezik h mi hogy legyen megcsinalva, ha kisebb, akkor mar el is kezdhetnek dolgozni a tobbiek. de ehhez is kell egyfajta munkakultura h ha pl leragadsz valamivel ket-harom napra, akkor segitseget kersz, nem pedig elvesztegetsz meg ket hetet. illetve az implementacio ideje alatt is van ertelme kodrivjuknak meg beszelgeteseknek, hogy ne az legyen h az ember dolgozott egy honapot a sajat elkepzelese alapjan, aztan kiderul h a megoldasa tobb szempontbol sem megfelelo.minden szintu programozot kell tudni hasznalni, akkor leghatekonyabb a szervezet.
es az mar nagyon off, de sok hierarchiaban lenezik a tesztereket, pedig az igazan jo teszterek kincset ernek.
-
#25954560
törölt tag
válasz Dr. Akula #180 üzenetére
szerintem jo doksira szukseg van (/lenne). mas kerdes h en is ugy allok neki irni, mintha a fogam huznak, de az elgondolas legyen benne tisztan es erthetoen.
ha viszont egy cegnel tulburjanzik a dokumentacio, akkor az a minimum h le legyen irva mibe minek kell bekerulnie. idealis esetben egy uj teruletet legkonnyebb nagyjabol megerteni egy jo leirasbol. aztan persze ugyis Yoda a vege: 'use the source, Luke'
DjF:
igen, az implementaciohoz kozeli doksikat hiba tul koran megirni vagy nem frissiteni.[ Szerkesztve ]