В последнее время активно обсуждается темя зависимости количества ошибок в зависимости от языка на котором ведётся разработка. Эта темя всплывала здесь

Автор: eao197
Дата: 05.06.05

, здесь

Автор: FDSC
Дата: 13.06.05

и даже в мегафлейме здесь

Автор: Сергей Губанов
Дата: 09.06.05

. Так же эта тема с завидной регулярностью появляется и в вечных темах "X vs Y" и "зачем нужен goto?".
Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен. Забавно, но об этом с дивной регулярностью вспоминают во время споров, когда исчерпываются аргументы в защиту того или иного языка.
Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.
Тема, конечно, не оригинальна, и что на эту тему исписаны тонны бумаги (и выработаны стандарты, такие как ISO9000, ANSI или ГОСТ), но хотелось бы выяснить мнение участников форума, особенно со своим практическим опытом и своей точкой зрения на это.
Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
— Организация процесса разработки
— Организация процесса тестирования
— Архитектура ПО
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Язык программирования
— Стиль кодирования
— Используемые модули и библиотеки
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти
Список далеко не полон, есть множество ньюансов и деталей. Было бы интересно обсудить, что вы думаете по этому поводу.

Слона то мы и не заметили.

IMHO на первом месте стоит квалификация проектной комманды

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

AF> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
AF> — Организация процесса разработки
AF> — Организация процесса тестирования
AF> — Архитектура ПО
AF> — Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
AF> — Язык программирования
AF> — Стиль кодирования
AF> — Используемые модули и библиотеки
AF> — Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
AF> — Аккуратное слежение за выделением и освобождением памяти

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

AVM>Слона то мы и не заметили.

AVM>IMHO на первом месте стоит квалификация проектной комманды

Да, про этот фактор Андрей Федотов действительно забыл.
Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

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

AF>> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
AF>> — Организация процесса разработки
AF>> — Организация процесса тестирования
AF>> — Архитектура ПО
AF>> — Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
AF>> — Язык программирования
AF>> — Стиль кодирования
AF>> — Используемые модули и библиотеки
AF>> — Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
AF>> — Аккуратное слежение за выделением и освобождением памяти

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

AVM>Слона то мы и не заметили.

AVM>IMHO на первом месте стоит квалификация проектной комманды

Вообще то логично, в список внести её необходимо. Однако насколько мне известно — все проводимые в данной области исследования, как это ни пародоксально, свидетельсвтуют о том, что это далеко не самый важный фактор — ни для качества, ни для надёжности.
Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

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

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

AVM>>Слона то мы и не заметили.

AVM>>IMHO на первом месте стоит квалификация проектной комманды

E>Да, про этот фактор Андрей Федотов действительно забыл.
E>Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

Как говорил Иосиф Виссарионович "Кадры решают все".
Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

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

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

AVM>>Слона то мы и не заметили.

AVM>>IMHO на первом месте стоит квалификация проектной комманды

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

AF> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.
У тебя похоже проектная команда = команда студентов.
IMHO проектная команда = команда студентов + менеджер, который ими управлял + тех лидер, который их консультировал + и тд. Не надо преувеличивать роль руководства в проектной команде. Формально PM несет ответственность за проект, реально же успех проекта зависит не от конкретных людей, а от команды в целом. А вот завалить проект может и отдельно взятая личность.

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

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

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

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

AVM>>>Слона то мы и не заметили.

AVM>>>IMHO на первом месте стоит квалификация проектной комманды

E>>Да, про этот фактор Андрей Федотов действительно забыл.
E>>Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

AVM>Как говорил Иосиф Виссарионович "Кадры решают все".
Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...
Вспомнить хотя бы историю про Берию и удвоение мощьности авиационного двигателя...

AVM>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

Это верно только от части. Достаточно одного умного руководителя, что бы выстроить работу команды новичков (примеры тому видел сам, хотя это, конечно и достаточно трудно), а если у него ещё есть несколько опытных сотрудников и он их умело расставляет на ключевые позиции и эффективно строит процесс разработки (куда я включаю как составные части общение с заказчиками, сбор требований, анализ, проектирование, построение архитектуры, тестирование и все прочие компоненты) — то такая команда может работать и быстро и эффективно и выдавать продукт очень выского качества.
Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.

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

(С) — Увы, забыл

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

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

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

AVM>>>Слона то мы и не заметили.

AVM>>>IMHO на первом месте стоит квалификация проектной комманды

AF>> Вообще то логично, в список внести её необходимо. Однако насколько мне известно — все проводимые в данной области исследования, как это ни пародоксально, свидетельсвтуют о том, что это далеко не самый важный фактор — ни для качества, ни для надёжности.
AVM>Примеры в студию, плиз
Увы — на бумаге. Найду в электронном виде — выложу на всеобщее обозрение.

AF>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.
AVM>У тебя похоже проектная команда = команда студентов.
Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.

AVM>IMHO проектная команда = команда студентов + менеджер, который ими управлял + тех лидер, который их консультировал + и тд. Не надо преувеличивать роль руководства в проектной команде. Формально PM несет ответственность за проект, реально же успех проекта зависит не от конкретных людей, а от команды в целом.
В общем то согласен.
AVM>А вот завалить проект может и отдельно взятая личность.
А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

AVM>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. Насколько я вижу — у многих есть аналогичный опыт. Хотя, конечно, делать качественный продукт с высококвалифицированной командой — проще.
AVM>Ты можешь выстроить процессы, которые расчитаны на средний уровень квалификации разработчиков и делать качественный софт. Но IMHO ключевое слово тут не процессы, а средний уровень квалификации , потому что процессы ты сравнительно легко можешь менять и затачивать под конкретную ситуацию. А вот изменить уровень квалификации проектной команды обычно намного тяжелее.
Как раз-таки наоборот — гораздо важнее процессы, а квалификация — вторична.
Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
В то же время трудолюбивый и исполнительный новичок может делать полезную работу — и при умении им управлять может оказаться гораздо полезнее, чем иной раздолбайствующий профессионал.
Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.

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

AF>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.

Зависит от проектов. Если проект позволяет, то действительно команда начинающих программистов способна под пристальным контролем выдавать качественный продукт (но хотя бы один высококлассный спец быть должен). А бывают проекты, когда новичкам просто нечего поручить. Управляемые платформы эту ситуацию конечно сглаживают, но и они отнюдь не панацея.

AVM>>А вот завалить проект может и отдельно взятая личность.
AF> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

СММмы и прочие ISO конечно штуки крутые, но на малых командах (до 10 человек) они работают плохо — эффективность низкая, зато гибкость они снижают сильно. Так что тоже не панацея.

AF> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.

А мой показывает обратное. Намек понятен?

AF> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?

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

AF> В то же время трудолюбивый и исполнительный новичок может делать полезную работу

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

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

AF> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...

Правильно. Но в твоём списке менеджмент вообще отсутствует. А зря.

AVM>>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

AF> Это верно только от части.

Это очень правильно. И это легко объяснятся. Дело в том что большинство багов появляются не в момент первоночального написания кода, а тогда, когда его начинают изменять по каким либо причинам. Это происходит потому, что когда код пишется, то как правило всё тщательно тестируется самим разработчиком. Когда вносятся изменения, то повторное тестирование всех сценариев очень часто не делается. Изменения вносятся в основном по нескольким причинам. Первая — change request, изменение требований заказчиком во время разработки. С этим ничего не поделаешь. Хотя и здесь можно многое контролировать, если архитектура и дизайн с самого начала были ориентированы на простое внесение изменений в систему. Вторая причина — изменение самой архитектуры и дизайна. Это в чистом виде ошибки архитекторов и дизайнеров. Чем больше таких ошибок тем больше багов будет внесено в систему в момент её изменения.

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

Есть ещё один момент связанный с переделками. Это занимает определённое время, в результате команда не укладывается в сроки, отсюда спешка, тап-ляп кодирование и откровенное игнорирование тестирования самими разработчиками. Порой доходит до того, что в QA сдаётся не то чтобы глючный непротестированный код, а просто откровенно недоделанный, код в котором отсутствует какая-то функциональность. Расчёт делается на то, что пока QA будет тестировать, всё это будет паралельно дописываться.

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

AF> Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен.

Мне кажется этот посыл ошибочным. Я что-то не слышал о том, что кто-то говорит "качество системы или ПО обеспечивается исключительно языком программирования". Это домыслы. Говорят (и я с этим согласен), что некоторые языки способны облегчить выявление ошибок и теми или иными путями не дать совершить ошибки. Улавливаешь разницу?

AF>Забавно, но об этом с дивной регулярностью вспоминают во время споров, когда исчерпываются аргументы в защиту того или иного языка.

Ничего забавного. Безопастность порождаемого кода — это реальное достоинство. Разработчикам языков претендующих на звание "safe" пришлось не мало потрудиться чтобы обеспечить приемлемую функциональность без опасных конструкций.

AF> Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.

Что пришло в голову сразу:
1. Качество проектирования (грамотное применение выбранной парадигмы и паттернов, корректность предположений, качество декомпозиции).
2. Класс и отвественность программистов (человеческий фактор).
3. Использование средств автоматизации (визульные дизайнеры, рефакторинг, генерация кода, отладчики, IDE).
4. Использование библиотек (их качество).
5. Характеристики безопасности языка программирования и рантайма.
6. Умение команды (если разработка ведется командой) разделять обязанности и распараллеливать разработку.
7. Наличие ревизии кода и рефакторинга.

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

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

AF>>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.

AVK>Зависит от проектов. Если проект позволяет, то действительно команда начинающих программистов способна под пристальным контролем выдавать качественный продукт (но хотя бы один высококлассный спец быть должен). А бывают проекты, когда новичкам просто нечего поручить. Управляемые платформы эту ситуацию конечно сглаживают, но и они отнюдь не панацея.

В общем то согласен. Про наличие хотя бы одного спеца я собственно и сам писал. А вот насчёт сложности проекта — это вопрос. Те же сети были сделаны как раз новичками. Бедолаги получив задание от родины и правительства (родного, американского) сидели и ждали, когда наконец придёт профессионал, который раскажет им, что им надо делать. А он так и не пришёл. И ничего — сделали. За год сделали.

AVM>>>А вот завалить проект может и отдельно взятая личность.
AF>> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

AVK>СММмы и прочие ISO конечно штуки крутые, но на малых командах (до 10 человек) они работают плохо — эффективность низкая, зато гибкость они снижают сильно. Так что тоже не панацея.

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

AF>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.
AVK>А мой показывает обратное. Намек понятен?

Понятен.
Непонятно только, что именно показывает ваш опыт? Что связь есть (с чем я согласен) или что эта связь — прямая?

AF>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?

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

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

AF>> В то же время трудолюбивый и исполнительный новичок может делать полезную работу

AVK>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
А вот это во многом зависит от того, как распределять работу.

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

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

AF>> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...

IT>Правильно. Но в твоём списке менеджмент вообще отсутствует. А зря.
+1
Кстати совершенно верно. Я его забыл, точнее не выделил отдельно из процесса организации работ по проекту.

AVM>>>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>>>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>>>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

AF>> Это верно только от части.

IT> ...
IT>Есть ещё один момент связанный с переделками. Это занимает определённое время, в результате команда не укладывается в сроки, отсюда спешка, тап-ляп кодирование и откровенное игнорирование тестирования самими разработчиками. Порой доходит до того, что в QA сдаётся не то чтобы глючный непротестированный код, а просто откровенно недоделанный, код в котором отсутствует какая-то функциональность. Расчёт делается на то, что пока QA будет тестировать, всё это будет паралельно дописываться.

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

То есть обобщая, качество зависит от:
— Менеджмента
— Качества проектирования (качества архитектуры, в частности учётом возможных изменений в архитектуре)
— Управления внесением изменений (по запросу клиента ли или при правке багов)
— Правильной оценкой времени при планировании, с учётом возможных рисков, связанных с правкой багов в предидущих версиях
— Организацией процесса тестирования (в частности передачей на тестирование продукта своевременно)

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

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

AF>> Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен.

VD>Мне кажется этот посыл ошибочным. Я что-то не слышал о том, что кто-то говорит "качество системы или ПО обеспечивается исключительно языком программирования". Это домыслы. Говорят (и я с этим согласен), что некоторые языки способны облегчить выявление ошибок и теми или иными путями не дать совершить ошибки. Улавливаешь разницу?

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

AF>>Забавно, но об этом с дивной регулярностью вспоминают во время споров, когда исчерпываются аргументы в защиту того или иного языка.

VD>Ничего забавного. Безопастность порождаемого кода — это реальное достоинство. Разработчикам языков претендующих на звание "safe" пришлось не мало потрудиться чтобы обеспечить приемлемую функциональность без опасных конструкций.

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

Автор: eao197
Дата: 05.06.05

— панацеей она не является и для того, что бы обеспечить высокий уровень качества нужно задейстовать что-то ещё.

AF>> Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.

VD>Что пришло в голову сразу:
VD>1. Качество проектирования (грамотное применение выбранной парадигмы и паттернов, корректность предположений, качество декомпозиции).
VD>2. Класс и отвественность программистов (человеческий фактор).
VD>3. Использование средств автоматизации (визульные дизайнеры, рефакторинг, генерация кода, отладчики, IDE).
VD>4. Использование библиотек (их качество).
VD>5. Характеристики безопасности языка программирования и рантайма.
VD>6. Умение команды (если разработка ведется командой) разделять обязанности и распараллеливать разработку.
VD>7. Наличие ревизии кода и рефакторинга.

+1

Спасибо! Про рефакторинг и средства разработки я вообще не подумал, хотя следовало бы

А как по твоему влияют на оное процесс разработки и менеджмент проекта?

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

AVM>>Как говорил Иосиф Виссарионович "Кадры решают все".
AF> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...
AF> Вспомнить хотя бы историю про Берию и удвоение мощьности авиационного двигателя...
Не слышал такую историю, расскажи они удвоили мощьности авиационного двигателя?

AF> Это верно только от части. Достаточно одного умного руководителя, что бы выстроить работу команды новичков (примеры тому видел сам, хотя это, конечно и достаточно трудно), а если у него ещё есть несколько опытных сотрудников и он их умело расставляет на ключевые позиции и эффективно строит процесс разработки (куда я включаю как составные части общение с заказчиками, сбор требований, анализ, проектирование, построение архитектуры, тестирование и все прочие компоненты) — то такая команда может работать и быстро и эффективно и выдавать продукт очень выского качества.
Вот вот вот, ты уже сам начинаешь подтверждать, что квалификация одного из членов проектной команды — руководителя, имеет очень важную роль. Полностью с тобой согласен.

AF> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
Бывает, и достаточно.

AF>

AF> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF> (С) — Увы, забыл
Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

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

AVK>>Зависит от проектов. Если проект позволяет, то действительно команда начинающих программистов способна под пристальным контролем выдавать качественный продукт (но хотя бы один высококлассный спец быть должен). А бывают проекты, когда новичкам просто нечего поручить. Управляемые платформы эту ситуацию конечно сглаживают, но и они отнюдь не панацея.

AF>А вот насчёт сложности проекта — это вопрос.

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

AF>Согласен. Панацеи вообще не бывает.

Бывает. Только это не технология, а человек. Не конкретный, а вобще.

AF>>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.
AVK>>А мой показывает обратное. Намек понятен?

AF>Понятен.
AF>Непонятно только, что именно показывает ваш опыт? Что связь есть (с чем я согласен) или что эта связь — прямая?

Не, намек был на то что твой опыт — не аргумент в споре. Как и мой.

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

AF>В принципе я бы согласился с таким подходом, елси бы не одна загвоздка
AF>Квалификация определяется по навыкам, умениям и знаниям.

Это вторичные признаки, позволяющие предварительно оценить эту самую квалификацию. Давай обратимся к словарю (KM.ru)

КВАЛИФИКАЦИЯ, и, ж.

1. см. квалифицировать.

2. Степень годности к какомун. виду труда, уровень подготовленности. Повышение квалификации. Высшая к.

3. Профессия, специальность. Приобрести квалификацию токаря.

Очевидно что в данном случае нам подходит 2 пункт. Итого — квалификация это степень годности к выполнению определенной работы. Так вот, человек, который прекрасно знает технологии, но при этом не имеет достаточного самоконтроля чтобы не халтурить, не годен к выполнению этой самой работы.

AVK>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF> А вот это во многом зависит от того, как распределять работу.

Нет, это, прежде всего, зависит от задач проекта.

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

AF>>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.
Для новичков обязательно нужен хоть один квалифицированный технический консультант, причем с качествами "няньки".

AVM>>У тебя похоже проектная команда = команда студентов.
AF>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, ....
Я не пойму о чем мы спорим, ты говоришь то же что и я только другими словами
AF> ... а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.
Ты никогда не встречал архитектора, которого вот-вот хватит кандратий, после того как он в 10-й раз сделал code review "новичка, без особого опыта или квалификации"?

AVM>>IMHO проектная команда = команда студентов + менеджер, который ими управлял + тех лидер, который их консультировал + и тд. Не надо преувеличивать роль руководства в проектной команде. Формально PM несет ответственность за проект, реально же успех проекта зависит не от конкретных людей, а от команды в целом.

AVM>>А вот завалить проект может и отдельно взятая личность.
AF> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.
CMMI 3 в нашей жизни очень редкая вешь. Я не в том плане, что сертификатов мало раздадено, а в том что денег эта штука жрет немеряно и не всякий заказчик захочет покупать качество по таким ценам. Причем даже наличие полного CMMI не гарантирует успех проекта.

AVM>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
Есть, причем прямая связь.

AVM>>Ты можешь выстроить процессы, которые расчитаны на средний уровень квалификации разработчиков и делать качественный софт. Но IMHO ключевое слово тут не процессы, а средний уровень квалификации , потому что процессы ты сравнительно легко можешь менять и затачивать под конкретную ситуацию. А вот изменить уровень квалификации проектной команды обычно намного тяжелее.
AF> Как раз-таки наоборот — гораздо важнее процессы, а квалификация — вторична.
ISO 9000 предусматривает ответственность руководства за обучение персонала.
Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.


AF> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
Не надо смешивать теплое с твердым.
Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
a) хорошего прораба?
b) хороших штукатуров?

AF> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.

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

AF>> Это верно только от части. Достаточно одного умного руководителя, что бы выстроить работу команды новичков (примеры тому видел сам, хотя это, конечно и достаточно трудно), а если у него ещё есть несколько опытных сотрудников и он их умело расставляет на ключевые позиции и эффективно строит процесс разработки (куда я включаю как составные части общение с заказчиками, сбор требований, анализ, проектирование, построение архитектуры, тестирование и все прочие компоненты) — то такая команда может работать и быстро и эффективно и выдавать продукт очень выского качества.
AVM>Вот вот вот, ты уже сам начинаешь подтверждать, что квалификация одного из членов проектной команды — руководителя, имеет очень важную роль. Полностью с тобой согласен.
Но не всей команды в целом. А это очень существенная разница. Тем более, что достаточно квалификации всего одного члена команды — руководителя — оказаться низкой и всё на смарку.

В связи с чем возникает интересный вопрос — чей уровень квалификации наиболее критичен для проекта — всегда ли ответ один или есть несколько вариантов — схем построения эффективной команды?

AF>> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
AVM>Бывает, и достаточно.
Бывает. Но разве это то, к чему стоит стремиться?

AF>>

AF>> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF>> (С) — Увы, забыл
AVM>Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.

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

AVK>Минуточку. Про сложность я ничего не писал. Дело не в сложности, дело, скажем так, в изведанности. Если точно известно что и как писать, то можно придумать набор техник и метрик, которые обеспечат стабильное качество, вне зависимости от сложности выполняемых операций.
+1

AVK>А вот если неизвестно ...
Подобные — исследовательские проекты — особый случай. Во-первых от них, как правило не требуется такое качество ПО и его надёжность кода, как для ракетостроения или финансов. А во-вторых, там как правило программирование как таковое вообще вторично и служит инстументом для решения совершенно других задач — научных, исследовательских, математических, технологических и т.п. Даже если это исследования связанные с теорией компиляторов или с ИИ — всё равно качество кода здесь — не на первом месте.

AVK>Не, намек был на то что твой опыт — не аргумент в споре. Как и мой.

Забавная складывается ситуация. Я предложил высказать свои точки зрения и вруг с удивлением узнаю, что это уже оказывается спор.
Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта. Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?
Тем более, что ничто не мешает привести собственные примеры, которые опровергнут, дополнят, расширят или изменят моё утверждение. Как раз это было бы полезно, что бы выявить, что было факторами успеха или провала в других проектах.

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

AF>>В принципе я бы согласился с таким подходом, елси бы не одна загвоздка
AF>>Квалификация определяется по навыкам, умениям и знаниям.

AVK>Это вторичные признаки, позволяющие предварительно оценить эту самую квалификацию. Давай обратимся к словарю (KM.ru)
AVK>

КВАЛИФИКАЦИЯ, и, ж.

AVK>1. см. квалифицировать.

AVK>2. Степень годности к какомун. виду труда, уровень подготовленности. Повышение квалификации. Высшая к.

AVK>3. Профессия, специальность. Приобрести квалификацию токаря.

AVK>Очевидно что в данном случае нам подходит 2 пункт. Итого — квалификация это степень годности к выполнению определенной работы. Так вот, человек, который прекрасно знает технологии, но при этом не имеет достаточного самоконтроля чтобы не халтурить, не годен к выполнению этой самой работы.

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

AVK>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>> А вот это во многом зависит от того, как распределять работу.
AVK>Нет, это, прежде всего, зависит от задач проекта.

Например?

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

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

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

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

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

Вот Андрей привел список факторов, который с учетом дополнения AVM можно по разному отсортировать в зависимости от того, какие свойства мы хотим получить от продукта. Если говорить о высоком качестве и надежности (в ущерб скорости разработки и, возможно, стоимости), то я бы их перечислил следующим образом:

— Организация процесса разработки
— Архитектура ПО
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Язык программирования
— Используемые модули и библиотеки
— Квалификация проектной команды
— Стиль кодирования
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти

Хотя, если проект должен быть выполнен одной организацией и одной относительно небольшой командой, то я бы его пересортировал так:

— Организация процесса разработки
— Архитектура ПО
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Квалификация проектной команды
— Язык программирования
— Используемые модули и библиотеки
— Стиль кодирования
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти

Повторюсь, речь идет именно о качестве и надежности.

Если во главу угла поставить что-то другое, скажем, стоимость разработки, то, возможно список опять изменился бы:

— Квалификация проектной команды
— Язык программирования и используемые модули и библиотеки
— Архитектура ПО
— Организация процесса разработки
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти
— Стиль кодирования


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

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

AVK>>А вот если неизвестно ...
AF> Подобные — исследовательские проекты — особый случай.

Что такое особый случай? Если ты намекаешь на то что такая ситуация встречается редко, то это не так.

AF> Во-первых от них, как правило не требуется такое качество ПО и его надёжность кода, как для ракетостроения или финансов.

Отнюдь. Качество кода требуется всегда.

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

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

AF> Даже если это исследования связанные с теорией компиляторов или с ИИ — всё равно качество кода здесь — не на первом месте.

А вот к примеру создание ОС — там тоже качество кода не на первом месте?

AF>Забавная складывается ситуация. Я предложил высказать свои точки зрения и вруг с удивлением узнаю, что это уже оказывается спор.

Ну ты же сам начал оспаривать высказанное.

AF>Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта.

Неа. Есть еще логическое мышление.

AF> Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?

Обращаться можно. Обобщать нужно очень осторожно.

AF>Тем более, что ничто не мешает привести собственные примеры, которые опровергнут, дополнят, расширят или изменят моё утверждение.

А ты эти примеры привел?

AF>Это при условии, что он халтурит всегда. А если, как чаще всего и бывает — он хорошо работает в том проекте, который ему интересен и плохо на саппорте, например, — как тут быть?

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

AF>Если бы тебя на саппорт засунули лет на 10 — ты уверен, что работал бы с энтузиазмом или вообще работал бы, а не халтурил?

А меня бы туда не засунули.

AVK>>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>>> А вот это во многом зависит от того, как распределять работу.
AVK>>Нет, это, прежде всего, зависит от задач проекта.

AF> Например?

Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?

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

AF>Но не всей команды в целом. А это очень существенная разница. Тем более, что достаточно квалификации всего одного члена команды — руководителя — оказаться низкой и всё на смарку.
Не надо преувеличивать роль PM, если у тебя грамотная команда разработчиков, то они не дадут PM-у завалить проект. В крайнем случае, если они увидят что PM делает полную туфту, они эскалируют проблему на более высокий уровень.
Главное, чтобы члены проектной команды были адекватно промотивированы, но это уже другая история.

AF>В связи с чем возникает интересный вопрос — чей уровень квалификации наиболее критичен для проекта — всегда ли ответ один или есть несколько вариантов — схем построения эффективной команды?

AF>>> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
AVM>>Бывает, и достаточно часто.
AF>Бывает. Но разве это то, к чему стоит стремиться?
Естественно, к этому стремиться НЕ надо.

AF>>>

AF>>> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF>>> (С) — Увы, забыл
AVM>>Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

AF>Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.

Заставить — нет, научить — да.
Ты не сможешь заставить человека сделать то что он не умеет делать, если предварительно не научишь его делать это.
Идея понятна?

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

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

AF>>>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.
AVM>Для новичков обязательно нужен хоть один квалифицированный технический консультант, причем с качествами "няньки".
Согласен. Или с опытом вождя-вдохновителя

AVM>>>У тебя похоже проектная команда = команда студентов.
AF>>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, ....
AVM>Я не пойму о чем мы спорим, ты говоришь то же что и я только другими словами
Так я вроде и не спорю. Просто меня удивило то, каким образом из моего поста про то, что команды студентов навичков грамотно управлялись был сделан вывод, что у них нет ПМ... Особенно когда он там был.

AF>> ... а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.
AVM>Ты никогда не встречал архитектора, которого вот-вот хватит кандратий, после того как он в 10-й раз сделал code review "новичка, без особого опыта или квалификации"?
Встречал. Правда видел и таких, которые бедолагу доводили сами до состояния камикадзе, летящего на встречу теплому ветру...

AVM>CMMI 3 в нашей жизни очень редкая вешь. Я не в том плане, что сертификатов мало раздадено, а в том что денег эта штука жрет немеряно и не всякий заказчик захочет покупать качество по таким ценам. Причем даже наличие полного CMMI не гарантирует успех проекта.
Абсолютно согласен. Правда здесь причины неуспеха кроются уже не в качестве ПО. Обычно это уже ошибки управления, а ещё чаще — ошибки общения с клиентами.

AVM>>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
AVM>Есть, причем прямая связь.
То есть ситуация, когда есть две команды, у первой квалификация в среднем выше, и она проваливает проект, а вторая его делает — это прямая связь?
Или всё-таки стоит рассмотреть, что вы имеете в виду под квалификацией команды? Кого конкретно в команде?

AVM>>>Ты можешь выстроить процессы, которые расчитаны на средний уровень квалификации разработчиков и делать качественный софт. Но IMHO ключевое слово тут не процессы, а средний уровень квалификации , потому что процессы ты сравнительно легко можешь менять и затачивать под конкретную ситуацию. А вот изменить уровень квалификации проектной команды обычно намного тяжелее.
AF>> Как раз-таки наоборот — гораздо важнее процессы, а квалификация — вторична.
AVM>ISO 9000 предусматривает ответственность руководства за обучение персонала.
Совершенно верно.
AVM>Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.
А что им тосковать — будут учить. Потом никто и не предполагает в реальном проекте брать 100 новичков на одного ПМ и архитектора. Обычно есть градация от новичков до выскоквалифицированных профи, притом и тех и других должна быть определённая пропорция.

AF>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>Не надо смешивать теплое с твердым.
AVM>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>a) хорошего прораба?
AVM>b) хороших штукатуров?
А вот это зависит от размеров квартиры и того, построена она или нет.
Эта аналогия не совсем применима, по той причине, что перештукатурить совсем не так дёшево, как переписать код.

AF>> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
AVM>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
AVM>Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.
А что есть квалификация Тим-лида и ПМ'а — как не умение смортеть за этими самыми разработчиками?

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

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

AF>>Но не всей команды в целом. А это очень существенная разница. Тем более, что достаточно квалификации всего одного члена команды — руководителя — оказаться низкой и всё на смарку.
AVM>Не надо преувеличивать роль PM, если у тебя грамотная команда разработчиков, то они не дадут PM-у завалить проект. В крайнем случае, если они увидят что PM делает полную туфту, они эскалируют проблему на более высокий уровень.
AVM>Главное, чтобы члены проектной команды были адекватно промотивированы, но это уже другая история.

Роль руководства (и в частном случае ПМ — если реально руководит он), не стоит преуменьшать. Если в результате его ошибок в последний момент потребуется вносить много критичных правок — никакой профессионализм команде не поможет. Прецеденты к сожалению были.

AF>>Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.
AVM>
AVM>Заставить — нет, научить — да.
AVM>Ты не сможешь заставить человека сделать то что он не умеет делать, если предварительно не научишь его делать это.
AVM>Идея понятна?
+1
Согласен.

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

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

AVK>>>А вот если неизвестно ...
AF>> Подобные — исследовательские проекты — особый случай.

AVK>Что такое особый случай? Если ты намекаешь на то что такая ситуация встречается редко, то это не так.

Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

AF>> Во-первых от них, как правило не требуется такое качество ПО и его надёжность кода, как для ракетостроения или финансов.

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

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

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

AF>> Даже если это исследования связанные с теорией компиляторов или с ИИ — всё равно качество кода здесь — не на первом месте.

AVK>А вот к примеру создание ОС — там тоже качество кода не на первом месте?
Но это и не исследовательский проект, о котором шла речь.

AF>>Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта.
AVK>Неа. Есть еще логическое мышление.
На основе чего?

AF>> Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?
AVK>Обращаться можно. Обобщать нужно очень осторожно.
Согласен. К чему всех нас и призываю.

AF>>Тем более, что ничто не мешает привести собственные примеры, которые опровергнут, дополнят, расширят или изменят моё утверждение.
AVK>А ты эти примеры привел?
Пожалуйста. Мне известно несколько человек из разных НИИ, которые держат эдакий кафедральный бизнес — пишут софт на сторону для промышленных заказчиков. Софт пишут при помощи студентов, чья квалификация оставляет желать лучшего. Качество софта на уровне (была возможность убедиться в этом).

AF>>Если бы тебя на саппорт засунули лет на 10 — ты уверен, что работал бы с энтузиазмом или вообще работал бы, а не халтурил?

AVK>А меня бы туда не засунули.
От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

AVK>>>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>>>> А вот это во многом зависит от того, как распределять работу.
AVK>>>Нет, это, прежде всего, зависит от задач проекта.

AF>> Например?
AVK>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
Это зависит от новичка и того, как поручать. Если новичок толковый, схватывает быстро, ему подробно всё обяснить и следить за тем что он делатет — то вполне можно. Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

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

AF>Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?

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

Минуточку? Разве я говорил про исследовательский код? Пойми — ситуации, когда невозможно поставить программисту абсолютно четкое задание, встречаются отнюдь не только в исследовательских проектах. Создание любой платформы, системного кода, первая разработка определенного типа приложений в очень большой степени состоят из таких ситуаций. Точное предсказание времени и контроль результатов возможны только при уже отлаженном техпроцессе, но ведь кто то этот техпроцесс на конкретном типе кода должен отладить, не так ли?

AVK>>А вот к примеру создание ОС — там тоже качество кода не на первом месте?
AF> Но это и не исследовательский проект, о котором шла речь.

Про исследовательские проекты придумал ты.

AVK>>А меня бы туда не засунули.
AF> От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

Это почему это (я про саппорт)?

AF>>> Например?
AVK>>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
AF>Это зависит от новичка

Каким образом?

AF> и того, как поручать.

А как надо?

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

Как показывает практика — не помогает. Вышеозначенный тип кода обладает одной особенностью — затраты на его реализацию сильно меньше затрат на проектирование. Если составить подробнейший план, то новичек конечно справится. Но на практике же поступают обычно так: проектируют не столь тщательно и все тонкие места программист допроектирует при реализации. Это сильно быстрее вариант с подробнейшим проектом. Есть еще одна засада — зачастую при добавлении нового функционала требуется рефакторинг старого. Предусмотреть это заранее очень сложно. Итого — попытка использовать новичка в подобных проектах приводит к отрицательному результату. Хотя, конечно, иногда так поступают, но не ради того чтобы получить пользу от новичка, а для того чтобы из новичка сделать спеца.

AF> Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

Дело не в хотении, а в целесообразности.

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

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

AVK очень точно высказался по поводу изведанности. Для неизведанного опыт не даёт ответа на вопрос "Как надо делать?". Опыт даёт только ответ на вопрос "Как НЕ надо делать?". Поэтому, к опыту надо обязательно обращаться, но только с теми вопросами на которые он может дать ответ.

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

AF> Вот именно потому, что я её улавливаю, я и затеял этот пост.
AF> Если спросить кого-либо на прямую о том, согласен ли он с данным тезисом — врядли найдётся на форуме много тех, кто с этим согласится. Но вот если начать читать посты, то сразу бросается в глаза, что в пылу полемики об этом часто забывают. Я даже не говорю про мегафлейм вокруг оберона, даже в постах про более приземлённые языки зачастую ошибки рассматриваются исключительно в контексте языка программирования.

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

AF> Да и потом, Влад, я же вовсе не тебя имел в виду

Это не важно.


AF> Я же не говорил, что она не является достоинством. Тем более, что сам думаю, что она полезна. Но как прекрасно показано здесь

Автор: eao197
Дата: 05.06.05

— панацеей она не является и для того, что бы обеспечить высокий уровень качества нужно задейстовать что-то ещё.

AF> Спасибо! Про рефакторинг и средства разработки я вообще не подумал, хотя следовало бы

Чем дальше в лес, тем они играют все большую и большую роль.

AF> А как по твоему влияют на оное процесс разработки и менеджмент проекта?

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

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

AVM>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.

Власть сама по себе не страшна. Страшна власть, которая потворствует принятию "судьбоносных" решений.

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

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

AF>>Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

AVK>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
Нет конечно.
Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно. Хотя согласен, что гораздо надёжнее её поручить профи.

AVK>>>А меня бы туда не засунули.
AF>> От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

AVK>Это почему это (я про саппорт)?
Потому как неисповедимы пути БГ... Я вот знаю бывшую звезду советской науки — который сейчас как раз в саппорте и работает.

AF>>>> Например?
AVK>>>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
AF>>Это зависит от новичка

AVK>Каким образом?

AF>> и того, как поручать.

AVK>А как надо?

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

AVK>Как показывает практика — не помогает. Вышеозначенный тип кода обладает одной особенностью — затраты на его реализацию сильно меньше затрат на проектирование. Если составить подробнейший план, то новичек конечно справится. Но на практике же поступают обычно так: проектируют не столь тщательно и все тонкие места программист допроектирует при реализации. Это сильно быстрее вариант с подробнейшим проектом. Есть еще одна засада — зачастую при добавлении нового функционала требуется рефакторинг старого. Предусмотреть это заранее очень сложно. Итого — попытка использовать новичка в подобных проектах приводит к отрицательному результату. Хотя, конечно, иногда так поступают, но не ради того чтобы получить пользу от новичка, а для того чтобы из новичка сделать спеца.

AF>> Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

AVK>Дело не в хотении, а в целесообразности.

Вот с этим я полностью согласен.

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

AVK>>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
AF> Нет конечно.
AF> Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно.

Ты сам себе противоречишь.

AF> Хотя согласен, что гораздо надёжнее её поручить профи.

И гораздо эффективнее, что характерно. И качество результата кардинально лучше.

AVK>>Это почему это (я про саппорт)?
AF> Потому как неисповедимы пути БГ... Я вот знаю бывшую звезду советской науки — который сейчас как раз в саппорте и работает.

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

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

AF> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

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

AVK>>>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
AF>> Нет конечно.
AF>> Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно.

AVK>Ты сам себе противоречишь.
В чём?
С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

AF>> Хотя согласен, что гораздо надёжнее её поручить профи.

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

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

VD>Так может это просто твое восприятие? Просто когда речь идет о языке, то не логично обсуждать, к примеру, качества программиста. Сравнивая языки мы подразумеваем, что инструмент в руках приблизительно одинаковых по классу специолистов.

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

VD>Чем дальше в лес, тем они играют все большую и большую роль.
Да, такая тенденция хорошо прослеживается.

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

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

AF>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

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

AVK>>Ты сам себе противоречишь.
AF>В чём?

AVK>>Поручишь ее реализацию новичку?
AF> Нет конечно.

...

AF>Проектирование — конечно не поручишь, а вот реализацию вполне можно.

AF>Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно.

Ты точно читал что я написал? Невозможно заранее спроектировать все, по мере реализации будут вылазить недопроектированные и недоучтиенные вещи? Что, новичек будет постоянно бегать к архитектору за дополнительными доработками? А если он просто косяк пропустит по неопытности? Архитектор виноват?

AF>В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

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

AVK>>И гораздо эффективнее, что характерно. И качество результата кардинально лучше.
AF>А вот это большой вопрос. Если соотношение проектирование к реализации — заметно в пользу проектирования — тогда конечно.
AF> А вот если соотношение обратное...

Но изначально ты спорил с тем что это зависит от проекта.

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

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

AVK>>>Ты сам себе противоречишь.
AF>>В чём?

AVK>

AVK>>Поручишь ее реализацию новичку?
AF>> Нет конечно.

AVK>...

AF>>Проектирование — конечно не поручишь, а вот реализацию вполне можно.

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

AF>>Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно.

AVK>Ты точно читал что я написал? Невозможно заранее спроектировать все, по мере реализации будут вылазить недопроектированные и недоучтиенные вещи? Что, новичек будет постоянно бегать к архитектору за дополнительными доработками? А если он просто косяк пропустит по неопытности? Архитектор виноват?

В зависимости от системы, а так же от того, какова цель — если научить новичка (о чём ты же сам и написал) — то вполне можно делать и так.

AF>>В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

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

Я сколько помню придерживаюсь одной и той же точки зрения с самого начала.
Да, возможность применения слабоквалифицированной рабочей силы зависит от проекта, но только в контексте других условий. Ведь это очень большая разница, когда требуется сделать большой проект, малым числом людей и в предельно сжатые сроки и сделать тот же проект, с большим количеством людей и со свободными (относительно, кончено) сроками. Конечно в первом случае нужны профи и только. А вот во втором можно брать и людей с более низкой квалификацией, а то и вовсе новичков.

AVK>>>И гораздо эффективнее, что характерно. И качество результата кардинально лучше.
AF>>А вот это большой вопрос. Если соотношение проектирование к реализации — заметно в пользу проектирования — тогда конечно.
AF>> А вот если соотношение обратное...

AVK>Но изначально ты спорил с тем что это зависит от проекта.
А спорил не с тем, что это зависит от проекта, а с неявно высказанным тезисом о том, что невозможно обеспечить высокое качество при низкой квалификации части команды. Вот этого возможно достичь в любом проекте. Подчёркиваю: при условии, что прочие требования к проекту (сроки, деньги, политическая обстановка и т.п.) принципиально это позволяют.

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

AVK>Ты точно читал что я написал? Невозможно заранее спроектировать все, по мере реализации будут вылазить недопроектированные и недоучтиенные вещи? Что, новичек будет постоянно бегать к архитектору за дополнительными доработками? А если он просто косяк пропустит по неопытности? Архитектор виноват?

В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения. Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

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

AVK>>Ты точно читал что я написал? Невозможно заранее спроектировать все, по мере реализации будут вылазить недопроектированные и недоучтиенные вещи? Что, новичек будет постоянно бегать к архитектору за дополнительными доработками? А если он просто косяк пропустит по неопытности? Архитектор виноват?

AF>В зависимости от системы,

Что, собственно, и требовалось доказать.

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

AF>Я сколько помню придерживаюсь одной и той же точки зрения с самого начала.

А о чем ты тогда спорил со мной? Я ничего другого и не утверждал.

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

Не зависит это от сроков. Это зависит только и исключительно от целей проекта. Если уже есть профессиональная команда, то разьавление ее новичками только ухудшит ситуацию.

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

Здорово. Сам придумал и сам же споришь с чем придумал.

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

Д>В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения.

Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

Д> Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

Да, если ее немного. В итоге обойдется дешевле.

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


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

......

AF> Список далеко не полон, есть множество ньюансов и деталей. Было бы интересно обсудить, что вы думаете по этому поводу.

Не самую последнюю роль играет мотивация сотрудников. Я не имею в основном не финансовую мотивацию, а простое желание сделать проект. Интересные задачи, как правило, выполняются быстро и качественно.

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

AVK>Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

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

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

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

AVK>>Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

Д>а бывает, что она составляет основную часть работы. Так что все зависит от проекта,

Именно это я и сказал с самого начала.

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

AF>С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

Ты это всё пробовал или теоретизируешь? Полезность детального проектирования с написанием подробной спецификации и передачей всего этого потом в разработку пэтэушникам придумали большевики вместе с мериканскими мэнеджарами для того чтобы оправдать необходимость аутсорсии. Такая схема работает очень плохо. Архитектору надо продумать каждую строчку кода и её задокументировать. Это объём работ больший чем само по себе написание кода. К тому же многие вещи гораздо проще решаются именно во время процесса написания кода. Одно дело удержать все мелочи в голове и совсем другое выразить их в коде и увидеть проблемы. В общем, бред это всё. Мы опять скатываемся к флейму на тему программистов-дигеров. Не работает это.

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

Д>В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения. Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

Примеры ты конечно придумал классные

UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен. И тому есть много причин:

1. Большинство багов в любом проекте — это UI (ну да, его же рисуют новички ).
2. С автоматическим тестированием UI до сих пор хреново.
3. Все недочёты и недоработки видны невооружённым взглядом, так что схалявить и замазать (типа сделаем две кнопки вместо одной) практически невозможно.
4. Событийная модель, которая делает код трудно понимаемым и поддерживаемым, так сказать код без начала и без конца.
5. Постоянные затычки и workarounds в стандартных и не очень компонентах.
6. Заказчики, всё время требующие воплощения своих фантазий в UI (заметь, про BL они как правило вообще не догадываются).
7. Практически полное отсутствие повторного использования.
8. Среди приоритетов один из первых — это удобство для пользователя, а не чистота объектной модели и пр. лабуды.
9. Постоянная несовместимость с разрешениями, цветовыми схемами, предпочтениями пользователей.

Список можно продолжать.

В общем, насчёт формочек это ты явно мимо кассы. Не каждый профессионал способен написать хороший UI код средней сложности, а уж в результата сваливания UI кода на хрупкие плечи новичков получается редкостное г. Оно как бы работает, но лучше не знать как.

Что там ещё? Обёртки?

Обёртки это первый шаг к разработке public-интерфейсов собственных библиотек и фреймворков. Как работает твоя библиотека внутри мало кого интересует, лишь бы она делала то, что от неё требуется. А вот насколько у неё удобный, последовательный и в то же время достаточный интерфейс — это пользователей как правило волнует и даже очень. Новичок конечно может сделать рапер, но как бы потом на этот рапер не пришлось делать ещё один рапер. Впрочем, если у тебя 10 новичков, то возможно десятая обёртка всей этой луковицы оказажется годной к использованию.

В общем, молодёжь надо учить, а не искать для неё задачи полегче. И самый простой способ — это давать им типовые задачи, которые уже решались профессионалами и в которых нужно просто разобраться и повторить всё по образу и подобию.

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

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

AF>>С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

IT>Ты это всё пробовал или теоретизируешь? Полезность детального проектирования с написанием подробной спецификации и передачей всего этого потом в разработку пэтэушникам придумали большевики вместе с мериканскими мэнеджарами для того чтобы оправдать необходимость аутсорсии. Такая схема работает очень плохо. Архитектору надо продумать каждую строчку кода и её задокументировать. Это объём работ больший чем само по себе написание кода. К тому же многие вещи гораздо проще решаются именно во время процесса написания кода. Одно дело удержать все мелочи в голове и совсем другое выразить их в коде и увидеть проблемы. В общем, бред это всё. Мы опять скатываемся к флейму на тему программистов-дигеров. Не работает это.

Я бы не был столь категоричен. И именно потому, что пробовал и это работало. Правда тут есть довольно сильные зависимости от:
— новичка
— какова реальная сложность кода (именно не критичность или важность, а сложность)
— того, в чём выражается сложность кода (архитектура, алгоритмы, объём)
— того, что из этого новичок может сделать хорошо и качественно

Хотя в целом согласен. Поручать критичные вещи новичку — не лучшая идея.

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

AF> Я бы не был столь категоричен. И именно потому, что пробовал и это работало.

И я пробовал много раз, во многих проектах и во многих командах. С новичками и с профессионалами. И что интересно. Чем больше общения + доверия и меньше бумажек + формализма, тем лучше результат. Новичку конечно можно поручить и довольно сложную задачу. Но он её хорошо решит только под присмотром профессионала. Но в данном случае целью должна быть не освободить профессионала, а научить новичка. Т.е. профику в данном случае нужно будет побыть ещё и нянькой.

AF>Правда тут есть довольно сильные зависимости от:
AF> — какова реальная сложность кода (именно не критичность или важность, а сложность)
AF> — того, в чём выражается сложность кода (архитектура, алгоритмы, объём)

Опять находим противоречие. Простой код проще и быстрее самому написать, чем объяснить кому бы то ни было. Со сложным ещё хуже. Как правило не начав его писать сомому трудно сказать что вообще нужно делать.

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

IT>UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен.

Ха, просто супер.
У меня на эту тему были ну просто войны с коллегами. Сделать качественные контролы и адекватное GUI — это зачастую самые сложные задачи в приложениях. И к ним же обычно самые высокие требования.

Рад, что хоть кто-то считает так же.

--------
Не согласен только насчет "повторного" использования. ИМХО, задачи ввода и автоматизации валидации данных, а так же визуальные use-cases на эту тему весьма поддаются автоматизации.

Примеры, поддающиеся автоматизации (навскидку):
— контрол с данными надо сопровождать специальным лейблом, который автоматически будет disabled/visibled в зависимости от состояния целевого контрола, так же пусть передает фокус на целевой контол при кликаньи на лейбл.

— в момент валидации данных неплохо автоматически установить фокус на контрол, где требуется вмешательство, иногда для этого надо открыть соответствующую вкладку в TabControle, или проскролить, если форма скролится (все это автоматизируется)

— надписи к полям данных (и колонкам таблицы) можно получать автоматически.

— список actions надо привязывать не к контролу, а к полю сущности, тогда формирование индивидуального ContextMenu для контролов и ячеек таблиц будет значительно более простым делом;

— дизайнить менюхи в стандартных дизайнерах — вообще самое ГУИшное зло, необходимо использовать паттерн Command, можно обогощать его доп. признаками, типа код иконки, подсказка, раздел справки и т.д. Тогда будет единообразное построение меню и даже обычных кнопок на форме, связанных с командами, разумеется и единообразная обработка событий от них.
(кстати, неоднократно подумывал о дизайнере менюшек именно под реализацию технологии Command, но все руки не доходят)

— ввести на ГУИ понятие "контейнер данных", наделить его состояниями, обыграть множество use-cases при различных его состояниях. Ввести понятие связанных контейнеров данных.

— заполнение деревях — одно из самых муторных действ. Особенно, если заполянть надо по lazy-loading и из разнородных истоников, отображая разнородные данные. мы решили проблему путем написания набора DataSources под деревяхи и самой деревяхи, умеющей общатся с DataSources. Кода практически не стало.

(список неполный, это что сейчас вспомнилось)

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

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

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

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

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

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

V>Не согласен только насчет "повторного" использования. ИМХО, задачи ввода и автоматизации валидации данных, а так же визуальные use-cases на эту тему весьма поддаются автоматизации.

Полностью со всем согласен. Но я немного не о том. Ты фактически говоришь о разработке UI фреймворка адаптированного к твоей задаче. Здесь можно и нужно выявлять повторно используемый код. Я же говорю о прикладной-логике работы самих форм. Ну, например, у тебя есть комбобокс в котором содержится список адресов. При выборе адреса форма заполняет несколько полей соответствующих этому адресу. Вроде ничего сложного. Но теперь мы хотим повторно использовать эту же логику на другой форме. В большинстве случаев решение — Copy/Paste. Можно конечно сделать контрол, который будет инкапсулировать подобное поведение, но не факт, что на второй форме у нас будет тот же самый лэйаут. Может быть даже надо будет добавить/убрать ещё одно поле. В совсем маразматических случаях среди наших полей может появиться ещё одно вообще не относящееся к делу. Т.е. речь не об универсальной логике взаимодействия контролов и объектов, а о специфике конкретной формы или даже участка формы. Что-то типа visual inheritance компонентов. В идеале, берём такой компонент, кидаем на форму, логику реюзаем, его визуальные части изменяем по собственному усмотрению.

V>Примеры, поддающиеся автоматизации (навскидку):

На предыдущем проекте было у нас что-то подобное. Всё это прошло три или четыре реинкарнации. В результате архитектура UI была намертво прибита гвоздями к архитектуре объектной модели. Не к бизнес-модели, а к самому фреймворку. Начинали мы с команды в 4 постоянно от безделья курящих бамбук BL-девелопера и без передыху пыхтящих ничего не успевающих 4-х UI-щиков, а заканчивали в 3 BL-девелопера и 1-го UI-щика. Вот такой получился эффект. Но возможно это только при интерграции BL и UI фреймворков, а точнее при совместной разработке обоих. Ну и конечно большую роль сиграла квалификация нашего UI-шика. Монстр, блин.

V>- контрол с данными надо сопровождать специальным лейблом, который автоматически будет disabled/visibled в зависимости от состояния целевого контрола, так же пусть передает фокус на целевой контол при кликаньи на лейбл.

Текст для него можно взять, например, из атрибута DisplayName поля объекта на которое забаинден целевой контрол.

V>- в момент валидации данных неплохо автоматически установить фокус на контрол, где требуется вмешательство, иногда для этого надо открыть соответствующую вкладку в TabControle, или проскролить, если форма скролится (все это автоматизируется)

Базовую валидацию тоже можно размечать атрибутами.

V>- надписи к полям данных (и колонкам таблицы) можно получать автоматически.

DisplayName

V>- список actions надо привязывать не к контролу, а к полю сущности, тогда формирование индивидуального ContextMenu для контролов и ячеек таблиц будет значительно более простым делом;

Не знаю. ContextMenu зависит от контекста, а не от объекта.

V>- ввести на ГУИ понятие "контейнер данных", наделить его состояниями, обыграть множество use-cases при различных его состояниях. Ввести понятие связанных контейнеров данных.

В датасетах (точнее у DataRowView) есть весьма простая, но полезная функциональность — IEditableObject. Можно на это посмотреть, да и вообще глянуть на DataRowView полезно.

V>- заполнение деревях — одно из самых муторных действ. Особенно, если заполянть надо по lazy-loading и из разнородных истоников, отображая разнородные данные. мы решили проблему путем написания набора DataSources под деревяхи и самой деревяхи, умеющей общатся с DataSources. Кода практически не стало.

Интересно посмотреть на ваше решение. Вообще же, Lazy loading — это большая палка с двумя острыми концами.

V>(список неполный, это что сейчас вспомнилось)

Да всё понятно Главная идея — UI далёк от совершенства и нам ещё есть над чем работать

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

IT>UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен. И тому есть много причин:

IT>1. Большинство багов в любом проекте — это UI (ну да, его же рисуют новички ).

Единственный мой проект, в котором основные баги были в UI — это был проект с полностью нестандартным интерфейсом а-ля Mac OS. Во всех остальных на него приходилось максимум процентов 20, основная часть — это логика и проблемы в используемых библиотеках. Наверно, мы что-то неправильно делали

IT>2. С автоматическим тестированием UI до сих пор хреново.

Есть такое дело. Да не очень оно и нужно, если есть модульные тесты для логической части.

IT>4. Событийная модель, которая делает код трудно понимаемым и поддерживаемым, так сказать код без начала и без конца.

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

IT>5. Постоянные затычки и workarounds в стандартных и не очень компонентах.

Дык документировать надо, и затычки с обходными решениями — в первую очередь!

IT>6. Заказчики, всё время требующие воплощения своих фантазий в UI (заметь, про BL они как правило вообще не догадываются).

Вот для этого и нужные толковые архитекторы и руководители проектов.

IT>7. Практически полное отсутствие повторного использования.

и что?

IT>8. Среди приоритетов один из первых — это удобство для пользователя, а не чистота объектной модели и пр. лабуды.

и?

IT>9. Постоянная несовместимость с разрешениями, цветовыми схемами, предпочтениями пользователей.

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

IT>Список можно продолжать.

Ну попробуй.

IT>Не каждый профессионал способен написать хороший UI код средней сложности

написать или спроектировать?

IT>Обёртки это первый шаг к разработке public-интерфейсов собственных библиотек и фреймворков.

Я говорил про обертки к чужим библиотекам, которые используются в проекте. Дальнейшее поскипано, ибо к теме отношения не имеет.

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

Честно говоря, не понимаю, о чем вообще спор. Существуют разные программисты — одни профессиональные, другие не очень. В любом среднем проекте имеются и те. и другие, причем вторых намного больше. Это — объективная реальность, данная нам в ощущениях, и другой у нас нет. Остается только организовать работу таким образом, чтобы выполнить проект.
Можно (и нужно) заняться обучением новичков, но основная задача фирмы — производство программ, а не обучение сотрудников за свой счет, и эту задачу надо решать здесь и сейчас.
Можно (и нужно) нанять как можно больше профи, но их число ограничено и на все задачи их не хватит
И какие варианты у нас остаются? Профессионалов отправить кодировать, а новичков поставить ими управлять?

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

VD>Жаль нельзя поставить смайлик на минус. Всегда смешно когда программисты не ставят ни во что свое руководство. Можно подумать, что это они его нанимают, а не наоборот.

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

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

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

Если все же вернуться к теме качества софта (качество ПО — способность ПО удовлетворять предъявленным функциональным и нефункциональным требованиям), то позволю себе настаивать — квалификация разработчиков имеет очень важное значение. Именно разработчики (программисты/дизайнеры/архитекторы) реализуют функциональные и нефункциональные требования в коде и если они не имеют достаточной квалификации — ни о каком качестве не может быть и речи.
Руководство же в большей мере влияет на сроки и бюджет проекта.
Понятно, что все в этом мире взаимосвязанно, но приоритеты я бы расставил именно так.

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

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

AF>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

С точки зрения денег — согласен. Я бы расположил стоимость (в USD) ошибок по мере ее убывания так:

— ошибки в управлении (в том числе и при оценке проекта);
— ошибки анализа и архитектуры;
— ошибки в дизайне и разработке.

Если же говорить о качестве ПО, то ИМНО на первое место выходят ошибки анализа и архитектуры и ошибки в дизайне и разработке.

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

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

AVM>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.

IT>Власть сама по себе не страшна. Страшна власть, которая потворствует принятию "судьбоносных" решений.
Тогда пусть одиним из признаков "квалификации" власти будет ее способность уметь ограничить себя в "потворстве принятию "судьбоносных" решений"

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

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

AF>> Я бы не был столь категоричен. И именно потому, что пробовал и это работало.

IT>И я пробовал много раз, во многих проектах и во многих командах. С новичками и с профессионалами. И что интересно. Чем больше общения + доверия и меньше бумажек + формализма, тем лучше результат. Новичку конечно можно поручить и довольно сложную задачу. Но он её хорошо решит только под присмотром профессионала. Но в данном случае целью должна быть не освободить профессионала, а научить новичка. Т.е. профику в данном случае нужно будет побыть ещё и нянькой.

Игорь, со всем этим я согласен.
Однако мы рассматриваем несколько вырожденный случай. Конечно если у нас 9 профи и один новичок, то проучать новичку наиболее критичный участок, который до этого спроектировал профи, что бы новичок постоянно бегал к нему с вопросами — это как минимум странно.
Я же подразумевал несколько другую ситуацию: команда, где 2-3 профи и 6-8 новичков. В данном случае, когда на одного профи 3-4 новичка, описанная выше стратегия обучения новичков уже работает. Если ребята обучаемые, профи умеет учить — хотя бы средне, то производительность связки профи + 2-4 новичка уже выше чем у одного профи в 1,5 — 3 раза (в зависимости от ситуации). В добавок — по завершению проекта имеем не только сделанный проект, но и несколько более опытных сотрудников. Потому это не только обучение — но и более высокая производительность.

AF>>Правда тут есть довольно сильные зависимости от:
AF>> — какова реальная сложность кода (именно не критичность или важность, а сложность)
AF>> — того, в чём выражается сложность кода (архитектура, алгоритмы, объём)

IT>Опять находим противоречие. Простой код проще и быстрее самому написать, чем объяснить кому бы то ни было. Со сложным ещё хуже. Как правило не начав его писать сомому трудно сказать что вообще нужно делать.
Это если кода мало. А если много и кодеров не один, а несколько?

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

AVM>>>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF>>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
AVM>>Есть, причем прямая связь.
AF> То есть ситуация, когда есть две команды, у первой квалификация в среднем выше, и она проваливает проект, а вторая его делает — это прямая связь?
AF> Или всё-таки стоит рассмотреть, что вы имеете в виду под квалификацией команды? Кого конкретно в команде?
Под квалификаций команды я имею квалификацию каждого члена проектной команды (ПМа, архитектора, дизайнера/разработчика, тест-дизайнера/тестера). Чем выше квалификация членов проектной команды, тем выше вероятность что качество произведенного продукта будет высоким. (Естественно при всех прочих равных условиях).

AVM>>Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.
AF>А что им тосковать — будут учить. <SKIP>
Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?

AF>>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>>Не надо смешивать теплое с твердым.
AVM>>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>>a) хорошего прораба?
AVM>>b) хороших штукатуров?
AF>А вот это зависит от размеров квартиры и того, построена она или нет.
А какая разница? Тебе все равно рано или поздно понадобиться хороший штукатур.

AF>Эта аналогия не совсем применима, по той причине, что перештукатурить совсем не так дёшево, как переписать код.
Стоимость 1 кв метра штукатурки — примерно 10-15 USD. Работы примерно на 20-30 мин. Итого — 5-10 USD/час.
Ты точно уверен что перештукатурить стоит дороже чем переписать код????

AF>>> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
AVM>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
AVM>>Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.
AF>А что есть квалификация Тим-лида и ПМ'а — как не умение смортеть за этими самыми разработчиками?
ИМНО для ПМа важнее правильно сделать оценку проекта, его планирование и уметь грамотно управлять рисками. Зачем к множеству рисков добавлять еще и риск связанный с низкой квалификацией персонала?

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

AVM>Если все же вернуться к теме качества софта (качество ПО — способность ПО удовлетворять предъявленным функциональным и нефункциональным требованиям), то позволю себе настаивать — квалификация разработчиков имеет очень важное значение. Именно разработчики (программисты/дизайнеры/архитекторы) реализуют функциональные и нефункциональные требования в коде и если они не имеют достаточной квалификации — ни о каком качестве не может быть и речи.
AVM>Руководство же в большей мере влияет на сроки и бюджет проекта.
AVM>Понятно, что все в этом мире взаимосвязанно, но приоритеты я бы расставил именно так.

У меня есть несколько догадок по этому поводу:
— Скорее всего у вас работа с требованиями ведётся (как и в большинстве мест) достаточно хаотично.
— Нет регулярных, систематических и глубоких codereview
— Начальство занимается только сроками и бюдежтом (судя по вашим же словам)
— У вас или нет аналитиков и архитекторов вообще или они занимаются лишь общими контурами системы, не вдаваясь в детали
То есть де-факто девелоперу самому надо догадываться, что от него хотят. Да вдобавок его код толком никто не смотрит. То есть вся система в целом зависит от того, как каждый напишет свой кусок. В этом случае совершенно естественно, что ему нужна высокая квалификация.
Если это так, то это только подтверждает как раз то о чём я и говорил — о низкой квалификации управляющих.

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

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

AVM>>>>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF>>>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
AVM>>>Есть, причем прямая связь.
AF>> То есть ситуация, когда есть две команды, у первой квалификация в среднем выше, и она проваливает проект, а вторая его делает — это прямая связь?
AF>> Или всё-таки стоит рассмотреть, что вы имеете в виду под квалификацией команды? Кого конкретно в команде?
AVM>Под квалификаций команды я имею квалификацию каждого члена проектной команды (ПМа, архитектора, дизайнера/разработчика, тест-дизайнера/тестера). Чем выше квалификация членов проектной команды, тем выше вероятность что качество произведенного продукта будет высоким. (Естественно при всех прочих равных условиях).
Это очевидно. Но это ещё не означает, что это наиболее важный критерий. Ты уверен — что в этих "прочих равных условиях" нет чего то такого — что влияет гораздо больше, чем квалификация команды на качество ПО?

AVM>>>Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.
AF>>А что им тосковать — будут учить. <SKIP>
AVM>Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?
Это так. Но только в жизни редко бывает когда задача только одна. И если новичков таки надо учить, то кто это будет делать?

AF>>>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>>>Не надо смешивать теплое с твердым.
AVM>>>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>>>a) хорошего прораба?
AVM>>>b) хороших штукатуров?
AF>>А вот это зависит от размеров квартиры и того, построена она или нет.
AVM>А какая разница? Тебе все равно рано или поздно понадобиться хороший штукатур.
А теперь посмотри на это со стороны фирмы, которая предоставляет услуги штукатуров.

AF>>>> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
AVM>>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
AVM>>>Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.
AF>>А что есть квалификация Тим-лида и ПМ'а — как не умение смортеть за этими самыми разработчиками?
AVM>ИМНО для ПМа важнее правильно сделать оценку проекта, его планирование и уметь грамотно управлять рисками. Зачем к множеству рисков добавлять еще и риск связанный с низкой квалификацией персонала?
Причин может быть несколько сотен.

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

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

AVM>>Если все же вернуться к теме качества софта (качество ПО — способность ПО удовлетворять предъявленным функциональным и нефункциональным требованиям), то позволю себе настаивать — квалификация разработчиков имеет очень важное значение. Именно разработчики (программисты/дизайнеры/архитекторы) реализуют функциональные и нефункциональные требования в коде и если они не имеют достаточной квалификации — ни о каком качестве не может быть и речи.
AVM>>Руководство же в большей мере влияет на сроки и бюджет проекта.
AVM>>Понятно, что все в этом мире взаимосвязанно, но приоритеты я бы расставил именно так.

AF> У меня есть несколько догадок по этому поводу:
AF>- Скорее всего у вас работа с требованиями ведётся (как и в большинстве мест) достаточно хаотично.
нет, этот процесс у нас поставлен сравнительно хорошо, хотя нам еще есть к чему стремиться

AF>- Нет регулярных, систематических и глубоких codereview
Есть формальный code review c иcпользованием check style, кроме того разработчик настраивает IDE так, что бы она показывала ему проблемные места в коде.

AF>- Начальство занимается только сроками и бюдежтом (судя по вашим же словам)
Да, это приоритетная задача руководства. А так же управление рисками.
Насколько я знаю ПМ ни разу не смотрел мой код. Это не его работа.

AF>- У вас или нет аналитиков и архитекторов вообще или они занимаются лишь общими контурами системы, не вдаваясь в детали
У нас на проект всегда есть выделенный аналитик, который занимается требованиями и консультирует разработчиков.

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

AF> Если это так, то это только подтверждает как раз то о чём я и говорил — о низкой квалификации управляющих.
с управлением у нас все в порядке
Кроме этого есть еще выделенная команда тестирования

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

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

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

AVM>>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.

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

Именно так и есть. Это называется знать пределы своей компетентности. И это обязательное условие для менеджеров в любой более-менее вменяемой компании.
Или проще говоря — умение не лезть не в своё дело.

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

VD>Неквалифицированный руководитель — это самое фиговое что может быть. Но от квалифицированного руководителя не будет толку если у него бездарная команда проектировщиков или программистов.

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

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

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

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

AF>>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

Д>>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

AVM>С точки зрения денег — согласен. Я бы расположил стоимость (в USD) ошибок по мере ее убывания так:

AVM>- ошибки в управлении (в том числе и при оценке проекта);
AVM>- ошибки анализа и архитектуры;
AVM>- ошибки в дизайне и разработке.

Согласен. Сразу бы так.

AVM>Если же говорить о качестве ПО, то ИМНО на первое место выходят ошибки анализа и архитектуры и ошибки в дизайне и разработке.

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

С точки зрения клиетна, по моему, качество ПО определяют (по старшинству приоритета):
— Анализ
— Проектирование архитектуры системы
— Проектирование архитектуры модулей/подсистем
— Качество кодирования

А вот с технической точки зрения:
— Качество кодирования
— Проектирование архитектуры модулей/подсистем
— Проектирование архитектуры системы
— Анализ

То есть с точностью до наоборот.

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

AF>>- Нет регулярных, систематических и глубоких codereview
AVM>Есть формальный code review c иcпользованием check style, кроме того разработчик настраивает IDE так, что бы она показывала ему проблемные места в коде.
Ключевое слово здесь — формальный. То есть его проще говоря нет. То есть качество кодирования полностью отдано на откуп самим разработчикам. Вывод очевиден — их влияние на качество выше, чем могло бы быть.

AF>>- Начальство занимается только сроками и бюдежтом (судя по вашим же словам)
AVM>Да, это приоритетная задача руководства. А так же управление рисками.
AVM>Насколько я знаю ПМ ни разу не смотрел мой код. Это не его работа.
Не его. Его работа — организовать, что бы твой код мониторился. И естественно — не им самим.

AF>>- У вас или нет аналитиков и архитекторов вообще или они занимаются лишь общими контурами системы, не вдаваясь в детали
AVM>У нас на проект всегда есть выделенный аналитик, который занимается требованиями и консультирует разработчиков.
Вот это — грамотно

AF>> То есть де-факто девелоперу самому надо догадываться, что от него хотят.
AVM>нет
+1
>>Да вдобавок его код толком никто не смотрит.
AVM>нет
-1 именно так — формальный просмотр кода — это не просмотр вовсе
>>То есть вся система в целом зависит от того, как каждый напишет свой кусок. В этом случае совершенно естественно, что ему нужна высокая квалификация.
AVM>нет
-1 если код не контролируется — его низкое качество может быть не выловлено и тестами и всплывёт у клиента

AF>> Если это так, то это только подтверждает как раз то о чём я и говорил — о низкой квалификации управляющих.
AVM>с управлением у нас все в порядке
AVM>Кроме этого есть еще выделенная команда тестирования
+1 Вот это правильно.

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

AVM>>Под квалификаций команды я имею квалификацию каждого члена проектной команды (ПМа, архитектора, дизайнера/разработчика, тест-дизайнера/тестера). Чем выше квалификация членов проектной команды, тем выше вероятность что качество произведенного продукта будет высоким. (Естественно при всех прочих равных условиях).
AF>Это очевидно. Но это ещё не означает, что это наиболее важный критерий. Ты уверен — что в этих "прочих равных условиях" нет чего то такого — что влияет гораздо больше, чем квалификация команды на качество ПО?
Есть, но если мы говорим о качестве, то IMHO квалификация первое НЕОБХОДИМОЕ условие

AVM>>Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?
AF>Это так. Но только в жизни редко бывает когда задача только одна. И если новичков таки надо учить, то кто это будет делать?
А система образования зачем

AF>>>>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>>>>Не надо смешивать теплое с твердым.
AVM>>>>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>>>>a) хорошего прораба?
AVM>>>>b) хороших штукатуров?
AF>>>А вот это зависит от размеров квартиры и того, построена она или нет.
AVM>>А какая разница? Тебе все равно рано или поздно понадобиться хороший штукатур.
AF>А теперь посмотри на это со стороны фирмы, которая предоставляет услуги штукатуров.
Позиция этой фирмы очевидна и их цель расходится с моей целью.

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

AF>>>- Нет регулярных, систематических и глубоких codereview
AVM>>Есть формальный code review c иcпользованием check style, кроме того разработчик настраивает IDE так, что бы она показывала ему проблемные места в коде.
AF>Ключевое слово здесь — формальный. То есть его проще говоря нет. То есть качество кодирования полностью отдано на откуп самим разработчикам. Вывод очевиден — их влияние на качество выше, чем могло бы быть.

Ты неправильно понял значение слова "формальный". Формальный не в том смысле что "можно забить", а в том смысле что процедура code review описана, тулзы сконфигурированы для типовых случаев и требований и подстраиваются для каждого проекта.
Иногда (если требует заказчик) снимаются метрики кода для выявления проблеммных мест. Code review делается персонально (смотришь свой код) и перекрестно (смотришь код соседа).
так что с этим все в нормально

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

AVM>>>Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?
AF>>Это так. Но только в жизни редко бывает когда задача только одна. И если новичков таки надо учить, то кто это будет делать?
AVM>А система образования зачем
И ты знаешь хотя бы один вуз, который выпускает готовых программистов?

AF>>>>>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>>>>>Не надо смешивать теплое с твердым.
AVM>>>>>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>>>>>a) хорошего прораба?
AVM>>>>>b) хороших штукатуров?
AF>>>>А вот это зависит от размеров квартиры и того, построена она или нет.
AVM>>>А какая разница? Тебе все равно рано или поздно понадобиться хороший штукатур.
AF>>А теперь посмотри на это со стороны фирмы, которая предоставляет услуги штукатуров.
AVM>Позиция этой фирмы очевидна и их цель расходится с моей целью.
Естественно. Пока ты не штукатур на этой фирме...

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

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

AF>>>>- Нет регулярных, систематических и глубоких codereview
AVM>>>Есть формальный code review c иcпользованием check style, кроме того разработчик настраивает IDE так, что бы она показывала ему проблемные места в коде.
AF>>Ключевое слово здесь — формальный. То есть его проще говоря нет. То есть качество кодирования полностью отдано на откуп самим разработчикам. Вывод очевиден — их влияние на качество выше, чем могло бы быть.

AVM>Ты неправильно понял значение слова "формальный". Формальный не в том смысле что "можно забить", а в том смысле что процедура code review описана, тулзы сконфигурированы для типовых случаев и требований и подстраиваются для каждого проекта.
AVM>Иногда (если требует заказчик) снимаются метрики кода для выявления проблеммных мест. Code review делается персонально (смотришь свой код) и перекрестно (смотришь код соседа).
AVM>так что с этим все в нормально

Тогда каюсь, был неправ. Написал бы просто — формализованный, вопросов бы не было.

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

AVM>>Если же говорить о качестве ПО, то ИМНО на первое место выходят ошибки анализа и архитектуры и ошибки в дизайне и разработке.

AF>Согласен. Правда тут есть маленькая оговорка — качество можно рассматривать с разных точек зрения, рассматривать с точки зрения клиента — то есть соответствие ПО его задачам, а можно рассматривать с чисто технической точки зрения — как стабильность работы, число падений и т.п.
"стабильность работы, число падений и т.п." есть ничто иное как не функциональные требования.
Если они будут учтены при анализе, то не будут реализованы и протестированы. Так что без анализа никуда.

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

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

AVM>>>>Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?
AF>>>Это так. Но только в жизни редко бывает когда задача только одна. И если новичков таки надо учить, то кто это будет делать?
AVM>>А система образования зачем
AF>И ты знаешь хотя бы один вуз, который выпускает готовых программистов?
MIT

AVM>>Позиция этой фирмы очевидна и их цель расходится с моей целью.
AF>Естественно. Пока ты не штукатур на этой фирме...
Если штукатур вменяемый, то он стремиться повысить свою квалификацию, делать качественную работу, получать хорошие рекомендации и вознаграждение. У меня знакомый паркетчик, берет дорого но к нему очередь стоит. Причем его бригадиру и в голову не приходит мысль заменить его на несколько бестолковых паркетчиков. Наооборот ему в помошь выделили несколько квалифицированных людей и он уверен, что никто из этих людей не запьет, ничего не стащит, и шлифмашину не воткнет в розетку 380В из-за своей низкой квалификации.

Думаю, что сначала неплохо определиться с понятием "качество".

Для клиента качество ПО определяется в основном:
1. Соответствие функционала требованиям.
2. Количество багов.
3. Удобство использования ПО.
В принципе, менеджер выдвигает к ПО те же требования. Таким образом на первый план выходит анализ требований. Самая распрекрасная программа не стоит ничего, если она никому не нужна, или ей неудобно пользоваться, в отличии от конкурентов. Баги вычищаются в первую очередь тестированием, и еще раз тестированием. В принципе, даже самый гнилой код можно вычистить от багов, и с точки зрения клиента ПО будет просто отличным.

Второе понимание качества ПО — качество самого кода. Ни клиенту, ни менеджеру до него особого дела нет. Но, несомненно, косвенно качество кода влияет на качество продукта и на усилия, затрачиваемые на его поддержку и внесение изменений. Для получения качественного кода нужно сочетание определенных условий, все они важны и несоблюдение одного из условий может просто убить весь эффект, полученный от остальных.
1. Постоянный рефакторинг. Без него любая самая замечательная архитектура обрастает "костылями" со всеми вытекающими последствиями.
2. Стиль кодирования. Пожалуй это основное. Если девелопер привык писать "грязный" код, решая сиюминутные задачи, то какой бы он ни был квалифицированный и опытный, от него вреда будет больше, чем толку.
3. Соблюдение code convention. Очевидное условие.
4. Code review.

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

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

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

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

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

Д>Единственный мой проект, в котором основные баги были в UI — это был проект с полностью нестандартным интерфейсом а-ля Mac OS. Во всех остальных на него приходилось максимум процентов 20, основная часть — это логика и проблемы в используемых библиотеках. Наверно, мы что-то неправильно делали

Я же говорю, если UI примитивный, то проблем нет. Например, взял из БД датасет, забаиндил его на грид и готово.

IT>>4. Событийная модель, которая делает код трудно понимаемым и поддерживаемым, так сказать код без начала и без конца.

Д>Трудно понимаемый и поддерживаемый — это когда всю логику навешивают на форму? Не спорю, только научить отделять мух от котлет можно даже новичков, если у них в голове не совсем уж пусто.

Ну и куда ты отделишь такую вещь как считывание значения полей из формы и заполнение объектов? Базовую валидацию и выдачу сообщений об ошибках ввода?

IT>>5. Постоянные затычки и workarounds в стандартных и не очень компонентах.

Д>Дык документировать надо, и затычки с обходными решениями — в первую очередь!

Что документировать? Как сделать флэт комбобокс в html?

IT>>6. Заказчики, всё время требующие воплощения своих фантазий в UI (заметь, про BL они как правило вообще не догадываются).

Д>Вот для этого и нужные толковые архитекторы и руководители проектов.

Ну да. Хорошо бы ещё и толкового заказчика при этом.

Д>и что?
Д>и?

IT>>9. Постоянная несовместимость с разрешениями, цветовыми схемами, предпочтениями пользователей.

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



IT>>Список можно продолжать.

Д>Ну попробуй.

Да ты не кипятись так Мы же всё понимаем. У тебя и заказчик правильный, и архитекторы с руководителями само собой

IT>>Не каждый профессионал способен написать хороший UI код средней сложности

Д>написать или спроектировать?

Проектировать интерфейс должны ПМ (в смысле продакт) вместе с аналитиками и заказчиком. Результатом должен быть альбом с wireframes. Ну это в идеале конечно.

IT, в целом согласен, есть одно уточнение:

> Д>Трудно понимаемый и поддерживаемый — это когда всю логику навешивают на форму? Не спорю, только научить отделять мух от котлет можно даже новичков, если у них в голове не совсем уж пусто.

> Ну и куда ты отделишь такую вещь как считывание значения полей из формы и заполнение объектов? Базовую валидацию и выдачу сообщений об ошибках ввода?

Отделить-то можно (Model-View-Controller и т.п.), но подобный подход, реализуемый настолько последовательно, что это приводит к возможности повторного использования отдельных аспектов, требует еще более высокой квалификации разработчиков.

Дарней,

> VD>Жаль нельзя поставить смайлик на минус. Всегда смешно когда программисты не ставят ни во что свое руководство. Можно подумать, что это они его нанимают, а не наоборот.

> Вот и я тоже все время удивляюсь таким "непризнанным гениям".
> Если начальник действительно неадекватен — можно без труда занять его место, при условии что вышестоящее начальство фирмы не такое же тупое. Если неадекватно все начальство фирмы — что вообще делать в такой фирме?

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

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

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

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

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

Здравствуйте, AndreyFedotov.

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

Главное в разработке ПО — настрой всех сотрудников. Прежде всего, настрой на творческий процесс при проектировании.

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

---

Надёжный код могут написать только разбирающиеся в тематике приложения сотрудники и только путём его многократного переписывания с начала и доконца. Лучше если сотрудники работают на пределе квалификации (это можно устроить в любом проекте). Лучше, если и несколько архитектур будет испытано.
Пример: А.С. Пушкин.

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

Проще говоря, нужна не просто хорошая организация проекта, нужна организация, направленная в основном имеенно на надёжность (на 90%)

---

Тут говорилось о том, что "новички" довели кого-то до "кандратия".
Я — очень молодой программист. Однако, буквально недавно проволялся с гипертоническим кризом 3 дня из-за программы, написаной другим "новичком", причём, формально, он опытнее меня (у меня вообще диплом только бакалаврский диплом [4 курса, ещё учусь]).
А вот на мои исходники обыно мало ругаются (обычно, но иногда приходится доставать ручку и записывать новые слова ).

По поводу "нянек".

Неопытным сотрудникам вовсе не нужна "нянька", им нужна фора времени и доступ к необходимой информации.

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

Ещё видел собственными глазами, и не только видел но и пытался помочь. Всем отделом однажды объясняли одному опытному цифровику как работают цифровые фильтры. Объяснить так и и не смогли, хотя сами знали...
Так что по поводу нянек — враньё, самое настоящее.

---

Прошу прощения, не совсем конечно. Консультации нужны, но всё-таки не в таких масштабах.

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

FDS>Главное в разработке ПО — настрой всех сотрудников. Прежде всего, настрой на творческий процесс при проектировании.

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

FDS>Надёжный код могут написать только разбирающиеся в тематике приложения сотрудники

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

FDS>Да и ещё, необходимо, что бы каждый отрывок кода верифицировался на соответствие созданному заранее абстрактному алгоритму, а этот алгоритм доказывался.

А если таких отрывков 100. А если 1000? А если такого формального алгоритма не существует?

FDS>Верификация должна проводиться независимо несколькими сотрудниками, желательно, не участвующими в разработке.

Unit testing by HR. А если тестировщики тоже допустят ошибку?

FDS>Неопытным сотрудникам вовсе не нужна "нянька", им нужна фора времени и доступ к необходимой информации.

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

FDS>Прошу прощения, не совсем конечно. Консультации нужны, но всё-таки не в таких масштабах.

В каких таких?

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

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

FDS>>Главное в разработке ПО — настрой всех сотрудников. Прежде всего, настрой на творческий процесс при проектировании.

AVK>Настрой это конечно здорово, но он, такая вот штука, очень быстро улетучивается, поэтому на одном настрое далеко не уедешь.

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


FDS>>Надёжный код могут написать только разбирающиеся в тематике приложения сотрудники

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

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

FDS>>Да и ещё, необходимо, что бы каждый отрывок кода верифицировался на соответствие созданному заранее абстрактному алгоритму, а этот алгоритм доказывался.

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

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


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


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


AVK>Unit testing by HR. А если тестировщики тоже допустят ошибку?

Все мы там будем.

---

FDS>>Неопытным сотрудникам вовсе не нужна "нянька", им нужна фора времени и доступ к необходимой информации.

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

Согласен. Я и сказал в конце, что помощь обязательно нужна. Как раз про это было сказано.
Однако обычно за очень сложные проекты новичков и не сажают. Да и бывает такое, что новички справляются и с очень сложными вещами, хотя сам, честно говоря, такого не видел. Может врут?

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

FDS>>Прошу прощения, не совсем конечно. Консультации нужны, но всё-таки не в таких масштабах.

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

Не в масштабах "нянек". Я уже говорил, что неплохо, если программист работает на пределе возможностей. Особенно, если он молодой программист.

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

Здравствуйте, 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> Однако современный порядок дел обстоит так, что проекты становятся все сложнее и сложнее и потребность в неквалифицированной рабочей силе падает.

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

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

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

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

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

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

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

Просто других нет.

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

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

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

Спутниковый софт — это не софт???!!! Жуть.
Ошибки реализации это, в том числе, и ошибки при разработке алгоритмов. Речь идёт не о том, как понята задача, а о том, насколько правильно разработан для её выполнения алгоритм. То есть ошибки не при кодировании, а при разработке до кодирования.