Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, AVM, Вы писали:
AVM>>>Честно говоря ничего не понял AVM>>>- почему не понял предметную область понятно — я с ней никогда не сталкивался AVM>>>Код тоже вводит в некоторое замешательство: AVM>>>- Делфи запрещает давать осмысленные имена переменным ? Или где-то есть описание алгоритма, которое использует такие обозначения для переменных?
FDS>>А где там не осмысленные имена? hWa и hp и т.п. — это имена вершин (типа хэндлов) соответствующих множеств — W и Pi — это есть в алгоритме (который тут не влез). AVM>Ни в жизнь бы не догадался.
FDS>>Имеется, наверное, ввиду mul4 — да, это жуть. FDS>>Но к сожалению более осмысленных имён, чем mul, не получилось по архитектуре. Дело в том, что в системе используется один программный тип вершин и два математических. По этому эти mul обозначены исключительно номерами. Можно было, конечно, сделать и лучше, но ... AVM>Как архитектура связана с именами переменных?
AVM>>>- Процедура вложена в функцию? FDS>>Многократно. То что я привёл вложено в огромную функцию на 700 с лишним строк. FDS>>Там по коду дальше ещё одна аналогичная функция. В Delphi так можно. AVM>IMHO классы все таки лучше. 700 строк — я боюсь таких функций, они напоминают мне regexp размером 1Кб, который встречались мне давным-давно
FDS>>>>По поводу утверждения "аналитики должны объяснить предметную область программисту". FDS>>>>В общем, а кто должен был объяснить предметную область аналитикам? Они ведь немного другими вопросами занимаются. Они то же не математики. AVM>>>А какими вопросами занимаются аналитики, и почему аналитик не может быть математиком?
FDS>>Лично моё представление об аналитике: FDS>>1. Работает с заказчиком и выясняет необходимые требования к ПО FDS>>2. Работает с тестерами и программистами, что бы они поняли правильно эти требования AVM>Это системные аналитики и ИМНО никто не запрещает им (впрочем как и разработчикам) заниматься математикой и алгоритмами. У меня была практика работы в паре с аналитиком при разработке одной не совсем тривиальной расчетной задачи. Как показала практика это очень эффективно — парное программирование с аналитиком. Задача решается быстрее, да и время неплохо проводиться.
FDS>>3. Формализует бизнес-процессы заказчиков, для уточнения ТЗ, составления подходящих вариантов использования и т.п. AVM>Это уже скорее бизнес-аналитики.
FDS>>Проще говоря — аналитик производит анализ ТЗ заказчика и не разбирается в её реализации, если только очень поверхностно. FDS>>На самом деле тут нужен консультант по математической части: программист-математик. AVM>А аналитик-математик подойдет?
FDS>>>>2. При проектировании функции была допущена ошибка. Кто виноват. FDS>>>> Но знал как правильно построить структуру данных только я, а когда остальные догадались, было уже поздно. AVM>>>А подсказать им раньше не получилось? FDS>>Не получилось. Кто ж знал, что они очевидные вещи сами не поймут. Как было просто в графе данных G1 (мой класс) представить вершинами не только вершины мат. гарфа, но и его дуги. FDS>>>>Это, опять же, программист не понимал, как правильно использовать мой компонент. То есть тоже в какой-то степени не понимал особенностей предметной области. Хотя правильный способ использования компонента для меня был очевиден. AVM>>>Дело в качестве документации на компоненту? FDS>>Документации вообще не было, а то что было, было не у тех, кому нужно. Потом, они использовали не мой визуальный компонент, а только пару невизуальных классов. AVM>Документирование и коммуникации очень способствуют пониманию очевидных вещей и сильно экономят время
Здравствуйте, FDSC, Вы не писали. Теперь пишу.
FDS>>>Имеется, наверное, ввиду mul4 — да, это жуть. FDS>>>Но к сожалению более осмысленных имён, чем mul, не получилось по архитектуре. Дело в том, что в системе используется один программный тип вершин и два математических. По этому эти mul обозначены исключительно номерами. Можно было, конечно, сделать и лучше, но ... AVM>>Как архитектура связана с именами переменных?
Просто. Два прог. класса на два реальных или один программный на два реальных. Впрочем, тут скорее ошибка программирования
AVM>>>>- Процедура вложена в функцию? FDS>>>Многократно. То что я привёл вложено в огромную функцию на 700 с лишним строк. FDS>>>Там по коду дальше ещё одна аналогичная функция. В Delphi так можно. AVM>>IMHO классы все таки лучше. 700 строк — я боюсь таких функций, они напоминают мне regexp размером 1Кб, который встречались мне давным-давно
Ну. Это же десяток вложенных функций общим объёмом более 700 срок. Чего тут боятся?
FDS>>>Лично моё представление об аналитике: FDS>>>1. Работает с заказчиком и выясняет необходимые требования к ПО FDS>>>2. Работает с тестерами и программистами, что бы они поняли правильно эти требования AVM>>Это системные аналитики и ИМНО никто не запрещает им (впрочем как и разработчикам) заниматься математикой и алгоритмами. У меня была практика работы в паре с аналитиком при разработке одной не совсем тривиальной расчетной задачи. Как показала практика это очень эффективно — парное программирование с аналитиком. Задача решается быстрее, да и время неплохо проводиться.
Сипматичная была аналитик?
По сути, согласен. Только я бы назвал не аналитиком, а консультантом.
FDS>>>3. Формализует бизнес-процессы заказчиков, для уточнения ТЗ, составления подходящих вариантов использования и т.п. AVM>>Это уже скорее бизнес-аналитики.
У нас нет различий. Видимо действительно сильное различие в зависимости от фирмы.
FDS>>>Проще говоря — аналитик производит анализ ТЗ заказчика и не разбирается в её реализации, если только очень поверхностно. FDS>>>На самом деле тут нужен консультант по математической части: программист-математик. AVM>>А аналитик-математик подойдет?
Тут всё-таки лучше программист. И потом, программист-математик — это специальность, а аналитик-математик? Где его искать?
AVM>>Документирование и коммуникации очень способствуют пониманию очевидных вещей и сильно экономят время
Ага. Знать бы ещё заранее как твой компонент будут использовать и что его вообще будет кто-то использовать.
Кстати, по поводу коммуникаций, как сразу тихо становилось в отделе, когда молодые сотрудники в рабочее время уходили пить пиво.
Re[9]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, AVM, Вы писали:
IT>>>И у вас у всех был один source control? AVM>>Там один нельзя — гостайна однако
FDS>Слушай, ты когда-нибудь работал с гостайной? Особенно с простым ДСП.
FYI Гостайна и ДСП лченть разные вещи. Их различие ниболее наглядно проиллюстрировано в УК РФ. FDS>Дело обстоит примерно так: вижу секретные материалы: "Можно отфоткать?" — "конечно, только надпись секретно потом сотри!"
Т.е. на бумагах стоял гриф? Если ты серьезно, то я "восхищен" твоей безбашенностью.
Здравствуйте, eao197, Вы писали:
E>Если возвратиться в начало, то мне это кажется очевидным. Если программист плохо разбирается в математике, то он может просто не понять, что (a-b) может дать ноль и что такую проверку нужно будет сделать перед тем, как писать c=d/(a-b). <skip>
Это скорее уж арифметика. В общем мне твоя идея понятна и я ее в некотором смысле разделяю.
При всех прочих равнях, большой плюс если программист знает предметную область, но в первую очередь он должен знать программирование.
Re[9]: Влияние языка и процесса разработки на качество ПО
FDSC wrote:
> IT>>И у вас у всех был один source control? > AVM>Там один нельзя — гостайна однако > Слушай, ты когда-нибудь работал с гостайной? Особенно с простым ДСП. > Дело обстоит примерно так: вижу секретные материалы: "Можно > отфоткать?" — "конечно, только надпись секретно потом сотри!"
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, eao197, Вы писали:
E>>Если возвратиться в начало, то мне это кажется очевидным. Если программист плохо разбирается в математике, то он может просто не понять, что (a-b) может дать ноль и что такую проверку нужно будет сделать перед тем, как писать c=d/(a-b). <skip> AVM>Это скорее уж арифметика. В общем мне твоя идея понятна и я ее в некотором смысле разделяю. AVM>При всех прочих равнях, большой плюс если программист знает предметную область, но в первую очередь он должен знать программирование.
Да, это было бы желательно, чтобы программировали именно те, кого учат программированию. Здесь я с тобой согласен, хотя бывают и другие мнения, которые так же в чем-то правы. Например: Re: В продолжение темы обучения, ПТУ, ВУЗов и т.п.
Здравствуйте, eao197, Вы писали:
E>К тому же вокруг "знать программирование", при желании, можно поднять просто офигительный флейм. Но лично у меня желания нет.
Аналогично
Re[10]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, AVM, Вы писали:
IT>>>>И у вас у всех был один source control? AVM>>>Там один нельзя — гостайна однако
FDS>>Слушай, ты когда-нибудь работал с гостайной? Особенно с простым ДСП. AVM>FYI Гостайна и ДСП лченть разные вещи. Их различие ниболее наглядно проиллюстрировано в УК РФ. FDS>>Дело обстоит примерно так: вижу секретные материалы: "Можно отфоткать?" — "конечно, только надпись секретно потом сотри!" AVM>Т.е. на бумагах стоял гриф? Если ты серьезно, то я "восхищен" твоей безбашенностью.
Серёъзно.
Re[10]: Влияние языка и процесса разработки на качество ПО
Здравствуйте, Cyberax, Вы писали:
C>Первому отделу тоже нужны раскрытые преступления.
По моему, первый отдел выясняет факт разглашения или несанкционир. использования в других отделах, а так же источник информации. А раскрывают дальше...
Re[9]: Влияние языка и процесса разработки на качество ПО
В обещм, да. Янус кстати, родился в осуждении. Мы с АВК отдахали в Гелинджике и я предложил сделать офлайн-клиента. Оказалось, что АВК тоже подумывал о чем-то подобном (тогда мы все сидели на диалапе). Обсудили... пришли к выоду, что дотнет это как раз тот инструмент который позволит максимально облегчить решение задачи (ну, и интересно было тогда дотнет только что родился).
После приезда в Москву АВК сел и сделал первый прототип. Пользоваться им было нельзя, но это была та кость которую потом обрасла мясом.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
AF> В последнее время активно обсуждается темя зависимости количества ошибок в зависимости от языка на котором ведётся разработка. Эта темя всплывала здесь
. Так же эта тема с завидной регулярностью появляется и в вечных темах "X vs Y" и "зачем нужен goto?". AF> Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен. Забавно, но об этом с дивной регулярностью вспоминают во время споров, когда исчерпываются аргументы в защиту того или иного языка. AF> Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО. AF> Тема, конечно, не оригинальна, и что на эту тему исписаны тонны бумаги (и выработаны стандарты, такие как ISO9000, ANSI или ГОСТ), но хотелось бы выяснить мнение участников форума, особенно со своим практическим опытом и своей точкой зрения на это. AF> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО: AF> — Организация процесса разработки AF> — Организация процесса тестирования AF> — Архитектура ПО AF> — Чёткие определения интерфейсов, включая диапазоны входных и выходных данных AF> — Язык программирования AF> — Стиль кодирования AF> — Используемые модули и библиотеки AF> — Анализ программы на предмет критических мест (нехватка памяти, переполнение стека) AF> — Аккуратное слежение за выделением и освобождением памяти AF> Список далеко не полон, есть множество ньюансов и деталей. Было бы интересно обсудить, что вы думаете по этому поводу.
Мне нравится Ваша идея — рассмотреть как можно больше факторов, влияющих на качество ПО, и оценить их приоритеты.
Мне также жаль, что "мегафлейм вокруг Оберона" приобрел такой скандальный характер. (По крайней мере, у меня такой цели никогда не было.)
Все же сделаю одно замечание "методологического" характера.
При перечислении многих факторов может возникнуть желание рассматривать их как независимые.
Например, совершенно отделить "язык программирования" от "архитектуры ПО" и "аккуратного слежения за выделением и освобождением памяти".
Возможно, это правильно по отношению к каким-нибудь "проходным" языкам.
Но некоторые языки выражают определенную "философию программирования" и оказывают большое влияние на другие факторы качества ПО. А значит — и на весь процесс разработки в целом.
К таким "философским" языкам относятся, в частности, Си++, Оберон и еще ряд языков (достаточно взглянуть, как Vlad2 сражается за любимый C#).
Так как сторонники разных "философских языков" исповедуют разную "философию программирования", то им очень трудно найти "нейтральную территорию", чтобы просто мирно побеседовать. (Я рад, когда это все-таки случается.)
Вот и ведется на разных форумах бесконечная "война кошек с собаками".
Достаточно одного неаккуратного замечания, чтобы вспыхнул яростный "флейм".
Вот возьмем один из Ваших пунктов: AF> — Аккуратное слежение за выделением и освобождением памяти.
Совершенно невинный пункт. Но у меня уже готово сорваться ехидное: "И Вы собираетесь организовать это аккуратное слежение на Си++?! Не лучше ли взять за основу НАДЕЖНЫЙ язык, уступающий Си++ в производительности всего несколько процентов!? (В случае Оберона.)"
Тут, конечно, не выдержали бы нервы у кого-нибудь из фанатов Си++: "Целых НЕСКОЛЬКО процентов?!!! Да тебя утопить за это следовало бы!!! А Оберон — в печку, к черту, в тартарары!"
Короче говоря, мне нравится Ваша идея. К тому же очень хочется найти ту "нейтральную территорию", на которой можно просто обмениваться опытом и любезностями.
Но боюсь, что, изгнанные "в дверь", "философские языки" пролезут "в окно". Например, в оценке приоритетов разных факторов качества ПО.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
