본문 바로가기

관심사/독후감

<마이클 C. 페더스 > 레거시 코드 활용 전략 레거시 코드 활용 전략은 테스트 코드 없이 레거시 코드를 다 감수하시겠습니까? 글을 읽은 후, 흥미를 갖게 된 책이었다. 이후, 비즈니스 로직이 복잡한 업무를 담당하게 되었고 나의 복잡한 심정을 대변해줄 대상을 찾는 심정으로 이 책을 읽게 되었다. 이 책은 현업에서 리팩토링을 하면서 암묵적으로 체득한 기법들이 명쾌하게 정리되어 있어 흥미로웠다. 리팩토링을 할 때, 적용 결과가 이전보다 낫다고 확신할 수 없는 경우가 종종 있었다. 이 때, 리팩토링을 하지 않으면 코드를 이해하기 어려웠기 때문에 별다른 선택지가 없어서 고민하고는 했다. 몇 번의 실패를 경험한 후, 스케치하듯이 연습 삼아 리팩토링을 하며 코드를 분석하는 패턴을 체득하게 되었다. 물론, 이 코드는 로컬에서만 사용했고, 리팩토링 효과가 확실하다고..
<조영호> 오브젝트 05. 책임 할당하기 1. 클래스가 여러 이유로 변경돼야 한다면 응집도가 낮은 것이다. 변경의 이유를 기준으로 클래스를 분리해야한다. 2. 응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화한다. 반면 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고, 일부는 초기화되지 않은 상태로 남겨진다. 때문에 함께 초기화되는 속성들을 기준으로 클래스를 분리해야한다. 3. 모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도가 높다고 볼 수 있다. 반면 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래서의 응집도가 낮다고 볼 수 있다. 06. 메시지와 인터페이스 디미터 법칙 클래스 내부의 메서드는 아래 조건을 만족하는 인스턴스에게만 메시지를 전송해야한다. -> this 객체 / ..
<마틴 클러스만> 데이터 중심 애플리케이션 설계 01장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 트위터의 데이터 파이프라인 사례 System design for Twitter The Architecture Twitter Uses To Deal With 150M Active Users, 300K QPS, A 22 MB/S Firehose, And Send Tweets In Under 5 Seconds 꼬리 지연 시간 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요하다. 예를 들어 아마존은 내부 서비스의 응답 시간 요구사항을 99.9분위로 기술한다. 99.9분위는 요청 1000개 중 1개만 영향이 있음에도 말이다. 보통 응답 시간이 가장 느린 요청을 경험한 고객들은 많은 구매를 해서 고객 중에서 계정에 ..
도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문 03. 컨테이너 실전 구축 및 배포 애플리케이션과 시스템 내 단일 컨테이너의 적정 비중 도커는 애플리케이션과 인프라를 도커 컨테이너라는 단위로 분리한 것이라 볼 수 있다. 이런 관점에서 웹 애플리케이션과 워커형 상주 애플리케이션 프로세스 하나를 하나의 컨테이너로 만드는 방식 (컨테이너 1개 = 프로세스 1개)이 괜찮게 생각될 수 있다. 실제로 도커 초기에는 "컨테이너 1개 = 프로세스 1개"를 반드시 지켜야 한다고 생각하는 사용자가 있어 자주 토론거리가 됐다. 그러나 "컨테이너 1개=프로세스 1개" 원칙을 고수하는 것은 무리이다. 예를 들어, 크론 프로세스에서, 다른 job을 실행하는 경우가 있다. 사실 도커 공식문서에는 "컨테이너는 하나의 관심사에만 집중해야 한다"라고 적혀있다. 즉, 컨테이너 하나가 ..
최범균 <DDD START! > 4-5장 요약 4장. 리포지터리와 모델 구현 별도 테이블에 저장하는 밸류 매핑 애그리거트에 속한 객체가 밸류인지 엔티티인지 구분하는 방법은 고유 식별자를 갖는지 여부를 확인하는 것이다. 하지만 식별자를 찾을 때 매핑되는 테이블의 식별자를 애그리거트 구성요소의 식별자와 동일한 것으로 착각하면 안된다. 별도 테이블로 저장되고 테이블에 PK가 있다고 해서 테이블과 매핑되는 애그리거트 구성요소가 고유 식별자를 갖는 것은 아니다. 보통 주문 애그리거트는 실주문을 의미하는 Order 테이블과 주문 품목을 의미하는 Order Lines 테이블로 구성되어 있다. 여기서 주문 품목(Order Lines)은 밸류이다. Order Lines 테이블도 고유 PK를 갖고 있지만, 주문 애그리거트를 식별하는 고유 식별자는 주문번호이다. (위 ..
위르헌 아펄로 -Management 3.0 9. 제약 조건을 정렬하는 방법 여러분의 목표와 팀의 목표를 절충하자 팀과 목표가 부딪히면 그걸 해결해야 할 것이다. 팀의 결정을 무시하면 매우 갚기 어려운 동기 부채가 생길 것이고, 그건 상황을 더욱 어렵게 만들 뿐이다. 권한 경계 목록을 만들자 권한 경계 목록을 만들면 사람들이 전기 철조망에 뛰어들지 않아도 되기 때문에 사람들에게 동기를 부여하고 생산성을 유지할 수 있다. 10. 규칙을 만드는 기술 애자일의 맹점 애자일 선언의 애자일은 팀이 훌륭할 때만 훌륭하다. 애자일 선언이 역량 문제를 해결해주지는 않는다. 프로젝트의 치사율을 낮추고 싶은 애자일 관리자라면 아래의 기본 원칙을 응용할 수 있다. 문화 : 사회 시스템의 역량을 높이기 위해 어떤 방법을 적용하든, 결국 모든 것은 사람이 진심으로 관심이..
<사이트 신뢰성 엔지니어링> - 2부 요약 본문 중에서...Chapter 6. 분산 시스템 모니터링 알럿 호출 방식 철학매번 호출기가 울릴 때마다 긴급한 상황임을 인지하고 그에 대응할 수 있어야 한다. 이러한 긴급 호출은 빈번한 호출로 인한 피로를 느끼지 않도록 하루에 단 몇번 정도만 발생해야 한다.모든 호출은 대응이 가능해야한다.호출은 새로운 문제나 지금까지 보지 못한 사건에 대한 것이어야 한다.호출에 대한 모든 대응은 이성적이어야 한다. 장기적 모니터링 장애 호출에 대해 이미 정해진 규칙에 의해 대응하는 것은 위험 신호다. 팀의 그 누구도 이런 호출에 대해 자동화를 할 의지가 없다는 것은 팀이 스스로 만든 기술 부채를 해소할 자신이 없다는 것을 암시한다. 한 걸음 더 나아가기 순수한 노력의 힘은 너덜너덜한 시스템을 고가용성을 갖춘 시스템으로 ..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 9장 요약 Chapter 9: Why It's Always Hard to Steer9.2.2 The history of software engineeringThe Size/Complexity Dynamic 은 문제의 크기가 커질수록 복잡도가 제곱으로 높아지는 문제 유형을 말한다.소프트웨어 역사를 보면, 성공하는 경험을 할 수록, 조직은 점점 더 어려운 문제를 찾고, 도전해왔다. 그러면서 소프트웨어가 발전해왔다. 위의 그림은 소프트웨어 개발에 대한 effect diagram이다.소프트웨어 조직이 성공을 경험하면 -> 도전적인 과제를 찾아서 -> 문제의 크기가 커져서 -> 솔루션의 복잡도가 높아진다.문제의 난이도가 높아지면, 처음에는 개발자수를 늘리고, 고급인력을 채용하면서 리니어하게 문제를 해결할 수 있다. 그런데 ..

티스토리툴바