Что вы думаете о тестовых заданиях?

[ax_mct]

Цитата:

Сообщение от EVGL

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

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

[EVGL]

Цитата:

Сообщение от ax_mct

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

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

[ax_mct]

Цитата:

Сообщение от EVGL

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

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

То есть вопрос в ролях и ожиданий насколько самостоятелен должен быть водитель.

[gudzon]

Цитата:

Сообщение от ax_mct

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

То есть вопрос в ролях и ожиданий насколько самостоятелен должен быть водитель.

Очень правильные слова.

[Ivanhoe]

Цитата:

Сообщение от ax_mct

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

Цитата:

Сообщение от EVGL

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

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

[ice]

Цитата:

Сообщение от Ivanhoe

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

а время потраченное программистами на уточнение ТЗ будет оплачено?

[Ivanhoe]

Цитата:

Сообщение от ice

а время потраченное программистами на уточнение ТЗ будет оплачено?

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

P.S. Такая мысль. Никто ж не заставляет платить за рекламу или тестовый образец? Тут также. Все что нужно, уже заложено в ставку. Риски "не продать" - такие же как и везде. Подумайте, как продаются проекты по Акс (как консалтингом, так и внутренние проекты) - там всегда есть "бесплатная" работа. Так устроен этот бизнес.

Цитата:

Сообщение от ax_mct

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

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

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

Если делим что-то на что-то нужно сначала проверить, не появится ли в знаменателе 0.

Если что-то ищем, потом нужно поверить нашли ли и решить что делать, если не нашли.

Если есть if нужно подумать, что делать в случае else и нужно ли.

Если есть swith в нем обязателен default.

И никогда не верить предположениям. Типа "ну тут то никак не может быть иначе". Может. И надо подумать как на это реагировать.

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

[ax_mct]

Цитата:

Сообщение от Кирилл

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

Это все верно на уровне реализации конкретного метода или методов, но не решения/проекта в АОТ. То есть это необходимо но часто недостаточно.
То есть хороший программист АХ должен думать не только о вариантах на уровне кода но и о вариантах использования на функциональном уровне то есть пользовательского интерфейса. Иначе он "плохой"