- 익명으로 편하게 고민, 일상을 공유하는 소셜 네트워크 서비스입니다.
해당 프로젝트의 모든 정보는 WIKI 를 참고하실 수 있습니다.
└─ src
├─ docs Rest Docs API 자동화 관련
├─ api-guide.adoc
├─ api-html.adoc
├─ main
├─ kotlin
├─ com.flabedu.blackpostoffice
├─ commom 공통으로 사용하는 파일들
├─ annotation - 사용자 권한 체크등 관련된 어노테이션
├─ config - Redis, MySQL Replication, S3등 설정 파일 관련
├─ encryption - 비밀번호 암호화등 관련
├─ enumeration - 사용자 권한 부여등 Enum Class
├─ interceptor - 스프링 인터셉터를 통해 중복 코드를 제거하기 위한 것과 관련
├─ property - yml파일을 객체에 매핑하여 property로 사용
├─ utils.constants - 공통 상수 관련
├─ controller Model과 View의 연결하는 제어 로직을 담당
├─ exception 예외처리 관련
├─ dto - 예외처리 관련 데이터 교환을 위해 사용
├─ handler - 전역적으로 예외를 다루는 핸들러
├─ mapper Mybatis 매핑XML에 기재된 SQL을 호출하기 위한 인터페이스
├─ model 비즈니스 로직과 사용되는 데이터를 다루는 영역
├─ service 비즈니스 로직을 수행
├─ test 테스트 코드 관련
├─ kotlin
├─ com.flabedu.blackpostoffice
├─ ... - 여러 기술들의 트레이드 오프를 고려한 후, 어떤 기술을 도입하는 것이 가장 서비스에 가장 적합할까?
- 다른 개발자가 내 코드를 보았다고 가정할 때, 어떻게 코드를 작성하는 것이 이해하기 쉬운 코드이며 유지보수에 용이한 코드일까?
- 꾸준히, 깊은 이론 학습을 통해 내가 작성한 코드를 어떻게 더 좋은 코드로 만들까?
- 대용량 트래픽의 상황에서 지속적인 서버 개선을 위해 어떻게 성능을 튜닝할까?
- 위의 관심사들을 기반으로 고민한 이슈들을 기술블로그 에 작성하고 팀 내 공유하여 함께 성장해가는 개발 문화 추구
- 자바에서는 형식을 맞추기 위해 무의미하고 반복적인 코드를 작성하게 되어 항상 코드가 비대해지기 마련이었습니다. 저는 이 문제를 해결하기 위해 코틀린을 사용하였습니다.
- 코틀린은 타입 추론과 더불어 자체적으로 함수형 프로그래밍을 지원해주기 때문에 자바에 비해 훨씬 코드를 간결하게 작성할 수 있었으며 개발 생산성과 유지 보수성 면에서도 훨씬 좋은 성과를 거두었습니다.
- 또한 코틀린은 별도의 표기가 없는 경우 널 값을 허용하지 않기 때문에 자바에서 흔히 발생하는 널 포인터 예외를 피할 수 있었습니다. 이는 널 포인터 때문에 프로그램이 중단되는 현상을 방지하는 성과를 거둘 수 있었습니다.