프로그래밍 초식

레퍼런스변수를 너무 많이 사용, 변수 용도가 변화하면 추적이 복잡해진다.(심지어 내가) 코드를 이해하는데 드는 비용이 커진다. 인지부하 발생.이해하는 비용이 커진다는 것은 코드변경에 드는 비용이 커지고, 유지보수가 어려워진다.선언하고 몇번 참조하지 않는 변수는 인라인화

레퍼런스구현 기술과 도구를 익혀야 함은 당연하고, 다른 기본기가 필요함.코드의 함수, 클래스, 메서드가 점점 커진다.(내 이야기... 프로젝트에서 어떤 클래스는 무려 600줄 짜리였다.)큰 코드는 분석이 어렵다.(=== 수정 및 유지보수가 어렵다.)변수의 의미가 중간에

레퍼런스개발자는 본능적으로 요구사항을 전달받으면 코드 구현을 떠올리는 습성이 있다...코딩이란 떠오른 구현 아이디어를 코드로 옮기는 과정(그러나 시간이 지나면...)구현의 기반이 된 요구사항은 사라지고, 소스코드의 의미도 휘발된다.처음부터 의미를 발굴해서 기능을 추가해

만약 anyDao.insert()에 추가 값이 필요하면?\-> BigDataObj 클래스에 추가적인 필드 추가만약 otherDato.update()에 추가 값이 필요하면?\-> BigDataObj 클래스에 또 추가적인 필드 추가 하면된다.코드양도 줄고, 객체 전체를 파

레퍼런스else가 없다는 걸 빨리 인지가능코드 인덴테이션이 줄어들어 복잡도가 감소코드 가독성이 높아지고, 유지보수가 용이해짐참고: 구현패턴(켄트 벡 저)예시는 ChatGPT 형님의 도움을 받았다.보호절을 부적절하게 적용한 예시보호절을 효과적으로 적용한 예시

레퍼런스새 매니저로 변경하고, 이전 매니저에서 새 매니저로 바뀐 내역을 남겨야 한다.nest.js 기준으로 아래와 같이 작성할 수 있다.클라이언트 코드서버 코드클라이언트에서 보낸 데이터를 서버에서 무지성으로 사용하는 로직이다.클라이언트가 보낸 금액을 그대로 서버가 받아

레퍼런스처음엔 한가지 작업만 수행하는 for 루프였다.그러나 항상 문제는 기능 추가 또는 변경시에 발생한다.서로 다른 목적을 가진 코드가 뒤섞인다. 따라서 코드의 복잡도가 증가하여, 이해가 어려워지고 유지보수성이 떨어진다.그래서 for 루프 기능단위로 분리해야 한다.기

계산과 결과반영이 섞여 있는 코드 계산로직을 이해하는데 결과코드가 노이즈로 작용한다. 특히 계산로직과 중첩된 조건문이 크고 아름다울 경우엔.. 또한 계산로직만 테스트하기 어렵다. 개선 방법 먼저 계산로직의 입력과 출력을 파악해야 한다. 복잡한 계산의 경우 직관적으로

여러 읽기와 쓰기 쿼리를 논리적으로 하나로 묶는 것트랜잭션이 커밋되면 묶인 모든 쿼리가 DB에 반영되고, 롤백되면 모두 반영되지 않는다.트랜잭션은 어플리케이션 레벨에서 데이터일관성을 보장하기 위한 고민을 아주 많이 없애준다. 중간에 에러가 발생하더라도 트랜잭션 단위로

2

레퍼런스서버가 요청별로 개별 쓰레드를 생성하는 모델이다. 웹서버의 특성상 I/O 대기(클라이언트 송수신, DB 송수신) 시간이 전체 처리 시간에서 많은 비중을 차지하므로, CPU가 노는 시간이 많아진다.쓰레드/프로세스 전환 과정에서 현재 작업중인 쓰레드/프로세스의 프로

레퍼런스 로직이 삽입된 쿼리 ` 로직이 잘 안보인다. 주요 로직이 어플리케이션과 쿼리에 걸쳐 분산되어 분석이 어려워진다. 유사한 쿼리를 중복해서 만들 수 있다. 주요 로직을 단위 테스트하기 어렵다. 쿼리와 결합되어 있으므로 쿼리를 실행해야 로직을 검증 할 수 있다

레퍼런스커넥션 풀의 종류유휴 커넥션사용 중 커넥션커넥션 풀 사용 이유 : 성능DB와 네트워크 연결하는 시간 생략하여 응답속도 향상 및 처리량 증가커넥션 개수를 일정 수준으로 제한하여 DB 포화를 방지하고, 일관된 DB 성능 유지 가능성능향상 때문에 사용하는 커넥션 풀이