Басня об "одном флаконе"

Здесь я хочу поговорить о культуре программирования на SAP-проектах. Изначально я планировал включить этот кусок в качестве небольшого лирического отступления к одному из своих ПОЧЕМУ (см. вступление к одному из первых моих постов). Но, как водится, сказать нашлось много чего.

Итак, на заре своей SAP-карьеры, но уже имея некоторый опыт работы, я пытался устроиться в одну уважаемую западную компанию на должность консультанта по SAP SEM. На интервью я шел с радужными мыслями. Ведь, я собирался поменять область деятельности. Прощайте, годы программирования и копания в технических настройках! Я хотел стать функциональным консультантом по SAP SEM. Своими представлениями я заранее поделился с рекрутером, который отправлял меня на то интервью. Он меня похвалил за четкое позиционирование и сообщил, что это как раз то, что нужно его клиенту. Концептуальное проектирование системы, интервью и консультирование заказчиков, применение и изучение методик стратегического управления предприятием - вот, что меня ждало, и я этого хотел! Передо мной открывались новые горизонты, интересные дела. Внутри бродил тревожный, но приятный холодок неизвестности. Я думал: "Уж в западных конторах-то знают, как правильно внедряются системы. У них там и методологии, и разделение обязанностей, и ваще все по уму". На то, как внедряется SAP, да и, вообще, любая система российскими интеграторами, я уже насмотрелся...

Меня собеседовал какой-то начальник отдела. В какой-то момент он спросил: "А приходилось ли вам писать на ABAP-е?". Я сказал, что нет. Он поцокал языком и сообщил: "Вообще-то, без ABAP консультанту в SAP-е никуда. Стандартного функционала настолько часто не хватает, что практически в любом месте приходится хоть две строчки, но написать. А нередко и отнюдь не две." Во мне зародилось смутное подозрение, что эту работу я не получу. Потом он начал мучать меня вопросами вроде "а как нам сделать так, чтобы если в продуктив BW придет пакет лишь с парой ошибочных записей, то не надо было бы удалять и перегружать все, ведь инициализация дельты может проходить сутки?". Мне приходилось мычать или пытаться выжать из своих обширных обще-IT-шных и скудных BW-шных знаний хоть что-нибудь, что напоминает ответ. Я понял, что работу точно не получу. Но заодно и понял и другое.

Понял, что моему идеализму нет места на российском рынке специалистов по SAP Business Intelligence (это сейчас этот термин активно используется, а тогда говорили просто SAP SEM или SAP BW/SEM). Ситуация в России и тогда, и сейчас сродни вообще ситуации с любой профессией в сфере IT: нужно все и сразу, и в одном флаконе. И не важно, какая порода у конторы-интегратора: российская или западная.

Сейчас, умея ABAP-ить, и зная почти все о BW, я, скорее, соглашусь с тем начальником, но соглашусь лишь отчасти. На то место наверняка взяли BW-шника с опытом в ABAP-е. Может, он был грамотный программист, но это вряд ли. Среди "модульных" консультантов SAP я еще не видел ни одного, кто хотя бы сносно пишет на ABAP-е. Да и, вообще, на каком-нибудь языке. Основной принцип: лишь бы работало. Господа, чем ТАК писать, лучше не писать вообще! И, уважаемые работодатели, не гонитесь за тем пресловутым "одним флаконом": лучше наймите немного больше ABAP-еров и дайте им посидеть со вступительным курсом по нужному модулю. Или, хотя бы, потрудитесь проверить, как справляется "модульный" консультант с ABAP-ом, прежде, чем он начнет "колбасить" на проекте.

Практически только у профильных программистов на SAP-проектах получается качественный код. У консультантов же на входе:

• Дурной стиль кода. Например, не видел, чтобы кто-то задумывался о системном применении отступов и регистра символов, и в идентификаторах, и в ключевых словах. Тут еще употребление переносов строк, комментарии, логическое разбиение на блоки операторов и многое-многое другое. Ну, кто знает, что такое плохой стиль, - тому объяснять не надо.
• Запутанная, неочевидная логика. Усугубляется тем, что плох стиль, но это не главная причина. В стремлении к тому, чтобы "лишь бы заработало", консультант по многу раз вносит небольшие правки и пробует кусок кода, а когда он, наконец, заработал, бросает как есть, вместо того, чтобы "причесать" его.
• Бездумный Copy-Paste. Консультанту проще скопировать кусок кода откуда-нибудь еще и "подкрутить" его, чем разобраться, как он работает и понять, что из него, например, нужна только одна строчка. Или он весь, вообще, не нужен.
• "Hard-coded" подход. Например, использование выборки напрямую из таблицы через оператор SELECT, а не использование специализированного гибкого функционального модуля или класса, разработанного SAP.
• Просто неоптимальный код. Консультант не есть профессиональный ABAP-ер, поэтому просто не может знать, как проще, быстрее и эффективнее реализовать ту или иную задачу. Или делается так, что вызывается один и тот же код по многу раз, хотя достаточно и одного, но вначале. В результате, получаются хромые и кривые ABAP-убожества.
• Отсутствие обработки особых ситуаций. Хороший программист всегда учитывает, что на вход куску кода могут попасть самые различные данные или внутри него могут возникнуть ошибки. Консультант почти никогда не думает об этом. "Лишь бы работало!"

На выходе:

• Кирпич в себе. Представление о том, что делает этот нечитабельный код имеет только тот, кто его писал, да и то через некоторое время это будет весьма не факт. Чтобы модифицировать такой негибкий код, нужно прилагать чудовищные усилия, если не переписывать полностью под новые требования. Заказчик получает вещь в себе, монолитный немодифицируемый кирпич.
• Тормоза. Неоптимальный, раздутый, да мало ли еще какой может быть плохой код. А заказчик страдает, ожидая построения отчета по 20 минут или завершения обработки по несколько часов. Его, конечно, успокоят: "Ничего, все в порядке. SAP - прожорливая система. Поставьте еще один сервер, добавьте памяти, и будет вам щастье".
• Ползучие ошибки. Консультанты попробовали на паре (ну хорошо, не на паре - на тысяче, код-то неправильный!) записей - ура, все работает! Работу сдали, а потом медленно начнут проявляться "непонятные" ошибки. То на каком-то материале отчет "валится в дамп", то почему-то зависает Java-часть, то просто результаты не верные. А заказчик либо столкнется с простоем системы, либо внедрение просто затянется.

Поверьте, как правило, при той загрузке и темпах работы, что имеет "модульный" консультант, у него в голове остается очень немного места, чтобы еще при этом и хорошо программировать. И даже можно не уточнять, SAP это или не SAP. То, что я сказал выше, вполне можно приложить и к любой корпоративной информационной системе, которая внедряется в России. Лично я был свидетелем этого в той же Axapta, пардон, Microsoft Dynamics AX.

Итак, диагноз поставлен, и еще раз рефреном сформулирую лечение:

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

А пока мы имеет то, что я еще неоднократно буду ссылаться на этот пост в своих последующих ПОЧЕМУ :)