Nuey.log

디미터 법칙Law of Demeter: 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.객체는 자료를 숨기고 함수를 공개한다.즉, 객체는 조회함수로 내부 구조를 공개하면 안된다는 의미다.대표적인 휴리스틱이다.휴리스틱  Heuristic완벽하진 않지만, 일반법으로 좋은/간단한 해결법을 말한다.자세한 예시로클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다.클래스 Cf 가 생성한 객체f 인수로 넘어온 객체C 인스턴스 변수에 저장된 객체하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다.복잡한 듯이 보이지만 디미터 법칙을 위반하는 사례만 피하면 된다.클래스 A→B에서 조회를 했다면 B에 있는 자료만 가져와야지A→B→C조회를 하면 안된다는 거다.한마디로 코드가 꼬인 ..

각 변수마다 get/set 함수를 제공한다면 구현을 외부로 노출하는 셈이다.변수 사이에 함수를 넣는다고 구현이 감춰지진 않기에 추상화가 필요하다.객체 ↔ 자료구조객체Object는 추상화 뒤로 숨긴 채 함수만 공개한다.자료구조는Data structure 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.두 개념은 거의 정반대다. 아래 같은 내용의 코드를 절차지향/객체지향 구조로 알아보자.절차지향 구조객체지향 구조 이렇듯 객체지향/절차지향 구조는 반대되며 각 장단점을 가지고 있다.절차적인 코드는 기존 자료구조(도형)를 변경하지 않으면서 새 함수를 추가하기 쉽고↔ 자료 구조 class를 추가하면 함수를 모두 변경해야 한다.객체지향은 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.↔ 새로운 함수를..

코드 형식은 의사소통이다프로젝트가 커질 수록 수많은 개발자들이 만든 클래스를 보게 될 텐데 개발자마다 고유의 스타일로 코드를 적어두었다면 상당히 읽기 힘들 겁니다. 그래서 개발초기에 tab의 크기와 font, 주석형식을 모두 정해두고 진행합니다. 그걸 일일히 검사할 수는 없으니까 sonarQube를 이용해 형식을 검사하면 형식에 맞지 않는 코드들을 찾을 수 있습니다.적절한 행(세로) 길이 Lines책에 따르면 우리가 많이 사용하는 tomcat 등 거대한 시스템도 클래스의 길이가 대개 200줄을 넘지 않는다. 작은 파일들로도 대규모 시스템을 만들 수 있다는 증거다.가로 형식 맞추기신문 기사처럼 작성하라독자는 신문을 위에서 아래로 읽는다.최상단에 가장 큰 표제가 간단한 설명이 적혀있다.이름은 간단하면서도 설..

주절거리는 주석작성한 개발자가 아니며 이해가 안 되어 다른 모듈까지 뒤져야하는 주석은 좋지 않다.같은 이야기를 중복하는 주석.있으나 마나 한 주석 오해의 여지혹은살짝 잘못된 정보가 담긴 주석의무적으로 다는 주석이력을 기록하는 주석2024.10.14 - [🛠 도구/➰ Visual Studio] - [VScode]GitLens위치를 표시하는 주석공로를 돌리거나 저자를 표시하는 주석주석으로 처리한 코드HTML주석전역 정보주석을 달 땐 근처에 있는 코드만 기술하라.시스템 전반적 정보를 기술하지 않아야 한다.ex) 포트값 정보 등너무 많은 정보모호한 관계함수 헤더

법적인 주석정보를 제공하는 주석 의도를 설명하는 주석.의도를 명료하고 밝히는 주석.결과를 경고하는 주소예전에는 이러한 너무 시간이 오래 걸리는 코드를메서드 이름 앞에 _ 를 붙이는 게 관례였다고 한다.요즘에는 @Ignore 속성에 문자열로 넣어준다고 한다.ex:  @Ignore("실행이 너무 오래 걸린다.")(Junit을 추가하거나 Maven프로젝트에서 사용 가능함)TODO / FIXME 주석프로젝트를 진행하다보면..아직 어떻게 진행할 지 정해지지 않은 부분들이 있습니다.이런 경우에 TODO주석을 달아 둡니다.따라서 TODO /  FIXME 주석은 꼭 필요하고 확인해야할 주석입니다.중요성을 강조하는 주석

들어가기 전에자동 주석 호출메서드 위에 /** 를 적은 뒤 Enter를 누르면 자동 주석이 적혀집니다.주석은 필요악이다주석을 유지하고 보수하기는 현실적으로 불가능이라주석은 오래될 수록 코드에서 멀어진다.부정확한 주석은 아예 없는 것보다 나쁘다.코드로 의도를 표현하라초보자가 보았을 경우에는 고작 저 조건을 검사하려고 메서드를 따로 만들어야 하느냐 생각 할 수 있지만후에 혜택을 받을 조건이 변경될 것을 생각하면 유지보수를 위해 따로 메서드를 만드는 게 좋다.또한 굳이 알 필요 없는 조건을 보기 위해 더 긴 주석을 읽을 필요가 없어진다.의도를 정확하고 깔끔하게 표현한 코드가, 복잡하고 주석이 많이 달린 코드보다 훨씬 좋다.

부수효과를 일으키지 마라비밀번호가 맞게 입력되었는 지 확인만 하는 함수였는데틀릴 시 Session을 날려버리는 식의 기능을 추가하지 말아야 한다.명령과 조회를 분리하라보면 두가지 기능을 하고 있는데로그인확인 (조회)값 저장 (명령)이런 나눠야 한다는 말이다.오류 코드 보다는예외를 사용하라에러를 처리하는 부분이 없기 때문에만약 로그인 실패 시 에러를 그 때 그 때처리해야 한다.이런 경우 보통 try/catch문을 사용하는데 그 전에→ if/else로 먼저 처리하는 것이 좋다. 그럼 어떻게 오류를 처리해야 하는 지 알아보자.try/catch블록을 뽑아내서예외도 하나의 작업으로오류도 한가지 작업이기 때문에오직 오류만 처리해야 한다.구조적 프로그래밍: 함수가 클수록 Single entry-exit rule 적용..

시작하기 전 용어에 대해Parameter: 매개 변수. 선언된 함수에서 지정한 전달받는 데이터의 형태. Argument: 인수. 전달하는 데이터 값.함수명과 인수명은 한 쌍이어야 한다.이상적인 인수 개수는0개인수가 많을 수록 우리는 해당 인수들이 함수 내 어떤 역할을 하는 지 찾아야 하므로인수는 적을 수록 좋다.3개 이상은 최대한 피하는 것이 좋다.많이 쓰는 단항(1개) 형식(추천)이항 함수 이항 함수와 무조건 나쁜 건 아니지만되도록 단항함수로 바꾸어 쓸 수 있게 method 또는 class를 이용해 분리하도록 한다.삼항 함수flag(boolean) 인수인수 목록: 인수 개수가 가변적인 함수 활용ex) String.format()출력 인수를 피하라

프로그램의 기본단위 :함수  프로그래밍 초창기에는 시스템을 루틴과 하위루틴으로 나눴고포트란과 PL/1 시절에는 시스템을 프로그램, 하위 프로그램, 함수로 나눴다.지금은 함수만 남아있다.  작게 만들어라.가로 150자, 세로 100줄을 넘어서는 안된다.  책에서는 20줄도 길다한다.이렇게 만드는 방법을 제시하자면제어문 is/else문 while문 등에 들어가는 블록은 한줄이어야 한다.대개 거기서 함수를 호출한다.따라서 if문 안에 다시 if문을 쓰는 식의중첩 제어문 2단을 초과해서는 안된다.함수는 한가지를 해야한다 그 한가지를 잘해야 한다.함수의 의미를 유지하는 수준까지 줄인다.함수 안 코드를 다른 함수로 추출할 수 있다면→그 함수는 여러가지를 하는 셈이다. 내려가기 규칙 참고로 책 저자가 만든 규칙이름인..

기술 개념 단어를 사용하라적잘한 프로그래머 용어가 없다면문제 영역에서 이름을 가져오면 된다. 맥락을 추가하라 함수를 끝까지 모두 읽고서야 if/else문에서 코드가 어떻게 사용되었는 지 알 수 있다.위 코드를 맥락있는 코드로 정리하면 아래처럼 적을 수 있다.  불필요한 맥락을 없애라Gas Station Deluxe라는 애플리케이션을 만들고자 할 경우GSD라는 단어를 모든 파일의 앞에 붙이면 IDE에서 검색이 힘들어진다.웹주소를 구분해야 한다면PostAddress, MAC, URI라는 이름들도 괜찮다.