Экстремальное программирование и специализация
Просто нужно иметь по 2 спеца в каждой области 
Да тоже была такая мысль, но там говориться что пары должны меняться, дабы исключить сговор , привыкание и пр, т.е. уже нужно как минимум 4 спеца в одной области. В то же время говорится что XP программинг не стоит делать если программеров больше 10-ти.
получается в эти рамки умещается только 2 специализации. Похоже XP программинг подходит только для написания курсовых в компьютерном классе
получается в эти рамки умещается только 2 специализации. Похоже XP программинг подходит только для написания курсовых в компьютерном классе
В то же время говорится что XP программинг не стоит делать если программеров больше 10-ти.
Где такое говорится?
В Кент Беке есть глава "Когда не следует использовать XP"
Цитирую ( не полностью копирую, но смысл остался не тронутым ):
Конечно это все условно, может и 11 нормально быть, а 9 - плохо. Все от ситуации зависит.
Сорри 12 - хорошо, а 8 - плохо.
Цитирую ( не полностью копирую, но смысл остался не тронутым ):
Огромное значение имеет масштаб проекта . Скорее всего вам не удасться эффективно использовать xp если над проектом работает сотня программеров. Пятьдесят программеров тоже много, скорее всего и 20 программистов будет много. Десять программистов - определенно подходящее количество.Это я сегодня прочитал, т.к. книжка появилась. Но про магическое число 10 еще до этого неоднократно натыкался в инете.
Конечно это все условно, может и 11 нормально быть, а 9 - плохо. Все от ситуации зависит.
Сорри 12 - хорошо, а 8 - плохо
.надуманная проблема какая-то. вот мы пишем вдесятером проект на джаве. все без исключения временно и вынужденно являются спецами в джаве.
А что за проект интересно, есть подозрение что не очень сложный, т.к. не требует никаких доп. знаний кроме языка программирования , как я понял.
дай ссылку плз на определение XP . именно определение . то что оно в целом представляет - вроде в инете прочёл , но не понял .............
ЗЫ sorry за ламерство .........
ЗЫ sorry за ламерство .........
Если бы я знал точное определение
Думаю его и сам автор точно сформулировать не может как следует. Т.к. при чтении возникает довольно часто ощущение отсутствие корреляции методики с практикой, т.е. сначала придумали как хорошо было бы если было бы так, а потом кто-то поверив пробует это.
Но вот на обложке книги , автором которой является Кент Бек написано :
Экстремальное программирование - это упрощенная методика организации производства для небольших и средних команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстроменяющихся требований.
Думаю его и сам автор точно сформулировать не может как следует. Т.к. при чтении возникает довольно часто ощущение отсутствие корреляции методики с практикой, т.е. сначала придумали как хорошо было бы если было бы так, а потом кто-то поверив пробует это
.Но вот на обложке книги , автором которой является Кент Бек написано :
Экстремальное программирование - это упрощенная методика организации производства для небольших и средних команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстроменяющихся требований.
Вот кстати правила :
http://www.xprogramming.ru/XPRules/XPRules.html
Не знаю , мне это больше коммунизм напоминает, в том плане , что утопия.
Например в правилах есть такое :
Каждый день начинается с утреннего Собрания стоя.
Собрание стоя
Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды. Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды.
В типичном собрании большинство участников ничего не вносят, просто участвуют чтобы послушать что скажут другие. Большое количество времени людей тратится чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании.
Для такого рода коммуникаций и нужно собрание стоя. Намного лучше иметь одно короткое обязательное собрание, чем множество длинных на которых большинство разработчиков должно все равно присутствовать.
Если у вас проводятся ежедневные собрания стоя, то все остальные собрания должны посещать только те люди, которые необходимы и будут что-либо привносить. Более того, имеется возможность даже избежать некоторых собраний. С ограничением участников, большинство собраний может быть проведено спонтанно перед монитором, где обмен идеями намного более интенсивен.
Ежедневное утреннее собрание это не еще одна трата времени. Оно позволит вам избежать многих других собраний и сэкономит больше времени, чем на него затрачено.
http://www.xprogramming.ru/XPRules/XPRules.html
Не знаю , мне это больше коммунизм напоминает, в том плане , что утопия.
Например в правилах есть такое :
Каждый день начинается с утреннего Собрания стоя.
Собрание стоя
Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды. Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды.
В типичном собрании большинство участников ничего не вносят, просто участвуют чтобы послушать что скажут другие. Большое количество времени людей тратится чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании.
Для такого рода коммуникаций и нужно собрание стоя. Намного лучше иметь одно короткое обязательное собрание, чем множество длинных на которых большинство разработчиков должно все равно присутствовать.
Если у вас проводятся ежедневные собрания стоя, то все остальные собрания должны посещать только те люди, которые необходимы и будут что-либо привносить. Более того, имеется возможность даже избежать некоторых собраний. С ограничением участников, большинство собраний может быть проведено спонтанно перед монитором, где обмен идеями намного более интенсивен.
Ежедневное утреннее собрание это не еще одна трата времени. Оно позволит вам избежать многих других собраний и сэкономит больше времени, чем на него затрачено.
ну такие "собрания стоя" каждый день раз по 20 проводятся . место проведения - курилка ........
Ну так курилка это все-таки общение больше для удовольствия чем для дела, или у вас
"Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды." ?
"Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды." ?
Но вот на обложке книги , автором которой является Кент Бек написано :
Экстремальное программирование - это упрощенная методика организации производства для небольших и средних команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстроменяющихся требований.
дык любая группа разработчиков пытается следовать упрощённым методикам . а "в условиях неясных или быстроменяющихся требований" - в вебе это на каждом шагу . а в чём смысл этой методики ?
Ну единственное что в этой методике принял мой организм - unit testы. Хотя учитывая лень разработчиков, которые даже зачастую и комментарии леняться вставлять, врятли они будут следовать этому правилу. Для того чтобы они не ленились сажают их вместе ( pair-программинг ) или парное программирование. У нас его просто называют - спаривание .
Правило такое что для каждого метода нужно делать тестовую процедуру. И потом все тесты собираются в одном проекте. В результате можно контролировать отъехало что-то или нет в результате изменений.
.Правило такое что для каждого метода нужно делать тестовую процедуру. И потом все тесты собираются в одном проекте. В результате можно контролировать отъехало что-то или нет в результате изменений.
проект достаточно сложный. многопользовательская реалтаймовая среда коллективной разработки и обсуждения всяких чертежей, схем. десяток мегабайт исходников. просто парное программирование это не парное программирование а парное кодирование на самом деле. и, плюс к этому, разный уровень знаний не особо мешает работать в паре.
Понятно что много чего используется для создания проекта,
Так в чем сам проект заключается ? Какие функции он выполняет ?
Неужели в этом проекте не нужны хорошие знания по оптимизации, БД или другим технологиям ?
Так в чем сам проект заключается ? Какие функции он выполняет ?
Неужели в этом проекте не нужны хорошие знания по оптимизации, БД или другим технологиям ?
Ну единственное что в этой методике принял мой организм - unit testы. Хотя учитывая лень разработчиков, которые даже зачастую и комментарии леняться вставлять, врятли они будут следовать этому правилу. Для того чтобы они не ленились сажают их вместе ( pair-программинг ) или парное программирование. У нас его просто называют - спаривание .
Правило такое что для каждого метода нужно делать тестовую процедуру. И потом все тесты собираются в одном проекте. В результате можно контролировать отъехало что-то или нет в результате изменений.
типа а каждый из разработчиков когда заявляет "работает" не должен никак за свои слова отвечать ? типа перед этим оттестить , предоставить результат тестов с описанием тестов ......
ну а потом посмотрев на результаты отчётов не так уж сложно "И потом все тесты собираются в одном проекте" .
а заранее обговаривать условия сотрудничества 2 разработчиков если они сидят в 1 оффисе - смешно . они всегда по нормальному договорится сумеют .а не сумеют - то нах такие нужны , даже если они каждый сам по себе супер разработчик .......
Ну написал например функцию Add(x, y) использовал ее в своей задаче.
Тут дополнительно к этому необходимо написать следующее
function TestProcedure1001 : boolean
begin
result := true;
if Add(1,2) <> 3 then result := false;
if Add(1,1) <> 2 then result := false;
end;
ну и так далее , в результате имеется большое количество процедур тестов и компилишь за день 100 раз ты не свой проект а тестовый который вызывает все процедуры и выясняет все ли успешно сработали.
Про unit test я ничего против не имею , полезно, просто учитывая практику что многим лень написать
Add(x, y) // складывает два числа x и y
то писать unit test еще ленивей.
Тут дополнительно к этому необходимо написать следующее
function TestProcedure1001 : boolean
begin
result := true;
if Add(1,2) <> 3 then result := false;
if Add(1,1) <> 2 then result := false;
end;
ну и так далее , в результате имеется большое количество процедур тестов и компилишь за день 100 раз ты не свой проект а тестовый который вызывает все процедуры и выясняет все ли успешно сработали.
Про unit test я ничего против не имею , полезно, просто учитывая практику что многим лень написать
Add(x, y) // складывает два числа x и y
то писать unit test еще ленивей.
ну это всё явно не для веб-програмирования ..............
и кто мешает вместо вызыва тестового проекта вызвать сразу исходный . он вроде так же покажет всё ли сработало ?
и кто мешает вместо вызыва тестового проекта вызвать сразу исходный . он вроде так же покажет всё ли сработало ?
Просто все моменты сложно протестить за один заход ( смотришь на то что правил в текущий момент) , а тут все наглядно видно что такая-то процедура отъехала.
Однако все равно обнадеживаться на 100% нельзя. Т.к. в тесте невозможно перебрать всевозможные варианты параметров. Как правило останавливаются на граничных вариантах. Ну и если в дальнейшем в какой-то ситуации метод даст сбой, то эту ситуацию также прописывают в тестовую процедуру.
Однако все равно обнадеживаться на 100% нельзя. Т.к. в тесте невозможно перебрать всевозможные варианты параметров. Как правило останавливаются на граничных вариантах. Ну и если в дальнейшем в какой-то ситуации метод даст сбой, то эту ситуацию также прописывают в тестовую процедуру.
Ну абстрактно рассуждать об хр можно очень долго. А вообще, в рамках нашей конторы хр призвано решить всего лишь несколько задач. Перечислю в порядке понижения важности:
1. Обезопасить себя от смерти проекта при уходе программиста, ведущего этот проект.
2. В принципе вытекает из превого. Избежать шантажа по повышению з.п. от ведущих основные проекты программистов, размазав их знания среди некольких человек.
3. Поднять погрязщие в дискуссиях и разнообразных подходах, не дающие однако уже второй год никаких результатов проекты, Specman в частности.
4. Повысить надежность кода написанием тестов, так как тестеры со своими обязанностими в сложных проектах уже давно не справляются.
Все остально детали и маловажно.
з.ы. Для читающих, мы с работаем в одной конторе.
1. Обезопасить себя от смерти проекта при уходе программиста, ведущего этот проект.
2. В принципе вытекает из превого. Избежать шантажа по повышению з.п. от ведущих основные проекты программистов, размазав их знания среди некольких человек.
3. Поднять погрязщие в дискуссиях и разнообразных подходах, не дающие однако уже второй год никаких результатов проекты, Specman в частности.
4. Повысить надежность кода написанием тестов, так как тестеры со своими обязанностими в сложных проектах уже давно не справляются.
Все остально детали и маловажно.
з.ы. Для читающих, мы с работаем в одной конторе.
ну в вебе - оттестил на сколько можно , выложил . а потом оперативно правишь по результатам жалоб от пользователей (если будут) ........
2.Избежать шантажа по повышению з.п. от ведущих основные проекты программистов, размазав их знания среди некольких человек.Только вот ведущие почему-то все это и затеяли , или они чтобы сами себя избавить от соблазна ?
ты что-ли не читаешь, на что отвечаешь?
> Так в чем сам проект заключается ? Какие функции он выполняет ?
>> многопользовательская реалтаймовая среда коллективной разработки и обсуждения всяких чертежей, схем. десяток мегабайт исходников.
> Неужели в этом проекте не нужны хорошие знания по оптимизации, БД или другим технологиям ?
>> просто парное программирование это не парное программирование а парное кодирование на самом деле. и, плюс к этому, разный уровень знаний не особо мешает работать в паре.
> Так в чем сам проект заключается ? Какие функции он выполняет ?
>> многопользовательская реалтаймовая среда коллективной разработки и обсуждения всяких чертежей, схем. десяток мегабайт исходников.
> Неужели в этом проекте не нужны хорошие знания по оптимизации, БД или другим технологиям ?
>> просто парное программирование это не парное программирование а парное кодирование на самом деле. и, плюс к этому, разный уровень знаний не особо мешает работать в паре.
многопользовательская реалтаймовая среда коллективной разработки и обсуждения всяких чертежей, схем. десяток мегабайт исходников.
Это чего за беда такая ?. Типа Autocad c чатом + мегабайт исходников ?
Понятно что можно работать в паре, например когда один рулит а другой сидит и "спит" .
Просто в правилах xp описывается что второй следит и подсказывает или дает советы тому кто в данный момент рулит. Что ты будешь советовать челу который например в данный момент углубился в свою специфику от которой ты далек. Нельзя же знать все.
Если ничего, то какой смысл твоего просиживания рядом, вот что вызывает вопросы.
Это чего за беда такая ?
. Типа Autocad c чатом + мегабайт исходников ?Понятно что можно работать в паре, например когда один рулит а другой сидит и "спит" .
Просто в правилах xp описывается что второй следит и подсказывает или дает советы тому кто в данный момент рулит. Что ты будешь советовать челу который например в данный момент углубился в свою специфику от которой ты далек. Нельзя же знать все.
Если ничего, то какой смысл твоего просиживания рядом, вот что вызывает вопросы.
>Типа Autocad c чатом + мегабайт исходников
да. + шара десктопа + все действия и движения коллективны + и т.д.
не возникает вообщем такой проблемы. все более менее разбираются во всем, потому что работают над одним и тем же, сильно не расходясь. и к тому же обычно один пишет и думает, а другой лишь следит и обсуждает, мысли со стороны кидает. взаимодействие происходит на уровне кодирования.
да. + шара десктопа + все действия и движения коллективны + и т.д.
не возникает вообщем такой проблемы. все более менее разбираются во всем, потому что работают над одним и тем же, сильно не расходясь. и к тому же обычно один пишет и думает, а другой лишь следит и обсуждает, мысли со стороны кидает. взаимодействие происходит на уровне кодирования.
Ну понятно, такое среднее представление у каждого получается. Возможно в некоторых проектах это и допустимо, т.е. где спецификой можно пренебречь, например запихивать данные в базу извлекать можно изучить за час, но вот разобраться со спецификой конкретной БД , уметь затачивать под нее stored procedures , ну и обладать полным представленем возможностей специфичных sql запросов, в рамках XP не получится. А ведь бывают случаи когда это необходимо.
Просто тогда уж сразу вводит XW eXtremeWorking. Т.е. нет ни у кого никакой специализации вообще, т.е. дизайнеры сидят с программерами, также программеры иногда занимаются бухгалтерией совместно с местным бухгалтером.
Зачем высшее образование, когда есть среднее , получается что в xp именно так.
Просто тогда уж сразу вводит XW eXtremeWorking. Т.е. нет ни у кого никакой специализации вообще, т.е. дизайнеры сидят с программерами, также программеры иногда занимаются бухгалтерией совместно с местным бухгалтером.
Зачем высшее образование, когда есть среднее , получается что в xp именно так
.
Ну единственное что в этой методике принял мой организм - unit testы. Хотя учитывая лень разработчиков, которые даже зачастую и комментарии леняться вставлять, врятли они будут следовать этому правилу. Для того чтобы они не ленились сажают их вместе ( pair-программинг ) или парное программирование. У нас его просто называют - спаривание .
Правило такое что для каждого метода нужно делать тестовую процедуру. И потом все тесты собираются в одном проекте. В результате можно контролировать отъехало что-то или нет в результате изменений.
Все эти тесты - самообман. Они не доказывают отсутствия глюков. Лучший тест - анализ кода глазами.
А ведь бывают случаи когда это необходимо.
Бывает, но редко. имхо: сильно специализироваться, например, в конкретной СУБД сегодня слишком рисковано, поскольку что будет и во что она превратиться завтра не известно.
> Все эти тесты - самообман. Они не доказывают отсутствия глюков. Лучший тест - анализ кода глазами.
Он тоже не доказывает отсутствия глюков.
По каким критериям он тогда лучший?
Он тоже не доказывает отсутствия глюков.
По каким критериям он тогда лучший?
Когда глазами - работает AI человека,
а не одна микроизвилина - строчка с тестовыми параметрами.
а не одна микроизвилина - строчка с тестовыми параметрами.
Я просил критерий.
Правильно ли я понял, что в качестве критерия предлагается сложность инструмента, используемого для тестирования?
А зачем он такой нужен?
Правильно ли я понял, что в качестве критерия предлагается сложность инструмента, используемого для тестирования?
А зачем он такой нужен?
Анализ отлавливает неограниченное количество глюков. Количество - вопрос времени. unit test сколько не гоняй - он будет давать все время положительный результат, а глюк будет сидеть рядом.
P.S. Есть кстати не unit testы, а тесты нагружающие систему случайными данными или событиями. Их намного сложнее писать, но толку от них больше.
P.S. Есть кстати не unit testы, а тесты нагружающие систему случайными данными или событиями. Их намного сложнее писать, но толку от них больше.
> Анализ отлавливает неограниченное количество глюков. Количество - вопрос времени.
Выше вроде написали, что XP придумано для ситуаций, когда времени мало.
> unit test сколько не гоняй - он будет давать все время положительный результат, а глюк будет сидеть рядом.
Ну разумное существо едва ли станет утверждать, что эти тесты нужны для поиска всех или почти всех глюков.
Мне представляется, у них другое назначение.
> Есть кстати не unit testы, а тесты нагружающие систему случайными данными или событиями. Их намного сложнее писать, но толку от них больше.
То же ведь, в зависимости от ситуации.
Если некоторая ветка кода получает управление только в вырожденных случаях, она так и останется непроверенной при такой методике.
Выше вроде написали, что XP придумано для ситуаций, когда времени мало.
> unit test сколько не гоняй - он будет давать все время положительный результат, а глюк будет сидеть рядом.
Ну разумное существо едва ли станет утверждать, что эти тесты нужны для поиска всех или почти всех глюков.
Мне представляется, у них другое назначение.
> Есть кстати не unit testы, а тесты нагружающие систему случайными данными или событиями. Их намного сложнее писать, но толку от них больше.
То же ведь, в зависимости от ситуации.
Если некоторая ветка кода получает управление только в вырожденных случаях, она так и останется непроверенной при такой методике.
> unit test сколько не гоняй - он будет давать все время положительный результат, а глюк будет сидеть рядом.Отмазка перед начальством?
Ну разумное существо едва ли станет утверждать, что эти тесты нужны для поиска всех или почти всех глюков.
Мне представляется, у них другое назначение.
О! Я придумал пездатый аналог unit-test: делается прототип беcпилотного такси. Опытный образец отлично объезжает все препятствия на взлетной полосе со скоростью 200 км/ч и паркуется с точностью до одного сантиметра. Прокатишься ли ты на нём по МКАД?
> Отмазка перед начальством?
1. Доказательство, что код работает хоть иногда.
Нужно, прежде чем передавать его другим людям, чтобы они тратили на него своё время,
показать, что ты и сам хоть немного потестировал.
2. regression testing
> Опытный образец отлично объезжает все препятствия на взлетной полосе со скоростью 200 км/ч и паркуется с точностью до одного сантиметра.
Знание этого существенно повысит заинтересованность тех, то будет проводить дальнейшие испытания.
> Прокатишься ли ты на нём по МКАД?
Сначала это будут делать испытатели, и не сразу на МКАД.
Опять же, выше было сказано, что XP не позиционируется для таких проектов.
1. Доказательство, что код работает хоть иногда.
Нужно, прежде чем передавать его другим людям, чтобы они тратили на него своё время,
показать, что ты и сам хоть немного потестировал.
2. regression testing
> Опытный образец отлично объезжает все препятствия на взлетной полосе со скоростью 200 км/ч и паркуется с точностью до одного сантиметра.
Знание этого существенно повысит заинтересованность тех, то будет проводить дальнейшие испытания.
> Прокатишься ли ты на нём по МКАД?
Сначала это будут делать испытатели, и не сразу на МКАД.
Опять же, выше было сказано, что XP не позиционируется для таких проектов.
У Володи опять спорящее настроение?
Почему разработчики Linux не практикуют XP при написании Linux?
Почему разработчики Linux не практикуют XP при написании Linux?
> У Володи опять спорящее настроение?
У Глеба кончились аргументы?
> Почему разработчики Linux не практикуют XP при написании Linux?
Конкретно regression testing некоторые люди/организации проводят.
Находят реальные баги.
Почему не используют другие приёмы XP?
У меня сложилось впечатление, что XP предназначена для относительно небольших проектов,
и небольших команд разработчиков, которые к тому же могут часто собираться вместе.
Может быть, поэтому?
Попробуй прочитать этот тред, здесь ещё много интересного, чего ты, видимо, не заметил.
У Глеба кончились аргументы?
> Почему разработчики Linux не практикуют XP при написании Linux?
Конкретно regression testing некоторые люди/организации проводят.
Находят реальные баги.
Почему не используют другие приёмы XP?
У меня сложилось впечатление, что XP предназначена для относительно небольших проектов,
и небольших команд разработчиков, которые к тому же могут часто собираться вместе.
Может быть, поэтому?
Попробуй прочитать этот тред, здесь ещё много интересного, чего ты, видимо, не заметил.
Конкретно regression testing некоторые люди/организации проводят.Это понятие появилось до XP.
Находят реальные баги.
Почему не используют другие приёмы XP?Какой нибудь драйвер, framework просто кусок кода всегда пишут от 1 до 4 человек. В Linux разве не так? Почему не практикуют XP?
У меня сложилось впечатление, что XP предназначена для относительно небольших проектов,
и небольших команд разработчиков, которые к тому же могут часто собираться вместе.
Может быть, поэтому?
Попробуй прочитать этот тред, здесь ещё много интересного, чего ты, видимо, не заметил.
> Почему не практикуют XP?
А вдруг практикуют?
Особенно те драйвера, которые коммерческими конторами пишутся?
А вообще хакеры - обычно ведь индивидуалисты.
А вдруг практикуют?
Особенно те драйвера, которые коммерческими конторами пишутся?
А вообще хакеры - обычно ведь индивидуалисты.
обычно тесты делают не для всей системы, а для ее небольших составных частей... 
в твоем примере скорее не всю машину бы мучали, а отдельно подрубали к аккумулятору вольтметр и т.д.
в твоем примере скорее не всю машину бы мучали, а отдельно подрубали к аккумулятору вольтметр и т.д.
Угу. Причем, аккумулятор + вольтметр показывает не то напряжение, что аккумулятор под нагрузкой + вольтметр.
А вдруг практикуют?Ты видел когда нибудь продукт написанный в стиле XP?
Не уверен. А это интересно?
Так вот они совсем не похожи по стилю на Linux.
А какой стиль у Linux?
Особенно, у тех драйверов и фреймворков, которые разрабатываются сторонними компаниями,
и не включаются в официальное ядро по причине кривости?
Особенно, у тех драйверов и фреймворков, которые разрабатываются сторонними компаниями,
и не включаются в официальное ядро по причине кривости?
А какой стиль у Linux?Не такой какой у продуктов XP. Долго объяснять. Поработай месяц там, где практикуют XP и сразу поймешь в чём разница.
Особенно, у тех драйверов и фреймворков, которые разрабатываются сторонними компаниями,Так это уже не Linux, не так ли?
и не включаются в официальное ядро по причине кривости?
> Поработай месяц там, где практикуют XP и сразу поймешь в чём разница.
Сам там работай, мне и так неплохо
Это невербализуемые ощущения?
> Так это уже не Linux, не так ли?
Хз, мне это крючкотворство не очень интересно.
Сам там работай, мне и так неплохо
Это невербализуемые ощущения?
> Так это уже не Linux, не так ли?
Хз, мне это крючкотворство не очень интересно.
Сам там работай, мне и так неплохоВербализуемые, но не в двух словах. Моё отношение излилось в треде по имени "экстремально программирование".
Это невербализуемые ощущения?
Имхо, к системному и прикладному предъявляются разные требования, поэтому XP как раз лучше себя чувствует при разработке прикладного ПО, чем системного.
Отличия следующие:
1. Формализуемость. Системное ПО более формализуемое, чем прикладное. Например, понятие "файл" достаточно точно формализуется, формализовать понятие "товар" - очень тяжело.
2. Кол-во понятий и кол-во отношений между понятиями. В системном ПО довольно малое кол-во отдельных понятий (файл, процесс, ядро, драйвер и т.д. прикладное ПО имеет с очень большим кругом понятий (задача, человек, дом, должность и т.д.)
3. Статичность типов. В системном ПО: тип объектов статичен, файл он в Африке файл, тип объекта меняется только в пределах работает/не работает.
В прикладном ПО тип объекта может сильно меняться от контекста, например, человек - это и агент, и ресурс, и мера измерения вместимости автомобиля, и товар и т.д.
4. Меняемость требований. К системному ПО требования мало меняются, возьмем тот же файл, нам как 30 лет назад достаточно было функций: открыть, закрыть, прочитать, записать, так и сейчас.
В прикладном ПО - требования меняются быстро: расширяется круг задач, который можно переложить на компьютер, расширяются знания о прикладной области, меняются люди, законы, взаимоотношения и т.д.
Вывод:
системное ПО - это статичный по сути код, один раз спроектированный и написанный такой код может не меняться довольно длительное время.
прикладное ПО - это динамичный, постоянно меняющийся код.
Поэтому при разработке системного ПО достаточно (может быть даже удобнее) использовать стандартные методики (сначала много думаем и много проектируем, потом много пишем
при разработке прикладного ПО стандартных методик не хватает, (как можно, например, спроектировать класс Человек, если мы еще точно не знаем, в каком контексте и каким образом мы будем с этим человеком работать).
Поэтому приходиться использовать гибкие (agility) методики (например, XP которые позволяют разрабатывать и поддерживать проект в постоянно меняющихся плохоформализованных условиях.
Отличия следующие:
1. Формализуемость. Системное ПО более формализуемое, чем прикладное. Например, понятие "файл" достаточно точно формализуется, формализовать понятие "товар" - очень тяжело.
2. Кол-во понятий и кол-во отношений между понятиями. В системном ПО довольно малое кол-во отдельных понятий (файл, процесс, ядро, драйвер и т.д. прикладное ПО имеет с очень большим кругом понятий (задача, человек, дом, должность и т.д.)
3. Статичность типов. В системном ПО: тип объектов статичен, файл он в Африке файл, тип объекта меняется только в пределах работает/не работает.
В прикладном ПО тип объекта может сильно меняться от контекста, например, человек - это и агент, и ресурс, и мера измерения вместимости автомобиля, и товар и т.д.
4. Меняемость требований. К системному ПО требования мало меняются, возьмем тот же файл, нам как 30 лет назад достаточно было функций: открыть, закрыть, прочитать, записать, так и сейчас.
В прикладном ПО - требования меняются быстро: расширяется круг задач, который можно переложить на компьютер, расширяются знания о прикладной области, меняются люди, законы, взаимоотношения и т.д.
Вывод:
системное ПО - это статичный по сути код, один раз спроектированный и написанный такой код может не меняться довольно длительное время.
прикладное ПО - это динамичный, постоянно меняющийся код.
Поэтому при разработке системного ПО достаточно (может быть даже удобнее) использовать стандартные методики (сначала много думаем и много проектируем, потом много пишем
при разработке прикладного ПО стандартных методик не хватает, (как можно, например, спроектировать класс Человек, если мы еще точно не знаем, в каком контексте и каким образом мы будем с этим человеком работать).
Поэтому приходиться использовать гибкие (agility) методики (например, XP которые позволяют разрабатывать и поддерживать проект в постоянно меняющихся плохоформализованных условиях.
> Системное ПО более формализуемое, чем прикладное.
Хуйня.
> Например, понятие "файл" достаточно точно формализуется.
И что же такое файл?
> Кол-во понятий и кол-во отношений между понятиями.
Хуйня.
> В системном ПО довольно малое кол-во отдельных понятий
По сравнению со всем объёмом прикладного ПО - может быть,
но по сравнению с любым отдельным проектом - вряд ли.
> Статичность типов.
Тут я просто не понял, о чём ты говоришь.
> К системному ПО требования мало меняются,
Хуйня.
> В прикладном ПО - требования меняются быстро: расширяется круг задач, который можно переложить на компьютер
Точно так же увеличиваются и требования к ОС.
Хуйня.
> Например, понятие "файл" достаточно точно формализуется.
И что же такое файл?
> Кол-во понятий и кол-во отношений между понятиями.
Хуйня.
> В системном ПО довольно малое кол-во отдельных понятий
По сравнению со всем объёмом прикладного ПО - может быть,
но по сравнению с любым отдельным проектом - вряд ли.
> Статичность типов.
Тут я просто не понял, о чём ты говоришь.
> К системному ПО требования мало меняются,
Хуйня.
> В прикладном ПО - требования меняются быстро: расширяется круг задач, который можно переложить на компьютер
Точно так же увеличиваются и требования к ОС.
> В прикладном ПО - требования меняются быстро: расширяется круг задач, который можно переложить на компьютерСомнительно как-то. Если бы ядро Линукса меняли с такой скоростью, от него бы рожки да ножки остались.
Точно так же увеличиваются и требования к ОС.
> Если бы ядро Линукса меняли с такой скоростью,
с какой именно?
> от него бы рожки да ножки остались
много ли в версии 2.6 кода, сохранившегося c версии 1.0?
с какой именно?
> от него бы рожки да ножки остались
много ли в версии 2.6 кода, сохранившегося c версии 1.0?
> много ли в версии 2.6 кода, сохранившегося c версии 1.0?
Только не говори мне, что каждые две недели выходит новая версия. 1.0 сколько лет назад было?
Только не говори мне, что каждые две недели выходит новая версия. 1.0 сколько лет назад было?
> Только не говори мне, что каждые две недели выходит новая версия.
Иногда и чаще
> 1.0 сколько лет назад было?
Хорошо, возьмём 2.0 - я его застал, и пользовал по полной программе.
По современным меркам - игрушка.
Иногда и чаще
> 1.0 сколько лет назад было?
Хорошо, возьмём 2.0 - я его застал, и пользовал по полной программе.
По современным меркам - игрушка.
файл - последовательность байтов/битов.
Далее уже можно говорить доступ к последовательности - последовательный или индексный, если доступ на чтение/запись, теряются данные после чтения/не теряются и т.д.
Но главное мы определили:
Теперь если я вижу "файл", то понимаю что там есть последовательность байт, если вижу последовательность байт - то знаю, что эту последовательность можно представить в виде файла.
Так что такое "товар"?
>> В системном ПО довольно малое кол-во отдельных понятий
> По сравнению со всем объёмом прикладного ПО - может быть,
> но по сравнению с любым отдельным проектом - вряд ли.
Давай в качестве примера, возьмем ядро ОС (можно даже добавить GUI) и документооборот магазина, и посчитаем кол-во понятий (замечу, что документооборот, например, должен знать о таких вроде бы не связанных с магазином понятий, как что такое вес, объем, вместимость помещения, прочность упаковки, температура, климат, праздники, беременность, транспорт, командировка и т.д.)
>> Статичность типов.
> Тут я просто не понял, о чём ты говоришь.
В зависимости от контекста, над объектом (понятием) допустимы разные операции.
Над файлом: будь он на диске, pipe-ом, socket-ом, порт-ом и т.д. операции одиннаковые.
Так какие операции допустимы над человеком? Хотя бы примерно, хотя бы в рамках вышеуказанного документооборота небольшого магазина.
ps
справка: тип объекта - это набор допустимых операций над объектом.
> увеличиваются и требования к ОС.
Пример, плиз. Что сильно нового добавилось за последние 30 лет? из крупного только 3D-GUI появился.
имеются ввиду, конечно требования не вида больше, выше, сильнее, а кардинальные.
Пример: добавление системы прав - это кардинальное изменение, т.к. добавление ортогонально уже к имеющимся, поэтому требуется полный пересмотр всей архитектуры и требуется менять каждый объект.
Добавление, например, usb - это локальное изменение, фактически добавился только новый тип драйвера.
Далее уже можно говорить доступ к последовательности - последовательный или индексный, если доступ на чтение/запись, теряются данные после чтения/не теряются и т.д.
Но главное мы определили:
Теперь если я вижу "файл", то понимаю что там есть последовательность байт, если вижу последовательность байт - то знаю, что эту последовательность можно представить в виде файла.
Так что такое "товар"?
>> В системном ПО довольно малое кол-во отдельных понятий
> По сравнению со всем объёмом прикладного ПО - может быть,
> но по сравнению с любым отдельным проектом - вряд ли.
Давай в качестве примера, возьмем ядро ОС (можно даже добавить GUI) и документооборот магазина, и посчитаем кол-во понятий (замечу, что документооборот, например, должен знать о таких вроде бы не связанных с магазином понятий, как что такое вес, объем, вместимость помещения, прочность упаковки, температура, климат, праздники, беременность, транспорт, командировка и т.д.)
>> Статичность типов.
> Тут я просто не понял, о чём ты говоришь.
В зависимости от контекста, над объектом (понятием) допустимы разные операции.
Над файлом: будь он на диске, pipe-ом, socket-ом, порт-ом и т.д. операции одиннаковые.
Так какие операции допустимы над человеком? Хотя бы примерно, хотя бы в рамках вышеуказанного документооборота небольшого магазина.
ps
справка: тип объекта - это набор допустимых операций над объектом.
> увеличиваются и требования к ОС.
Пример, плиз. Что сильно нового добавилось за последние 30 лет? из крупного только 3D-GUI появился.
имеются ввиду, конечно требования не вида больше, выше, сильнее, а кардинальные.
Пример: добавление системы прав - это кардинальное изменение, т.к. добавление ортогонально уже к имеющимся, поэтому требуется полный пересмотр всей архитектуры и требуется менять каждый объект.
Добавление, например, usb - это локальное изменение, фактически добавился только новый тип драйвера.
> много ли в версии 2.6 кода, сохранившегося c версии 1.0?
Если там осталось так мало кода от ранних версий, то что это SCO так долго трясла своими правами на старые участки кода?
Если там осталось так мало кода от ранних версий, то что это SCO так долго трясла своими правами на старые участки кода?
файл - последовательность байтов/битов.вам в /dev/null
> вам в /dev/null
и чем такой файл не подходит под мое определение?
Ps
перед нами частный случай файла: последовательность нулевой длины, доступная на чтение и запись, теряющая данные при записи.
и чем такой файл не подходит под мое определение?
Ps
перед нами частный случай файла: последовательность нулевой длины, доступная на чтение и запись, теряющая данные при записи.
> но по сравнению с любым отдельным проектом - вряд ли.
Могу даже так сказать, системное ПО работает с некоей придуманной человеком формальной детерминированной упрощенной абстракцией (компьютер, железки, каналы связи и т.д.).
Прикладное ПО старается работать с реальным миром во всей его полноте.
Поэтому кол-во понятий в прикладном ПО будем всегда больше, чем в системном.
Могу даже так сказать, системное ПО работает с некоей придуманной человеком формальной детерминированной упрощенной абстракцией (компьютер, железки, каналы связи и т.д.).
Прикладное ПО старается работать с реальным миром во всей его полноте.
Поэтому кол-во понятий в прикладном ПО будем всегда больше, чем в системном.
> файл - последовательность байтов/битов
Тогда, файлы - это всё, с чем работают любые программы, и чем сами они являются.
Толку от такой формализации - никакого.
А вот в каждой конкретной ситуации ключевыми будут особые свойства тех файлов, с которыми работают,
а многие другие сущности, хоть и представляются в виде последовательности байтов,
файлом не назовут.
Никакого различия системного и прикладного ПО этот пример не показывает.
> Давай в качестве примера, возьмем ядро ОС (можно даже добавить GUI) и документооборот магазина Б,
> и посчитаем кол-во понятий.
Затрудняюсь это сделать, понятий получится очень много в обоих случаях.
Давай лучше ты без меня этим займёшься.
> документооборот, например, должен знать о таких вроде бы не связанных с магазином понятий, как ...
А о всех ли этих понятиях знает конкретная программная реализация?
> Над файлом: будь он на диске, pipe-ом, socket-ом, порт-ом и т.д. операции одиннаковые.
Говорят, в Plan 9 это так. В распространённых практически используемых ОС - уже нет.
Но ты определил файл так, что любая сущность в любой программе является файлом.
Соответственно, над файлом возможны все операции, которые возможны над любой сущностью
> Что сильно нового добавилось за последние 30 лет?
Из интересных мне областей.
В области информационной безопасности - непонятно даже как грамотно поставить задачу,
чтобы она имела какое-то практическое значение. Соответственно, есть много разных новых подходов.
30 лет назад это было интересно только военным, которые пытались переносить подходы,
принятые для бумажного документооборота, которые сколь-нибудь применимы только для военных.
В области сетевых технологий - хитрые файрволы: тут идея в том, что на промежуточных узлах можно делать то,
что придумано для оконечных узлов. Различные подходы к обеспечению качества обслуживания - опять же,
только для того чтобы грамотно поставить практически важную задачу, нужны познания из прикладных областей.
Тогда, файлы - это всё, с чем работают любые программы, и чем сами они являются.
Толку от такой формализации - никакого.
А вот в каждой конкретной ситуации ключевыми будут особые свойства тех файлов, с которыми работают,
а многие другие сущности, хоть и представляются в виде последовательности байтов,
файлом не назовут.
Никакого различия системного и прикладного ПО этот пример не показывает.
> Давай в качестве примера, возьмем ядро ОС (можно даже добавить GUI) и документооборот магазина Б,
> и посчитаем кол-во понятий.
Затрудняюсь это сделать, понятий получится очень много в обоих случаях.
Давай лучше ты без меня этим займёшься.
> документооборот, например, должен знать о таких вроде бы не связанных с магазином понятий, как ...
А о всех ли этих понятиях знает конкретная программная реализация?
> Над файлом: будь он на диске, pipe-ом, socket-ом, порт-ом и т.д. операции одиннаковые.
Говорят, в Plan 9 это так. В распространённых практически используемых ОС - уже нет.
Но ты определил файл так, что любая сущность в любой программе является файлом.
Соответственно, над файлом возможны все операции, которые возможны над любой сущностью
> Что сильно нового добавилось за последние 30 лет?
Из интересных мне областей.
В области информационной безопасности - непонятно даже как грамотно поставить задачу,
чтобы она имела какое-то практическое значение. Соответственно, есть много разных новых подходов.
30 лет назад это было интересно только военным, которые пытались переносить подходы,
принятые для бумажного документооборота, которые сколь-нибудь применимы только для военных.
В области сетевых технологий - хитрые файрволы: тут идея в том, что на промежуточных узлах можно делать то,
что придумано для оконечных узлов. Различные подходы к обеспечению качества обслуживания - опять же,
только для того чтобы грамотно поставить практически важную задачу, нужны познания из прикладных областей.
> Прикладное ПО старается работать с реальным миром во всей его полноте.
Каждый отдельный прикладной проект - нет.
А вот ОС работает с любым прикладным проектом, и понятия оттуда перетекают,
получается, что универсальная ОС действительно должна работать с реальным миром во всей его полноте.
Каждый отдельный прикладной проект - нет.
А вот ОС работает с любым прикладным проектом, и понятия оттуда перетекают,
получается, что универсальная ОС действительно должна работать с реальным миром во всей его полноте.
и чем такой файл не подходит под мое определение?null плохой пример. Возьми другой девайс. Он никак не последовательность байт. Ты не можешь сделать на нём lseek назад.
Ps
перед нами частный случай файла: последовательность нулевой длины, доступная на чтение и запись, теряющая данные при записи.
> то это SCO так долго трясла своими правами на старые участки кода?
Хинт: пресс-релизы и "требования" SCO - плохой источник знаний о положении дел с разработкой Linux.
Хинт: пресс-релизы и "требования" SCO - плохой источник знаний о положении дел с разработкой Linux.
> Он никак не последовательность байт. Ты не можешь сделать на нём lseek назад.
Возвражение не понял.
Последовательность - это множество, с введенной операции упорядоченности отдельных элементов в этом множестве.
Какое отношение lseek имеет к последовательности?
Возьмем socket: множество байт есть? - есть, операция упорядоченности есть? есть, это время "прихода" байта в socket.
Так почему это не последовательность?
Возвражение не понял.
Последовательность - это множество, с введенной операции упорядоченности отдельных элементов в этом множестве.
Какое отношение lseek имеет к последовательности?
Возьмем socket: множество байт есть? - есть, операция упорядоченности есть? есть, это время "прихода" байта в socket.
Так почему это не последовательность?
Сетевой пакет - это натурально последовательность байт. Беспесды.
Будем считать его файлом, согласно твоему определению?
Тогда почему выходит так, что операции с ним совсем другие, чем например, с дисковыми файлами?
Будем считать его файлом, согласно твоему определению?
Тогда почему выходит так, что операции с ним совсем другие, чем например, с дисковыми файлами?
Возьмем socket: множество байт есть? - есть, операция упорядоченности есть? есть, это время "прихода" байта в socket.Это не последовательность, это поток.
Так почему это не последовательность?
> Тогда, файлы - это всё, с чем работают любые программы, и чем сами они являются.
> Толку от такой формализации - никакого.
Почему никакого?
Мы полностью формализовали понятие, можно даже доформализовать это понятие до уровня математики, т.е. при написании функций работы с файлом можно будет подключать мощный аппарат математики (доказательство правильности кода, делать оптимизации и т.д.)
При чем формализовать получилось большую часть вызовов для работы с файлами (т.к. read/write основные операции за рамками осталось только открытие файла и настройка файла.
> Но ты определил файл так, что любая сущность в любой программе является файлом.
> Соответственно, над файлом возможны все операции, которые возможны над любой сущностью
Вывод неверных.
Если A, является Б, то это не означает, что над Б возможны те же операции, что и над A.
Человек является физич. телом, и это не означает, что физическое тело, например, умеет мыслить.
> А о всех ли этих понятиях знает конкретная программная реализация?
Переформулирую утверждение:
за единицу времени разработки прикладного ПО, в программу необходимо закладывать больше ортогональных понятий, чем за единицу времени разработки системного ПО.
ps
Важное уточнение: в первую очередь считать, конечно, стоит ортогональные к друг другу понятия, потому что именно они в первую очередь сказываются на кол-ве типов, на кол-ве связей.
> информационной безопасности
имхо, это уже ближе к прикладной области, чем к системной.
ps хотя здесь надо уточнить, что мы понимаем под системным ПО, а что под прикладным....
> Толку от такой формализации - никакого.
Почему никакого?
Мы полностью формализовали понятие, можно даже доформализовать это понятие до уровня математики, т.е. при написании функций работы с файлом можно будет подключать мощный аппарат математики (доказательство правильности кода, делать оптимизации и т.д.)
При чем формализовать получилось большую часть вызовов для работы с файлами (т.к. read/write основные операции за рамками осталось только открытие файла и настройка файла.
> Но ты определил файл так, что любая сущность в любой программе является файлом.
> Соответственно, над файлом возможны все операции, которые возможны над любой сущностью
Вывод неверных.
Если A, является Б, то это не означает, что над Б возможны те же операции, что и над A.
Человек является физич. телом, и это не означает, что физическое тело, например, умеет мыслить.
> А о всех ли этих понятиях знает конкретная программная реализация?
Переформулирую утверждение:
за единицу времени разработки прикладного ПО, в программу необходимо закладывать больше ортогональных понятий, чем за единицу времени разработки системного ПО.
ps
Важное уточнение: в первую очередь считать, конечно, стоит ортогональные к друг другу понятия, потому что именно они в первую очередь сказываются на кол-ве типов, на кол-ве связей.
> информационной безопасности
имхо, это уже ближе к прикладной области, чем к системной.
ps хотя здесь надо уточнить, что мы понимаем под системным ПО, а что под прикладным....
> Это не последовательность, это поток.
Со второй частью соглашусь, с первой частью утверждения (это не последовательность) ты меня пока не убедил.
т.е.
Пока система утверждений выглядит так:
Файл - это последовательность байтов.
Некоторые файлы также являются потоками.
Со второй частью соглашусь, с первой частью утверждения (это не последовательность) ты меня пока не убедил.
т.е.
Пока система утверждений выглядит так:
Файл - это последовательность байтов.
Некоторые файлы также являются потоками.
> Будем считать его файлом, согласно твоему определению?
Да, будем.
> Тогда почему выходит так, что операции с ним совсем другие, чем например, с дисковыми файлами?
Уточнение, они не другие, они дополнительные.
с пакетом, я могу работать и как с файлом:
Да, будем.
> Тогда почему выходит так, что операции с ним совсем другие, чем например, с дисковыми файлами?
Уточнение, они не другие, они дополнительные.
с пакетом, я могу работать и как с файлом:
byte [] packet = GetPacket;
using (Stream stream = new MemoryStream(packet
{
Header header = ReadHeader(stream);
byte[] data = stream.ReadBytes(header.DataLength);
int crc = stream.ReadInt;
ckCrc(data, crc);
}
> с пакетом, я могу работать и как с файлом
можешь
только если посмотришь на TCP/IP стек в любой распространённой ОС,
то увидишь, что там с пакетами работают совсем по-другому
потому что, никакого смысла считать пакет файлом нет для этих задач
всё как ты и говорил, в различных ситуациях - различные операции используются
как же проявляются отличия системного ПО от прикладного?
можешь
только если посмотришь на TCP/IP стек в любой распространённой ОС,
то увидишь, что там с пакетами работают совсем по-другому
потому что, никакого смысла считать пакет файлом нет для этих задач
всё как ты и говорил, в различных ситуациях - различные операции используются
как же проявляются отличия системного ПО от прикладного?
> как же проявляются отличия системного ПО от прикладного?
Переход количества в качество.
ps
В данном случае с пакетом: мы имеем еще одно ортогональное понятие - "документ".
Сетевый пакет - это частный случай документа запакованного в файл.
На стыке "документ <-> файл" у нас появляются такие понятия, как Reader/Writer, Parser/Generator, Packer/Unpacker и т.д.
Переход количества в качество.
ps
В данном случае с пакетом: мы имеем еще одно ортогональное понятие - "документ".
Сетевый пакет - это частный случай документа запакованного в файл.
На стыке "документ <-> файл" у нас появляются такие понятия, как Reader/Writer, Parser/Generator, Packer/Unpacker и т.д.
> Переход количества в качество.
Вот только доводов у тебя нет.
Ты считаешь, что это количество определяется тем, прикладной проект или системный (знания о последних у тебя,
видимо, из пресс-релизов SCO почёрпнуто ). Я думаю, что лучше поискать другие факторы.
Вот только доводов у тебя нет.
Ты считаешь, что это количество определяется тем, прикладной проект или системный (знания о последних у тебя,
видимо, из пресс-релизов SCO почёрпнуто
). Я думаю, что лучше поискать другие факторы.> Тогда, файлы - это всё, с чем работают любые программы, и чем сами они являются.
> Толку от такой формализации - никакого.
Пример полезного использования.
т. к. любая сущность является файлом, а файлы я, например, умею на лету шифровать или сжимать, значит я умею и шифровать, и сжимать любую сущность.
т.е. фактически мы ввели следующие утверждения:
всё, с чем работают любые программы, представимо в виде файлов
файлы можно шифровать и сжимать на лету
далее используя простейший аппарат мат. логики, приходим к выводу:
все, с чем работают любые программы, можно шифровать и сжимать на лету
ps
в очень прикладной области, даже такие простые формализации очень тяжело делаются, т.к. приходится оперировать плохо формализиуемыми понятиями.
> Толку от такой формализации - никакого.
Пример полезного использования.
т. к. любая сущность является файлом, а файлы я, например, умею на лету шифровать или сжимать, значит я умею и шифровать, и сжимать любую сущность.
т.е. фактически мы ввели следующие утверждения:
всё, с чем работают любые программы, представимо в виде файлов
файлы можно шифровать и сжимать на лету
далее используя простейший аппарат мат. логики, приходим к выводу:
все, с чем работают любые программы, можно шифровать и сжимать на лету
ps
в очень прикладной области, даже такие простые формализации очень тяжело делаются, т.к. приходится оперировать плохо формализиуемыми понятиями.
> далее используя простейший аппарат мат. логики, приходим к выводу:
> все, с чем работают любые программы, можно шифровать и сжимать на лету
ну допустим
а вот будет ли это практически применимо?
для ответа на этот вопрос придётся забить на высокоуровневые абстракции и рассмотреть,
что на самом деле происходит в конкретной программе
> все, с чем работают любые программы, можно шифровать и сжимать на лету
ну допустим
а вот будет ли это практически применимо?
для ответа на этот вопрос придётся забить на высокоуровневые абстракции и рассмотреть,
что на самом деле происходит в конкретной программе
Стоп.
Разговор начинался с кода Linux-а и как с кодом Linux-а соотносится XP.
Код Linux-а это в первую очередь код ядра ОС + вспомогательные утилиты, именно в этом контексте я употреблял термин системное ПО.
т.е. когда я говорил, системное ПО - я имел ввиду, разработка ядра ОС.
Ps
Понятно, что термин "системное ПО" можно применить для любого движка, как для СУБД, так и для игрового движка, так 1С - это тоже системное ПО, потому что это все системы для упрощения реализации прикладных задач.
Но еще раз повторяю, в рамках данного треда под системным ПО понималось четко очерченный круг ПО.
Разговор начинался с кода Linux-а и как с кодом Linux-а соотносится XP.
Код Linux-а это в первую очередь код ядра ОС + вспомогательные утилиты, именно в этом контексте я употреблял термин системное ПО.
т.е. когда я говорил, системное ПО - я имел ввиду, разработка ядра ОС.
Ps
Понятно, что термин "системное ПО" можно применить для любого движка, как для СУБД, так и для игрового движка, так 1С - это тоже системное ПО, потому что это все системы для упрощения реализации прикладных задач.
Но еще раз повторяю, в рамках данного треда под системным ПО понималось четко очерченный круг ПО.
> Разговор начинался с кода Linux-а и как с кодом Linux-а соотносится XP.
А в результате ты стал сравнивать прикладное ПО и системное.
Если мы назовём системным ПО ядро ОС и вспомогательные утилиты,
а прикладным ПО - то, к чему хорошо применимо XP, то
1) кучу программ упустим
2) будет немало пересечений: тот же usb-стек и драйвера usb-устройств вполне,
по моему представлению, можно разработать методами XP, и я вполне допускаю,
что какие-то конторы поступают подобным образом
Таким образом, применимость XP не имеет прямого отношения к тому, системное ПО или прикладное.
А в результате ты стал сравнивать прикладное ПО и системное.
Если мы назовём системным ПО ядро ОС и вспомогательные утилиты,
а прикладным ПО - то, к чему хорошо применимо XP, то
1) кучу программ упустим
2) будет немало пересечений: тот же usb-стек и драйвера usb-устройств вполне,
по моему представлению, можно разработать методами XP, и я вполне допускаю,
что какие-то конторы поступают подобным образом
Таким образом, применимость XP не имеет прямого отношения к тому, системное ПО или прикладное.
есть деление всего ПО на прикладное и системное, я согласен с тем, что такое деление нечетко, грубо, противоречиво и т.д.
но для основной массы ПО такое деление имеет право на жизнь.
далее я взял крайние точки: в качестве примера системного ПО я взял ядро ОС, а в качестве примера прикладного ПО - всеми так любимую бухгалтерию (документооборот).
И далее постарался проанализировать почему в одном случае, мы имеем одни методы разработки, а в другом - другие.
т.е. я только говорю, что для одного вида ПО есть одна тенденция, а другого вида ПО - есть другая тенденция, и я не в коем случае не говорю, что у одних только одно, у других только другое.
Опять же небольшая аналогия:
чернобелый спектр тоже можно поделить на черный и белый, это деление будет тоже очень условно, грубо и противоречиво.
Но в то же время, можно также выделить некоторые тенденции:
черное нагревается на солнце, белое отражает свет, белое быстро пачкается, белое лучше заметно и т.д.
И в данном случае, также за скобками оставляется такие вопросы, как "а серое - больше нагревается, или больше отражает свет; черное заметно или незаметно и т.д."
но для основной массы ПО такое деление имеет право на жизнь.
далее я взял крайние точки: в качестве примера системного ПО я взял ядро ОС, а в качестве примера прикладного ПО - всеми так любимую бухгалтерию (документооборот).
И далее постарался проанализировать почему в одном случае, мы имеем одни методы разработки, а в другом - другие.
т.е. я только говорю, что для одного вида ПО есть одна тенденция, а другого вида ПО - есть другая тенденция, и я не в коем случае не говорю, что у одних только одно, у других только другое.
Опять же небольшая аналогия:
чернобелый спектр тоже можно поделить на черный и белый, это деление будет тоже очень условно, грубо и противоречиво.
Но в то же время, можно также выделить некоторые тенденции:
черное нагревается на солнце, белое отражает свет, белое быстро пачкается, белое лучше заметно и т.д.
И в данном случае, также за скобками оставляется такие вопросы, как "а серое - больше нагревается, или больше отражает свет; черное заметно или незаметно и т.д."
> далее я взял крайние точки: в качестве примера системного ПО я взял ядро ОС, а в качестве примера прикладного ПО - всеми так любимую бухгалтерию (документооборот).
> И далее постарался проанализировать почему в одном случае, мы имеем одни методы разработки, а в другом - другие.
> т.е. я только говорю, что для одного вида ПО есть одна тенденция, а другого вида ПО - есть другая тенденция
может и есть тенденция, но причины ты приводишь неубедительные
мне кажется, тут важнее требования:
если нужно небольшой проект сдать в срок, и похуй на всё- то тут, как я понял, XP рулит
а если нужно, чтоб работало (например, нужна формальная верификация, или просто, как в случае линукса,
самому потом этим пользоваться и развивать) - другие методы
> И далее постарался проанализировать почему в одном случае, мы имеем одни методы разработки, а в другом - другие.
> т.е. я только говорю, что для одного вида ПО есть одна тенденция, а другого вида ПО - есть другая тенденция
может и есть тенденция, но причины ты приводишь неубедительные
мне кажется, тут важнее требования:
если нужно небольшой проект сдать в срок, и похуй на всё- то тут, как я понял, XP рулит
а если нужно, чтоб работало (например, нужна формальная верификация, или просто, как в случае линукса,
самому потом этим пользоваться и развивать) - другие методы
> если нужно небольшой проект сдать в срок, и похуй на всё- то тут, как я понял, XP рулит
> а если нужно, чтоб работало (например, нужна формальная верификация, или просто, как в случае линукса,
> самому потом этим пользоваться и развивать) - другие методы
AFAIK, основные среды разработки для Java и Smalltalk делались как раз с использованием XP-методик.
Т.е. вроде и проект немаленький, и для себя делали....
> а если нужно, чтоб работало (например, нужна формальная верификация, или просто, как в случае линукса,
> самому потом этим пользоваться и развивать) - другие методы
AFAIK, основные среды разработки для Java и Smalltalk делались как раз с использованием XP-методик.
Т.е. вроде и проект немаленький, и для себя делали....
> Т.е. вроде и проект немаленький
Т.е. наврали в этом треде про неприменимость XP для таких случаев?
Т.е. наврали в этом треде про неприменимость XP для таких случаев?
Если высказывание было в форме "XP (agility-методики) не подходят для разработки больших проектов", то да - наврали
Правильнее высказывание звучит так: на больших проектах agility-методики (XP) надо совмещать с такими методиками, как RUP и MSF, т.е. Xp - в первую очередь, работает на уровне одной команды, а RUP(MSF) связывает эти команды вместе, и задает генеральный курс.
Замечу, что между RUP(MSF) и XP - много общего, это та же спиральная модель, те же этапы, то же тестирование, та же работа, напрямую с пользователями и т.д.
ps
я бы даже сказал, но это совсем уже ИМХО, что в некоторой степени XP - ориентировано на хороших разработчиков, а стандартные методики (особенно сертификация по ISO) - на средних, т.е. XP старается раскрыть потенциал отдельных хороших разработчиков/программистов, а стандартные стараются не допустить раскрытия "потенциала" плохих программистов/разработчиков.
Т.е. agility-методики стараются сделать хорошо, а стандартные методики стараются сделать неплохо.
Правильнее высказывание звучит так: на больших проектах agility-методики (XP) надо совмещать с такими методиками, как RUP и MSF, т.е. Xp - в первую очередь, работает на уровне одной команды, а RUP(MSF) связывает эти команды вместе, и задает генеральный курс.
Замечу, что между RUP(MSF) и XP - много общего, это та же спиральная модель, те же этапы, то же тестирование, та же работа, напрямую с пользователями и т.д.
ps
я бы даже сказал, но это совсем уже ИМХО, что в некоторой степени XP - ориентировано на хороших разработчиков, а стандартные методики (особенно сертификация по ISO) - на средних, т.е. XP старается раскрыть потенциал отдельных хороших разработчиков/программистов, а стандартные стараются не допустить раскрытия "потенциала" плохих программистов/разработчиков.
Т.е. agility-методики стараются сделать хорошо, а стандартные методики стараются сделать неплохо.
Оставить комментарий
hov77
Кто-нибудь может объяснить как в XP решается проблема специализации программистов. Т.е. один хороший спец по БД, другой монстрит оптимизированные алгоритмы в ASM, третий пишет нейронные сети, четвертый пишет для Web. Так вот как их в пару посадить чтобы смысл был. Т.к. не спец по сути даже посоветовать ничего не сможет другому, а спецу объяснять почему он так сделал, а не так и что это вообще значит - нет времени. Да и не каждый является искуссным преподом способным объяснить за 10 мин все что изучал 10 лет.Помоему XP утопия, по крайней мере Pair-программинг точно. Только в небольших проектах реально, где используемые технологии не выходят за рамки одной специализации.