리팩토링7 1. 좋은 함수 만들기 - 부작용과 거리두기 요즘의 개발에서 프레임워크나 라이브러리 사용이 없는 개발은 생각하기 어렵다. 특히 DDD 등의 개념까지 기본지식처럼 취급되어 점점 추상화된 개발에 익숙해지고 있다. 복잡한 애플리케이션 구현을 하다보면 이러한 것들에 대해 당연히 필요하다. 다만, 이게 심해지다보면 실제 구현을 해야할 변수, 함수, 클래스 등을 잘 작성하는 것보다 프레임워크나 라이브러리의 기능을 얼마나 많이 알고 있느냐를 개발자의 성장으로 오해할 수도 있다. 프레임워크와 라이브버리와 같은 도구에 대해서 숙련도가 높다면 당연히 좋겠지만, 그 이전에 좋은 변수, 함수, 클래스에 대해 먼저 고민하는 것도 필요하다. 그래서 이번 시리즈에서는 좋은 함수에 대해서 이야기하려고 한다. JS/TS 환경에서 불변객체 다루는 방법이 순수 함수형 언어들에 비해.. 2023. 1. 18. 5. 테스트하기 좋은 코드 - SQL 지난 시간까지 애플리케이션 코드를 어떻게 개선하면 좋을지에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 3. 외부에 의존하는 코드 개선 4. 검증이 필요한 비공개 함수 개선 이번 편에서는 애플리케이션 코드가 아닌 Query (비단 RDBMS뿐만 아니라 NoSQL도 해당) 에 대해서 이야기를 해본다. 최근엔 ORM (혹은 ODM) 사용이 대중화되었지만, 여전히 많은 프로젝트에서는 SQL Builder를 통해서 Native Query를 작성한다. SQL Builder를 통해서 Native Query를 작성하는 것은 복잡한 조회 조건이 필요한 환경에서는 굉장히 효율적인 방법이다. 예를 들어, 통계/정산/물류 등 복잡한 조회 Query가 필요하거나, Bulk Insert등.. 2022. 10. 18. 2. 테스트하기 좋은 코드 - 제어할 수 없는 코드 개선 1편 을 통해 테스트하기 어려운 코드에 대해 이야기를 나눴다. 이번 편에서는 테스트하기 어려운 코드 중 첫번째인 "제어할 수 없는 코드를 개선하는 법"을 이야기해보자. 2-1. 문제 상황 먼저 앞에서 보았던 discount() 코드를 다시 보자. export default class Order { ... discount() { const now = LocalDateTime.now(); if (now.dayOfWeek() == DayOfWeek.SUNDAY) { this._amount = this._amount * 0.9 } } } 이 discount() 는 실행할때마다 항상 결과가 다르다. LocalDateTimw.now()의 코드를 보면 알겠지만, 현재 시간은 항상 다르기 때문이다. 그렇기 때문에 실행.. 2022. 9. 1. TDD 잘알못을 위한 돌직구 세미나 참석 후기 OKKY 최단시간 마감 세미나! TDD 잘알못을 위한 돌직구 세미나에 다녀왔습니다. 세미나 링크 발표순서는 변경되어서 박재성님이 먼저 진행하셨습니다. 가장 빨리 마감된만큼 참석을 원했지만 아쉽게 안되신 분들도 많을거라 생각합니다. 모든 내용을 다 담진 못했지만, 최대한 미참석자분들에게 공유될 수 있도록 작성했습니다. 이걸로 조금이나마 아쉬움을 달래셨으면 합니다. 그럼 발표 내용 시작하겠습니다! 1. 박재성 Naver -> 아키에이지 -> NHN Next 에서 활동 NEXT 종료 후 뭘할지 고민하다가 교육으로 가게 됨 NextStep으로 1인 교육 사업 자바지기 -> SLIPP 커뮤니티 운영 이 발표에서는 TDD와 리팩토링을 왜 해야하는지 알고 있다는 가정하에 진행 개발 현장을 떠난지 6년이 되어가고 있음.. 2018. 6. 22. 4. 악취나는 코드 개선하기 시리즈 - 값의 가변성 (Mutation) IntelliJ 블로그에 올라온 시리즈물을 번역 & 재정리 하였습니다. 심하게 중첩된 코드글에서 저는 getMappedField 메소드의 리턴 타입을 Optional로 변경하고 싶었습니다. 변경자체는 굉장히 사소한 일이지만, 그 메소드를 호출하는 코드들의 변경은… 음 또다른 문제였습니다. QueryValidator클래스의 validateQuery메소드는 여러 호출자 중에서 예상했던 것보다 훨씬 더 복잡한 메소드였습니다. getMappedField를 Optional로 변경하려고 할때, 놀라울 정도로 많은 Null 체크 코드를 isPresent로 변경했습니다. 이게 전부가 아닙니다. 이 메소드는 거의 100라인이라 1개의 캡쳐화면에 전부 담을수가 없었습니다. (이것 역시 다른 글의 주제가 될 예정입니다.) .. 2017. 9. 18. 2. 악취나는 코드 개선하기 시리즈 - 심하게 중첩된 코드 IntelliJ 블로그에 올라온 시리즈물을 번역 & 재정리 하였습니다. 악취나는 코드 개선하기 시리즈를 계속 진행하며, 이번 포스트에서는 명백한 리펙토링을 거부하는 천진난만한 코드를 살펴 보려고 합니다. 코드 예제 자체는 매우 사소한 것이지만 실제로는 이 특정 프로젝트에서 반복적으로 발견되는 문제의 증상입니다. 즉, 코드의 중첩입니다. 이것은 loop문, if 문, 심지어 람다 표현식 또는 내부 클래스, 또는 위의 모든 것의 조합 일 수 있습니다. The Smell: Deeply Nested Code 먼저 발견한 문제있는 코드는 내부 if 문이있는 double for 루프입니다. (MappedClass의 메소드) 이 코드의 문제점은 무엇입니까? 단일 문자 변수 이름(mf, n)를 관대하게 봐줄수 있고, .. 2017. 9. 3. 이전 1 2 다음
