Здравствуйте, 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>В каких таких?

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

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