Здравствуйте, FDSC, Вы писали:

FDS>Я имею ввиду тот настрой, который не улетучивается. Не интузиазм, а настрой типа: "не халтурить" (упрощённо говоря).

Такого настроя в природе не бывает. Обстоятельства и интересы у человека периодически меняются. Ну ты сам подумай — какой настрой может быть если, к примеру, у тебя родился ребенок.

AVK>>Ерунда. Приемы, используемые для создания надежного кода никакого отношения к тематике не имеют.

FDS>Дело не в самих приёмах, а в правильности их применения. Если разработчики ничего не понимают в предметной области, они могут просто пропустить смысловую ошибку в алгоритме или неправильно оценить свойства управляемых процессов, а потом долго удивляться.

Неверное понимание задачи это совсем другое. К надежности кода это отношения не имеет.

AVK>>А если таких отрывков 100. А если 1000?

FDS>Всё верно. Я считаю, что качественный, и в том числе, надёжный код писать экономически не выгодно. Если конечно, этот процесс каким-либо образом не автоматизировать с помощью супер умных программ.

Ну и? Вывод то из этого какой?

AVK>>А если такого формального алгоритма не существует?

FDS>Плохо. Тогда ког заранее не качественный.

Однако нет. Существует масса приемов и методик, в том числе и эвристических, позволяющих и в такой ситуации создавать более-менее качественный код. Вобщем максимализм тут не катит.

FDS>Однако обычно за очень сложные проекты новичков и не сажают.

Это если есть из чего выбрать. Однако современный порядок дел обстоит так, что проекты становятся все сложнее и сложнее и потребность в неквалифицированной рабочей силе падает.

FDS>Иногда самокритика действенней, чем критика других. Если конечно, хватает квалификации себя покритиковать.

А если нет?

AVK>>В каких таких?

FDS>Не в масштабах "нянек".

Именно что в масштабах нянек, особенно на первые полгода работы на серьезном проекте. Ты недооцениваешь количество косяков и ошибок, которые может наплодить неопытный человек.

FDS>Я уже говорил, что неплохо, если программист работает на пределе возможностей. Особенно, если он молодой программист.

Это горю не поможет.

FDS>Вообще, там где я работал, очень мало внимания уделяется тому какой код пишет молодой специалист.

И это очень плохо.

FDS> Фактически действительно надо самому догадываться о том как ты его написал.

В результате ты варишся в своем котле и узнаешь что сурово накосячил только когда случайно кто то наткнется на твой код.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, FDSC, Вы писали:

FDS>>Я имею ввиду тот настрой, который не улетучивается. Не интузиазм, а настрой типа: "не халтурить" (упрощённо говоря).

AVK>Такого настроя в природе не бывает. Обстоятельства и интересы у человека периодически меняются. Ну ты сам подумай — какой настрой может быть если, к примеру, у тебя родился ребенок.

Сбежать нафиг на работу и сидеть там подольше

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, FDSC, Вы писали:

FDS>>Я имею ввиду тот настрой, который не улетучивается. Не интузиазм, а настрой типа: "не халтурить" (упрощённо говоря).

AVK>Такого настроя в природе не бывает. Обстоятельства и интересы у человека периодически меняются. Ну ты сам подумай — какой настрой может быть если, к примеру, у тебя родился ребенок.

Не каждый же день ребёнок рождается. А вот от начальника, например, много зависит. Или там, от симпатичной секретарши...
Шучу. В общем, какая может быть работа, если у тебя ребёнок родился?

AVK>>>Ерунда. Приемы, используемые для создания надежного кода никакого отношения к тематике не имеют.

FDS>>Дело не в самих приёмах, а в правильности их применения. Если разработчики ничего не понимают в предметной области, они могут просто пропустить смысловую ошибку в алгоритме или неправильно оценить свойства управляемых процессов, а потом долго удивляться.

AVK>Неверное понимание задачи это совсем другое. К надежности кода это отношения не имеет.

Это имеет отношение к правильности алгоритмов.

AVK>>>А если таких отрывков 100. А если 1000?

FDS>>Всё верно. Я считаю, что качественный, и в том числе, надёжный код писать экономически не выгодно. Если конечно, этот процесс каким-либо образом не автоматизировать с помощью супер умных программ.

AVK>Ну и? Вывод то из этого какой?

Чем дальше, тем хуже.

AVK>>>А если такого формального алгоритма не существует?

FDS>>Плохо. Тогда ког заранее не качественный.

AVK>Однако нет. Существует масса приемов и методик, в том числе и эвристических, позволяющих и в такой ситуации создавать более-менее качественный код. Вобщем максимализм тут не катит.

Может подскажешь что-нибудь конкретное. Ничего не знаю

FDS>>Однако обычно за очень сложные проекты новичков и не сажают.

AVK>Это если есть из чего выбрать. Однако современный порядок дел обстоит так, что проекты становятся все сложнее и сложнее и потребность в неквалифицированной рабочей силе падает.

Ну, в общем да. Но сложность тоже бывает разной.

AVK>Именно что в масштабах нянек, особенно на первые полгода работы на серьезном проекте. Ты недооцениваешь количество косяков и ошибок, которые может наплодить неопытный человек.

Очень даже дооценивают — у меня все программы срлошь в ошибках. Причём я когда пишу заранее знаю где они, какие и как от них избавится.


FDS>>Я уже говорил, что неплохо, если программист работает на пределе возможностей. Особенно, если он молодой программист.

AVK>Это горю не поможет.

Это поможет более вдумчиво подходить к делу.

FDS>>Вообще, там где я работал, очень мало внимания уделяется тому какой код пишет молодой специалист.

AVK>И это очень плохо.

Согласен на все 1000000%.

FDS>> Фактически действительно надо самому догадываться о том как ты его написал.

AVK>В результате ты варишся в своем котле и узнаешь что сурово накосячил только когда случайно кто то наткнется на твой код.

Точно.

Здравствуйте, eao197, Вы писали:

AF>> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:

E>Я выделил эти два слова, чтобы чуть-чуть перевести акценты. Спор, который развивается после дополнения AVM о необходимости учета <i>квалификации проектной команды</i>

Автор: AVM
Дата: 25.06.05

, имхо, скатывается в сторону обсуждения условий успешности проекта. А успешность далеко не всегда подразумевает качество и надежность. Иногда успешность -- это дешевизна, иногда -- скорость выхода продукта на рынок, иногда -- высокое качество (например, точность математических расчетов), иногда -- высочайшая надежность (например, для систем жизнеобеспечения). Зачастую для достижения успеха какие-то качества приносятся в жертву.
Ок, давай переформулируем задачу так: какие вещи надо учесть, чтобы получить продукт с высоким качеством в разумные сроки и с разумной стоимостью. Превышение сроков и бюджета плохо, но не критично. Качество на первом месте.

1) Квалифицированная команда
Кроме обычных распространенных ролей, в команду в обязательном порядке должен входить configuration engineer, который должен следить за конфигурациями продукта, test environment, development environment, проводить сборку и развертывание билдов, etc.
Так же я считаю, что дизайн и разработку должны делать одни и те же люди. Коммуникации в команде должны быть налажены на максимально возможном уровне.
Архитектор проекта должен следить за соблюдением того, что Брукс назвал "концептуальное единство".
IMHO допустима некоторая кривость дизайна, если эта кривость одинаковая во всех местах.

2) Process
Управление требованиями. В обязательном порядке traceability требований до разумно низкого уровня. Это сравнительно дорого, но при разработке качественного софта без этого никак.
Наличие различных Guidelines: Design Guidelines, Development Guidelines, Testing Guidelines and etc. Гайдлайны должны описывать общие принципы и содержать примеры best practices. Guidelines должны "настраиваться" для каждого проекта. Все члены проектной команды должны их использовать в обязательном порядке. Все отступления от Guidelines должны специально оговариваться.

Review. Review требований для выяснения их полноты и непротиворечивости. Review дизайна, review кода для выяснения проблемных мест. Review тест-кейсов на на полноту покрытия функциональности тестами. Review проектного schedule на предмет его реальности. И тд. Высокая квалификация членов проектной команды очень важна для проведения review. Очень полезно если разработчик просмотрит тест-кейсы и требования и выскажет свои рекомендайции по тестированию тех или иных мест, если архитектор на фазе inception прикинет архитектуру, поделиться ей с разработчиками и они выскажут свои соображения по project estimation, если тестеры просмотрят требования и прикинут как они будут их тестировать, и тд.

Тестирование, тестирование и еще раз тестирование. Функциональное, модульное (в контейнере и в не его), нагрузочное, performance.... Тестировать должно проводиться в зафиксированно тестовой среде. Тестироваться должен конкретный нумерованный билд. Все найденные баги (проблемные места) должны учитываться в bug tracking system для последующего анализа.
"У тестера должно быть сердце разработчика .... в баночке на столе" — IMHO стеб, который может перерастать в опасное глумление. На этапе тестирования задача разработчиков подсказать тестерам потенциально проблемные места, которые должны быть протестированны с особой тщательностью. Тестеры должны помнить что их задача не опустить разработчиков, а сделать совместно с ними качественный продукт.

Отдельной строкой должен быть предусмотрен Unit Testing. Разработчики пишут unit-test, тестеры готовят input and expected values для нетривиальных случаев. Покрытие кода тестами должно быть максимально разумным.
IMHO вполне реально полность протестировать юнит тестами логику работы всего backend и DAL, и нет ничего гиморнее чем писать юнит тесты для presentation. Обычно тестеры протестируют presentation быстрее и лучше.

При тестировании очень полезно использовать эмутяторы нагрузки и профайлеры. Тут опять же не обойтись без командной работы тестер+разработчик (опять коммуникации!!!).

3) Development environment
В обязательном порядке должна включать систему bug tracking, которая позволяет создавать различного вида отчеты. Единый репозитарий кода и документации на который желательно навесить софт для валидации кода и снятия метрик.
Процедура сборки и развертывания продукта на test environment должна быть автоматизированной.
Процедуру traceability требований желательно автоматизировать.

4) Delivery
Поставляться должен только протестированный билд. Вносить изменения в протестированный билд можно, но это уже породит новый не тестированный билд, который ОБЯЗАТЕЛЬНО должен быть протестирован перед поставкой. Даже если меняется одна строчка в протестированном коде, мы автоматически получаем еще один раунд тестирования.

Ранжировать эти факторы я специально не хочу. Пусть каждый сам определит их важность.

В заключении добавлю, что бессмысленно вести флейм о том кто важнее на проекте. На разных фазах нагрузка на разные проектные роли различна. Самое важное — это наличие единой команды, которая стремиться к единой цели. IMHO только такие команды способны создавать качественное ПО.

PS: про некотрые очевидные вещи, такие как формальные методики оценки, плотность распределения багов, документирование, прототипирование, code rules, и тд я здесь не пишу. Они должны быть описаны в соответствующих guidelines и настроены для нужд конкретного проекта.

ЗЫЫ: Эх где бы найти заказчика, который все это оплатит

Здравствуйте, AVM, Вы писали:

AVM>Здравствуйте, eao197, Вы писали:

AF>>> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:

E>>Я выделил эти два слова, чтобы чуть-чуть перевести акценты. Спор, который развивается после дополнения AVM о необходимости учета <i>квалификации проектной команды</i>

Автор: AVM
Дата: 25.06.05

, имхо, скатывается в сторону обсуждения условий успешности проекта. А успешность далеко не всегда подразумевает качество и надежность. Иногда успешность -- это дешевизна, иногда -- скорость выхода продукта на рынок, иногда -- высокое качество (например, точность математических расчетов), иногда -- высочайшая надежность (например, для систем жизнеобеспечения). Зачастую для достижения успеха какие-то качества приносятся в жертву.
AVM>Ок, давай переформулируем задачу так: какие вещи надо учесть, чтобы получить продукт с высоким качеством в разумные сроки и с разумной стоимостью. Превышение сроков и бюджета плохо, но не критично. Качество на первом месте.

AVM, все это интересно и для небольшой команды/небольшого проекта, вероятно, это вполне нормальный сценарий работы.

Но, если вначале упоминался Ариан 5, то значит речь можно вести и о проектах гораздо большего маштаба. В которых есть несколько десятков, а то и сотен команд и командочек. И в которых в общей сложности заняты сотни и тысячи разработчиков. В таких условиях квалификация отдельной команды вообще не должна быть критическим фактором -- важны только высокие средние показатели.

Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.

Так же, имхо, очень важна архитектура ПО. Ведь промах на начальном этапе проектирования в таких масштабах может стоить очень и очень дорого.

Ну и процесс тестирования всех компонентов и их интеграция так же должны быть в центре внимания. Как именно тестирование организовано у конкретного разработчика -- это дело этого разработчика. Но вот заставить все это работать вместе, работать правильно и предоставить способ в этом убедиться -- вот это задача. Если с ней не справиться, то получится, как с Beagle 2, когда один модуль считал дистанцию в метрах, а другой -- в футах.

Поэтому первые два списка факторов у меня упорядочены с рачетом на "большие" проекты (естественно, что я упорядочил исходя из своего багажа знаний). А вот третий список больше расчитан на небольшие команды/проекты и, имхо, он не сильно отличается от описанного тобой.

Здравствуйте, eao197, Вы писали:

E>AVM, все это интересно и для небольшой команды/небольшого проекта, вероятно, это вполне нормальный сценарий работы.
Возможно, я не спорю, но думаю что эти же факторы будут играть очень важную роль и в больших проектах.

E>Но, если вначале упоминался Ариан 5, то значит речь можно вести и о проектах гораздо большего маштаба. В которых есть несколько десятков, а то и сотен команд и командочек. И в которых в общей сложности заняты сотни и тысячи разработчиков. В таких условиях квалификация отдельной команды вообще не должна быть критическим фактором -- важны только высокие средние показатели.
В свое время читал несколько интересных статей о TQM. В них популярно объяснялось почему качество машины определяется качеством изготовления болтов. Если токарь начинает делать бракованые болты, то о 100% качестве машины говорить не приходится.

E>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.
С точки зрения сроков и бюджета — ДА, организация на первом месте.

E>Так же, имхо, очень важна архитектура ПО. Ведь промах на начальном этапе проектирования в таких масштабах может стоить очень и очень дорого.
Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный?
IMHO тот который лучше протестирован.

E>Ну и процесс тестирования всех компонентов и их интеграция так же должны быть в центре внимания. Как именно тестирование организовано у конкретного разработчика -- это дело этого разработчика. Но вот заставить все это работать вместе, работать правильно и предоставить способ в этом убедиться -- вот это задача. Если с ней не справиться, то получится, как с Beagle 2, когда один модуль считал дистанцию в метрах, а другой -- в футах.
Без тестирования никуда, полностью согласен. В том числе и интеграционного.
А вот по поводу метров<->футов. Это очень не удобно и увеличивает затраты, но если считается правильно и там где надо переводиться, почему это должно снизить качество? Просто возрастает сложность тестирования.

E>Поэтому первые два списка факторов у меня упорядочены с рачетом на "большие" проекты (естественно, что я упорядочил исходя из своего багажа знаний). А вот третий список больше расчитан на небольшие команды/проекты и, имхо, он не сильно отличается от описанного тобой.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, AndrewVK, Вы писали:

AVK>>Здравствуйте, FDSC, Вы писали:

FDS>>>Я имею ввиду тот настрой, который не улетучивается. Не интузиазм, а настрой типа: "не халтурить" (упрощённо говоря).

AVK>>Такого настроя в природе не бывает. Обстоятельства и интересы у человека периодически меняются. Ну ты сам подумай — какой настрой может быть если, к примеру, у тебя родился ребенок.

E>Сбежать нафиг на работу и сидеть там подольше
...или выспаться там побольше

Здравствуйте, AVM, Вы писали:

AVM>Здравствуйте, eao197, Вы писали:

E>>AVM, все это интересно и для небольшой команды/небольшого проекта, вероятно, это вполне нормальный сценарий работы.
AVM>Возможно, я не спорю, но думаю что эти же факторы будут играть очень важную роль и в больших проектах.

А я и не говорил, что они будут играть маленькую роль. Просто в таких проектах будут более важные роли, такие как организация и интеграция.

E>>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.
AVM>С точки зрения сроков и бюджета — ДА, организация на первом месте.

Так ведь сроки и бюджет для многих проектов -- это и есть самое важное. Не уложился в срок -- проект закрыли. Вышел за рамки бюджета -- проект закрыли. Все, все квалифицированные разработчики могут искать себе другую работу.

E>>Так же, имхо, очень важна архитектура ПО. Ведь промах на начальном этапе проектирования в таких масштабах может стоить очень и очень дорого.
AVM>Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный?
AVM>IMHO тот который лучше протестирован.

Тут я имел ввиду немного другие вещи. Вот скажем создают радиолокационный комплекс. Выбирают математические модели и пр., и пр. Чего-то моделируют и решают: считать будем вот так. Вот эта фигня будет излучать сигнал такой-то мощности с такой-то частотой. Вот эта фигня будет принимать сигнал. Потоки данных будут такие-то. Обрабатывать их сначала будет вот этот шкаф, затем вот этот, а потом вот этот. Все понеслась, нужно делать. И потом оказывается, что шкаф #2 не успевает обрабатывать все данные с заданым темпом, т.к. он еще занят нормализацие сигнала. Значит в него нужно вставить еще один специализированный процессор для нормализации. Так, а кто у нас этим будет заниматься? И кто ему будет данные передавать? А забирать? И все, стройная архитектура которая, к тому же должна была быть специфицирована и согласована со всеми субподрядчиками, перекраивается, переспецифицируется и дводится до сведения всех исполнителей. Хорошо, если доводится, и хорошо, если всех

E>>Ну и процесс тестирования всех компонентов и их интеграция так же должны быть в центре внимания. Как именно тестирование организовано у конкретного разработчика -- это дело этого разработчика. Но вот заставить все это работать вместе, работать правильно и предоставить способ в этом убедиться -- вот это задача. Если с ней не справиться, то получится, как с Beagle 2, когда один модуль считал дистанцию в метрах, а другой -- в футах.
AVM>Без тестирования никуда, полностью согласен. В том числе и интеграционного.
AVM>А вот по поводу метров<->футов. Это очень не удобно и увеличивает затраты, но если считается правильно и там где надо переводиться, почему это должно снизить качество? Просто возрастает сложность тестирования.

Да возрастает. И у кого-то может возникнуть желание избежать лишних сложностей. Поэтому должна быть вышестоящая инстанция, которая бъет по голове тех, кто на интеграционное тестирование предоставляет некачественные компоненты.

E>>Поэтому первые два списка факторов у меня упорядочены с рачетом на "большие" проекты (естественно, что я упорядочил исходя из своего багажа знаний). А вот третий список больше расчитан на небольшие команды/проекты и, имхо, он не сильно отличается от описанного тобой.
AVM>

Здравствуйте, AVM, Вы писали:

AVM>Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный?

При прочих равных однозначно двухзвенка.

Здравствуйте, FDSC, Вы писали:

FDS>Не каждый же день ребёнок рождается. А вот от начальника, например, много зависит. Или там, от симпатичной секретарши...

Нет, ну понятно что я утрирую. Смысл — показать что человеку свойственно со временем менять свои цели и интересы в зависимости от обстоятельств или каких то внутренних причин.

AVK>>Неверное понимание задачи это совсем другое. К надежности кода это отношения не имеет.

FDS>Это имеет отношение к правильности алгоритмов.

Но мы то о надежности.

AVK>>Однако нет. Существует масса приемов и методик, в том числе и эвристических, позволяющих и в такой ситуации создавать более-менее качественный код. Вобщем максимализм тут не катит.

FDS>Может подскажешь что-нибудь конкретное. Ничего не знаю

Про конкретное нужно рассказывать долго и в контексте конкретного проекта.

FDS>Очень даже дооценивают — у меня все программы срлошь в ошибках.

А вот теперь представь, что еще столько же ошибок и архитектурных просчетов ты просто не видишь. Катастрофическая ситуация, надо сказать.

FDS> Причём я когда пишу заранее знаю где они, какие и как от них избавится.

Еще раз — главная проблема не в допускаемых ошиках, а в том что при недостатке опыта ты просто часть ошибок, особенно в области архитектуры, не в состоянии обнаружить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AVM, Вы писали:

AVM>>Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный?
AVK>При прочих равных однозначно двухзвенка.
— меньше фигур,проще играть ее просто проще протестировать.

Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, ну понятно что я утрирую. Смысл — показать что человеку свойственно со временем менять свои цели и интересы в зависимости от обстоятельств или каких то внутренних причин.

Я имеют ввиду то, что нужно поддерживать такие интересы у программистов. А то у нас тут один 3 раза в месяц появляется. Причём два из них — на 30 минут к директору.

AVK>>>Неверное понимание задачи это совсем другое. К надежности кода это отношения не имеет.

FDS>>Это имеет отношение к правильности алгоритмов.

AVK>Но мы то о надежности.

Спутники падают очень часто именно из-за неправильности алгоритмов. Я имею ввиду, в том числе, и неправильные оценки диапазона измеряемых значений, точности методов и т.п.
Это тоже надёжность. По моему. Я не прав?

AVK>>>Однако нет. Существует масса приемов и методик, в том числе и эвристических, позволяющих и в такой ситуации создавать более-менее качественный код. Вобщем максимализм тут не катит.

FDS>>Очень даже дооценивают — у меня все программы срлошь в ошибках.

AVK>А вот теперь представь, что еще столько же ошибок и архитектурных просчетов ты просто не видишь. Катастрофическая ситуация, надо сказать.

Чёрт, там столько не поместится!

FDS>> Причём я когда пишу заранее знаю где они, какие и как от них избавится.

AVK>Еще раз — главная проблема не в допускаемых ошиках, а в том что при недостатке опыта ты просто часть ошибок, особенно в области архитектуры, не в состоянии обнаружить.

Кстати. А есть ли возможность получить такой опыт именно самостоятельно, в процессе самообучения?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Я просто не согласился с тезисом "неквалифицированный руководитель — это самое фиговое что может быть" — причем здесь мои личные качества?

Да, уж какие личные качества? У нас начальник просто дурак, а я весь проект тащу.

ПК>Дабы моя точка зрения была яснее:

ПК>1) Самое фиговое, что может быть это вовсе не слабая квалификация руководителя, а слабая квалификация всей команды, включая менеджера.

Зашибись. Всей команды! А кто в этом виноват? Ну, не как коллективно вся команда?

ПК>2) В зависимости от характера рабочего процесса роль квалификации менеджера очень сильно может меняться; соответственно, при некоторых рабочих процессах слабая квалификация менеджера может вполне успешно компенсироваться квалификацией и слаженностью работы остальной команды с большим успехом, чем слабая квалификация ключевых инженеров.

Не может ни чем компенсироваться некомпетентность руководства. Оная приведет к тому, что будет угроблена и команда, и проект.

ПК>3) Наконец, уже отвечая на последовавшие комментарии, добавлю, что кажущаяся некоторым привлекательной возможность "занять место руководителя" или взгляд на происходящее как "можно подумать, что это они его нанимают, а не наоборот" далеко не так уж универсальны, как может показаться некоторым. Бывает, что и команда нанимает себе менеджера, и что инженер имеет более высокий статус в компании, чем менеджер проекта, в котором инженер участвует, и что у инженера нет никакого желания уходить "в менеджеры" и т.п. Все зависит от характера рабочего процесса, принятого в той или иной фирме.

Желание, не желание. Все что делает команда определяется руководством. Если же команда наняла тупого руководителя и не подчиняется ему, то это просто идиотизм. Зачем было тратить деньги?

Здравствуйте, Трурль, Вы писали:

Т>Наверное, зависит от проекта. Для Беломор-канала достаточно было просто грамотного менеджмента. Для запуска спутника — нет.

Для любого проекта низкое качество руководства — это приговор. Так что тут разницы нет. А то что чем сложнее задача, тем больше отвественности на руководстве с этим я согласен.

Здравствуйте, EXO, Вы писали:

VD>>Но от квалифицированного руководителя не будет толку если у него бездарная команда проектировщиков или программистов.

EXO>Пардон, а разве подбор команды это не квалификация руководителя?

В идеале она самая. Но бывает, что подбором занимаются "проффесионалы". Ну, в области кадров. Умные анкеты... психологические тесты... А руководитель обязан жить с тем что дали.

К тому же случаются ошибки. Хотя грамотный руководитель должен во время уметь выгнать нерадивого сотрудника.

Здравствуйте, FDSC, Вы писали:

FDS>Я имеют ввиду то, что нужно поддерживать такие интересы у программистов.

Кто бы спорил

FDS> А то у нас тут один 3 раза в месяц появляется. Причём два из них — на 30 минут к директору.

Ну так видимо полезный программист, если его до сих пор не выгнали.

AVK>>Но мы то о надежности.

FDS>Спутники падают очень часто именно из-за неправильности алгоритмов.

Еще раз — речь не о надежности спутников, а о надежности софта. Софт, работающий из-за неверных требований != ненадежному софту. Вот только спутники наверное падают не из-за того что программист неверно понял задачу, а из-за ошибок реализации.

FDS>Кстати. А есть ли возможность получить такой опыт именно самостоятельно, в процессе самообучения?

Наверное можно, но займет это в разы больше времени и денег, нежели обучение при наличии опытного наставника. К примеру не возможно самостоятельно почувствовать все прелести очень больших систем, не написав такую систему.

Здравствуйте, eao197, Вы писали:

E>А я и не говорил, что они будут играть маленькую роль. Просто в таких проектах будут более важные роли, такие как организация и интеграция.
Я бы сказал что в больших проектах организация и интеграция должны быть добавлены к этим ролям. А вот будут ли они превалировать над ними, большой вопрос. Если организацию и интеграцию поставить над всем остальным, то легко получить "военно-морскую лошадь" — голова в яблоках, а зад в мыле.

E>>>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.
AVM>>С точки зрения сроков и бюджета — ДА, организация на первом месте.
E>Так ведь сроки и бюджет для многих проектов -- это и есть самое важное. Не уложился в срок -- проект закрыли. Вышел за рамки бюджета -- проект закрыли. Все, все квалифицированные разработчики могут искать себе другую работу.
Вспомни постановку задачи, качество превыше всего, время и деньги считались вторичными. Если же говорить только о деньгах, то расклад может получится совсем другим.

E>>>Так же, имхо, очень важна архитектура ПО. Ведь промах на начальном этапе проектирования в таких масштабах может стоить очень и очень дорого.
AVM>>Я не склонен преуменьшать роль архитектуры, но поясни мне пожалуйста какой продукт надежнее клиент-серверный или многозвенный?
AVM>>IMHO тот который лучше протестирован.

E>Тут я имел ввиду немного другие вещи. Вот скажем создают радиолокационный комплекс. Выбирают математические модели и пр., и пр. Чего-то моделируют и решают: считать будем вот так. Вот эта фигня будет излучать сигнал такой-то мощности с такой-то частотой. Вот эта фигня будет принимать сигнал. Потоки данных будут такие-то. Обрабатывать их сначала будет вот этот шкаф, затем вот этот, а потом вот этот. Все понеслась, нужно делать. И потом оказывается, что шкаф #2 не успевает обрабатывать все данные с заданым темпом, т.к. он еще занят нормализацие сигнала. Значит в него нужно вставить еще один специализированный процессор для нормализации. Так, а кто у нас этим будет заниматься? И кто ему будет данные передавать? А забирать? И все, стройная архитектура которая, к тому же должна была быть специфицирована и согласована со всеми субподрядчиками, перекраивается, переспецифицируется и дводится до сведения всех исполнителей. Хорошо, если доводится, и хорошо, если всех
Это к вопросу о плохом прототипировании и плохом управлении требованиями. IMHO те же проблеммы но на более высоком уровне.
К слову, радиолокационный комплекс — не программная, а аппаратная-программная задача.

E>>>Ну и процесс тестирования всех компонентов и их интеграция так же должны быть в центре внимания. Как именно тестирование организовано у конкретного разработчика -- это дело этого разработчика. Но вот заставить все это работать вместе, работать правильно и предоставить способ в этом убедиться -- вот это задача. Если с ней не справиться, то получится, как с Beagle 2, когда один модуль считал дистанцию в метрах, а другой -- в футах.
AVM>>Без тестирования никуда, полностью согласен. В том числе и интеграционного.
AVM>>А вот по поводу метров<->футов. Это очень не удобно и увеличивает затраты, но если считается правильно и там где надо переводиться, почему это должно снизить качество? Просто возрастает сложность тестирования.
E>Да возрастает. И у кого-то может возникнуть желание избежать лишних сложностей. Поэтому должна быть вышестоящая инстанция, которая бъет по голове тех, кто на интеграционное тестирование предоставляет некачественные компоненты.
Полностью согласен.

Здравствуйте, FDSC, Вы писали:

FDS>>>Надёжный код могут написать только разбирающиеся в тематике приложения сотрудники
AVK>>Ерунда. Приемы, используемые для создания надежного кода никакого отношения к тематике не имеют.
FDS>Дело не в самих приёмах, а в правильности их применения. Если разработчики ничего не понимают в предметной области, они могут просто пропустить смысловую ошибку в алгоритме или неправильно оценить свойства управляемых процессов, а потом долго удивляться.
Аналитики должны объяснить разработчикам смысл, а тестеры проверить правильно ли разработчики этот смысл поняли.

FDS>>>Прошу прощения, не совсем конечно. Консультации нужны, но всё-таки не в таких масштабах.
AVK>>В каких таких?
FDS>Не в масштабах "нянек". Я уже говорил, что неплохо, если программист работает на пределе возможностей. Особенно, если он молодой программист.
IMHO плохо если программист работает на пределе своих возможностей — задалбывает это и интерес пропадает. Плюс нет времени остановиться и спокойно посмотреть, чего же я тут такое наработал.

Здравствуйте, AVM, Вы писали:

AVM>Здравствуйте, eao197, Вы писали:

E>>А я и не говорил, что они будут играть маленькую роль. Просто в таких проектах будут более важные роли, такие как организация и интеграция.
AVM>Я бы сказал что в больших проектах организация и интеграция должны быть добавлены к этим ролям. А вот будут ли они превалировать над ними, большой вопрос. Если организацию и интеграцию поставить над всем остальным, то легко получить "военно-морскую лошадь" — голова в яблоках, а зад в мыле.

Да в жизни все может быть.

E>>>>Имхо, в таких проектах на первое место все же выходит именно организация и руководство. Организация всего: начиная от выбора подрядчиков и субподрядчиков, их оперативного взаимодействия, контроля за ходом работ и т.д.
AVM>>>С точки зрения сроков и бюджета — ДА, организация на первом месте.
E>>Так ведь сроки и бюджет для многих проектов -- это и есть самое важное. Не уложился в срок -- проект закрыли. Вышел за рамки бюджета -- проект закрыли. Все, все квалифицированные разработчики могут искать себе другую работу.
AVM>Вспомни постановку задачи, качество превыше всего, время и деньги считались вторичными. Если же говорить только о деньгах, то расклад может получится совсем другим.

Так-то оно так... Только вот военные не хотят финансировать проекты, которые в сроки не укладываются. А иметь глючный софт для управления ракетой "воздух-земля" себе же дороже может выйти.

А по сути я с твоим замечанием согласен.

AVM>К слову, радиолокационный комплекс — не программная, а аппаратная-программная задача.

Ага а появление новой незапланированной железячки там сразу дает жизни программистам. По самое нехочу.

Здравствуйте, AndrewVK, Вы писали:

AVK><SKIP> Однако современный порядок дел обстоит так, что проекты становятся все сложнее и сложнее и потребность в неквалифицированной рабочей силе падает.