*<클린 코드>를 참고하여 작성한 글입니다.나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 약영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 되고, 나쁜 요구사항은 다시 정의하면 되며, 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진

동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 하지만 이를 분리하면 어플리케이션 구조와 효율이 극적으로 나아진다. 구조적

*<클린 코드>를 참고하여 작성한 글입니다.켄트백이 제시한 단순한 설계 네가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다.모든 테스트를 실행한다 : 테스트가 불가능한 시스템은 검증도 불가능이다. 검증이 불가능한 시스템은 출시하면 안 된다. -> 테스트 케이

*<클린 코드>를 참고하여 작성한 글입니다.시스템 제작과 시스템 사용을 분리하라관심사 분리체계적이고 탄탄한 시스템 -> 모듈성을 깨서는 안 된다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적

*<클린 코드>를 참고하여 작성한 글입니다.클래스 체계 : 프로그램은 신문 기사처럼 읽힌다. 추상화 단계가 순차적으로 내려간다.캡슐화 : 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야한다는 법칙도 없다. 때로는 protected로 선언해

*<클린 코드>를 참고하여 작성한 글입니다.Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. 이 인스턴스를 API의 인수로 넘기거나 반환값으로 사용하지 않는다.외부 코드를 익히기는 어렵다. 외부 코

*<클린 코드>를 참고하여 작성한 글입니다.오류 코드보다 예외를 사용하라오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 깔끔해진다.Try-Catch-Finally 문부터 작성하라예외에서 프로그램 안에다 범위를 정의한다 는 사실은 매우 흥미롭다.

*<클린코드>를 참고하여 작성한 글입니다. 객체와 자료구조 자료 추상화 변수를 private으로 선언하더라도 값마다 조회함수와 설정함수(getter, setter)를 제공한다면 구현을 외부로 노출하는 셈이다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로

*<클린 코드>를 참고하여 작성한 글입니다.형식을 깔끔하게 맞추어 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.형식을 맞추는 목적 : 코드 형식은 의사소통의 일환이기 떄문적절한 행 길이를 유지하라 : 일반적으로

*<클린 코드>를 참고하여 작성한 글입니다.주석은 '순수하게 선하지' 못하다.애초에 주석이 필요 없는 방향으로 에너지를 쏟을 것.진실은 오로지 '코드' 한 곳에만 존재한다. 코드만이 정확한 정보를 제공하는 유일한 출처이다.간혹 필요할지라도, 주석을 가능한 줄이도

*<클린 코드>를 참고하여 작성한 글입니다.작게 만들 것각 함수가 명백하도록, 이야기 하나를 표현하도록.중첩 구조가 생길만큼 함수가 커져서는 안 된다.한 가지만 할 것함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.지정된

*<클린 코드>를 참고하여 작성한 글입니다.의도를 분명하게 밝혀라그릇된 정보를 피하라널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하거나, 흡사한 이름을 사용하지 않도록 유의.유사한 표기법을 사용할 것.의미 있게 구분하라연속된 숫자를 덧붙이거나 불용어를 추가하

*<클린 코드>를 참고하여 작성한 글입니다.깨끗한 코드에 대한 정의?비야네 스트로스트룹 : 우아하고 효율적인 코드, 철저한 오류 처리, 한 가지에 집중그래디 부치 : 잘 쓴 문장처럼 읽히는 코드, 명쾌한 추상화와 단순한 제어문데이브 토마스 : 다른 사람이 고치기