Продолжаем рубрику единого стиля Clean ABAP. Обсудим основные моменты написанные в книге, а также напишите в комментариях пользуетесь ли вы этими рекомендациями, если да, то какими, если нет, то почему?
Тезисно по 2-ой главе книги. Подглавы:
- 2.1. Помните о легаси коде
- 2.2. Помнить о производительности
Помнить о легаси коде
Ниже приведены некоторые советы и рекомендации по «чистому» ABAP, когда дело доходит до устаревшего кода:
- В основном независимые
Например, предложенные форматирования и комментирования не менялись десятилетиями, и вы сможете использовать Clean ABAP точно так же, как рекомендуется, во всем вашем ландшафте. - Игнорирование посторонних конструкций
В некоторых разделах вы найдете примеры с утверждениями, которые могут быть недоступны в ваших самых старых системах. Однако вы также обнаружите, что можете просто игнорировать эти утверждения и применять концепции в любом случае. - Сокращение последних конструкций
В некоторых разделах этой книги рекомендуется использовать новейшие языковые конструкции. В этих случаях вы можете определить самый поддерживать, а затем согласовать форму, доступную в этой версии. Большинство новейших языковых конструкций не увеличивают возможности ABAP; они просто уменьшают объем кода, который вам нужно написать. Таким образом, возврат к более старой форме может быть немного менее читабельным, но вы не потеряете никаких функций. - Компенсация недоступных конструкций c методами
Во многих случаях вы можете компенсировать недоступные языковые конструкции. Например, возможно, вы не можете использовать оператор VALUE, но в таких случаях добавление короткого метода аналогичного по конструкции VALUE, все равно даст вам чистый код. - Поддержание согласованной кодовой базы
Хорошая идея-синхронизировать стиль кода, даже если системы не подключены. Разработчикам не только может потребоваться регулярно переключаться между этими системами, но они могут даже иметь разные версии, открытые одновременно в нескольких окнах на своих рабочих столах. Согласование одного стиля кода для всех избавляет людей от лишних секунд, необходимых для выяснения, в какой версии они работают. - Разделение кодовой базы
В некоторых случаях предпочтительнее разделить кодовую базу на одну часть, использующую более новые конструкции, и другую, использующую более старые. Это разделение обычно происходит, когда вам действительно нужны новые конструкции, потому что они предоставляют новые способности. Например, относительно новые процедуры ABAP-Managed Database Procedures (AMDPS6) настолько упрощают взаимодействие с объектами базы данных, что вы можете захотеть их использовать, даже если некоторые старые системы в вашем ландшафте их не поддерживают. В этом случае вы должны сделать разделение очевидным и чистым, сохранив код в разных пакетах или транспортных слоях. Ваши разработчики могут сразу увидеть, к какой "ветви релиза" относится код, и вы сможете предотвратить случайные промахи. - Пересматривать при обновлении
Если вы согласны с более старым стилем кода, не забудьте пересмотреть это решение при обновлении ваших старых систем, иначе первоначальная причина вашего решения может быть потеряна.
Помните о производительности
Основная проблема при начинании с Clean ABAP заключается в том, что это может привести к снижению производительности существующих программ. В конце концов, некоторые наши предложения, кажется, противоречат производительности.
Прежде всего безвредны
Большая часть Clean ABAP посвящена темам, которые никак не влияют на производительность. Давайте возьмем, к примеру, именование, форматирование или комментарии, которые никак не помешают. С другой стороны мы имеем дело с областями, где производительность в любом случае не представляет первостепенного интереса. Эта часть относится к таким видам деятельности, как обработка исключений и модульное тестирование. Таким образом, большинство принципов Clean ABAP не влияют на производительность и могут быть безопасно применены к любому проекту. Даже если вы ограничите себя исключительно этими порциями Clean ABAP, вы все равно значительно выиграете.
Начинайте с чистого листа, деградируйте только там, где это необходимо
Основная тема, которая волнует людей, это сделать классы и методы маленькими. Следование этому совету может сделать вещи немного медленнее и больше. Меньше классы часто означают больше объектов, которые, в свою очередь, обычно потребляют больше памяти и требуют больше времени для их создания. Маленькие методы означают больше вызовов методов и, следовательно, более глубокие стеки вызовов. В то время как многие языки используют низкоуровневые оптимизации компилятора, такие как инлайнинг, которые буквально заставляют границы методов исчезать на уровне процессора, ABAP тратит свое время на проверку типов данных при каждом вызове. Эти различия невелики в индивидуальном масштабе, но в больших программах они могут складываться до такой степени, что может возникнуть необходимость нарушить некоторые «чистые» правила ABAP.
Рассмотрим теоретическую сторону: представьте себе, что программное обеспечение «А» имеет хорошее время отклика, но испорченный код, а программное обеспечение «Б» прямо противоположное, с чистым кодом, но испорченным временем отклика. Обе крайности нежелательны, конечно, но не одинаково. Программное обеспечение «А» делает практически невозможным выход из тупика без полной перестройки, что настолько дорого, что вряд ли когда-либо произойдет. В отличие от этого, плохая производительность программного обеспечения B, вероятно, может быть, улучшена путем рефакторинга или замены критических частей-шагов, которые имеют гораздо более приемлемые оценки усилий благодаря его чистому дизайну и высокому автоматическому охвату тестированием.
Начните с чистого дизайна и чистого кода. Если требования к производительности заставляют вас отойти от «чистых» предложений ABAP, делайте это постепенно, как можно меньшем количестве выбранных мест. Этот подход приведет вас к общему результату, который будет одновременно чистым и быстрым.
Не думайте о размере
Некоторое время назад кто-то измерил, что RETURN больших таблиц из методов происходит гораздо медленнее, чем их EXPORT. Эта идея вошла в документацию, литературу и учебные курсы. Инспектор кода был даже создан для проверки этой ситуации. Когда люди цитировали это правило, они мудро кивали и оставляли его неоспоримым.
Когда мы придумали чистый ABAP, мы обнаружили, что RETURN таблицы позволят нам писать более короткий и лаконичный код. Поэтому мы бросили вызов правилу RETURN и EXPORT и провели серию измерений, которые показали, что оба способа были одинаково быстрыми во всех последних выпусках ABAP. Мы поговорили о некоторых из них, и, наконец, языковая группа ABAP подтвердила, что некоторое время назад они добавили оптимизацию, которая заставила оба варианта использовать один и тот же механизм памяти; никакой разницы в производительности не существует ни в теории, ни на практике.
Если вы имеете дело с производительностью, не позволяйте смутным страхам и слухам ввести вас в заблуждение. Основывайте свои решения и шаблоны кодирования на реальных измерениях, которые вы выполняете для отдельных случаев, которые вы хотите подвергнуть сомнению.
Скоро вернусь...