Record of Learn

올해 3월에 끝났던 독서 스터디 할 때마다 대강 기억에 남았던 것들 정리해서 저장만 해놨던 건데 드디어 정리한다 가상 면접 사례로 배우는 대규모 시스템 설계 기초 / w. 알렉스 쉬 1장 사용자 수에 따른 규모 확장성 - 로드밸런서 : 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할(6p) - CDN(콘텐츠 전송 네트워크) : 이미지 비디오 CSS JavaScript 파일 등을 캐시. 정적 콘텐츠는 CDN을 통해 서비스 - 무상태(stateless) 웹 계층(17p) - 메세지 큐 : 메시지의 무손실 즉, 메시지 큐에 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성을 보장하는 비동기 통신을 지원하는 컴포넌트 - 샤딩 : 대규모 데이터베이스를 샤드라고 부르는 작은 단위..

15장 JUnit 들여다 보기 - 책에서 소개해주는 모듈은 문자열 비교 오류를 파악할 때 유용한 코드 ex) ABCDE와 ABXDE를 받아 로 반환 - 소스 흉내내면서 책에서 하라는대로 같이 수정해봤는데 되게 재미있었다 최종 ComparsionCompactor.java public class ComparisonCompactor { private static final String ELLIPSIS="..."; private static final String DELTA_END="]"; private static final String DELTA_START="["; private int contextLength; private String expected; private String actual; priva..

14장. 점진적인 개선 Args 클래스를 소개하며 초창기의 소스와 비교하며 점진적으로 개선되는 모습을 보여준다. 소스를 그냥 냅다 붙여넣기 해버려서 진짜 읽기 싫게 해놨다. 그냥 제일 앞에 잘 짜여졌다는 소스라도 따라 쳐보면서 이해하는게 빠르다. Args 구현 public static void main(String[] args) { try { Args arg = new Args(“l,p#,d*”, args); boolean logging = arg.getBoolean(‘l’); int port = arg.getInt(‘p’); String directory = arg.getString(‘d’); executeAppliocation(logging, port, directory); } catch (ArgsE..

13장 동시성 * 동시성? - 한 cpu안에서 동시에 여러 작업을 하는 것처럼 보이게 만드는 것처럼 보이게 만드는 것 1. 동시성이 필요한 이유 - 동시성은 결합을 없애는 전략이다. 즉, 무엇(what)과 언제(when)를 분리하는 전략 - 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다 - 구조적인 관점에서 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다 2. 동시성에 대한 오해 - 동시성은 항상 성능을 높여준다 -> 동시성은 때로 성능을 높여준다 대기시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다 - 동시성을 구현해도 설계는 변하지 않는다 -> 단일 스레드 시..

10장 클래스 1. 클래스는 작아야 한다 - 173p- 176p 예제 확인 2. 단일 책임 원칙(Single Responsibility Principle) : 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다 - 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. - 작은 클래스는 각자 맡은 책임이 하나, 변경할 이유도 하나이며 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다 3. 응집도 -179p-184p 예제확인 4. 변경하기 쉬운 클래스 -186p-188p 예제확인 11장 시스템 전에 스프링 강을 들을 때, 관심사 분리에 대한 내용을 배웠던거랑 비슷한 내용 같다. 근데 책으로 보려니까 이해안가는 부분들이 좀 많아서 몇 번 더 읽어 봐야 될듯 1. 시스템 제작과 ..

7장 - 오류처리 1. 오류보다 예외를 사용하라 - 오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해지기때문 2. ry-catch-finally문 부터 작성하라 3. 미확인 예외를 사용하라(내용이해안감) 4. 예외에 의미를 제공하라 5. 호출자를 고려해 예외 클래스를 정의하라 6. 정상 흐름을 정의하라 7. null을 반환하지마라 - null을 반환하는 코드는 일거리를 늘리고 호출자에게 문제를 떠넘기는 격 스쳐지나가는 null 반환하던 코드들,,,ㅠ 8. null을 전달하지 마라 - null을 반환하는거보다 더 나쁜 코드 8장. 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 패키지를 사고, 오픈소스를 이용하고, 때로는 다른 팀이 제공하는 컴포넌트를 사용함 이러한..

나쁜 코드에 주석을 다지 마라. 새로 짜라 1. 주석은 나쁜 코드를 보완하지 못한다 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라 2. 코드로 의도를 표현하라 //예제1. 직원에게 복지 혜택을 받을 자격이 있는지 검사 if((employee.flags & HOURLY_FLAG) && (EMPLOYEE.age>65)) //예제2. if(employee.isEligibleForFullBenefits()) 주석으로 달려는 설명을 함수로 만들어 표현해도 충분 3. 좋은 주석 - 법적인 주석(ex.저작권 정보, 소유권 정보...) - 정보를 제공하는..

1. 작게 만들어라 책에 나온 예제 코드 보고 이해 2. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다 3.함수 당 추상화 수준은 하나로 4. Switch문 책에 나온 예제 코드 보고 이해 5. 서술적인 이름을 사용하라 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다 6. 함수 인수 함수에서 이상적인 인수 개수는 0개 코드를 읽는 사람에게는 includeSetupPageInto(new PageContent) 보다 includeSetupPage()가 이해하기 쉽다. includeSetu..

1. 의도를 분명하게 밝혀라 잘못된 예 : int d; ->아무 의미도 드러나지 않다 int daysSinceCreation; int fileAgeInDays; 와 같이 분명한 정보 제공을 해줘야한다 2. 그릇된 정보를 피하라 여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지않는다 계정을 담는 컨테이너가 실제 List가 아니라면 그릇된 정보를 제공하는 셈이다 그러므로 accountGroup, bunchOfAccounts 같은 이름으로 명명한다 -> 주의주의 3. 의미 있게 구분하라 ex) getActiveAccount(); getActiveAccounts(); getActiveAccountInfo(); 프로젝트에 참여한 사람은 셋 중 어느 함수를 호출할지 알 수 없..