Sadie의 개발일기

https://sadie100.github.io/CypherTypeTest/ 사이퍼즈 성향 테스트 sadie100.github.io 3년 전에 만들고 Netlify를 통해 배포했던 사이퍼즈 플레이어 타입 테스트.도메인도 만료된 지 한참 전이고, 얼마 전 Netlify에서도 배포했던 프로젝트가 expire됐다는 메일을 받았다.이대로 묵혀둘까... 했는데 그래도 만들어둔 게 아쉬워서,별도의 도메인 구매가 필요 없는 깃헙 페이지를 이용해서 배포하여영원히 사는 프로젝트로 만들기로 했다.하는 김에 깃헙 액션을 통해 CI/CD도 연결해서, 거하게 리팩토링 작업을 했다.  Github Action을 위한 yaml 파일 만들기깃헙 액션 워크플로우를 만들기 위해서는 yaml 파일이 필요하다.해당 워크플로우가 어떤 Git..

Next + React Query로 SNS 서비스 만들기 강의를 듣다가 dayjs에 대해 알게 되었고, 강의 내에서의 dayjs configuration 코드를 보다가 알게 된 점이 있어 글로 남기고자 한다. (강의 내용과는 무관) dayjs는 플러그인 같은 개념이 있어서 쓰고자 하는 기능이 있으면 필요한 플러그인을 등록해줘야 한다고 한다. 예를 들면 이런 식이다. import dayjs from "dayjs"; import relativeTime from "dayjs/plugin/relativeTime"; import "dayjs/locale/ko"; dayjs.locale("ko"); dayjs.extend(relativeTime); export default function Post() { // ...

다중 스레드 코드 테스트 다중 스레드 코드에서 버그가 있다는 사실을 증명하는 테스트 케이스는 짜기 어렵다. => 동시 갱신 문제가 발생하는 문제는 너무 드물게 발생해서 대개는 테스트로 발견하지 못함. 테스트로 버그를 더 잘 찾아내기 위한 아이디어들 몬테 카를로 테스트 : 테스트로 버그를 더 잘 찾아내기 위한 아이디어. 조율이 가능하게 유연한 테스트를 만든 후 임의로 값을 조율하면서 반복해 돌린다. 시스템을 배치할 플랫폼 전부에서 테스트를 반복해서 돌린다. 부하가 변하는 장비에서 테스트를 돌린다. 그러나 위의 조치를 취하더라도 코드에서 스레드 문제를 찾아낼 가능성은 매우 낮음 스레드 코드 테스트를 도와주는 도구 IBM의 ConTest : 스레드 코드에 보조 코드를 더해 실패할 가능성을 높여주는 도구. 스레..

작업 처리량 높이기 URL 목록을 받아 네트워크에 연결한 다음 각 페이지를 읽어오고 분석하여 통계 보고서를 출력하는 코드를 짠다고 가정. 작업 처리량 계산 - 단일스레드 환경 편의상 다음과 같이 가정 페이지를 읽어오는 평균 I/O 시간 1초 페이지를 분석하는 평균 처리 시간 0.5초 처리는 CPU를 100% 사용하고 I/O는 0% 사용 => 스레드 하나가 N페이지를 처리하면 총 실행 시간은 1.5초*N 작업 처리량 계산 - 다중 스레드 환경 여러 스레드를 사용하면 프로세서를 사용하는 페이지 분석과 I/O를 사용하는 페이지 읽기를 겹쳐 실행할 수 있음 => 단일스레드의 세 배의 처리율로 처리 가능 데드락 다음 네 가지 조건을 모두 만족하면 데드락이 발생 상호 배제 : 여러 스레드가 한 자원을 공유하나 그 ..

라이브러리를 이해하라 Executor 프레임워크 애플리케이션에서 스레드를 사용할 때 Executor 클래스를 고려하면 좋다. Executor 프레임워크는 스레드 풀을 관리하고 풀 크기를 자동으로 조정하며 필요하다면 스레드를 재사용함. Future도 지원 -> 독립적인 연산 여럿을 실행한 후 모두가 끝나는 것을 기다릴 때 유용 스레드를 차단하지 않는 방법(논 블로킹) 최신 프로세서는 차단하지 않고도 안정적으로 값을 갱신함 => 흔히 CAS라 불리는 연산 덕분(데이터베이스 분야에서 낙관적 잠금이라는 개념과 유사) synchronized 키워드가 언제나 락을 거는 것과 다르게, CAS 연산은 스레드가 같은 값을 수정해 문제를 일으킬 때를 감지하여 이럴 경우에만 갱신이 성공할 때까지 재차 시도함 ⇒ 락을 거는 ..

가능한 실행 경로 다음의 incrementValue 메서드가 있는 IdGenerator 클래스가 있다고 하자. public class IdGenerator { int lastIdUsed; public int incrementValue() { return ++lastIdUsed; } } 스레드 하나가 IdGenerator 인스턴스 하나를 사용한다고 가정하면 가능한 실행 경로+결과는 하나다. 하지만 만약 IdGenerator 인스턴스를 스레드 두 개가 호출한다면 다음 결과들이 모두 가능하다. 스레드 1이 94를 얻고, 스레드 2가 95를 얻고, lastIdUsed가 95가 됨 스레드 1이 95를 얻고, 스레드 2가 94를 얻고, lastIdUsed가 95가 됨 스레드 1이 94를 얻고, 스레드 2가 94를 ..

N7: 이름으로 부수 효과를 설명하라 함수, 변수, 클래스의 이름에 부수 효과를 숨기지 않는다. => 여러 작업을 수행하는 함수일 경우, 하는 일을 모두 기술하는 이름을 사용한다. 테스트 T1: 불충분한 테스트 테스트 케이스는 잠재적으로 깨질 만한 부분을 모두 테스트해야 한다. => 테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 그 테스트는 불완전하다. T2: 커버리지 도구를 사용하라! 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다. 대다수 IDE는 테스트 커버리지를 시각적으로 표현하여 테스트가 빠뜨리는 공백을 알려준다. T3: 사소한 테스트를 건너뛰지 마라 사소한 테스트는 짜기 쉽고, 제공하는 문서적 가치는 구현에 드는 비용을 넘어선다. T4: ..

자바 J1: 긴 import 목록을 피하고 와일드카드를 사용하라 ex) import package.*; 긴 import 목록은 읽기에 부담스러우며, 명시적인 import문은 강한 의존성을 생성함 J2: 상수는 상속하지 않는다 상수는 상속 대신 static import를 사용한다. J3: 상수 대 Enum public static final int보다 enum을 사용하라. enum은 이름이 부여된 열거체로, 메서드와 필드도 사용할 수 있는 훨씬 유연하고 서술적인 도구이다. 이름 N1: 서술적인 이름을 사용하라 소프트웨어 가독성의 90%는 이름이 결정한다. 서술적인 이름을 신중하게 골라야 함 N2: 적절한 추상화 수준에서 이름을 선택하라 구현을 드러내는 이름은 피하고 작업 대상 클래스나 함수가 위치하는 추상..

G26: 정확하라 코드에서 뭔가를 결정할 때는 정확히 결정하고, 결정을 내리는 이유와 예외를 처리할 방법을 분명히 알아야 한다. -> 모호성과 부정확은 제거해야 함 G27: 관례보다 구조를 사용하라 설계 결정을 강제할 때는 규칙보다 관례를 사용한다. 명명 관례도 좋지만 구조 자체로 강제하면 더 좋다. ex) switch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다. G28: 조건을 캡슐화하라 부울 논리는 이해하기 어려우므로 조건의 의도를 분명히 밝히는 함수로 표현하라. ex) if(timer.hasExpired() && !timer.isRecurrent()) -> if(shouldBeDeleted(timer))로 변경 G29: 부정 조건은 피하라 부정 조건은 긍정 조건보다 이해하기 어려우므..

G15: 선택자 인수 선택자 인수 : 함수나 메서드의 인수 중 하나가 다른 인수들의 처리 방식을 결정하는 역할을 하는 것. 선택자 인수는 목적을 기억하기 어려울 뿐 아니라 각 선택자 인수가 여러 함수를 하나로 조합함 ex: calculateWeeklyPay(false) 같은 함수의 boolean 인수 일반적으로 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 좋다. G16: 모호한 의도 코드를 짤 때는 의도를 최대한 분명히 밝힌다. 행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 번호 등은 모두 가독성을 흐림 => 피하는 게 좋음 G17: 잘못 지운 책임 코드를 배치할 때는 독자가 자연스럽게 기대할 위치에 배치한다. ex) PI 상수는 삼각함수를 선언한 클래스에 배치 기능을 개발에 편..