МАЙДАН - За вільну людину у вільній країні


Архіви Форумів Майдану

4-й Интернационал в Америке. (Офтопик для компьютерщиков)

05/11/2005 | SpokusXalepniy
4-й Интернационал

Любой русский программист, после пары минут чтения кода, обязательно вскочит и произнесет, обращаясь к себе: переписать это все нафиг. Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный. На следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Ну, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

А в это время, в соседних четырех кубиках, будет ни на секунду не утихать работа китайских программистов, непостижимым образом умудряющихся прийти раньше русского программиста, уйти позже, и при этом сделать примерно втрое меньше. Эта четверка давно не пишет ничего нового, а только поддерживает код, написанный в свое время индусом, и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода - copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных, переданных по ссылке (ведь, китайский программист не может смириться с неудобствами вызванными тем, что он не может изменить значение внешнего параметра).
Вспоминая об этих переменных и ссылках, русский программист, как правило, на время теряет дар английской речи, и переходит к какой-то помеси русского и китайского. Он давно мечтает переписать весь кусок, над которым работают китайцы, но у него нет времени. Он уже переписывает два больших куска, и доказал начальству необходимость переписать третий. Кроме того, русский программист боится обидеть китайцев. Они могут решить, что он пытается вытеснить их с работы. К слову сказать, напрасно боится, поскольку китайцы уже так решили.

На китайцах висят серьезные баги, о которых знает начальство и постоянно их торопит. Китайцы уважают начальство и потому перевешивают баги друг на друга очень торопливо. Они знают, что все попытки починить приведут к появлению новых багов, еще худших. И в этом они правы. Разобраться в том, в каком порядке меняются статические переменные, и как приобретают свои значения, способен только один человек на фирме - индус. Но он пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения...

А кого еще увольнять? Русский - еще не переписал свой кусок, а индус - главная ценность фирмы - он редко обращает внимание на проект, но когда обращает, все понимают, что так как он, архитектуру никто не знает. Так вот, когда китайцев увольняют, у их кода возможны две основные судьбы. Первая - он попадет к русским, и его перепишут. Вторая - он попадет к местному, канадскому программисту.

О, канадский программист это особый тип. Он, ни на минуту не задумываясь, как рыцарь без страха и упрека, бросится фиксить самый свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но Баг каждый раз возвращался, как Бетмен в свой Готхем.

Итак, канадский программист, воспитанный на героической патетике американского футбола - бросаться в бой головой вперед, сделает то, чего китайцы не рисковали делать в течении трех долгих лет. Он, при помощи дебагера, отследит место, где статическая переменная приняла значение -1 вместо правильного 0, и решительным движением заведет рядом вторую переменную с правильным значением. Баг погибнет в неравной схватке с героем. Но победа будет достигнута тяжелой ценой. Работать перестанет все, включая только что переписанный русским программистом код. Это повергнет русского программиста в задумчивость на целых два дня, после чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с самого начала был неправильным, и все надо переписать. На это нам нужна неделя. Да, неделя, не больше.
Канадский программист смело бросится налаживать все, и станет еще хуже, хотя казалось бы... Эта суета выведет из медитации индуса, который придумает и вовсе гениальное решение - отбрэнчить код. Согласно его плану, мы теперь будем поддерживать две версии одного и того же кода - одну работающую, но с Багом, другую без Бага, но не работающую. Русский программист, услышав об этом плане, сломает линейку об стол и обзовет жену дурой, но на митинге возразить не решится.

К счастью, все это не сильно влияет на дела фирмы, поскольку продукт продается и так. Поэтому менеджмент ходит в целом довольный и не устает напоминать всем, что они отобраны как лучшие среди лучших. И что мы давно доказали свою способность выпускать продукт тем, что выпускаем его иногда.

Відповіді

  • 2005.05.11 | Сергій Кабуд

    проблема завжди в тупому дізайні

    і відсутності зрозумілого документування.

    Якщо менеджмент це вимогає на рівні свого власного розуміння-
    топто шоб 100% всього було задокументовано так, шоб менеджер це розумів досконало-
    проблем завжди меньше на порядок.
    Це як нормальний хелп файл чи рід мі.

    Є купа нормальних зразково зроблених програм в світі, якими ми користуємося щоденно. З хелп файлами, написаними зразково. От саме так і має писатися успішна документація- шоб на пальцях було ясно.

    Це має бути головна вимога проекту.

    Якщо вас запросили працювати в проект де нема документації-
    треба одразу почати документовати всі свої дії і кроки.
    То буде найкраща відмазка на всі випадки теж.
    згорнути/розгорнути гілку відповідей
    • 2005.05.11 | SpokusXalepniy

      Счастливые, кто верует!

      Сергій Кабуд пише:
      > проблема завжди в тупому дізайні і відсутності зрозумілого документування. Якщо менеджмент це вимогає на рівні свого власного розуміння - топто шоб 100% всього було задокументовано так, шоб менеджер це розумів досконало - проблем завжди меньше на порядок.

      То, что сейчас вся сила в гемоглобине, мы знаем-с.

      Ко всем тем проблемам, которые в шуточной форме описаны в 4-ом Интернационале, добавится ещё проблема, намертво зашитая в предлагаемом радикальном кабутовском решении, а именно.
      Ошибки в самой документации, вызванные несоответствием документов к модулям и самими модулями, а также многозначностью и субъективностью описания модуля на естественном языке - всё это прилично добавит головной боли начальству.
      Поддерживать полное соотвестсвие - задача не менее сложная, чем писать безошибочные программы. Мало того, при полном документировании резко увеличивается число связей в системе, что в свою очередь является существенным источником ошибок.
      Так что - зальём этот пожар бензинчиком!

      О решении этих проблем за последние 30 лет написаны ТОМА книг с советами и рекомендациями от самых успешных программистов. Часто - противоречивых советов. Хотя, удалось создать и некоторые незыблимые начала. Процентов на 5-10 эта проблема уже решена.
      згорнути/розгорнути гілку відповідей
      • 2005.05.11 | Сергій Кабуд

        замість писання програм тре писатит нову документацію

        у формі художнього роману
        програми все одно не працюють на 99% як потрібно
        то неахй індуси пишуть романи
        а боси видають їх


Copyleft (C) maidan.org.ua - 2000-2024. Цей сайт підтримує Громадська організація Інформаційний центр "Майдан Моніторинг".