Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе". G>>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS.
B>тут засада. сырцы были перелиты из одного репозитория в другой не раз. B>и там уже давно первым стоит билд-мастер. и после несколько изменений для последних релизов. B>так что причину к-л решения найти можно только у старых в памяти.
Импортировать в репозиторий можно с историей коммитов.
bkat пишет: > > > Да, умение читать код очень важно. > Но и "картинки" тоже весьма полезны.
Мдас, что-то с программерами нынешними рускоговорящими неладное
твориться. Единственный внятный пост в этой теме и ни одного плюсика...
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, genre, Вы писали:
G>>>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?
G>>Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.
G>Это так принципиально?
Конечно. Это означает, что дизайн-дока может не отвечать на вопрос почему сделано именно так, а не иначе.
Здравствуйте, genre, Вы писали:
G>>>>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?
G>>>Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.
G>>Это так принципиально?
G>Конечно. Это означает, что дизайн-дока может не отвечать на вопрос почему сделано именно так, а не иначе.
Хотите сказать, что я плохо умею писать дизайн доки, а вы хорошо? Ох уж эти пионерские переходы на личности, ну не могут никак люди без них
Через 5 лет после большого количества относительно мелких правок кода она и у вас не будет отвечать на этот вопрос. Вовсе не потому, что вы не умеете их писать.
Re[5]: Читай код
От:
Аноним
Дата:
07.05.09 12:25
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Импортировать в репозиторий можно с историей коммитов.
Особенно если старый и новый репозитории хостятся на раных моделях сорс-контролов? Не одним SVN живо человечество, есть еще много прочих VSS/Perforce/etc
В качестве домашнего задания, возьмите три любых сорс-контрола (A, B и C), пролейте сырцы сквозняком "A -> B -> C -> A" и проверьте полную историю коммитов. Точнее, хотя бы её наличие
Здравствуйте, Аноним, Вы писали: А>Особенно если старый и новый репозитории хостятся на раных моделях сорс-контролов? Не одним SVN живо человечество, есть еще много прочих VSS/Perforce/etc
Нормальные VCS умеют конвертировать историю как минимум из/в SVN, а часто — и друг между другом.
Здравствуйте, Gaperton, Вы писали:
G>Хотите сказать, что я плохо умею писать дизайн доки, а вы хорошо? Ох уж эти пионерские переходы на личности, ну не могут никак люди без них
G>Через 5 лет после большого количества относительно мелких правок кода она и у вас не будет отвечать на этот вопрос. Вовсе не потому, что вы не умеете их писать.
Блин. Да какие переходы на личности. Будте внимательней просто к вопросу на который отвечаете.
Вот наш диалог вкратце:
Вы: Читайте код, доки в сад.
Я: А как быть вот с этим?
Вы: В комментарии к коммиту оставить ссылку на доку с дизайном.
Я: То есть некоторые доки все-таки нужны?
Вы: нет, не нужны, они устареют
короче либо я либо вас понял не так, либо вы меня
Здравствуйте, Gaperton, Вы писали:
G>>>>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе". G>>>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS. B>>тут засада. сырцы были перелиты из одного репозитория в другой не раз. B>>и там уже давно первым стоит билд-мастер. и после несколько изменений для последних релизов. B>>так что причину к-л решения найти можно только у старых в памяти. G>Импортировать в репозиторий можно с историей коммитов.
угу... приходите в гости, я вас с деплоймент-инженером сведу, и вы ему расскажете, как надо переливать сырцы.
а он вам ответит, что в сырцах стоит не его имя, а прошлый спицилист. и репозиторий меняли уже 3 раза за прошедшие 4 года.
пошел обратно к статье.
Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен.
этот прикол я наблюдал уже несколько раз. приходит человек, устанавливает свою прошлую систему и дергает всех за руки показать, как офигительно там все было сделано.
я когда сюда пришел, меня спросили, что и как я типа могу улучшить. я им написал телегу с пунктами. сейчас перечитал — некоторые все еще актуальны, но примерно половина — полная чушь от того, что я в тот момент (только пришел в проект) понятия не имел, как оно не только устроено, но и как задизайнено. кстати, старые системы показываю, но только по запросу.
Меня потряс объем приложения – почти 50 мегабайт основных исходников...разрабатывавшийся десятками людей на тот момент на протяжении десяти лет.
что же тут удивительного? все на месте. 5 мег за год — нормальный такой выход для даже маленькой команды. а уж для серьезного проекта...
...есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать.
вот это начало, и ваш вывод — "читайте код". за это вас пинают. чтение и понимание кода — это не ключевое знание для проектирования сложных систем. совсем. потом что когда они проектируются (правильно или криво) кода еще нет.
...Тол, — Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
дословно моя беседа с индусами.
но система была спроектирована так не потому, что так был написан код. а код был написан так, как была спроектирована данная система.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
far. alt+f7
— Тебе, чтобы читать код, нужна документация? Прости – какая?
совершенно согласен. для чтения кода дока не нужна. для понимания смысла написания так как есть (почему сделано так, а не иначе) — нужна.
кстати. сегодня опять обсасывали старое решение. уже 4 варианта. разный timing для всех, разная сложность понимания, поддержки. все 4 делают одно и то же. и вот я ни разу не удивлюсь, если у меня потом спросит кто-то "а че вы написали так, а не вот так? так же проще?!..". я не уверен, что в заапрувленную документацию ляжет переписка за несколько дней и куча файлов с результатами замеров. так что вот этот выбор знают 4 человека. в доке его нет. возможно в коде будет коммент.
— Ну, там, диаграммы классов, например.
убедился, что смысла в них нет. для нашего решения. для чужого компонента — есть. а для нашего — нет.
программист переделывает структуру классов по 2 раза в день. ну муза прилетела, у него другое видение открылось...
...тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод,...
почему? ну почему вы не показали, как вы находите, а не что вы находите?!..
он же потом со следующим методом придет. ...хотя...ну да. обычно "ловить рыбу" не учат. иначе выпрут из "ловцов рыбы".
у меня знакомый был, все "уникальные навыки" которого заключались в том, что он знал порядок включения тумблеров. и его за это очень ценили.
...рассматривая диаграмму. Ясности она не добавляла.
выше. про полезность диаграммы классов для своего решения.
Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия "код — лучшая документация" дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате — рассчитывая только на свои силы, понимая — что код — основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, — можно достичь мастерства в reverse engineering и вообще понять, что это такое.
угу. только это не часть процесса создания. это часть процесса поддержки.
после недели медитации над чужим кодом, я могу переписать это за пару часов гораздо проще, и мне пофиг, че там реверс наинженерит.
я был бы счастлив, если бы мне вообще не пришлось вычитывать чужой код. замечено, что приходится читать то, что не работает. а вот то, что не имеет проблем — перечитывают гораздо реже.
Создать свою структуру и пришлепать ее сбоку может любой дурак. Квалифицированный инженер-программист (с упором на первом слове, не путать с "программером") умеет проводить анализ "чужой" подсистемы, восстановит мысль и идею автора, сможет мысль автора развить, продолжить ее, и эффективно решить свою задачу в рамках чужого подхода к проблеме.
"любой дурак", я надеюсь, художественное преувеличение?..
ваши рекомендации в случае если я не согласен с мыслью автора, или автор схалявил и вообще не реализовал заказанную бизнес-логику?
я не хочу продолжать ее. я готов ее переделать.
В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего — подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором — вопрос нескольких лет.
не согласен. хороший архитектор поднимается на уровень вверх. а там кода уже совсем нет.
т.е. если архитектор хороший, то с уровня приложения, он переходит на уровень решения. с проги на продукт.
а вот плохой — может довольно долго проектировать одно и то же. потому что нафиг он кому еще нужен, если он одно не может запроектировать, что бы работало нормально. (без перехода на личности! )
Второй важный аспект этой философии — понимание того, что код пишется в первую очередь для человека, и только во вторую — для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования?
совершенно согласен. недавно перетирали код-ревью, например. там это тоже было.
я вообще считаю, что если вы не можете рассказать любому о том, что вы делаете — вы сами это не понимаете.
...а если не можете обьяснить зачем вы это делаете — то вряд ли это кому еще надо.
во
Здравствуйте, Gaperton, Вы писали:
G>С другой стороны, уметь "читать код" можно тоже по разному — в этом деле есть разные уровни. Одно дело сориентироваться в чужом коде, и закрыть багу,
Это тоже полезный навык, особенно, если закрыть и ничего при этом не сломать.
G>и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?
Это сильно зависит от того насколько программист знаком с исследуемой темой. Думаю, будет очень легко развеять ореол божественности, если попросить Тола Корина проделать тоже самое с исходниками другой незнакомой ему области. Можно, например, декомпилировать Linq 2 SQL и попросить восстановить за пять минут дизайн любой из его подсистем по коду.
В остальном со всем согласен
Если нам не помогут, то мы тоже никого не пощадим.
<q>Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего — подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором — вопрос нескольких лет.</q>
Не айс. Использование магии в худшем смысле этого слова для решения практических задач. На некоем объеме проекта магия откажет Толу и он не сможет в уме перейти от кода к архитектуре. Тол крут, у него достаточно маны чтобы проделывать этот фокус с 50 мегабайтным проектом. Но магия отличается от инженерного дела одним маленьким, незначительным нюансом — она не гарантирует повторения результата при одинаковых начальных условиях. Тол вообще не застрахован от того, что в самый ответственный момент его заклинание просто не сработает. Что он будет делать тогда? Ну и скорее всего существует некий объем кода по достижении которого заклинания Тола перестанут работать просто потому, что у него не хватит маны. Сто, сто пятьдесят, двести мегабайт — рано или поздно Тол попробует легко разобраться с наследованием в хитром метаклассе и его заклинание не сработает.
ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.
Здравствуйте, IT, Вы писали:
G>>и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?
IT>Это сильно зависит от того насколько программист знаком с исследуемой темой. Думаю, будет очень легко развеять ореол божественности, если попросить Тола Корина проделать тоже самое с исходниками другой незнакомой ему области. Можно, например, декомпилировать Linq 2 SQL и попросить восстановить за пять минут дизайн любой из его подсистем по коду.
Ты, вообще, совершенно прав — вопрос только в том, зачем развеивать ореол божественности.
Этот текст обладает уникальной характеристикой, блин. Опытным людям в нем все кажется банальным и понятным (ибо оно так и есть), а пионеры с ним никогда не согласятся. Обрати внимание — я думал, что писал о чем? О том, что я думал что типа все знаю, и все такое, а есть нечто, гхм, неосязаемое, чему можно научиться только по методике дзен . Про код — это просто пример.
И что показывает практика чтения этого текста? Две категории людей. Первая — (разумеется) — говорит, ну да, что тут собственно такого, это очевидно. Вторая говорит — "херня!" . Прям как я в 99 году .
Вот я и говорю — дзен, блин. Палкой по башке. Может, хотя бы ореол божественности сподвигнет, а? Достиг сатори, дай достичь другому .
IT>В остальном со всем согласен
Дык . "Просветленных" много. Это, к счастью, не редкость. Текст вообще для начинающих, да еще — лакмусовая бумажка для менеджеров. И тех, кто читать "что написано" не умеет — фильтрует охренительно. Статистика d ,kjut поразительная, кстати. Из тех, кто умеет писать — менее 10% умеют читать "что написано".
Знаешь, больше всего мне понравился коммент человека с членом в аватаре. Он истинно глубоко понимает дзен.
не имею никакого отношения к программированию, но тем не менее отмечу: замечательную аналогию подобрали с дзеном.
здесь аналогия работает не только относительно процедуры постановки и решения проблем. весь подход, который вы описали, очень напоминает классические коаны о том, что тот кто смотрит на окружающий мир, не нуждается в учебниках, его документирующих.
но это к делу, я так понимаю, не особо относиться.
посему — просто примите благодарность за текст
Здравствуйте, bastrakov, Вы писали:
G>>Импортировать в репозиторий можно с историей коммитов.
B>угу... приходите в гости, я вас с деплоймент-инженером сведу, и вы ему расскажете, как надо переливать сырцы. B>а он вам ответит, что в сырцах стоит не его имя, а прошлый спицилист. и репозиторий меняли уже 3 раза за прошедшие 4 года.
Зачем мне общаться с вашим деплоймент-инженером, я не вполне понимаю. Поговорите с ним сами. Надо было раньше импортировать репозиторий с историей коммитов. Это сделать было можно. Вы же утратили наиболее ценную часть "документации", обеспечивающей трассировку от намерений к реализации, которая реально необходима и полезна.
Это, кстати, я наблюдаю часто. Люди не соблюдают элементарной дисциплины работы с VCS, которая критична для последующей поддержки, зато учат всех как на больших и длительных проектах надо писать документацию, которой они сами на самом деле ни разу в глаза не видели, но признаваться в этом не хотят даже себе.
B>вот это начало, и ваш вывод — "читайте код". за это вас пинают. чтение и понимание кода — это не ключевое знание для проектирования сложных систем. совсем. потом что когда они проектируются (правильно или криво) кода еще нет.
Умение "читать" впрямую связано с умением "писать". Кстати, об умении читать — это не статья о ключевых знаниях для проектирования сложных систем.
B>совершенно согласен. для чтения кода дока не нужна. для понимания смысла написания так как есть (почему сделано так, а не иначе) — нужна.
Нужно знание, а не дока, "дока" всего лишь один из возможных его носителей. Знание же может быть получено самыми разными способами.
Вот простой пример из инженерии — два способа, как организовать fault tolerance. Первый способ — коммитить контрольные точки на диск, и восстанавливаться из них при сбое. Про существование второго способа знают, как ни странно, не многие — работаем в кластере на разных машинах, держим состояние в оперативной памяти, и реплицируем его по кластеру, без записи на диск. Failover в данном случае выполняется с соседних машин, например в режиме а-ля пиринговая сеть. Второй способ — основан на параллелизме, и лучше описывает реальную ситуацию с обменом знаниями в компании, занимающейся разработкой.
Первый способ соответствует "документации" в качестве носителя информации, второй — живой обмен знаниями, который я описывал недавно в топике про code и design review. Второй способ на практике работает лучше, и наличие документации при его использовании совершенно не критично. Исключая случаи, когда документы фиксируют некоторую договоренность группы людей о чем то, которую важно соблюдать, и не могут быть сгенерированы из кода автоматически. Таких случаев не так много.
B>
B>...тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод,...
B>почему? ну почему вы не показали, как вы находите, а не что вы находите?!..
По памяти я нахожу. Потому, что уже умею ориентироваться в коде — я просто знаю, где оно лежит. Что тут надо показывать?
B>он же потом со следующим методом придет. ...хотя...ну да. обычно "ловить рыбу" не учат. иначе выпрут из "ловцов рыбы".
Со временем научится сам, это не фокус.
B>Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия "код — лучшая документация" дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате — рассчитывая только на свои силы, понимая — что код — основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, — можно достичь мастерства в reverse engineering и вообще понять, что это такое.
B>угу. только это не часть процесса создания. это часть процесса поддержки.
Поддержка неотделима от создания в случае "живой", развивающейся системы, которая коммерчески успешна.
B>после недели медитации над чужим кодом, я могу переписать это за пару часов гораздо проще, и мне пофиг, че там реверс наинженерит.
"За пару часов" вы в самом лучшем случае напишете 100 строк отлаженного кода. Изолированного кода, а в старом коде очень много неявных контрактов, и заставить работать "переписанное" гораздо тяжелее. Не умея реверс инженирить, ничего вы не перепишете, либо все сломаете, либо раздуете код, налепив сбоку соплей, и его зарубят на code review.
B>я был бы счастлив, если бы мне вообще не пришлось вычитывать чужой код. замечено, что приходится читать то, что не работает. а вот то, что не имеет проблем — перечитывают гораздо реже.
Не вычитывая чужого кода невозможно отдиагностировать и исправить ни одного дефекта в большой системе. Не умея диагностировать дефектов, нельзя уметь эффективно проектировать новые системы.
B>"любой дурак", я надеюсь, художественное преувеличение?..
Нет, правда жизни. И чем больший дурак, тем больше он напишет кода.
B>ваши рекомендации в случае если я не согласен с мыслью автора, или автор схалявил и вообще не реализовал заказанную бизнес-логику? B>я не хочу продолжать ее. я готов ее переделать.
Мало-ли кто что готов. Разработка управляется не эстетическими чувствами, а принципом value-cost. Результат переделки в большинстве случаев будет иметь такой cost, что не стоить value.
B>не согласен. хороший архитектор поднимается на уровень вверх. а там кода уже совсем нет.
Я видел как минимум одного очень хорошего архитектора, компетенция которого была налицо, и который думает так, как я написал. И я видел много плохих "архитекторов", думающих иначе. Собственно, они в массе своей больше хотели называться "архитекторами", чем реально являлись ими. Можете соглашаться, можете нет — я свое мнение никому не навязываю.
Здравствуйте, Eye of Hell, Вы писали:
EOH>ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.
В этом посте нет никакого описания процесса разработки. Вы не знаете, и из данного поста не можете знать, какой процесс разработки и дисциплины, обеспечивающие разработку программного комплекса такого размера, реально стоит за тем маленьким фрагментом, что я описываю.
В этом посте нет никакого описания процесса разработки. Вы не знаете, и из данного поста не можете знать, какой процесс разработки и дисциплины, обеспечивающие разработку программного комплекса такого размера, реально стоит за тем маленьким фрагментом, что я описываю.
Вот что с людьми форумы делают (<- данный смайлик означает, что я шучу, а не пытаюсь перейти на личности). Я про магию высказался, а Вы сразу решили, что раз мне спокойнее когда инженерного процесса больше чем магии, то из этого следует что вы за нее, родимую ратуете .
Я не знаю какой процесс разработки в компании, где работает Тол. Вполне возможно там все поставлено на хорошем уровне — есть дополняемая и расширяемая база знаний, автоматическое наполнение из кода, продуманная система работы с задачами и артефактами. Ведь инженерный процесс и магия — не взаимоисключающие вещи, да? Вы высказали сентенцию, что если программист владеет магией перехода от raw кода к архитектуре, то документация уже не критична. Я с этим согласен, но, в свою очередь, отметил неприятное свойство магии: не гарантирует результат и напрямую зависит от запаса маны, тоесть плохо масштабируется.
Вышесказанное — мое личное мнение и на объективность не претендует. Написано исключительно в целях сбора новой информации из комментов по интересной мне теме.
P.S. Регулярно читаю Ваш блог и очень высого мнения о Ваших знаниях в предметной области .
В этом посте нет никакого описания процесса разработки. Вы не знаете, и из данного поста не можете знать, какой процесс разработки и дисциплины, обеспечивающие разработку программного комплекса такого размера, реально стоит за тем маленьким фрагментом, что я описываю.
EOH>Вот что с людьми форумы делают (<- данный смайлик означает, что я шучу, а не пытаюсь перейти на личности). Я про магию высказался, а Вы сразу решили, что раз мне спокойнее когда инженерного процесса больше чем магии, то из этого следует что вы за нее, родимую ратуете .
Форумы поистине делают с людьми страшные вещи, что тут спорить . После мрака в ЖЖ, я уже нервно дергаюсь при каждом новом коменте на эту тему. Прошу, кстати, это учесть.
EOH> Я с этим согласен, но, в свою очередь, отметил неприятное свойство магии: не гарантирует результат и напрямую зависит от запаса маны, тоесть плохо масштабируется.
Подразумевается, что в нашем деле есть что-то, что гарантирует результат? Простите, что это? Я правда хочу услышать пояснения. Раскройте свою мысль подробнее, плиз.
Я с этим согласен, но, в свою очередь, отметил неприятное свойство магии: не гарантирует результат и напрямую зависит от запаса маны, тоесть плохо масштабируется.
Подразумевается, что в нашем деле есть что-то, что гарантирует результат? Простите, что это? Я правда хочу услышать пояснения. Раскройте свою мысль подробнее, плиз.
Попробую. Процесс разработки местами творческий, и при этом переживающий некоторую долю ошибок. Поэтому сильно гарантировать мы не можем ничего, так как, еси не использовать магию, у нас нет возможности оценить где творчески будет принято решение, вследствии изменившихся требований в будующем ставшее неверным, а также оценить где количество ошибок перейдет тонкую грань, когда технология перестанет их переживать и грохотом на нас осыпется.
Но это если конь сферический и в вакууме. Изредка ошибки встречаются везде. Чемпион россии по MTG при мне проиграл мелкий турнир, потому что ему фатально не повезло с раздачей карт, а оппоненту фатально повезло. Такое бывает. Но бывает, заметьте, изредка. Когда он играет со мной, я проигрываю 19 партий из 20. Потому что он объективно играет на пару порядков лучше, чем я.
К чему я клоню? К тому, что если ошибок вообще избежать вряд ли получится, то можно уменьшить частоту их получения и сроки их нахождения. Почему я говорю что магия — ненадежный архитектурный инструмент? Потому что она мало от нас зависит. У мага может *просто не получиться*. Не с той ноги встал. И мы с этим ни-че-го не сделаем. Тоесть вообще ничего. Сидит Тод, тупит в код, и у него "не прет". А мы, соответственно, сидим рядом и поняимаем, что без магии тут разобраться часов двадцать-тридцать. Разберемся, конечно, но нас не радует прокол на пустом месте. Потому что совокупность проколов на пустом месте дает как раз ту разницу, которая отличает просто хорошего игрока в MTG от чемпиона России.
Что можно сделать? Я уже не первый год занимаюсь техническим сопровождением когнитивной составляющей в разработке ПО и полностью с Вами согласен в том, что все плохо. На документацию забивают большой и длинный, в вики никто не пишет, систему управления задачами читают из-под палки и все равно предпочитают тестировщикам выдавать задачи устно, со всеми вытекающими. Напрашиваются несколько выводов. Во-первых, архитектура и комментарии должны быть записаны в коде. Тоесть никаких .doc файлов, mediawiki и прочих 1С:Мироздание. Прямо в сорцах расставляем в комментариях теги и записываем что нам надо. Doxygen, Natural Docs, javadoc и еще большая куча технологий и инструментов в помощь. Если это развернуть, то мы имеем документацию по проекту, которая всегда синхронизирована с исходниками и всегда актуальна. Потому что она из них генерится.
В этом случае, когда у Тода не получилось, потому что у него вчера заболела жена и он потратил весь запас маны на неделю вперед чтобы ее вылечить, мы не сидим грустно и не считаем на пальцах лидов, которых у нас мало. Мы открывает браузер документации, на страничке "вид сверху". Тыкаем в нужную подсистему на Главной Картинки. Затем тыкаем в нужный паттерн. Затем в нужную функцию. Затем на нужный файл. Он открываетс в редакторе и радостный Тод, имея справа редактор а слева автогенеренную историю по данной функциональности (мы ведь не только из сорцов автогенерим, да?) все делает за пять минут и идет пить кофе.
С интересом выслушаю встречные вопросы, бо методология достаточно сырая . You opinion counts (c).
Здравствуйте, Eye of Hell, Вы писали:
EOH>Тол вообще не застрахован от того, что в самый ответственный момент его заклинание просто не сработает. Что он будет делать тогда? Ну и скорее всего существует некий объем кода по достижении которого заклинания Тола перестанут работать просто потому, что у него не хватит маны. Сто, сто пятьдесят, двести мегабайт — рано или поздно Тол попробует легко разобраться с наследованием в хитром метаклассе и его заклинание не сработает.
Да и вообще, вот заболеет он завтра менингитом и станет идиотом — никто от этого не застрахован.
EOH>ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.
Беда в том, что если вы строите процесс, который не зависит от личности, то все личности в вашем проекте становятся взаимозаменяемыми. А значит, вам всё равно, что чувак типа Тола, что Вася Пупкин с опытом 3 года, обученный процессу. Т.е., фактически, вы делаете так, что людям типа Тола в вашем проекте нет места. А тем самым, лишаете себя возможности разрабатывать софтварий, в котором без людей такого класса просто не обойтись.
Если нам не помогут, то мы тоже никого не пощадим.
