728x90 분류 전체보기101 리팩토링&코드정리 방향성에 대한 고찰 각종 아키텍처 관련 책을 읽고 tidy first란 책을 읽는 와중에,어떤 분께서 리팩토링의 방향성에 대해 고민하고 있다는 이야기를 들었습니다. 그래서 한번 고민해봤습니다. 리팩토링과 코드정리의 정의를 엄격하게 구분한다면 따로 다뤄야 할 것 같은데,저는 리팩토링과 코드정리를 `동작 변경이 없는, 코드를 정리하는 행위`라는 공통점으로 함께 다루었습니다. 리팩토링을 왜 했는가? 저는 습관적으로 리팩토링을 해왔던 것 같습니다.보이 스카우트 규칙(떠날 때는 찾을 때 보다 캠프장을 더욱 깨끗이 하라)을 열심히 지키고자, 개발을 할 때 무언가 눈에 거슬리는 게 있으면 함께 고쳐왔습니다. 일단 제가 한 리팩토링은,눈에 거슬리는 지저분한 코드를 보자마자 고치는, 무지성 리팩토링(코드 정리)였습니다. 그래서 얻은 .. 2024. 5. 12. ADR (Architecture Decision Records) 아키텍쳐 결정 레코드 업무를 하다보니, 아키텍쳐 결정 레코드에 대한 니즈를 절실히 느껴 이를 만들고 관리하기로 했습니다. 템플릿을 공유합니다. # 해결된 문제 및 솔루션의 짧은 제목 ## Context and Problem Statement 상황 및 문제 설명 ## Decision Drivers 의사결정 동인 * …## Considered Options 고려된 옵션 1. 2. …## Decision Outcome 결정 결과 선택한 옵션과 그 이유### Consequences 결과 * Good, 이유 * Bad, 이유* Neutral, 이유 (Neutral : 좋지도 나쁘지도 않은 경우)… ### Confirmation 확인 ## Pros and Cons of the Other Options 다른 옵션의 장단점 ### 옵션.. 2024. 5. 12. CompletableFuture runAsync/supplyAsync/get runAsync, supplyAsync, get 코드리딩 CompletableFuture는 exceptionally로 예외를 핸들링 할 수 있고 그렇지 않으면 get()을 통해 캐치할 수 있음을 외워도 되지만, 급할 때는 코드를 읽어봐도 됩니다! runAsync, supplyAsync get 2024. 3. 2. CompletableFuture 코드 리뷰 기록 안녕하세요! 얼마 전에 저희 팀 성실천재쥬니어님의 PR에 코드 리뷰를 진행하였습니다. 하나의 서비스 흐름에서 모든 인터페이스의 리턴 타입이 CompletableFuture였습니다. 먼저 비즈니스를 살펴보고 코드를 읽다보니 Fire and Forget 패턴을 CompletableFuture + AsyncHttpClient를 통해 구현하신 것 같았습니다. (정확한 사유는 아직 여쭤보지 않아서 모릅니다. 그냥 코드 보고 추측했습니다.) 충분히 사용할 수 있는 기술들이지만 해당 PR에서는 몇가지 크리티컬한 문제가 있었고, 현재 구조에서는 불필요한 것 뿐만 아니라 코드의 복잡성을 올린다고 판단하여 CompletableFuture를 모두 걷어내고 AsyncHttpClient도 SyncHttpClient으로 변경하길.. 2024. 2. 10. Spring Batch의 JobParameter 설정 우선순위 spring batch의 Job을 실행할 때 사용되는 JobParameter 객체가 있습니다. 이 객체는 Job을 실행할 때 필요한 모든 파라미터를 담고 있고, 이 파라미터는 Job을 실행할 때 주입해줄 수도 있고 내부에서 코드를 통해 생성할 수도 있습니다. 외부와 내부에서 모두 같은 키에 대한 값을 생성할 때 어떤 것이 더 높은 우선순위를 가지는지 알아보겠습니다. 테스트를 위해 JobParametersIncrementer의 구현체를 하나 만들었습니다. public class CustomIdIncrementer implements JobParametersIncrementer { @Override public JobParameters getNext(final JobParameters parameters) .. 2024. 2. 3. ULID (Universally Unique Lexicographically Sortable Identifier) 유일성을 보장히는 식별자를 만드는 방법은 다양합니다. 그 중 UUID는 많이 들어보았을 것입니다. > UUID는 128bit으로 표현하는 중복되지 않는 식별자를 만들기 위한 표준 규약입니다. (중복 확률이 0은 아니지만 0에 가깝습니다) UUID는 128bit을 16진수로 표현한 32개의 문자로 이루어져 있습니다 (규약대로 하이픈을 추가하면 문자열로 봤을 때는 36자입니다) UUID와 비슷하지만 조금 다른 것이 있는데 그것이 바로 ULID 입니다. ULID는 Timestamp와 Randomness로 구성되어 있습니다. ULID의 특징은 다음과 같습니다. 128-bit compatibility with UUID 1.21e+24 unique ULIDs per millisecond Lexicographical.. 2024. 1. 31. checksum(체크섬, 검사합), CRC(순환중복검사) Checksum 체크섬은 중복 송/수신자간 데이터가 손상(data corruption)되었는지 확인하는 방법입니다. 여기서 송/수신자는 네트워크상 sender/receiver가 될 수 있고, client와 server가 될 수도 있습니다. 송신자는 전송할 데이터를 가지고 특정식을 수행한 후 전송합니다. (비트 단위로 구분하고 1의 보수를 취하고 그것들을 더하는 식) 수신자는 받은 데이터를 가지고 같은 방식으로 계산을 해 데이터 손상이 발생했는지 확인합니다. (계산 결과가 다르면 데이터 손상이 발생한 것입니다.) 네트워크 시스템에서는 TCP/IP가 위 checksum을 사용하고 있습니다. 굉장히 간단하지만, 데이터 순서가 바뀌는 오류에 대한 검출은 하지 못하는 점, 그리고 데이터의 무결성을 검증하는 것에 .. 2024. 1. 30. MySQL on duplicate key update & affected rows 오늘은 upsert를 위해 많이 사용하는 on duplicated key update와 이 때 상황에 따른 affected rows를 알아보려고 합니다. on duplicate key update는 중복되는 고유키(Unique Key)가 없으면 insert, 고유키가 있으면 update를 하는 명령입니다. (고유키이므로 당연히 PK도 포함입니다.) INSERT INTO TABLE(A, B, C) VALUES ( X, Y, Z ) ON DUPLICATE KEY UPDATE A = X, C = Z 위 구문은 다음을 의미합니다. 중복되는 키가 없다면 insert구문을 실행하고, 중복되는 키가 있다면 update 구문을 실행하라. 이 때 해당 테이블에 설정된 고유키의 수와 관계 또한 중요하지만 이것은 다음에 알.. 2024. 1. 25. 연습#weekly 이제 가끔 올리므로 weekly라고 이름을 바꿨습니다ㅋㅋ 오늘은 미디엄문제도 하나 풀었습니다. 비록 쉬운 문제들을 풀지만 1일 1알고리즘 열심히 수행하고 있습니다. https://leetcode.com/problems/number-complement https://leetcode.com/problems/check-if-word-is-valid-after-substitutions/ https://leetcode.com/problems/maximum-product-of-two-elements-in-an-array/description/ https://leetcode.com/problems/convert-binary-number-in-a-linked-list-to-integer https://leetcode... 2024. 1. 20. 연습#33~34 https://leetcode.com/problems/minimum-distance-to-the-target-element/ https://leetcode.com/problems/reverse-prefix-of-word/ 당분간 많이 바빠져서 daily 업로드는 못 하고 매일매일 풀긴 하지만 블로그에는 몰아서 도장을 찍으려고 합니다. 이제 easy문제는 어느정도 익었으니 medium으로 넘어가볼까 생각중입니다. 2024. 1. 16. 연습#32 일본 여행에 다녀왔습니다. 다시 시작합니다!!! 쉬운 문제로 재시작~~ 0번 인덱스부터 반복문을 돌면서 cur-target > 0 으로 계산했는데, 많은 분들이 바이너리 서치를 통해 풀었네요 2024. 1. 12. 다양한 캐시 전략들 캐시는 일정 기간동안 임시로 데이터 하위집합을 저장하기 위한 fast data storage layer입니다. 캐시란? 캐시에 대하여 캐시는 일정 기간동안 임시로 데이터 하위집합을 저장하기 위한 fast data storage layer입니다. 캐시는 어디에나 존재합니다. 하드웨어 캐시(ex. L1, L2), 페이지 캐시, 데이터베이스 캐시, API캐시, DNS캐 chupin-tech.tistory.com 이런 캐시를 구성하는데 다양한 전략이 있습니다. 내 애플리케이션의 읽기/쓰기 패턴에 맞는 전략을 선택하면 매우 효과적인 캐시 시스템을 구축할 수 있을 것입니다. 캐시에는 어떤 전략이 있는지 Read와 Write를 분리하여 알아보겠습니다. Read 전략 1. Cache-Aside 가장 기본적이고 일반적인.. 2024. 1. 5. 이전 1 2 3 4 5 6 ··· 9 다음 728x90
