Прошу прощения, а на ваших проектах руководители проектов задействованы?

да кому нужны эти дармоеды!

4uva4ok
Да, насколько помню, в ASAP именно про code review не сказано, но в целом сути не меняет. Есть стандартные этапы, которые тоже ужимают или вообще убирают.
У меня в нескольких разных компаниях был code review. Я не АБАПер, но, считаю, это оправдывающая себя точка контроля, особенно на очень крупных проектах, чтобы не наступил когда-нибудь хаос : )
Старшие товарищи сами себя не проверяют, они сами не пишут, как правило : )

ImpCons
Ну вот с банковской выпиской очень хороший пример. Автоматизировала ее и не раз – и входящую, и исходящую.
Примерная схема входящей выписки: берешь выписку за 3-6 месяцев для начала. Разбираешь каждую операцию - да, очень муторно порой (хорошо, когда в банке есть уникальный ключик под операцию, тгда vlookup и фильтры рулят, если нет, то сложнее, но все равно реально. У меня на практике только у одного банка не было такого ключика, повезло), прописываешь каждую уникальную операцию в Excel, параллельно копируешь в свой файл для тестирования. Потом этот Excel отправляешь бизнесу на проверку с просьбой указать схему проводок под КАЖДУЮ такую уникальную операцию.
Потом все настраиваешь, абапишь что-то, тестируешь, гоняешь эти файлы с уникальными операциями, выбранными из реальных файлов за 3-6 месяцев.
Далее это все добро тестирует бизнес. Объясняешь ,что можно погонять и мой файл, ну лучше взять еще реальных файлов, а еще лучше за год, но это редко бывает реально. Да, как правило, есть затыки с мастер данными, но на большинстве проектов прогружали мастер данные в рамках тестирования миграции, так что тоже вопрос решаем вполне). Акцентриуешь внимание на операциях, которые бывают редко. Человек/ люди, которые «сидят» на банках, в целом владеют ситуацией относительно таких редких операций.
Далее продуктив. Если бизнес прогнал пару раз такие файлы за 3-6 месяцев хотя бы, то ОТКУДА во время продуктива потребуется новый абапер??? Ну да, можно отловить пару новых операций, которые не выловились в файле за полгода, но это же не переписывать прогу с нуля. Программа стабильна в целом, а это рабочий момент, который очень даже может возникнуть и в будущем. Бизнес то развивается.
Если бизнес не прогнал как следует все в тесте, то это уже совсем другой вопрос. На мой взгляд, явное нарушение методологии. Да, на огромных проектах это очень трудоемко, согласна, но методологию то никто не отменял. Иначе да, будьте готовы к большим сюрпризам в продуктиве. И непосредственные руководители не всегда готовы озвучить пробему перед руководством, которое может принять решение о ресурсах и сроках.
На моем текущем проекте в начале стадии реализации возникла одна новая «хотелка» относительно миграции данных (большой такой кусок данных). Ну чего, взяли нового человека от бизнеса на 2,5 месяца, чтобы занимался этой задачей – сводил все эти таблички, выверял и т.д. Да, теоретически можно было «размазать» задачу по всем консультантам, ну работали бы на час другой больше каждый день, ну результат может был бы не очень. Но вот он грамотный подход – в итоге задача была решена нормально. Не идеально, немного с ошибками, но в целом хорошо.

Задействованы. И ?

Anna Turunova, согласен с таким подходом как у Вас очень даже и можно оттестировать все операции. Но получается что Вы и провели тестирование на данных нескольких периодов, причем с загруженными мастер данными. Т.е. Вы считаете что по методологии ведения проекта эти работы должны всегда планироваться на интегратесте или предварительных испытаниях? По операциям загрузки ЭБВ, вы факт БДДС собираете и правильное прописывание ФП тоже сами проводите? Если у клиента до внедрении SAP, в старой системе, например 1С, не реализован был контроль за лимитами БДДС, а сейчас его во внедрении SAP реализовываеся, то из-за этого меняются/добавляются документы их взаимосвязь и т.п. которые перед загрузкой ЭБВ используется и соответственно появляются нюансы по созданию документов по перечислениям между подразделениями, в/из кассу(ы), на карт счета и т.п. Необходимость контроля лимитов БДДС сильно добавляет нюансов в цепочки платежных документов и анализировать нужно не только схемы проводок (которые можешь узнать у бухгалтерии), но и как организовать правильный контроль за лимитами БДДС (узнавать нужно в финслужбах) - обем работы сразу растет.
По поводу работ по анлизу старых выписок, для больших проектов - на прошлом проекте у нас было 26 БЕ, на текущем около 100-150 подразделений имеющих расчетные счета, да и существует разделение по настройкам операций при загрузке ЭБВ между функциональными группами- отдельно FI настраивает бухгалтерские настройки, отдельно FM отражение их в бюджете и решать за другую группу проводить анализ банковских выписок тут понятное дело не смогу, да и пробить у РП наверно тоже. Понятное дело что всевозможные варианты настраиваем и проверяем, но на анализ банковской выписки старых периодов на таких объемах и в самом деле нужно при наличии серъезного добавления ресурсов.
Хотя согласен с Вами подход очень классный на небольших проектах где буду делать и FI и FM обязательно воспользуюсь им.

Неплохой пример, на котором можно проиллюстрировать
1) необходимость code review
2) почему порой срочно требуется новый абапер, несмотря на отличное тестирование , если не было 1)

Реальный пример:

Видимо неплохие консультанты , но посредственные программисты на одном из реальных проектов сотворили с обработкой выписки следующее: Собрали все примеры выписки за 3-6 месяцев. Молодцы. Далее консультант не нашел ничего лучше, чем прописать все "стандартные" ключевые слова из выписок в некий словарь, который чудесно "захардкодил" прямо в код модуля. Написал могучий блок кода , использую оператов ветвления и в результате тесты прошли блестяще , систему передали в продуктив.

А потом началось веселье:
1) так как не было ни нормального программиста, ни системы контроля качества кода, внутрь никто не посмотрел - да и зачем , оно ведь работает. Систему приняли в продуктив. Через месяц эксплуатации системы , как можно легко догадаться, появилась "уникальная выписка" , вновь нанятый консультант не нашел ничего лучше , как "захардкодить" очередной "нюанс". Через год эксплуатации данный модуль превратился в помойку. Как и следовало ожидать.

После того как пользователи устали ругаться и писать ТЗ на доработку , наконец-то на модуль взглянул программист , который сделал code-review, вынес словарь терминов в настройку и переписал модуль парсинга на более-менее универсальный алгоритм. История завершилась.

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

ImpCons
Да подход сбора информации и настройки системы может отличаться. На больших проектах в первую очередь рулит интерграция. Ее нет, все, пиши пропало, проблем не оберешься. Кто спорит Я просто привела схематичный пример. Когда много компонентов, конечно, сбор информации в части интеграции, настройки и т.д. намного сложнее.
Если у вас много-много БЕ, так что, можно собрать процентов 30 инфы и на этом успокоиться???

Но!!! Тестирование в полном объеме должно быть. Хотя бы 80-90% операций. Иначе система будет нестабильна просто, и там уже как повезет.
У меня есть знакомая, она работает тестировщиком (не знаю, как праивльно термин по-русски) программного обеспечения в США. Их таких там целая контора, которые только и делают, что тестируют.
А смысл нести в продуктив что-то, что нормально не протестировано и бизнесом не согласовано? Чтобы Акты подписать? А как люди потом на местах будут работать. Извините, но срочность несольких программистов во время продуктивного старта - я считаю, что это в корне не правильно. Это мое мнение.

Всегда есть базовые параметры (это как SAP, как круги Эйлера ), которые всегда пересекаются (да и не только для SAP). Сроки, деньги, человеческие ресурсы с определенным опытом и отношением к работе. Чем всего больше и лучше, тем и результаты лучше. Просто всегда стремятся на чем-то сэкономить. Без последствий это обычно не прокатывает.
Скажите нейрохирургу перед сложной операцией: денег нет, давай побыструхе, там еше пять человек под капельницами на очереди. Ну грустно же.
Не вижу больше смысла в дискуссии.

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

4uva4ok
Обычно приемку кода делают до переноса в кволити для тестирования (ну, у меня на проектах было так).
Это минимум две цели:
1) руководство в курсе, что есть проблема и с этим нужно что-то делать. Или привлекать другие ресурсы, или искать какой-то другой временный вариант решения проблемы и т.д. В зависимости от масштаба бедствия
2) экономия времени и нервов бизнеса и консультанта, которые это все потом в кволити будут тестировать.

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

Проблема контроля возникла не на пустом месте, это дань реальности. А реальность состоит из нескольких прискорбных истин:

1) Если бы 8 из 10 так называемых абаперов , попали на работу в обычную команду разработчиков на любом другом языке программирования типа C# для какой-нибудь классической СУБД, то они были бы изгнаны с позором на 2 неделе своей работы за полную концептуальную безграмотность.
2) Даже приличные программисты из оставшихся зачастую работают во внешнем консалте , и им зачастую наплевать на то, сколько проживет их программа и насколько она эффективно будет работать через месяц после старта. Это объективный факт - когда ты работаешь в штате , то тебе просто некуда деться с подводной лодки и все твои недоделки к тебе же и вернутся , добавив к тому же неприятности на работе.
3) Проекты по внедрению функциональности требуют зачастую Десятка разработчиков и один-два приличных и ответственных ситуации не спасают. За остальными нужно постоянно следить и убирать их из проекта чем раньше, тем лучше для заказчика.

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

Везет. А я уже (со стороны консалта) устал бодаться, чтобы аудит проводили хотя бы до переноса в продуктив.
С одной стороны это так. С другой абап - сильно привязан к системе, которая требует сил для изучения во много больше, чем "C# для какой-нибудь классической СУБД". Как ни крути - любой софт крайне сложная штука, которая кажется на первый взгляд очень простой. Поэтому сделать нормальные разработки за период обычного проекта - невозможно. Либо внедрение будет стоить дорого, либо придется внутренней команде потом дополировывать решение.

А вот реальных проблем с эффективностью программ не припомню. Нужно конкретно смотреть. Есть примеры?

А какой смысл ревьюить абсолютно сырую непротестированную разработку? Она еще по результатам тестов в кволити 20 раз существенно поменяться может - без конца все обновления ревьюить?

4uva4ok
А какой смысл супер сырую разработку тащить в кволити? Вообще-то перед кволити консультант в системе разработок все обязан протестировать. Для этого есть SCC1, все прекрасно носится по 5000 раз, если нужно.
Ну, потом, конечно, бывает доработки (именно доработки). Все они проходят code review в обязательном порядке.
Повторюсь, далеко не на каждом проекте была такая процедура, к сожалению.

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

Смысл в том, что в системе разработок не всегда есть данные, на которых можно приличный тест провести.
Более-менее актуальные данные, скопированые с продуктива - в тестовой системе. Она по идее и служит для проведения полномасштабных тестов.
Если все создавать и тутже тестировать в системе разработок - то зачем вообще 3-ландшафтная система нужна.