May 14 2008

Programmeerijad ja rähnid

Published by Targo at 7:29 am under Hea kood, Lugejate lemmikud, Programmeerijad

woodpecker.jpg building_collapse.jpg

Kui ehitajad ehitaksid maju samamoodi nagu programeerijad kirjutavad programme, siis esimene rähn hävitaks tsivilisatsiooni. – Murphy seaduste kogust

Leidsin riiulist mingi ehitusinseneridele mõeldud tehnilise taskuraamatu (pole aimugi, kuidas see sinna sai). Muuhulgas on seal palju tabeleid mitmesuguste materjalide omaduste kohta: tellised, teras, vineer, tihedus, kõvadus, tugevus. Arusaadav, et iga korralik insener peab omama ülevaadet, milliste materjalidega ta töötab, mis on nende tugevuspiirid ja muud tehnilised omadused. Seda enam on hämmastav, kui vähesed programmeerijad teavad, millest nad tegelikult oma programme kokku panevad. Rakendusprogrammeerija ei tea, mis toimub klassiteekide sees, mida ta kasutab. Teekide kirjutaja ei tea, mis toimub operatsioonisüsteemis. Süsteemprogrammeerija ei tea, mis toimub riistvaras. Kõige selle juures on imekspandav, et tarkvara üldse vahel töötab ja midagi mõistlikku teeb.

Kiire test: Kui sa oled C# programmeerija, siis kas sa tead, kui suur on mscorlib.dll? Kasutad XMLi? Kui suur on System.Xml.dll? (Java, C++ jne spetsialistid võivad mõelda oma põhiliste klassiteekide ja runtime’ide peale). Ei tea? Tegemist on umbes samasuguse probleemiga, kui ehitaja ei tea, kui palju kaalub tellis, sest iga kord kui keegi vastava rakenduse käima paneb, mõjutab laetud teekide hulk rakenduse mälutarvet ja sellega otseselt programmi jõudlust. Analoogiliselt, kui sa kasutad näiteks mingit stringitöötlusteeki, on hea teada, mis on nende operatsioonide tegelik ajaline keerukus, kui pilditöötlemisteeki, siis millised on selle sisemised andmestruktuurid, et saaks hinnata mäluvajadust jne.

Objekt-orienteeritud programmeerimine on väga hea asi, aga ebasoovitava kõrvalefektina on see veelgi süvendanud olukorda, kus inimesed:

  1. ei tea, mis klassiteegi sees toimub, sest kõik on ilusasti ära peidetud, pakendatud ja kapseldatud
  2. ei oska ilma spetsiaalse teegita ise üldse ühtki probleemi lahendada

Kord saadeti mind asja uurima suure, tähtsa ja rikka kliendi juurde, kes kurtis, et tema veebiserver ei skaleeru. Lasin nende avalehe profileerijast läbi ja leidsin tuhandeid String.Concat väljakutseid. Selgus, et nad panevad suure hulga oma HTMList lihtsalt stringiliitmise teel kokku, mis on C# kasutades muidugi rumal. Tegemist on tüüpilise näitega, kus programmeerija ei tea, kuidas tema vahendid tegelikult töötavad.

Osaks minu tööülesannetest on aeg-ajalt potentsiaalsete töösoovijatega vestlemine (veel enne tegelikku intervjuud/katseid). Küsin sealhulgas nende käest lihtsaid tehnilisi küsimusi, et leida, kas on üldse mõtet edasi vestelda või on tegu mõlemapoolse ajaraiskamisega. Tuleb siis selline tegelane, küsin tema käest, et kui tal on programmis näiteks massiiv punaseid palle ja rohelisi palle, kuidas oleks kõige parem neid sorteerida, nii et punased pallid satuvad algusesse ja rohelised lõppu. Tema selle peale, et teeks ArrayListi ja kasutaks siis selle Sort meetodit. Kas ta teab, kuidas Sort meetod töötab? Ei. Aga kui ta peaks ise sellise meetodi kirjutama? Vaikus. Bzzzzzt, järgmine, palun. Esiteks pole klassiteekides leiduvad üldotstarbelised sorteerimisalgoritmid antud ülesande puhul sugugi optimaalsed, teiseks pole mul midagi peale hakata inimesega, kes arvutiteaduse põhikontseptsioonidega hätta jääb (nagu ehitusinsener, kes füüsikaeksamil põrub). Aja- ning mäluvajaduse keerukusest ei jõudnud muidugi rääkima hakatagi.

 matrix.jpg

Uuri allikteksti, sula ühte koodiga – Linus Torvalds

Inimesed küsivad mult vahel nõu programmeerimisõpikute kohta. Häid õpikuid on palju, aga minu meelest on hea programmeerija parimaks lektüüriks hea kood :) Mitmesuguste andekate inimestega koos töötamise järel olen oma Microsofti-kogemuse juures rõõmus võimaluse üle igasugust huvitavat koodi lugeda, Windows, Office, .Net Framework, kõigis neis on geniaalseid lahendusi, rääkimata asjade mõistmisest tulenevast rahuldusest ja teadmistest, mis võimaldavad mul oma tööd efektiivsemalt teha (ma ei räägi siin mingitest sala-APIdest, vaid lihtsalt algoritmide tasemel mõistmisest). Väljaspool Microsofti on loomulikult samuti tuhandeid võimalusi uurida, kuidas asjad töötavad, olgu siis Open/Shared Source’i maailmas või mujal, ja suureks vaheks hea programmeerija ning tipp-programmeerija vahel on tihti see, kui palju ta igasuguste vidinate uurimisele on aega kulutanud. Kui alliktekstid pole saadaval, uuri jõudluskarakteristikuid, profileeri klassiteeke jne, et aru saada, kuidas asjad töötavad.

Ja hoidu rähnide eest :)

9 responses so far

9 Responses to “Programmeerijad ja rähnid”

  1. Jurion 26 Aug 2008 at 10:12 am

    And you write sort method each time when you need sort array?
    Why did you take existing site template and adapt it for your? Write site by your self :) . The main purpose of class or class library it is reusing in future!

    Maybe you question was wrong and question should be: what is the better sort algorithm? What algorithms do you know?

  2. Targoon 28 Aug 2008 at 2:41 pm

    Hi Juri, thanks for commenting. As an advocate of laziness in programming, I’m a big time believer in code reuse, and I cringe every time when I see people reinventing the wheel.
    However, I also believe that it is very important to pick the right tool for the job, and understand the properties of these tools well.
    In this particular case the data had a very powerful constraint on it, as there were only two types of items in the array. Also, the way I phrased the problem to the interviewee implied that switching the balls was a costly operation, and we wanted to save as much time as possible. The idea here was that he would recognize these two special circumstances, and adapt his approach accordingly, as opposed to using a hammer to drive in a screw.
    Regarding whether it’s better to ask about the sorting algorithms, I think the time for such questions is in school. Once we are in real life, our customers don’t care about algorithms, they care about whether we can take their data and apply the best approach to it. So I tend to ask somewhat vague, open-ended questions in interviews, because this is the nature of problems we face every day.

    cheers,
    Targo

  3. Jurion 02 Sep 2008 at 12:59 pm

    No, I am not supporting laziness in programming. I just don’t like some places at this article. You doing punishment of this man without improvements. Next code snippet improve part of truth at his solution. i don’t need know how to Sort() function work. I think this is the good framework reuse.

    class Program
    {
    static void Main(string[] args)
    {
    Ball[] balls = new Ball[]
    {
    new Ball(Color.Green),
    new Ball(Color.Red),
    new Ball(Color.Green),
    new Ball(Color.Green),
    new Ball(Color.Green),
    new Ball(Color.Red),
    };
    Array.Sort(balls);

    foreach (Ball b in balls)
    {
    Console.WriteLine(b.Color.ToString());
    }
    Console.ReadLine();
    }
    }

    public enum Color : int
    {
    Red = 1,
    Green = 2
    }

    public class Ball : IComparable
    {
    public Color Color
    {
    get;
    private set;
    }

    public Ball(){}

    public Ball(Color color)
    {
    Color = color;
    }

    #region IComparable Members

    public int CompareTo(Ball other)
    {
    return this.Color.CompareTo(other.Color);
    }

    #endregion
    }

  4. Targoon 11 Sep 2008 at 12:35 pm

    Hi Juri, sorry for not replying earlier, these days have been super busy.
    First, I don’t think we have any disagreement about the fact that code reuse is good. Obviously, you should use as much of the framework functionality as you can, *as long as you don’t sacrifice any other important tenets*. As long as you’ve only got 6 balls to sort, and swapping them takes a microsecond, who cares how you do it.
    In this particular interview I had with this guy, he failed on multiple counts though:
    - First, when someone asks you to create an algorithm for something and doesn’t provide much extra information, you should never, ever just jump into coding. You should always ask the critical questions about the data and the expected behavior. In this super-simplified problem, the obvious questions are: how many balls are we talking about? If you have one hundred million balls, the difference between the optimal algorithm and Array.Sort() is huge and your solution will fail miserably. What is the nature of the balls? In code, things usually look simple, but if we are actually programming an industrial robot that is physically sorting some physical balls, every operation we save counts. Asking these questions is one of the things that separates developers from coders :)
    - Second, it’s absolutely critical to know how your underlying algorithms behave. We can usually assume that framework providers use good algorithms, but there are countless components and methods where this is not the case. And even when the algorithm is good, it might have some quirks that make it unsuitable for your particular problem. For example, do you know if Array.Sort is stable or not? It doesn’t matter in this case, but it might in some others (Array.Sort uses QuickSort, which is not stable).

    cheers,
    Targo

  5. uudisimulikon 27 Oct 2009 at 2:17 pm

    Aga, kas selline kood lahendaks selle probleemi, kui tahetakse lihtsalt massiivis
    punased ja rohelised pallid sorteerida(p ees ja rohelised taga) kui teada et pallide arv ei ulatu miljonitesse vaid piirdub paarisajaga.
    Sry vbl rumal küssa see, aga olen alles avastamas seda sorti maailma.

    public static void Main(string[] arg)
    {
    ArrayList pallid = new ArrayList();
    pallid.Add(“Punane_pall”);
    pallid.Add(“Roheline_pall”);
    pallid.Add(“Punane_pall”);
    pallid.Add(“Punane_pall”);
    pallid.Add(“Roheline_pall”);
    pallid.Add(“Punane_pall”);
    pallid.Add(“Punane_pall”);

    pallid.Sort();
    for (int i = 0; i < pallid.Count; i++)
    {
    Console.WriteLine(pallid[i]);
    }
    }
    }

  6. Targoon 13 Nov 2009 at 4:19 pm

    uudishimulik, vaata minu vastuseid Juri kommentaarile ülal, seal on seda teemat käsitletud.

  7. eon 12 Feb 2012 at 4:36 pm

    Üldiselt on Sinu artiklid üsna põnevad, loen hea meelega. Aga siin oli tegemist tüüpilise “Mul on 15-aastane programmeerimiskogemus ja Sina, nolk, astu minema” suhtumisega.

    Tõenäoliselt oli tegemist noore tudengiga, kellel puudub kogemus ning IT-alane karjäär alles algamas. Sellise roll ongi kuskil ettevõttes väikese palga eest väikeste asjade kallal nokitseda ning vaadata üle tegijate õla, kuidas asjad käivad. Eks 1-2 aasta pärast jõuab ka tema arvestatavale tasemele. Eesti IT-alase hariduse tase ei soodusta olukorda, kus ülikoolist tulnud nooruk on kohe võimeline head koodi kirjutama.

    Vaatame, kas või 45-minutilise lennu kaugusele. Õppimine TTÜ-s või IT Kolledžis on nohu võrreldes õpingutega KTH-s või Chalmersis. Aga meie ei saagi oma ülikoolide õppekoormust karmistada, sest muidu ei suuda Eesti tudeng töö kõrvalt õppida. Ja keskmine Eesti tudeng ongi sunnitud mingisugustki tööd tegema, et elus midagigi endale lubada.

    Aga nüüd tagasi artikli sisu juurde.
    Kuidas Su “Bzzzzzt, järgmine, palun.” peaks seda inimest motiveerima? Oli siis tõesti nii keeruline formuleerida paari lausega omapoolne visioon “heast” lahendusest?

    Võid talle “Ei” öelda, kuid näpunäited ja sõbralik suhtumine kindlasti motiveeriks teda. Ehk läheks ta koju asju uurima. Sinu vastuse peale, ta tõenäoliselt läks sõpradega õltsi jooma ning mine sa tea, äkki kõlaski fraas: “Fuck IT, ma lähen haldusjuhtimist õppima” = miinus üks kaotsiläinud tulevane IT tegija.

  8. Targoon 12 Feb 2012 at 6:56 pm

    e, ülesande püstitusel puudus kontekst.
    Esiteks, loomulikult ma ei öelnud inimesele “Bzzzzzt”, ma suhtlen enamasti ikka normaalselt ja selgitan, mis värk on. Aga oma peas ma mõtlesin nii. Peamine emotsioon oli siinjuures pettumus, sest võimekaid inimesi on vähe ja iga intervjueeritava puhul hoian ma salajas pöialt, et ole nüüd ometi tubli ja saa ülesandega hakkama.
    Teisalt olen võtnud inimesi enamasti küllaltki nõudlikele positsioonidele, kus läheb vaja asjadest sügavuti aru saamist ja iseseisva mõtlemise oskust. Pikalt käehoidmist seal lubada ei saa ja ainult mutrikeeramisest tavaliselt ei piisa.
    Konkreetne situatsioon oli reklaamitud ka küllaltki nõudlikuna (ja ei leidnud üldse Eestis aset), eeldades korralikku fundamentaalteadmiste sügavust. Kas tegemist on tudengiga või eluaeg töötanuga, ei mängi antud küsimuse juures isegi mingit rolli. Mõlemal juhul on võimalik aru saada, mida ja miks inimene teeb, või siis mitte aru saada. Ja kui arusaamist ei ole, siis mine tea, võibolla pole karjäärivalik tõesti õige?

  9. http://Www.Vouchercode.io/hsamuel.co.ukon 27 Feb 2016 at 11:59 am

    http://Www.Vouchercode.io/hsamuel.co.uk...

    Targo tarkvara » Programmeerijad ja rähnid…

Trackback URI | Comments RSS

Leave a Reply