Здравствуйте, eao197, Вы писали:
E>>>>>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д. AVM>>>>С точки зрения сроков и бюджета — ДА, организация на первом месте. E>>>Так ведь сроки и бюджет для многих проектов -- это и есть самое важное. Не уложился в срок -- проект закрыли. Вышел за рамки бюджета -- проект закрыли. Все, все квалифицированные разработчики могут искать себе другую работу. AVM>>Вспомни постановку задачи, качество превыше всего, время и деньги считались вторичными. Если же говорить только о деньгах, то расклад может получится совсем другим.
E>Так-то оно так... Только вот военные не хотят финансировать проекты, которые в сроки не укладываются. А иметь глючный софт для управления ракетой "воздух-земля" себе же дороже может выйти.
Вот и я о том же, где бы найти того кто за это будет платить.
AVM>>К слову, радиолокационный комплекс — не программная, а аппаратная-программная задача. E>Ага а появление новой незапланированной железячки там сразу дает жизни программистам. По самое нехочу.
Это точно.
Здравствуйте, AndrewVK, Вы писали:
FDS>> А то у нас тут один 3 раза в месяц появляется. Причём два из них — на 30 минут к директору.
AVK>Ну так видимо полезный программист, если его до сих пор не выгнали.
Просто других нет.
AVK>>>Но мы то о надежности.
FDS>>Спутники падают очень часто именно из-за неправильности алгоритмов.
AVK>Еще раз — речь не о надежности спутников, а о надежности софта. Софт, работающий из-за неверных требований != ненадежному софту. Вот только спутники наверное падают не из-за того что программист неверно понял задачу, а из-за ошибок реализации.
Спутниковый софт — это не софт???!!! Жуть.
Ошибки реализации это, в том числе, и ошибки при разработке алгоритмов. Речь идёт не о том, как понята задача, а о том, насколько правильно разработан для её выполнения алгоритм. То есть ошибки не при кодировании, а при разработке до кодирования.
Здравствуйте, AVM, Вы писали:
AVM>Аналитики должны объяснить разработчикам смысл, а тестеры проверить правильно ли разработчики этот смысл поняли.
Да причём здесь аналитики! Кто объснить смысл того, может у меня быть переполнение переменной или нет! Это разработчик должен решать, а тестеры тут могут и не помочь.
Я сейчас дам тебе задачу про бензольное кольцо и какие-нибудь там фракции — попробуй разбирись. Аналитики не обязаны тебе алгоритмы составлять.
FDS>>>>Прошу прощения, не совсем конечно. Консультации нужны, но всё-таки не в таких масштабах. AVK>>>В каких таких? FDS>>Не в масштабах "нянек". Я уже говорил, что неплохо, если программист работает на пределе возможностей. Особенно, если он молодой программист. AVM>IMHO плохо если программист работает на пределе своих возможностей — задалбывает это и интерес пропадает. Плюс нет времени остановиться и спокойно посмотреть, чего же я тут такое наработал.
Это смотря какое начальтсво. У меня всё наоборот. Это по моему к настрою скорее относится. А вот когда чуствуешь себя секретарём-машинисткой — вои это "задалбывает", и очень сильно.
Здравствуйте, FDSC, Вы писали:
AVM>>Аналитики должны объяснить разработчикам смысл, а тестеры проверить правильно ли разработчики этот смысл поняли. FDS>Да причём здесь аналитики! Кто объснить смысл того, может у меня быть переполнение переменной или нет! Это разработчик должен решать, а тестеры тут могут и не помочь. FDS>Я сейчас дам тебе задачу про бензольное кольцо и какие-нибудь там фракции — попробуй разбирись. Аналитики не обязаны тебе алгоритмы составлять.
Аналитики должны объяснить предметную область разработчику и при необходимости помочь/составить необходимые алгоритмы.
Хотя везде наверное по разному.
Здравствуйте, FDSC, Вы писали:
AVK>>Ну так видимо полезный программист, если его до сих пор не выгнали.
FDS>Просто других нет.
На таких условиях . Ну так наверное проблемы как раз в этом.
AVK>>Еще раз — речь не о надежности спутников, а о надежности софта. Софт, работающий из-за неверных требований != ненадежному софту. Вот только спутники наверное падают не из-за того что программист неверно понял задачу, а из-за ошибок реализации.
FDS>Спутниковый софт — это не софт???!!! Жуть.
Где я такое сказал?
FDS>Ошибки реализации это, в том числе, и ошибки при разработке алгоритмов. Речь идёт не о том, как понята задача, а о том, насколько правильно разработан для её выполнения алгоритм. То есть ошибки не при кодировании, а при разработке до кодирования.
Вот только непонятно одно — я ни разу не сталкивался с ошибками из-за неверного понимания, зато ошибок, вызванных кривой архитектурой или неумелой реализаций видел массу.
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, FDSC, Вы писали:
AVM>>>Аналитики должны объяснить разработчикам смысл, а тестеры проверить правильно ли разработчики этот смысл поняли. FDS>>Да причём здесь аналитики! Кто объснить смысл того, может у меня быть переполнение переменной или нет! Это разработчик должен решать, а тестеры тут могут и не помочь. FDS>>Я сейчас дам тебе задачу про бензольное кольцо и какие-нибудь там фракции — попробуй разбирись. Аналитики не обязаны тебе алгоритмы составлять. AVM>Аналитики должны объяснить предметную область разработчику и при необходимости помочь/составить необходимые алгоритмы. AVM>Хотя везде наверное по разному.
AVM>Давай задачку, я оченю сколько она стоить будет
Она в другом отделе в сейфе у начальства, так что не получится, и деньги за неё уже получены. Давно.
Дам другой реальный пример. 23 числа сам исправлял. Станет понятно о чём я говорю.
Функция строит сетевой график по данному графу работы-вершины. То что ниже, одна из частей функций упрощения первоначального сетевого графика. После кода поясняю, что имеется ввиду в данном случае под необходимостью понимания предметной области.
Вот такой код (часть вложенной функции):
// Склеиваем вершины W и PiA, заменяя одной вершиной Wfunction GlueingTops: boolean;
var
h, htmp : integer;
M : TMultitude;
Me : TMultitudeElement;
// Склеивание вершин по единственной выходящей фиктивной дугеprocedure GlueingOutFictive;
var
I, J : integer;
hp : integer;
begin
Me := TMultitudeElement.Create;
// Просматривать множество вершин W
I := 0;
while I < integer(G1[hWa].OutLinkSize) do
begin
h := G1[hWa].OutLinks[I];
// Если только одна выходная дуга и она фиктивнаяif (G1[h].OutLinkSize = 1) then
begin
hp := G1[h].OutLinks[0];
Me.Number1 := hp;
// Проверка на фиктивность дугиif (G1[h].Data.FictiveOut.IsFound(Me, htmp)) then
begin{ hp - вершина из множества Pi. Докажем это:
1. 1. При любом склеивании не появляется новых вершин Pi.
2. Из любой вершины Pi не идёт ни одной фиктиной дуги
(пояснение в п. 2)
3. При удалении фиктивных дуг из графа вершины не удаляются.
4. Удаляются только фиктивные дуги.
5. В каждую вершину W входит по меньшей мере одна реальная работа.
6. В вершины Pi входят только фиктивные дуги
2. Удаление фиктивной дуги со склеиванием, если она единственная
выходящая из вершины
Пояснение к 1.2:
Фиктивные дуги выходят только из вершин W, так как при их
создании рассматриваются только вершины W, а новых фиктивных
дуг не появляется
Т.о. следующая за ней вершина Pi становится вершиной W и
получает по крайней мере одну входящую реальную работу от
вершины W (см. 1). Т.е. создаётся полноценная вершина W.
3. Удаление фиктивной дуги со склеиванием, если она единственная
входящая в вершину
Вершина Pi склеивается с предыдущей вершиной W,
так как в вершины Pi фиктивные дуги могут идти только из
вершин множества W (см. 1 и 2).
При этом в W входит по меньшей мере одна реальная работа,
так как дуги, соотв. реальным работам никогда не удаляются
Т.е. данная процедура не может дать вершину с одной
входящей фиктивной дугой
}// Все ссылки, исходящие из hp перевести на h
M := TMultitude.Create;
M.AddUnique(hp);
for J := 0 to G1[hp].OutLinkSize - 1 do
begin
htmp := G1[hp].OutLinks[J];
G1.AddReference(h, htmp);
// Удалить информацию о входящей ссылке с hp и внести - о ссылке c h
// При этом ссылка - обязательно реальная работа (см. 1.2.) и
// множества htmp.FictiveIn и h.FictiveOut не рассматриваются
G1[htmp].Data.Mul4.Sub(M);
G1[htmp].Data.Mul4.AddUnique(h);
end;
G1[h].Data.Duration.Union(G1[hp].Data.Duration);
if G1[hp].Data.FictiveOut.Count <> 0 then
raise Exception.Create(err22);
// Все ссылки на hp перевести на hfor J := 0 to G1[hp].Data.Mul4.Count - 1 do
begin// htmp - предыдущая вершина
htmp := G1[hp].Data.Mul4[J].Number1;
// Если ссылка не с h (т.е. не удаляемая ссылка) - добавить еёif htmp = h then continue;
G1.AddReference(htmp, h);
// см. 1.6. (Входящие дуги - фиктивные)
G1[htmp].Data.FictiveOut.Sub(M);
G1[htmp].Data.FictiveOut.AddUnique(h);
// Обработка Duration не ведётся, так как у врешины множества Pi
// не может быть входных работ, отличных от фиктивныхend;
// Обновить информацию о входящих ссылках в вершину h
M.Clear;
M.AddUnique(h);
G1[h].Data.Mul4 .Union(G1[hp].Data.Mul4);
G1[h].Data.FictiveIn.Union(G1[hp].Data.FictiveIn);
// Удалить информацию о ссылке от h, так как её больше нет
// (Эта информация прила из предыдущих 2-х объединений)
// Из Duration информацию удалять не надо,
// так как удаляемая дуга - фиктивная
G1[h].Data.Mul4 .Sub(M);
G1[h].Data.FictiveIn.Sub(M);
M.Destroy;
// Объединить множества PiA и Wa в одноfor J := 0 to G1[hp].Data.Mul1.Count - 1 do
G1[hp].Data.Mul1[J].Number2 := 1;
G1[h].Data.Mul3.Union(G1[hp].Data.Mul1);
// Удалить вершину hp
hp := G1.FindNodeOnHandle(hp);
G1.DeleteLinkObject(hp);
Result := true;
end;
end;
inc(I);
end;
Me.Destroy;
end;
Вот, там доказательство, прямо в коде. Смысл его в том, что если мы обнаружили фиктивную дугу, выходящую из вершины математического класса W, то эта дуга входит в вершину мат. класса Pi.
Тут два вопроса, по поводу предметной области.
1. Кто это доказательство должен был делать? Аналитики?
В общем, делал его программист. Причём доказательство неправильное. А я сам его после исправлял, причём там надо понимать, что такое сетевой график и фиктивные работы, например. Без понимания алгоритма, а значит, и предметной области не обойтись.
По поводу утверждения "аналитики должны объяснить предметную область программисту".
В общем, а кто должен был объяснить предметную область аналитикам? Они ведь немного другими вопросами занимаются. Они то же не математики.
2. При проектировании функции была допущена ошибка. Кто виноват?
Там есть всякие множества, с названиями типа FictiveOut. Они очень затрудняют программирование. Их могло бы и не быть, если бы программист использовал возможности базового компонента (моего компонента) на все 100%. Но знал как правильно построить структуру данных только я, а когда остальные догадались, было уже поздно.
Это, опять же, программист не понимал, как правильно использовать мой компонент. То есть тоже в какой-то степени не понимал особенностей предметной области. Хотя правильный способ использования компонента для меня был очевиден.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот только непонятно одно — я ни разу не сталкивался с ошибками из-за неверного понимания, зато ошибок, вызванных кривой архитектурой или неумелой реализаций видел массу.
Пример такой ошибки в соседней ветке этого обсуждения здесь
Здравствуйте, AndrewVK, Вы писали:
FDS>>Ошибки реализации это, в том числе, и ошибки при разработке алгоритмов. Речь идёт не о том, как понята задача, а о том, насколько правильно разработан для её выполнения алгоритм. То есть ошибки не при кодировании, а при разработке до кодирования.
AVK>Вот только непонятно одно — я ни разу не сталкивался с ошибками из-за неверного понимания,
Такое часто встречается, если разные компоненты пишутся разными организациями. Просто когда разработчики работают в одной команде и постоянно общаются, то такие проблемы действительно редкость, т.к. картина мира внутри одной команды приблизительно одна и та же. А вот когда что-то делается по формальным спецификациям, то вылазят вещи, которые для разработчиков спецификации были настолько очевидны, что их даже в спецификацию не включили. А другая команда про это ни сном ни духом.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FDSC, Вы писали:
FDS>Она в другом отделе в сейфе у начальства, так что не получится, и деньги за неё уже получены. Давно.
Эх жаль...
FDS>Дам другой реальный пример. 23 числа сам исправлял. Станет понятно о чём я говорю.
FDS>Функция строит сетевой график по данному графу работы-вершины. То что ниже, одна из частей функций упрощения первоначального сетевого графика. После кода поясняю, что имеется ввиду в данном случае под необходимостью понимания предметной области.
Честно говоря ничего не понял
— почему не понял предметную область понятно — я с ней никогда не сталкивался
Код тоже вводит в некоторое замешательство:
— Делфи запрещает давать осмысленные имена переменным ? Или где-то есть описание алгоритма, которое использует такие обозначения для переменных?
— Процедура вложена в функцию?
FDS>Вот такой код (часть вложенной функции):
...<SKIP>...
FDS>Вот, там доказательство, прямо в коде. Смысл его в том, что если мы обнаружили фиктивную дугу, выходящую из вершины математического класса W, то эта дуга входит в вершину мат. класса Pi.
Где и чего ????
FDS>Тут два вопроса, по поводу предметной области.
FDS>1. Кто это доказательство должен был делать? Аналитики?
FDS>В общем, делал его программист. Причём доказательство неправильное. А я сам его после исправлял, причём там надо понимать, что такое сетевой график и фиктивные работы, например. Без понимания алгоритма, а значит, и предметной области не обойтись.
Факт, без знания предметной области сложно разобраться что тут к чему.
FDS>По поводу утверждения "аналитики должны объяснить предметную область программисту". FDS>В общем, а кто должен был объяснить предметную область аналитикам? Они ведь немного другими вопросами занимаются. Они то же не математики.
А какими вопросами занимаются аналитики, и почему аналитик не может быть математиком?
FDS>2. При проектировании функции была допущена ошибка. Кто виноват? FDS>Там есть всякие множества, с названиями типа FictiveOut. Они очень затрудняют программирование. Их могло бы и не быть, если бы программист использовал возможности базового компонента (моего компонента) на все 100%. Но знал как правильно построить структуру данных только я, а когда остальные догадались, было уже поздно.
А подсказать им раньше не получилось?
FDS>Это, опять же, программист не понимал, как правильно использовать мой компонент. То есть тоже в какой-то степени не понимал особенностей предметной области. Хотя правильный способ использования компонента для меня был очевиден.
Дело в качестве документации на компоненту?
Re[7]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, eao197, Вы писали:
E>Но, если вначале упоминался Ариан 5, то значит речь можно вести и о проектах гораздо большего маштаба. В которых есть несколько десятков, а то и сотен команд и командочек. И в которых в общей сложности заняты сотни и тысячи разработчиков. В таких условиях квалификация отдельной команды вообще не должна быть критическим фактором -- важны только высокие средние показатели.
E>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.
Ты когда-нибудь сам видел такие проекты? Не конторы в которых тысячи команд, а именно проекты, в которых участвует обозначенное тобой количество разработчиков?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, AVM, Вы писали:
AVM>>>Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный? AVK>>При прочих равных однозначно двухзвенка. AVM>- меньше фигур,проще играть ее просто проще протестировать.
Она сама по себе проще. Меньше лэйеров, меньше взаимосвязей.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Но, если вначале упоминался Ариан 5, то значит речь можно вести и о проектах гораздо большего маштаба. В которых есть несколько десятков, а то и сотен команд и командочек. И в которых в общей сложности заняты сотни и тысячи разработчиков. В таких условиях квалификация отдельной команды вообще не должна быть критическим фактором -- важны только высокие средние показатели.
IT>Ты когда-нибудь сам видел такие проекты? Не конторы в которых тысячи команд, а именно проекты, в которых участвует обозначенное тобой количество разработчиков?
Думаю, что мне даже довелось в таком проекте поучаствовать в 2000-м году (с поправкой на состояние российской оборонки и белорусской экономики, из-за которого команды из одного-трех человек делали объемы работ, на которые в советское время потребовалось бы в два-три раза больше народа). Тогда только наш отдел в КБ взаимодействовал с тремя организациями (две из которых делали железяки, а третья была работодателем и приемщиком). И в нашем отделе, фактически, было три направления работ (т.е. полусамостоятельных полукоманд): программирование спецвычислителей, коммуникации и протоколы, диспетчеризация и расчеты. И лично я взаимодействовал с людьми из нескольких разных отделов главного нашего работодателя. А ведь на этой же теме работали и другие отделы нашего КБ. И все это было еще в самом начале разработки, когда никакой интеграции, за исключением эпизодических случаев, все создавалось, тестировалось и сдавалось в автономе.
Правда на гражданке я с такими проектами не сталкивался. К счастью, наверное.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Я просто не согласился с тезисом "неквалифицированный руководитель — это самое фиговое что может быть" — причем здесь мои личные качества?
VD>Да, уж какие личные качества? У нас начальник просто дурак, а я весь проект тащу.
Влад, я ты уверен, что начальник дурак — если в итоге весь проект на тебе — а лавры и бонусы — ему?
ПК>>Дабы моя точка зрения была яснее:
ПК>>1) Самое фиговое, что может быть это вовсе не слабая квалификация руководителя, а слабая квалификация всей команды, включая менеджера.
VD>Зашибись. Всей команды! А кто в этом виноват? Ну, не как коллективно вся команда?
+1 Согласен.
ПК>>2) В зависимости от характера рабочего процесса роль квалификации менеджера очень сильно может меняться; соответственно, при некоторых рабочих процессах слабая квалификация менеджера может вполне успешно компенсироваться квалификацией и слаженностью работы остальной команды с большим успехом, чем слабая квалификация ключевых инженеров.
VD>Не может ни чем компенсироваться некомпетентность руководства. Оная приведет к тому, что будет угроблена и команда, и проект.
+1 Согласен.
ПК>>3) Наконец, уже отвечая на последовавшие комментарии, добавлю, что кажущаяся некоторым привлекательной возможность "занять место руководителя" или взгляд на происходящее как "можно подумать, что это они его нанимают, а не наоборот" далеко не так уж универсальны, как может показаться некоторым. Бывает, что и команда нанимает себе менеджера, и что инженер имеет более высокий статус в компании, чем менеджер проекта, в котором инженер участвует, и что у инженера нет никакого желания уходить "в менеджеры" и т.п. Все зависит от характера рабочего процесса, принятого в той или иной фирме.
VD>Желание, не желание. Все что делает команда определяется руководством. Если же команда наняла тупого руководителя и не подчиняется ему, то это просто идиотизм. Зачем было тратить деньги?
Вот на этот счёт есть разные мнения — например "заведите козла"
Re[7]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Трурль, Вы писали:
Т>>Наверное, зависит от проекта. Для Беломор-канала достаточно было просто грамотного менеджмента. Для запуска спутника — нет.
VD>Для любого проекта низкое качество руководства — это приговор. Так что тут разницы нет. А то что чем сложнее задача, тем больше отвественности на руководстве с этим я согласен.
+1 Вопрос лишь в том, как низкоквалифицированный менеджер устроит проекту фаталити — просто завалит или позже за бесценок кому-нибудь продаст.
Re[6]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, eao197, Вы писали:
E>>>Но, если вначале упоминался Ариан 5, то значит речь можно вести и о проектах гораздо большего маштаба. В которых есть несколько десятков, а то и сотен команд и командочек. И в которых в общей сложности заняты сотни и тысячи разработчиков. В таких условиях квалификация отдельной команды вообще не должна быть критическим фактором -- важны только высокие средние показатели.
IT>>Ты когда-нибудь сам видел такие проекты? Не конторы в которых тысячи команд, а именно проекты, в которых участвует обозначенное тобой количество разработчиков?
E>Думаю, что мне даже довелось в таком проекте поучаствовать в 2000-м году (с поправкой на состояние российской оборонки и белорусской экономики, из-за которого команды из одного-трех человек делали объемы работ, на которые в советское время потребовалось бы в два-три раза больше народа). Тогда только наш отдел в КБ взаимодействовал с тремя организациями (две из которых делали железяки, а третья была работодателем и приемщиком). И в нашем отделе, фактически, было три направления работ (т.е. полусамостоятельных полукоманд): программирование спецвычислителей, коммуникации и протоколы, диспетчеризация и расчеты. И лично я взаимодействовал с людьми из нескольких разных отделов главного нашего работодателя. А ведь на этой же теме работали и другие отделы нашего КБ. И все это было еще в самом начале разработки, когда никакой интеграции, за исключением эпизодических случаев, все создавалось, тестировалось и сдавалось в автономе.
Это ещё не тысячи человек. Я то же над проектом примерно такого объёма — там было главное — далеко не организация взаимодействия. Хотя это то же очень хромало.
Здравствуйте, eao197, Вы писали:
AVK>>Вот только непонятно одно — я ни разу не сталкивался с ошибками из-за неверного понимания,
E>Такое часто встречается, если разные компоненты пишутся разными организациями. Просто когда разработчики работают в одной команде и постоянно общаются, то такие проблемы действительно редкость, т.к. картина мира внутри одной команды приблизительно одна и та же. А вот когда что-то делается по формальным спецификациям, то вылазят вещи, которые для разработчиков спецификации были настолько очевидны, что их даже в спецификацию не включили. А другая команда про это ни сном ни духом.
Однако, возвращаясь в начало, этоникоим образом не свидетельствует о том что слабые познания программиста в предметной области приведут к тому, что он будет писать менее надежный код.
Здравствуйте, AVM, Вы писали:
AVM>Честно говоря ничего не понял AVM>- почему не понял предметную область понятно — я с ней никогда не сталкивался AVM>Код тоже вводит в некоторое замешательство: AVM>- Делфи запрещает давать осмысленные имена переменным ? Или где-то есть описание алгоритма, которое использует такие обозначения для переменных?
А где там не осмысленные имена? hWa и hp и т.п. — это имена вершин (типа хэндлов) соответствующих множеств — W и Pi — это есть в алгоритме (который тут не влез).
Множество M, конечно, можно было бы обозвать MulSubstract, но это мало что добавило бы к пониманию (так же, как и MulHelper).
Имеется, наверное, ввиду mul4 — да, это жуть.
Но к сожалению более осмысленных имён, чем mul, не получилось по архитектуре. Дело в том, что в системе используется один программный тип вершин и два математических. По этому эти mul обозначены исключительно номерами. Можно было, конечно, сделать и лучше, но ...
Вообще, нумерованные Mul — очень грубые ошибки, можно было сделать две структуры в одной (типа UNION в C++) и проименовать их лучше — и было бы гораздо более читабельно.
Кстати, какие есть ещё замечания по технике исполнения кода? Очень интересно.
AVM>- Процедура вложена в функцию?
Многократно. То что я привёл вложено в огромную функцию на 700 с лишним строк.
Там по коду дальше ещё одна аналогичная функция. В Delphi так можно.
Можно было сделать класс, который только и содержал бы эти функции практически без данных, но я не думаю, что получилось бы понятнее. А сваливать в одну область видимости класса лишний десяток функций, которые далее нигде не нужны...
FDS>>Вот, там доказательство, прямо в коде. Смысл его в том, что если мы обнаружили фиктивную дугу, выходящую из вершины математического класса W, то эта дуга входит в вершину мат. класса Pi.
AVM>Где и чего ????
Я выделил жирно комментарии-доказательство.
FDS>>Тут два вопроса, по поводу предметной области.
FDS>>По поводу утверждения "аналитики должны объяснить предметную область программисту". FDS>>В общем, а кто должен был объяснить предметную область аналитикам? Они ведь немного другими вопросами занимаются. Они то же не математики. AVM>А какими вопросами занимаются аналитики, и почему аналитик не может быть математиком?
Лично моё представление об аналитике:
1. Работает с заказчиком и выясняет необходимые требования к ПО
2. Работает с тестерами и программистами, что бы они поняли правильно эти требования
3. Формализует бизнес-процессы заказчиков, для уточнения ТЗ, составления подходящих вариантов использования и т.п.
Проще говоря — аналитик производит анализ ТЗ заказчика и не разбирается в её реализации, если только очень поверхностно.
На самом деле тут нужен консультант по математической части: программист-математик.
FDS>>2. При проектировании функции была допущена ошибка. Кто виноват. FDS>> Но знал как правильно построить структуру данных только я, а когда остальные догадались, было уже поздно. AVM>А подсказать им раньше не получилось?
Не получилось. Кто ж знал, что они очевидные вещи сами не поймут. Как было просто в графе данных G1 (мой класс) представить вершинами не только вершины мат. гарфа, но и его дуги.
FDS>>Это, опять же, программист не понимал, как правильно использовать мой компонент. То есть тоже в какой-то степени не понимал особенностей предметной области. Хотя правильный способ использования компонента для меня был очевиден. AVM>Дело в качестве документации на компоненту?
Документации вообще не было, а то что было, было не у тех, кому нужно. Потом, они использовали не мой визуальный компонент, а только пару невизуальных классов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Однако, возвращаясь в начало, этоникоим образом не свидетельствует о том что слабые познания программиста в предметной области приведут к тому, что он будет писать менее надежный код.
Уже привели, посмотри ниже или выше, где я давал ссылку.
Re[7]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, FDSC, Вы писали:
E>>Думаю, что мне даже довелось в таком проекте поучаствовать в 2000-м году (с поправкой на состояние российской оборонки и белорусской экономики, из-за которого команды из одного-трех человек делали объемы работ, на которые в советское время потребовалось бы в два-три раза больше народа). Тогда только наш отдел в КБ взаимодействовал с тремя организациями (две из которых делали железяки, а третья была работодателем и приемщиком). И в нашем отделе, фактически, было три направления работ (т.е. полусамостоятельных полукоманд): программирование спецвычислителей, коммуникации и протоколы, диспетчеризация и расчеты. И лично я взаимодействовал с людьми из нескольких разных отделов главного нашего работодателя. А ведь на этой же теме работали и другие отделы нашего КБ. И все это было еще в самом начале разработки, когда никакой интеграции, за исключением эпизодических случаев, все создавалось, тестировалось и сдавалось в автономе.
FDS>Это ещё не тысячи человек. Я то же над проектом примерно такого объёма — там было главное — далеко не организация взаимодействия. Хотя это то же очень хромало.
Ключевые моменты я выделил жирным. К тому же я видел даже далеко не всю верхушку айсберга, т.к. был всего лишь винтиком в одном из шпунктиков. А ведь наши смежники имели своих смежников, у которых были свои и т.д. И это только гражданские, а ведь были еще и военные.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если нам не помогут, то мы тоже никого не пощадим.
Согласен. 
