TIL TIL

제6장. 객체와 자료구조 자료 추상화 어떻게 구현했는지, 정보가 어디에서 오는지를 표현하지 말자. 추상적으로 자료를 표현할 가장 좋은 방법이 무엇인지 고민하자. 아무 생각 없이 조회/설정 함수를 추가하지 말것 디미터 법칙 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 추가 설명 참고 (소스 : https://mangkyu.tistory.com/147) OOP에서 중요한 것은 "객체가 어떤 메세지를 주고 받는가" 이다. 다른 객체가 어떤 자료를 갖고 있는지 속사정을 알게 하지 말고, 메세지를 전달하는 함수를 공개해야 한다. 기차 충돌 : 객채 조회/설정 함수가 꼬리에 꼬리를 물고 나타나는 코드. 피하자 잡종 구조 : 절반은 객체, 절반은 자료 구조? 객체(Object)는 어떤 기능이나..

제 4장. 주석 “우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다.” “프로그래머들이 주석을 엄격하게 관리해야 한다고 주장할지도 모르겠다. 하지만 나라면 코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다.” 나쁜 코드에 좋은 주석을 달려고 노력하기 보단 좋은 코드를 만들자 그럼에도 필요한 좋은 주석 법적인 주석 : 회사 표준 등의 이유로 특정 주석이 필요한 경우 정보를 제공하는 주석 : 기본적인 정보를 주석으로 ㅈ제공하기 의도를 설명하는 주석 : 결정에 깔린 의도 설명 의미를 명료하게 밝히는 주석 : ex) a.compareTo(b) == -1; // a< b 결과를 경고하는 주석 : ex) // 여유시간이 ..

제 3장 함수 함수는 프로그램의 가장 기본적인 단위 좋은 함수를 만드는 규칙 함수는 작아야 한다. 중첩 구조가 생길 만큼 함수가 커져서는 안된다. 들여쓰기 수준이 1~2단을 넘어서면 안 된다. 함수는 한 가지만 해야한다. 함수 내 모든 작업의 추상화 수준이 동일해야 한다. 내려가기 규칙 : 위에서 아래로 코드를 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. switch 문은 가급적 피하자 명령과 조회를 분리하기 : 함수는 무언가를 수행하거나 무언가에 답하거나 둘 중 하나만 해야 한다. 함수의 이름을 서술적으로 지어라. 길어도 괜찮다. 함수의 인수는 특별한 이유가 없다면 적어야 한다. 오류 코드 대신 예외 처리가 깔끔하다 반복하지 마라 함수를 짜는 법 함수를 처음부터 보기 좋게 짜내긴 힘들다. ..

제 1장 깨끗한 코드 나중은 결코 오지 않는다. 나쁜 코드는 팀 생산성을 떨어뜨린다. 재설계조차 어렵게 만든다. 해결하는 유일한 방법은, 코드를 최대한 깨끗하게 유지하는 습관을 갖는 것이다. 문제는 "깨끗한 코드를 어떻게 작성할까?", "깨끗한 코드는 무엇일까?"이다. 깨끗한 코드에 대한 여러 의견 - 논리가 간단해야 한다. - 의존성을 줄여야 유지보수가 쉽다. - 오류 처리를 철저히 - 프로그래머들이 대충 넘어가곤하는 세세한 사항까지 챙길것 (ex, 메모리 누수, 경쟁 상태, 일관성 없는 명명법 등) - 한 가지를 제대로 한다 - 가독성이 좋아야 한다. - 다른 사람이 고치기 쉬워야 한다. - 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 제 2장 의미 있는 이름 의도가 분명하게 이름을 지어야한..

오늘의 미션 구매 인증 올리기 1월에 놓쳐서 아까웠던 노마드 개발자 북클럽 완주와 올해 목표였지만 시작도 안했던 블로그 쓰기 두마리 토끼를 잡는걸 목표로 열심히 하자!