애플리케이션 개발자는 제품을 빌드하고 출시하여 다음 제품을 빌드하기 시작해야 하는 끊임없는 압박을 받습니다. 앱에 마지막 광택을 입히는 데 시간을 할애하는 것은 개발자가 모든 I에 점을 찍고 T에 교차시키고 싶어하더라도 그들에게는 허락되지 않는 사치일 수 있습니다.
I에 점을 찍고 T에 가로선을 긋는 것은 최종 결과에 건강합니다. 물론, 논리적이고 잘 유지 관리되는 탐색기 폴더 구조는 화려한 새로운 기능이나 세련된 UI의 "와우" 요소가 없을 수 있습니다. 그러나 잘 만들어진 앱은 추가로 투자한 시간 이상의 혜택을 제공합니다.
- 기술 부채를 최소화합니다
- 앱 유지 관리가 더 쉬워집니다
- 이를 통해 개발자를 프로젝트에 더 쉽게 합류시킬 수 있습니다.
최소한의 침으로 최대한의 광택을 얻을 수 있도록 돕기 위해 애플리케이션 비즈니스 기능 요구 사항 외부에서 더 깨끗하고 유지 관리 가능한 애플리케이션을 구축하기 위한 고려 사항 영역의 몇 가지 예를 모아 보았습니다. Mendix.
보안, 보안, 보안
개발 및 테스트 전반에 걸쳐 보안에 대한 고려 사항은 항상 염두에 두어야 합니다. 그러나 최소 권한 원칙을 유지하도록 전체 보안 구현을 정기적으로 검토하는 것이 좋습니다. 이는 일반적으로 다양한 수준의 여러 개발자가 있기 때문에 특히 중요합니다. Mendix 개발 경험이 있고 동일한 애플리케이션을 동시에 작업합니다.
엔터티 수준 보안 유지
엔터티와 속성에 대한 CRUD 권한을 검토해야 합니다. 의미가 있는 경우 Xpath 제약 조건을 적용하여 엔터티에 대한 CRUD 액세스 권한을 추가로 제한합니다. 예를 들어, account 객체 =가 me에 속하는 경우에만 속성에 대한 읽기 액세스를 허용합니다.
또 다른 고려 사항은 '새 멤버의 기본 속성 권한'을 '없음'으로 설정하는 것입니다. 개발자가 각 속성의 읽기/쓰기 액세스 권한을 자동으로 설정하고 나중에 생각하도록 두는 대신 이에 대해 생각하는 것이 좋은 관행입니다.
민감한 상수에 대한 기본값을 비워 둡니다.
상수(환경 변수)의 모든 기본값을 비웁니다. 민감한 데이터 (예: API 키). 민감한 정보를 상수의 기본값으로 저장하지 마세요.
기본 'MxAdmin' 관리자 사용자 이름 변경
내가 추천 이름 바꾸기 또는 기본 관리자 사용자를 사용자 지정합니다.
모델링
주소 모델러 경고
의미가 있는 경우 권장 사항을 구현하십시오. '경고' 탭 사용자 정의 모듈의 경우
애플리케이션 로그 검토 및 개선 기회 식별
애플리케이션 로그에는 모델링 오류의 증상을 식별하는 데 도움이 되는 풍부한 정보가 포함되어 있습니다. 아래 예에서 경고 메시지는 애플리케이션에서 발생하는 자동 커밋 동작에 대해 알려주지만 대신 명시적으로 커밋해야 합니다.
MxAssist 모범 사례 봇을 들어보세요
따라서 MxAssist 베스트 프랙티스 봇 수천 개의 익명화된 데이터에 대한 통계 분석을 통해 일반적인 안티 패턴을 학습합니다. Mendix 앱. 또한 통합 Mendix 마이크로플로, 도메인 모델, 페이지, 보안 등을 개발하기 위한 모범 사례. 봇의 권장 사항을 검토하고, 의미가 있는 경우 구현합니다.
가정
도메인 모델을 읽기 쉽게 유지하세요
아래 예를 살펴보세요. 오른쪽의 데이터 모델은 프로젝트에 온보딩하는 새로운 개발자에게 더 이해하기 쉬울 것입니다.
더 읽기 쉬운 마이크로흐름을 위해 색상을 사용하세요
By 기본 색상 적용 선택된 마이크로플로우/나노플로우 동작을 통해 가독성을 크게 향상시킬 수 있습니다.
위의 스크린샷을 잠깐 살펴보면 마이크로플로우 로직 내의 하위 마이크로플로우 호출(녹색)과 로깅 작업(회색)을 쉽게 식별할 수 있습니다.
사용하지 않는 품목 정리
사용자 지정 생성 애플리케이션 모듈에서 사용되지 않는 항목을 정리하거나 "사용되지 않음"으로 표시합니다. 사용되지 않거나 제외된 항목을 참조로 유지하면서 Project/App Explore를 깨끗하게 유지하려면 '사용되지 않음' 폴더에 넣습니다.
마켓플레이스 모듈을 업데이트하고 Mendix Studio Pro
마켓플레이스 모듈과 귀하의 업데이트 기회를 식별하세요. 버전 Mendix 신규 개발. 이렇게 하면 최고 수준의 보안과 안정성을 누릴 수 있으며 다음에 필요한 업그레이드의 영향을 최소화할 수 있습니다.
맺음말
프로덕션에 배포할 때마다 깨끗하고, 체계적이고, 최적화된 애플리케이션을 유지하면 애플리케이션 엔진이 '잘 윤활'되고 다음 반복을 위해 준비된 상태가 됩니다. 제품 반복의 끝에서 큰 일회성 연습이 아닌, 제가 공유한 권장 사항을 일상적인 개발 주기의 일부로 통합하면 더 쉬워질 것입니다.
이 블로그에서 다루는 요점은 프로덕션 배포 전에 애플리케이션을 다듬기 위한 포괄적인 목록이 아닙니다. 다음 기사에서 훨씬 더 유용한 제안을 찾을 수 있습니다.