Здравствуйте, AndrewVK, Вы писали:
AVK>Подробную спецификацию это кодерам выдают и то не всегда. А ты, коль уж архитектор, работаешь не в тепличных, а вреальных условиях. Ты сам эту спецификацию создать должен.
Слушай, не надо, это уж совсем несерьезно. Персональный прокси-сервер, прокси для небольшой организации или тот прокси, через который, как утверждают, весь Китай в Интернет ходит (чтобы куда не надо не ходили) — это все же разные немного задачи ? Я что, должен сам додумывать ?
PD>>Вот когда подробные спецификации будут — тогда и поговорим.
AVK>Мда, плохой из тебя архитектор выходит.
Уж точно. Потому как категорически отказываюсь разрабатывать не то гоночную машину , не то КАМАЗ. Оба они автомобили, как понимаешь..
(А в скобках — тебе что именно надо — доказать неправильность моих идей или показать, что лично я — плохой архитектор ? Так ведь второе первое не доказывает. Даже если второе докажешь- первое от этого ни на йоту более доказанным не станет. Так что тебе здесь хочется ? Меня укольнуть ? Напрасно — на меня такие уколы не действуют . Тогда что ?)
AVK>Судя по тем преджположениям, что ты делал в форуме позволю себе не поверить.
Твое право. От этого ситуация не меняется. Софт работает, переделками не занимался, так что от твоей веры здесь ничего не зависит.
AVK>Помнишь я тебе вопросы задавал? Ты на большую часть не ответил. Попробуй, соотносясь с этим утверждением вопросы прочитать еще раз.
Ты же сам сказал — ответил, но не на все. А теперь, выходит, на большую часть не ответил. Ты уж в следующий раз уточняй. что ли — ответил на 43.5 % . А то я уж и не знаю, как отвечать.
PD>> И если все же одного — почему нельзя это по времени растянуть.
AVK>Потому что рынок.
А, ну вот так и говори. С этм возражением я согласен, я уже писал об этом. Только будем честными перед собой — мы заранее заявляем. что делать будем не лучшим образом. Тогда все, я свои возражения сниму.
Только не надо при этом хоть самого себя обманывать. Надо честно в этом признаться, и не возводить это в принцип, а признать, что в текущих условиях — иначе не можем.
Вот ответь прямо. Создали тебе идеальную ситуацию. Времени — сколько хочешь. Сроков нет. Специалистов — бери каких хочешь.
Так же будешь делать ?
PD>>Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
AVK>Но мне то что делать? Я ведь должен архитектуру дальше делать. Я не могу оставить неспроектированным кусок целиком. Мне нужно ввести абстракцию, изолирующую меня от специфики хранения. Но, пользуясь твоей методикой, я этого сделать не могу, потому что она должна быть согласована с реализацией, а реализацию я не могу никак определить.
Ну неужто именно впрямь в именно этой задаче не можешь ? Ну попроси кого-нибудь сделать тесты. Добавляются файлы, столько-то в минуту, изменения нет, добавление в хвост есть, что там еще... Неужели сложно тест сделать без прокси-сервера, смоделировать эту ситуацию и посмотреть, какая нагрузка хотя бы по PerfMon ? И какое время отклика ? Там работы на 2 дня.
PD>>Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому.
AVK>При декомпозиции обычно учитывают только входные данные и структуру. Как делать декомпозицию с обязательным учетом реализации я не знаю.
Ну не знаешь, так не знаешь. Твои проблемы.
AVK>>>Ну задачу я тебе дал.
PD>>Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
AVK>Это называется передергивание.
Нет. Это столь же конкретная постановка задачи, ничем не лучше. К завтрашнему дню notepad написать вполне можно — MFC + CMYView::CEDitView почти весь он и есть (ну там поимк еще добавить). А вот Word — не возьмусь. И не к завтрашнему дню, а вообще не возьмусь.
AVK>Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам,
Не ведет. Как ни реализуй модуль записи файлов в твоем прокси, от этого связность остальной части с этой компонентой не изменится. Хоть что там внутри этой компоненты будет.
>что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию.
Это почему ? На примере прокси, пожалуйста.
Ну а если уж на то пошло, то в моей работе (о которой у теяб такие сомнения) от меня как раз и требовали обеспечить доступ к данным. Абстракции — не требовали, предельно оптимальный доступ — да. И именно это я делал. Не слишком вдаваясь , зачем им тот или другой запрос нужен. А они тоже не очень вдавались в то, как я это сделаю, просто знали — сделаю все, что ни попросят.
Так мы и жили
Переход к слабосвязным системам снимает структурные проблемы, но ведет к снижению эфективности на стыках. Найти золотую середину — одна из сверхзадач проектирования архитектуры. Говорить сейчас о конкретном ее значении без конкретики конечно бессмысленно, но одно очевидно — чем больше у нас ресурсов, тем сильнее золотая середина смещается к слабосвязным решениям.
Именно. А слабосвязанные задачи предполагают декомпозицию до такого состояния, когда влияние связи намного меньше, чем самих компонент. В данном случае — производительность прокси при грамотной реализации может быть сделана такой, что эффект хранения данных на диске незначителен по сравнению с пропускной способностью по сети. Или наоборот.
AVK>Что же касается того, как эту середину выбрать, то ответ тоже уже был дан. Нужно проектировать максимально слабосвязное решение,
100% согласен.
>а потом, по мере необходимости, мигрировать в узких местах к решениям более связным.
А надо ли ? Если слабосвязанное решение оптимально по своим компонентам, а эффект от связи на порядок ниже чем от компонент, то оптимизировать надо ту компоненту, которая есть лимитирующая стадия процесса. А не связь. А лучше ее выявить на стадии проектирования и учесть. Реализацию ее.
>Здесь, опять же, замечу, что с увеличением количества ресурсов узкие места совсем не обязательно остануться там же, где и были.
Ну вообще-то, конечно, может быть. А реально, ответь на примере твоего прокси — если , скажем, файловая часть будет сделана наилучшим образом, из-за чего вдруг возникнет узкое место на связи этой подсистемы с остальной частью ? И что надо сделать, если она возникнет ? Ухудшить эту часть ?
>Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
Ну да, конечно. Поэтому-то я и возмутился, когда ты мне предложил абстрактный проки спроектировать.
AVK>А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
Неразумно. Моя интуиция — как я уже сказал, подсознательный прошлый опыт. Если он есть и я чувствую, что здесь можно ожидать (по прошлому опыту знаю) — тесты не нужны, конечно. Ну доведем до логического конца -я уже такое писал, для другой задачи, зачем мне тесты, когда я и так знаю, чего здесь можно ждать. Но в реальности это не всегда так, так что интуиция интуицией, а попробовать не мешает. Для того, чтобы интуиция не подвела.
PD>>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
AVK>А оно там было с первых версий?
Понятия не имею.
PD>>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
AVK>Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
М-да... Заказчик-то срок установил.
PD>>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить.
AVK>Еще раз — чем тесты лучше прототипа?
1. Очень дешевы. Годится или нет FAT/NTFS — через 2 дня будешь знать. Прототип когда еще готов будет...
2. Нет прочей информации. Не просто слабосвязано — нульсвязано. В чистом виде. В идеальных условиях. И уж если в идеальных условиях нет нужной производительности — пиши пропало, в реальной обстановке только хуже будет.
AVK>>>Она не дорогая, она просто невозможна.
PD>>Почему невозможна ?
AVK>Потому.
PD>> Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
AVK>Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
Хм, не понял
int * p = new int[99];
// fill p
int i,x = 1000;
int * p1 = new int[100];
for(i = 0; i < 24; i++)
p1[i] = p[i]; // я бы, конечно, memcpy реально употребил, это только для наглядности
p[24] = x;
for(i = 24; i < 99; i++)
p1[i+1] = p[i];
delete p;
p=p1;
Вот и все. Кто тут чего умеет и не умеет — бог знает. Где тут список — решительно не понимаю. Если можешь — объясни. Только без схоластики, пожалуйста, насчет ООП и прочего. Просто объясни.
PD>> К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается.
AVK>Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
А мне что в лоб, что по лбу. Мне данные хранить надо. Доступ к ним — хорошо, если бы по индексу, это удобнее всего. Но если по индексу не удастся найти нужной реализации — ладно, по ключу доступ тоже сойдет Мне на высокие материи наплевать, мне не теория нужна, что там заменяемо, а что нет. Мне — что делать, ответь ?
PD>> Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
AVK>Писать свою реализацию IList. А в чем проблема?
Ну и ну! Заложили туда IList, а выяснилось, что ни одной приличной реализации нет. Писать свою будем. А рядом хеш-таблица и дерево , оба вполне годятся, а мы говорим — ну уж нет, заложили мы IList, так будет IList. Свою реализацию его напишем (еще вопрос — будет ли лучше), время на это потратим, зато IList останется. Во имя высших принципов.И все из-за того, что на стадии проектирования не задумались — а есть ли вообще у IList реализация, где ни для каких операций нет O(N). А если нет — стоит ли самому ее изобретать или же можно другие кандидаты поискать.
PD>>Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
AVK>Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
Действительно офигеть можно. Человеку приводишь аналогию, а он ее буквально понимает. Ладно, придется впредь с тобой аналогиями не пользоваться.
Там еще одно письмо вроде от тебя лежит — извини, не отвечу. Да и вообще продолжу эту тему, если будет время. Не уверен.
А может, и не надо продолжать. Позиции сторон ясны, согласовать их в главном невозможно.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Pavel Dvorkin, Вы писали:
Д>Умение писать работоспособный код — это вопрос минимального профессионального соответствия. Та самая планка, ниже которой стоит слово "уволить немедленно". Настоящего квалифицированного программиста отличает умение писать не только работоспособный, но и легко читаемый, поддерживаемый, расширяемый код. Поэтому не надо рассказывать нам, что твои программы работают. Лучше расскажи, какое количество профессиональных программистов занимается/занималось поддержкой твоего кода.
Ни один. Проект сделан надолго, изменения в него вносить не придется. По причине того, что предметная область не будет изменена в течение ближайших десятилетий, да и вообще в обозримом будущем. Если не будет светопреставления. Никаких расширений там быть не может по определению — за полной их ненадобностью. Поверь, это действительно так.
Да, конечно, ситуация нетипичная, я понимаю. Но на тему поддержки и расширения кода я сейчас высказываться не буду — не готов. Будет время — трону и эту священную корову за вымя . В отдельном топике.
>Неплохо бы также узнать их мнение о твоем коде.
Ну если уж тебя это так интересует... Специально для тебя разыскал в почте.
Pavel,
I'd just like to thank you for all your effort this year. You have made
a major contribution to the success of the project so far. I hope
you will continue to enjoy the challenges of the project in 2003. Although you
are so far away you are always included in our thoughts and
conversations. We all appreciate the effort you have made.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ни один. Проект сделан надолго, изменения в него вносить не придется. По причине того, что предметная область не будет изменена в течение ближайших десятилетий, да и вообще в обозримом будущем. Если не будет светопреставления. Никаких расширений там быть не может по определению — за полной их ненадобностью. Поверь, это действительно так.
Если в данном проекте никакой саппорт кода действительно не предусматривается, расскажи о другом проекте
PD>Да, конечно, ситуация нетипичная, я понимаю. Но на тему поддержки и расширения кода я сейчас высказываться не буду — не готов. Будет время — трону и эту священную корову за вымя . В отдельном топике.
мы все уже трепещем
>>Неплохо бы также узнать их мнение о твоем коде.
PD>Ну если уж тебя это так интересует... Специально для тебя разыскал в почте.
PD>Pavel,
PD>I'd just like to thank you for all your effort this year. You have made PD>a major contribution to the success of the project so far. I hope PD>you will continue to enjoy the challenges of the project in 2003. Although you PD>are so far away you are always included in our thoughts and PD>conversations. We all appreciate the effort you have made.
ну я ведь просил отзывы других программистов, а не заказчика. А это — всего лишь стандартная отписка. Не сомневаюсь, что она у них в шаблоне сохранена, дабы рассылать разработчикам, которые не облажались слишком уж явно. Доброе слово — оно ведь и кошке приятно
Я надеюсь, ты не принял это всё за чистую монету?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Вот конкретно это место мне совершенно непонятно. Отказавшись от своей ФС мы очень значительно сократили расходы. Поэтому я не вижу причины, по которой мы встрянем с производительностью за две недели до дедлайна.
А просто по совету AndrewVK начали с прототипа. Не слишком заботясь о реализации. А в итоге там оказалось узкое звено. И его теперь иначе не расшить.
А если ты скажешь, что надо было ПМ'у с самого начала думать — так Андрей же и утверждает, что пока не сделаем — это ясно не будет, не может быть.
>Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем.
Кстати, вспомнил забавную историю на этот счет.
К счастью, вскоре настал день, когда заработала система моделирования
технических характеристик OS/360. Первые результаты показали наличие
серьезных проблем. Моделирование компиляции с Fortran H на машине Model 65 с
барабанами дало результат пять операторов в минуту! Анализ показал, что все
модели управляющей программы делали множество обращений к диску. Даже
интенсивно используемые модули супервизора часто обращались к диску, и
результат по звуку весьма напоминал шелест перелистываемой книги.
(C) Фредерик П.Брукс. Мифический человеко-месяц или как создатся программные системы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, не надо, это уж совсем несерьезно. Персональный прокси-сервер, прокси для небольшой организации или тот прокси, через который, как утверждают, весь Китай в Интернет ходит (чтобы куда не надо не ходили) — это все же разные немного задачи ? Я что, должен сам додумывать ?
В настоящий момент на рынке присутствуют прокси-сервера, способные работать как персонально для одной машины, так и для крупных организаций. Вот такой и нужен.
PD>Уж точно. Потому как категорически отказываюсь разрабатывать не то гоночную машину , не то КАМАЗ. Оба они автомобили, как понимаешь..
А ты погляди на софт который тебя окружает.
AVK>>Потому что рынок.
PD>А, ну вот так и говори. С этм возражением я согласен, я уже писал об этом. Только будем честными перед собой — мы заранее заявляем. что делать будем не лучшим образом.
ЧТо такое лучшим образом? Время разработки это такой же критерий, не хуже и не лучше других.
PD>Только не надо при этом хоть самого себя обманывать. Надо честно в этом признаться
В чем признаваться то?
PD>Вот ответь прямо. Создали тебе идеальную ситуацию. Времени — сколько хочешь. Сроков нет. Специалистов — бери каких хочешь.
Такой ситуации не бывает.
AVK>>Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам,
PD>Не ведет. Как ни реализуй модуль записи файлов в твоем прокси, от этого связность остальной части с этой компонентой не изменится.
Мы говорим не о реализациях, а об абстракциях. Согласно твоим утверждениям, абстрактная модель модуля записи файлов должна зависеть от его реализации.
>>что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию.
PD>Это почему ? На примере прокси, пожалуйста.
Почему высокая связность системы уменьшает предсказуемость и усложняет модификацию кода?
PD>Ну а если уж на то пошло, то в моей работе (о которой у теяб такие сомнения) от меня как раз и требовали обеспечить доступ к данным. Абстракции — не требовали, предельно оптимальный доступ — да. И именно это я делал.
Это не задача архитектора. Это задача оптимизатора.
>>а потом, по мере необходимости, мигрировать в узких местах к решениям более связным.
PD>А надо ли ?
Если эффективность не устраивает — надо.
PD> Если слабосвязанное решение оптимально по своим компонентам, а эффект от связи на порядок ниже чем от компонент, то оптимизировать надо ту компоненту, которая есть лимитирующая стадия процесса.
Внимательно читай. Я написал "мигрировать в узких местах".
PD>Ну вообще-то, конечно, может быть. А реально, ответь на примере твоего прокси — если , скажем, файловая часть будет сделана наилучшим образом, из-за чего вдруг возникнет узкое место на связи этой подсистемы с остальной частью ?
Легко. Ключ поиска в кеше стал включать, к примеру, еще и дату файла.
PD> И что надо сделать, если она возникнет ? Ухудшить эту часть ?
Рефакторинг.
>>Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
PD>Ну да, конечно. Поэтому-то я и возмутился, когда ты мне предложил абстрактный проки спроектировать.
Ты опять путаешь проектирование архитектуры и написание реализации.
AVK>>А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
PD>Неразумно. Моя интуиция — как я уже сказал, подсознательный прошлый опыт. Если он есть и я чувствую, что здесь можно ожидать (по прошлому опыту знаю) — тесты не нужны, конечно. Ну доведем до логического конца -я уже такое писал, для другой задачи, зачем мне тесты, когда я и так знаю, чего здесь можно ждать. Но в реальности это не всегда так, так что интуиция интуицией, а попробовать не мешает. Для того, чтобы интуиция не подвела.
Объясни мне простую вещь — а почему нельзя проводить тесты на реальном приложении? Пусть даже на начальном этапе оно недалеко от тестов ушло.
AVK>>А оно там было с первых версий?
PD>Понятия не имею.
Поинтересуйся.
AVK>>Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
PD>М-да... Заказчик-то срок установил.
Это проблемы заказчика. В любом случае — если мы начнем двигаться мелкими шажками-итерациями, то заказчик получит результат максимально быстро. А вот если мы назакладываемся в проектном решении на интуицию, а потом ошибемся, то перерасход времени будет дикий.
AVK>>Еще раз — чем тесты лучше прототипа?
PD>1. Очень дешевы.
Далеко не всегда. И, если само приложение грамотно спроектировано, эксперименты с реализациями куска будут не сильно дороже экспериментов с отдельным приложением. Зато не весь код потом пойдет в мусорную корзину, да еще и взаимосвязанные системы можно будет оттестировать.
AVK>>Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
PD>Хм, не понял
А что тут непонятного? IList — абстракция. ArrayList, массив — реализация. Understand?
AVK>>Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
PD>А мне что в лоб, что по лбу. Мне данные хранить надо.
Вот и описывай абстрактное хранилище данных. При чем тут хеш-таблица?
PD> Доступ к ним — хорошо, если бы по индексу, это удобнее всего. Но если по индексу не удастся найти нужной реализации — ладно, по ключу доступ тоже сойдет Мне на высокие материи наплевать, мне не теория нужна, что там заменяемо, а что нет. Мне — что делать, ответь ?
Устранить разброд и шатание и определится, что же тебе все таки нужно — доступ по ключу или доступ по индексу. Или и то и другое. Нужен ли тебе порядок следования.
AVK>>Писать свою реализацию IList. А в чем проблема?
PD>Ну и ну! Заложили туда IList, а выяснилось, что ни одной приличной реализации нет. Писать свою будем.
А куда деваться, если ее нет?
PD> А рядом хеш-таблица и дерево , оба вполне годятся,
Не годятся. IList подразумевает сохранение порядка следования, хеш-таблица нет, хештаблица требует уникального ключа, IList нет и т.д. Если у тебя есть обощенные алгоритмы, рассчитанные на IList, то ни о какой эквивалентности списка и хеш-таблицы и речи идти не может. Если же у тебя обобщенные алгоритмы изолированны от хранилища, так и создай IAbstractStorage, а уж внутри него реализуй хранение как тебе нравится — через массив, список или хеш-таблицу. Удивительно, что такие базовые вещи приходится описывать, но иначе непонятно как указать тебе на явные нестыковки в том, что ты пишешь.
(Кстати, характерный момент — ты пытаешься иллюстрировать архитектурные тезисы кодом с указателями, да еще и с пометками, мол тут memcpy надо использовать.)
AVK>>Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
PD>Действительно офигеть можно. Человеку приводишь аналогию,
Аналогии приводятся в иллюстрацию. Ты чего хотел своей аналогией проиллюстрировать? Как не надо строить дома? Это имеет отношение к тому, о чем мы говорим? Мы о строительстве домов говорим?
PD> а он ее буквально понимает. Ладно, придется впредь с тобой аналогиями не пользоваться.
Не только со мной. Не надо вобще пользоваться аналогиями кроме как для иллюстрации.
PD>А может, и не надо продолжать. Позиции сторон ясны, согласовать их в главном невозможно.
Не знаю. Пока что я вижу, что ты опять путаешься в каких то базовых вещах.
Здравствуйте, Дарней, Вы писали:
Д>мы все уже трепещем Д>Я надеюсь, ты не принял это всё за чистую монету?
Угу. У меня таких признаний — полный архив. Они причем совершенно искренне это пишут. Просто довольно сложно не внести мажорную контрибуцию, будучи одним из трех девелоперов в проекте
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, в условиях, когда используется доп. память, я принципиально скорости не сравниваю. Даже если при этом лишние действия делаются. Только при равных условиях по памяти.
Так тебе шашочки или ехать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А просто по совету AndrewVK начали с прототипа. Не слишком заботясь о реализации. А в итоге там оказалось узкое звено. И его теперь иначе не расшить.
И что? Павел, мы получили прототип не за две недели до дедлайна, а через две недели от начала. Что там делать больше двух недель? Мы же свою ФС не пишем, как не пишем и свой стек протоколов. PD>А если ты скажешь, что надо было ПМ'у с самого начала думать — так Андрей же и утверждает, что пока не сделаем — это ясно не будет, не может быть.
Совершенно верно. Архитектор выписывает список рисков. И именно они проверяются в первую очередь, как только готова соответствующая часть прототипа.
>>Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем.
Совершенно верно. И под это заранее заложены оценки стоимости. И даже если на каком-то этапе мы понимаем, что очередной прототип разрабатывать уже экономически невыгодно, мы получили минимальные потери на неудачном проекте. В противоположном случае у нас есть риск оплатить разработку супероттюненой ФС, которая пойдет в корзину. Потому что остальная часть приложения так и не взлетела. PD>Кстати, вспомнил забавную историю на этот счет.
PD>Это они прототип системы сделали
Рекомендую также ознакомиться с приблизительной оценкой затрат на проект. Насколько я помню, Брукс приводит оценку около 5000 человеко-лет. Павел, положа руку на сердце, ты когда-нибудь участвовал в проекте стоимостью хотя бы в 50 человеко-лет?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Рекомендую также ознакомиться с приблизительной оценкой затрат на проект. Насколько я помню, Брукс приводит оценку около 5000 человеко-лет.
Угу. В 1965 году с перфокартами. Я бы мог многое на эту тему порассказать.
>Павел, положа руку на сердце, ты когда-нибудь участвовал в проекте стоимостью хотя бы в 50 человеко-лет?
Здравствуйте, Дарней, Вы писали:
Д>мы все уже трепещем
Трепещите
>>>Неплохо бы также узнать их мнение о твоем коде.
Д>ну я ведь просил отзывы других программистов, а не заказчика.
Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Трепещите
и содрогнется ФП от очередного флейма, бессмысленного и беспощадного.
PD>Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Значит, это — просто посредник, который передает другим задания, в которых сам ничего не смыслит. Зачем тебе так хочется назвать его программистом?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[21]: Каков глубокий смысл сериализации? - в завершение
Отвечать не буду — пойдем по третьему кругу, и ничего нового не найдем.
В общем, из этой дискуссии мне более понятным стало то состояние дел, о котором я писал , когда говорил об эффективности. Сделаем что-нибудь, а потом будем это улучшать, пока не достигенм приемлемых характерстик...При таком подходе, естественно, ничего иного получиться не может.
Если ситуация с ресурсами остнется прежней — этот подход еще некоторое время будет существовать. Особенно в области т.н. серверного софта, рассчитаннного порой на использование на выделенном сервере, где кроме него ничего и не крутится серьезного... В области же софта для настольных станций это состояние дел и сейчас большие нарекания вызывает, а дальше больше будет. Потому что ясно — рост производительности железа замедлился. А аппетиты расти будут.
Так что это просто болезнь роста. Их уже много всяких было. Минует и эта.
На этом и прощаюсь.
With best regards
Pavel Dvorkin
Re[22]: Каков глубокий смысл сериализации? - в завершение
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В общем, из этой дискуссии мне более понятным стало то состояние дел, о котором я писал , когда говорил об эффективности. Сделаем что-нибудь, а потом будем это улучшать, пока не достигенм приемлемых характерстик...При таком подходе, естественно, ничего иного получиться не может.
Т.е. аргументы кончились, доказать ничего не вышло. Становимся в позу Оракула и начинаем вещать. Оракул, он, как известно, никогда свои слова доказательствами не подкрепляет, высшие силы доказательств давать не любят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е. аргументы кончились,
Силы кончились. И время тоже.
>доказать ничего не вышло.
Несомненно. Тебе. А другим — пусть сами решают. Я все сказал, что хотел.
>Становимся в позу Оракула и начинаем вещать. Оракул, он, как известно, никогда свои слова доказательствами не подкрепляет, высшие силы доказательств давать не любят.
Когда других аргументов нет — начинают такие применять. Что, впрочем, я от тебя и Sinclair не раз уже встречал.
А насчет оракулов — почитай историю Древней Греции. В особенности насчет Дельфийского оракула и его пророчества насчет "божественного Саламина". Тема — греко-персидские войны.
Здравствуйте, Дарней, Вы писали:
PD>>Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Д>Значит, это — просто посредник, который передает другим задания, в которых сам ничего не смыслит.
Как тебе хочется, чтобы это было так! Ну просто очень хочется! Невозможно же терпеть просто, если это иначе. Потому что тогда придется признать, что иначе бывает. Что не всегда проекты делают по принципу "что-нибудь сделаем и посмотрим, что из этого вышло". Что и по другому делают. И вполне удачно.
Разочарую — это не посредник. Это человек, написавший большУю часть кода и руководивший проектом.
>Зачем тебе так хочется назвать его программистом?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Как тебе хочется, чтобы это было так! Ну просто очень хочется! Невозможно же терпеть просто, если это иначе. Потому что тогда придется признать, что иначе бывает. Что не всегда проекты делают по принципу "что-нибудь сделаем и посмотрим, что из этого вышло". Что и по другому делают. И вполне удачно.
В условиях, когда требования к проекту определены заранее и намертво зафиксированы, а изменений в коде не предвидится в ближайший десяток лет? Бывает, конечно бывает! В таких условиях можно позволить себе любую прихоть, в том числе и сидеть месяц над листком бумаги и выдумывать, "где же оно там будет тормозить". Вместо того, чтобы сделать за неделю прототип и получить точные данные. В таких тепличных условиях надо вообще очень сильно постараться, чтобы запороть проект.
Но это — роскошь, которой не обладают (и никогда не будут обладать) 99,999% команд разработчиков. Поэтому просто глупо думать, что им подойдет такой же подход к работе.
PD>Разочарую — это не посредник. Это человек, написавший большУю часть кода и руководивший проектом.
Ну а саппортом твоего кода он занимался? Ты сам ответил — нет. Значит, это в любом случаем не является ответом на мой вопрос.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[24]: Каков глубокий смысл сериализации? - в завершение
Здравствуйте, Дарней, Вы писали:
Д>Ну а саппортом твоего кода он занимался? Ты сам ответил — нет. Значит, это в любом случаем не является ответом на мой вопрос.
Он его применял. Я его писал. Впрочем, иногда он изменения в него вносил. Когда я в отпуск уехал. Вернулся — посмотрел, что он там поменял. Принял, но мягко ему намекнул, что в дальнейшем будет лучше, если я сам этим буду заниматься.
(Послднее признание — специально для тебя. Чтобы у тебя был повод придраться к нему и меня упрекнуть)
1.1.4 stable rev. 510
