코딩 팁

만큼 태그릿이나 HTL을 사용하십시오.

JSP에 scriptlet을 포함하면 코드에서 문제를 디버깅하는 것이 어렵습니다. 또한 JSP에 scriptlet을 포함함으로써 단일 책임 원칙 및 MVC 디자인 패턴을 위반하는 보기 레이어와 비즈니스 로직을 구분하는 것은 어렵습니다.

읽을 수 있는 코드 쓰기

코드는 한 번 작성되지만 여러 번 읽습니다. 작성 코드를 정리하기 위해 시간을 좀 더 할애하면 Adobe와 다른 개발자들이 나중에 이 코드를 읽어야 할 때 배당금을 지불할 것입니다.

이름을 표시하는 의도 선택

이상적으로 다른 프로그래머는 컨텐츠를 이해하기 위해 모듈을 열 필요가 없습니다. 마찬가지로, 그들은 어떤 방법이 그것을 읽지 않고 무엇을 하는지 말할 수 있어야 한다. 이러한 아이디어를 보다 잘 구독하면 보다 쉽게 코드를 읽을 수 있고 보다 빠르게 코드를 작성하고 변경할 수 있습니다.

AEM 코드 베이스에서 다음 규칙이 사용됩니다.

• 인터페이스의 단일 구현 이름은 <Interface>Impl, 즉ReaderImpl.
• 인터페이스의 여러 구현 이름이 <Variant><Interface>(예:JcrReader 및 FileSystemReader.
• 추상 기본 클래스의 이름은 Abstract<Interface> 또는 Abstract<Variant><Interface>입니다.
• 패키지의 이름은 com.adobe.product.module입니다. 각 Maven 아티팩트 또는 OSGi 번들에는 고유의 패키지가 있어야 합니다.
• Java 구현은 API 아래의 구현 패키지에 배치됩니다.

이러한 규칙을 고객 구현에 반드시 적용할 필요는 없지만 규칙을 정의하고 준수하여 코드를 유지 관리할 수 있어야 합니다.

이상적으로, 이름들은 그들의 의도를 드러내야 한다. 이름이 분명하지 않은 경우에 대한 일반적인 코드 테스트는 변수나 메서드가 의미하는 것을 설명하는 주석이 있는 것입니다.

자신을 반복하지 마십시오.

DRY는 동일한 코드 집합을 복제할 수 없다고 말합니다. 이것은 문자열 리터럴과 같은 것에도 적용됩니다. 코드 복사는 어떤 것이 변해야 할 때마다 결함의 문을 열고, 찾고 제거해야만 한다.

벌거벗은 CSS 규칙 방지

CSS 규칙은 애플리케이션 컨텍스트에서 대상 요소에 따라 달라야 합니다. 예를 들어 .content.center​에 적용되는 CSS 규칙은 지나치게 광범위하며 잠재적으로 시스템 전체에 걸쳐 많은 컨텐츠에 영향을 줄 수 있으므로 나중에 다른 사람이 이 스타일을 무시할 것을 요구합니다. .myapp- centertext는 응용 프로그램 컨텍스트의 가운데 텍스트를 지정할 때 ** 보다 구체적인 규칙이어야 합니다.

사용되지 않는 API 사용 제거

API가 더 이상 사용되지 않을 때 사용되지 않는 API에 의존하지 않고 항상 새로운 권장 방법을 찾는 것이 좋습니다. 향후 업그레이드를 보다 원활하게 진행할 수 있습니다.

지역화할 수 있는 코드 작성

작성자가 제공하지 않는 모든 문자열은 JavaScript의 I18n.get() JSP/Java의 CQ.I18n.get()​을 통해 AEM i18n 사전에 대한 호출로 둘러싸야 합니다. 이 구현은 구현을 찾을 수 없는 경우 전달된 문자열을 반환하므로 기본 언어로 기능을 구현한 후 로컬라이제이션을 유연하게 구현할 수 있습니다.

안전을 위한 리소스 경로 이스케이프

JCR의 패스에는 공백이 없어야 하지만 공백이 있으면 코드가 깨지지 않습니다. Jackrabbit는 escape() 및 escapePath() 메서드를 사용하여 Text 유틸리티 클래스를 제공합니다. JSP의 경우 Granite UI는 granite:encodeURIPath() EL 함수를 표시합니다.

XSS API 및/또는 HTL을 사용하여 사이트 간 스크립팅 공격 방지

AEM은 XSS API를 통해 손쉽게 매개 변수를 정리하고 사이트 간 스크립팅 공격에 따른 안전 조치를 보장합니다. 또한 HTL은 이러한 보호 기능을 템플릿 언어로 바로 구축했습니다. API 요약서는 개발 - 지침 및 우수 사례에서 다운로드할 수 있습니다.

적절한 로깅 구현

Java 코드의 경우, AEM은 메시지 로깅을 위한 표준 API로 slf4j를 지원하며 관리의 일관성을 위해 OSGi 콘솔을 통해 사용할 수 있는 구성과 함께 사용해야 합니다. Slf4j는 5개의 서로 다른 로깅 수준을 표시합니다. 메시지를 기록할 수준을 선택할 때는 다음 지침을 사용하는 것이 좋습니다.

• 오류:코드가 손상되어 처리를 계속할 수 없습니다. 이는 예상치 못한 예외로 인해 발생하는 경우가 많습니다. 일반적으로 이러한 시나리오에 스택 추적을 포함하는 것이 유용합니다.
• 경고:제대로 작동하지 않지만 처리를 계속할 수 있습니다. 이것은 종종 PathNotFoundException​과 같이 우리가 예상했던 예외의 결과입니다.
• 정보:시스템을 모니터링할 때 유용한 정보입니다. 이것이 기본값이며 대부분의 고객은 이 설정을 환경에 그대로 둡니다. 그러므로 그것을 지나치게 사용하지 말아라.
• 디버그:처리에 대한 하위 수준 정보. 지원 관련 문제를 디버깅할 때 유용합니다.
• TRACE:가장 낮은 수준 정보(예: 메서드 입력/종료). 일반적으로 개발자만 사용합니다.

JavaScript의 경우, console.log​는 개발 중에만 사용해야 하며 모든 로그 문은 릴리스 전에 제거해야 합니다.

카고 컬트 프로그램 방지

코드 내용을 이해하지 않고 코드를 복사하지 마십시오. 확실하지 않은 경우 모듈 또는 API에 대해 더 많은 경험이 있는 사람에게 명확하지 않은 것을 확인하는 것이 가장 좋습니다.