*<클린 코드>를 참고하여 작성한 글입니다.깨끗한 코드에 대한 정의?비야네 스트로스트룹 : 우아하고 효율적인 코드, 철저한 오류 처리, 한 가지에 집중그래디 부치 : 잘 쓴 문장처럼 읽히는 코드, 명쾌한 추상화와 단순한 제어문데이브 토마스 : 다른 사람이 고치기
*<클린 코드>를 참고하여 작성한 글입니다.의도를 분명하게 밝혀라그릇된 정보를 피하라널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하거나, 흡사한 이름을 사용하지 않도록 유의.유사한 표기법을 사용할 것.의미 있게 구분하라연속된 숫자를 덧붙이거나 불용어를 추가하
*<클린 코드>를 참고하여 작성한 글입니다.작게 만들 것각 함수가 명백하도록, 이야기 하나를 표현하도록.중첩 구조가 생길만큼 함수가 커져서는 안 된다.한 가지만 할 것함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.지정된
*<클린 코드>를 참고하여 작성한 글입니다.주석은 '순수하게 선하지' 못하다.애초에 주석이 필요 없는 방향으로 에너지를 쏟을 것.진실은 오로지 '코드' 한 곳에만 존재한다. 코드만이 정확한 정보를 제공하는 유일한 출처이다.간혹 필요할지라도, 주석을 가능한 줄이도
*<클린 코드>를 참고하여 작성한 글입니다.형식을 깔끔하게 맞추어 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.형식을 맞추는 목적 : 코드 형식은 의사소통의 일환이기 떄문적절한 행 길이를 유지하라 : 일반적으로
*<클린코드>를 참고하여 작성한 글입니다. 객체와 자료구조 자료 추상화 변수를 private으로 선언하더라도 값마다 조회함수와 설정함수(getter, setter)를 제공한다면 구현을 외부로 노출하는 셈이다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로
*<클린 코드>를 참고하여 작성한 글입니다.오류 코드보다 예외를 사용하라오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 깔끔해진다.Try-Catch-Finally 문부터 작성하라예외에서 프로그램 안에다 범위를 정의한다 는 사실은 매우 흥미롭다.
*<클린 코드>를 참고하여 작성한 글입니다.Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. 이 인스턴스를 API의 인수로 넘기거나 반환값으로 사용하지 않는다.외부 코드를 익히기는 어렵다. 외부 코
*<클린 코드>를 참고하여 작성한 글입니다.TDD 법칙 세가지첫째: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.셋째: 현재 실패하는 테스트를 통과하라 정도로
*<클린 코드>를 참고하여 작성한 글입니다.클래스 체계 : 프로그램은 신문 기사처럼 읽힌다. 추상화 단계가 순차적으로 내려간다.캡슐화 : 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야한다는 법칙도 없다. 때로는 protected로 선언해
*<클린 코드>를 참고하여 작성한 글입니다.시스템 제작과 시스템 사용을 분리하라관심사 분리체계적이고 탄탄한 시스템 -> 모듈성을 깨서는 안 된다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적
*<클린 코드>를 참고하여 작성한 글입니다.켄트백이 제시한 단순한 설계 네가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다.모든 테스트를 실행한다 : 테스트가 불가능한 시스템은 검증도 불가능이다. 검증이 불가능한 시스템은 출시하면 안 된다. -> 테스트 케이
동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 하지만 이를 분리하면 어플리케이션 구조와 효율이 극적으로 나아진다. 구조적
*<클린 코드>를 참고하여 작성한 글입니다.나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 약영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 되고, 나쁜 요구사항은 다시 정의하면 되며, 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진