2011-10-11 скъпи програмисти

by Vasil Kolev

Скъпи програмисти,

Днес, дебъгвайки поредният проблем, причинен от вас, реших, че е крайно време да обясня нещо животоспасяващо. Животоспасяващо, защото ако го следвате, шансът да ви издебна в тъмна нощ и да ви заколя намалява сериозно.

В общи линии са две неща.

Едното е болестното ползване на framework-ове и други подобни нива на абстракция без реален смисъл. Примерни такива бози има на много места, на мен едно от най-омразните ми е cakephp (вероятно понеже с него съм се борил най-много). В повечето случаи нещо, което спестява 10% от вашето писане за сметка на едно огромно мазно средно-рядко лайно, което 1) стои във version control-а, 2) прави проследяването на действието на кода един порядък по-трудно и 3) е нещо, което не може да се update-не лесно (което ще обясня след малко) не си струва. Нито за вас (щото ще ви е по-трудно да намерите проблемите, които сами сте си създали), нито за мен, докато се опитвам да го подкарам или мигрирам, нито за който плаща. Just say no, и пишете кода колкото се може по-близо до естествената му среда – системни библиотеки, стандартни драйвери и т.н..
(друг пример е начинът, по който request-tracker ползва база данни и заявките от типа на “SELECT main.* FROM table1 main, table2 b …” и невероятната плетеница от callbacks, които са направили).

Второто нещо е, че външните библиотеки не са ваш проблем, ваша работа, ваша отговорност и по НИКАКЪВ начин не са от нещата, които трябва да се набият във version контрола, освен ако не поемете пълна отговорност да ги поддържате. В противен случай оставете работата на хората, които разбират от upgrade-и, миграции, системата на която работи софтуера ви и т.н. и не им създавайте допълнителни главоболия. Не ви е възможно да следите всички security update-и, всичките несъвместимости на стария lib с новите среди, а авторите на тия неща се справят доста добре с правенето на нещо, което да е backwards compatible (т.е. да работи с ужасът, който сте накодили) и същевременно със средата, в която оперирате.

Благодаря за вниманието.

(за тези, които ще ми обясняват колко са прекрасни тия framework-ове – аз мигрирах един магазин от cake на чисто php (дето не ставам за програмист) и излезе доста по-кратко и по-изчистено)

Tags: , ,

22 Responses to “2011-10-11 скъпи програмисти”

  1. Metin Says:

    Проблемът, според мен, са тези програмисти, които освен че програмират абстрактно, също така и работят абстрактно. На уиндоус, през FTP към сървъра. А и знанията им са абстрактни. Нямат грам идея що е то уеб сървър, как работи, как се инсталира и настройва. И фреймуъркът компенсира това им незнание. А то в крайна сметка се оказва, че е доста по-лесно да разбереш идеята (и особеностите) на http, вместо да се опиташ да разбереш идеята и особеностите на някой мастит фреймуърк. Аз самият съм минал по този път и смених последователно питонските Django, Turbogears, Pylons, Pyramid (върви от по-високо ниво на абстракция, към по-ниско). И в крайна сметка единствените два питонски фреймуърка, които бих ползвал доброволно са Flask и bottle.py. Последният е един файл от 1000 реда праволинеен и лесно разбираем код, който наистина спестява нерви (и не създава много).
    Основно влияние върху тези ми решения е имал фактът, че аз освен че пиша, до сега почти винаги и съм се грижил и за инсталиране и поддържане на това, което пиша. Пробвай да накараш някой от въпросните програмисти да направи същото за някое от произведенията си :).

  2. Стефан Кънев Says:

    Мисля, че проблема не ти е с framework-иците, а с PHP. :)

  3. Никола Says:

    Бий с лопатата, додето шават!

  4. chernobyl Says:

    Идеализмът ти е вдъхновяващ, но в истинския свят шефът просто иска код, който работи, и иска да стане бързо (ако може – за вчера). Та затова пестим 10% време чрез знайни и незнайни фреймуъркове, пишем недотам изчистен код, пачваме външни библиотеки, въобще вършим отвратителни, нехристиянски неща, и единственото, което можем евентуално да направим, е да оставим за следващия един коментар от сорта на:

    // извинявай, извинявай, извинявай, извинявай!

  5. Vasil Kolev Says:

    @Metin, ами ще трябва :) Тя DevOps философията не е лоша, може би трябва да направя някоя лекция по темата…

    @Кънев, не, то на всеки език може да се правят глупости (и се правят), другия ми пример (request-tracker-а) е perl, например. А това с влаченето на милиони неща с теб съм ти го обяснявал и около ruby-то :)

    @chernobyl, ама тия 10% са илюзорни поне според мен, щото даже и в правенето на кода не се спестяват… Да не говорим, че като трябва да дебъгвам аз кода го чета с grep, иначе няма начин да ми стигне времето :)

  6. iffi Says:

    тая миграция ли е дето каза, че си писал код с 30 goto-та вътре?

  7. Vasil Kolev Says:

    @iffi, не, кода с goto-тата е друга миграция, и май трябва да го покажа, да чуя мнение дали има по-свестен начин :)

  8. ju Says:

    Мисля, че проблемът ти е в това че не си писал нищо голямо (без framework), да не говорим че някой frameworks правят написания код по-сигурен

  9. ju Says:

    CGI Rules!

  10. Metin Says:

    Смея да се съглся частично. Фреймуърците не са лошо нещо, но само при следните условия:
    1. Не са големи.
    2. Магията е сведена до минимум. Тоест, фреймуъркът не е обектно ориентиран :)
    3. Имаш много ясна представа какво прави фреймуъркът и какви tradeoff-и правиш, ползвайки го.
    4. Не си идиот.

  11. ju Says:

    Не framework-а ви е проблем, проблема ви е да разберете frameworka (иска допълнително време) и точка 4 (да не го ползва идиот)

  12. Vasil Kolev Says:

    @ju, аз нямам проблем да разбера който и да е framework, просто повечето от тях наистина затрудняват debug-ването. Потърси статията за leaky abstraction и ще видиш за какво точно говоря. Колкото за програмистите и идиотите, моето мнение по въпроса май е достатъчно ясно :)

    Днес на бирата даже дадох едно обяснение – много framework-ове обръщат езикът за програмиране в сървър за нещо, чиято конфигурация се пише от програмиста, т.е. вместо да се пише какво точно се случва, програмистът пише какво трябва да стане заедно с малки парчета, които правят нещо. Гледайки колко зле се справят хората с erlang, prolog и sql, не мисля, че това е добра идея…

  13. ju Says:

    @Vasil Kolev: В общия случай няма нужда да дебъгваш самия framework, а кода писан върху него … освен ако търсиш някакъв бъг във frameworka, а по-вероятно търсиш бъг в кога на програмиста. Така или иначе ако нямаш framework е най-добре сам да си направиш подходящи абстракции (твой framework) … ако не ще пишеш (много) код “за лудо”…

  14. Arcopix Says:

    @ju, @Стефан Кънев – псувах много cakePHP докато осъзная, че тъпият freamwork изисква базата, с която ще работи да е структурирана и именувана по определен начин. Да ме извинявате, но не си правя базата, така че да му е удобно на глупавият интерфейс да работи прилежно. След като разбрах малките подробности и изисквания около базата с голямо удоволствие затрих целият проект и го пренаписах за два дена…

    Колкото до шефовете, които искат работещ код възможно най-бързо. Може би не е зле да им напомните, че кодът може да бъде написан за ден, но още толкова някой ще бърника из него за да разреши прост проблем.

    Съвсем не искам да споменавам, колко “по-бързо” работи нещо написано чрез framework…

  15. ju Says:

    Arcopix мисля, че това което казваш за базата не е така. Просто по default работи така, но може да се зададат изрично различни имена

  16. ju Says:

    Така де, минах от тук за да оставя линк към тези интересни слайдове:

    Frameworks 101 by Kris Noble
    http://speakerdeck.com/u/mikestreety/p/frameworks-101-by-kris-noble

  17. tie Says:

    Пробвай да накараш 10 програмиста да напишат cookie&session handling на произволен език и 9 от тях ще го направят със сериозни секюрити проблеми. Има огромен смисъл от ползването на фреймуъркс, и това че има изцепки както при самите фреймуъркс, така и при програмистите, които ги ползват, не е причина да се заклеймява цялата категория. Писането е в пъти по-бързо,кода е много по-консистентен, нивото нa reusability е много по-високо.

    Външните библиотеки са в общия случай проблем на програмиста, а не на администратора. Има тонове примери за по-нови версии на библиотеки, които чупят даден софтуерен компонент (всъщност това е общия случай). В този ред на мисли е задача на програмиста да провери и осигури правилното интегриране на библиотеката със неговия custom софтуер, а не на администратора. От гледна точка на администриране, аз предпочитам софтуерите, които инсталирам да идват в малки спретнати пакети, а не да замърсяват системата с 50-60 dependencies.

    Работата на един системен администратор НЕ Е да дебъгва custom софтуер и използвания фреймуърка – това е задължението на съответния програмист. Изглежда същинският проблем в този случай e, че някой не си е свършил работата и някой друг му я върши.

  18. dobber Says:

    @Arcopix вич точка 3 и особено 4 от списъка на Metin. При положение че първия ред в документацията на cakePHP е относно именуването на таблиците, какво точно си се чудил?

    Аз не разбрах защо никои не се съгласи с мнението на Никола – “Бий с лопатата, додето шават!”
    Само така!

  19. viz Says:

    “abstraction – a concept or idea not associated with any specific instance”

    Не е виновен този който яде баницата, а този който му я дава!

    Просто е! Като не ти харесва, не я ползвай. Така или иначе тя не е предвидена за “хора като теб”( с по-голямо IQ ).

    Framework не е широкоспектърна коцепция която да задоволи всички нужди на админа, търсещ възможни хакове за да улесни потребностите си. =/

    С други думи, не се препоръчва за хора с огромен опит.

    Никола е прав, бой с лопатата в гърба.

  20. Vasil Kolev Says:

    @tie, има разлика между framework и външен lib за нещо. Framework-а подчинява всичко на себе си, lib-а бива подчинен на приложението, т.е. централната логика не се измества в последния случай.

    @viz, аз не я ползвам. Ползват я хората, които пишат софтуера, който после аз трябва да подкарвам/поддържам/мигрирам. Аз лично единственото, което някога съм правил с framwork е като ножа опре до кокала, да пренапиша нещото да не го ползва (което дори при моята некадърност в това отношение още работи).

  21. gog Says:

    като “играещ треньор” – сисадмин и програмист, бих определил нещата така –
    framework е за неща които започваш от нищото, трябва да станат бързо и да си сигурен че си предпазен от повечето общи грешки които може да се направят поради недобро познаване на програмните методи и главно като администратор когато ми се наложи да се пише нещо комплексно – някакъв веб интерфейс с права, групи и роли предпочитам да ползвам framework. Изобщо нямам време да доизкусурявам някакви проблеми със сесии, кукита, права, роли и т.н. взимам, ползвам, тръгва и работи. Ако трябва нещо по-сериозно го предавам на програмист, който може да види идеите, проблемите, заданието и да го реализира както трябва.
    От друга страна като администратор който трябва да оправя проблеми по чужд код здраво кълна програмистите, понеже наистина трабълшутването на 15 различни фреймуорка на различни езици и платформи хич не е приятно, особено когато се получава че разбирам повече от програмиста и той научава от мен за основни похвати които е трябвало да знае отдавна

    с други думи извода е:
    има знаещи и можещи и незнаещи и неможещи
    изключвам комбинациите с тези които ги мързи :-D

  22. pete Says:

    Аз се занимам с много и малки проектчета и фрейма не ми спестява 10% ами сякаш по-скоро 25%.
    За големи проекти също с фрейм, но много по-внимателно.

Leave a Reply