Code ‐ 논리, 사고의 흐름 - thought-corner/Backend-PlayGround GitHub Wiki

📚 Early Return

• Early return으로 else의 사용을 지양한다.

if (doesUserChooseToOpenCell(userActionInput)) {
  if (isLandMineCell(selectedRowIndex, selectedColIndex)) {
    BOARD[selectedRowIndex][selectedColIndex] = LAND_MINE_SIGN;
    changeGameStatusToLose();
    return;  // Early Return 적용
  }
  open(selectedRowIndex, selectedColIndex);
  checkIfGameIsOver();
  return;
}

📚 사고의 depth를 줄여보자.

• 사용할 변수는 가깝게 선언하기
• 중첩 반복문 / 중첩 분기문

for (int i=0; i<20; i++) {
  for (int j=20; j<30; j++) {
    if (i >= 10 && j < 25) {
      doSomething();
    }
  }
}

📚 공백 라인을 대하는 자세

• 공백 라인도 의미를 가진다. -> 복잡한 로직의 의미 단위를 나누어 보여줌으로써 읽는 사람에게 추가적인 정보를 전달할 수 있다.

❗공백이 없는 것이 꼭 깔끔한 코드를 말하는 것이 아니다. 공백으로 의미를 명확히 전달할 수 있다는 부분도 새롭게 알게 되었다.

📚 부정어를 대하는 자세

// Bad
if (!isLeftDirection()) {  // 왼쪽 방향이 아니면?
  doSomething();
}

// Good 1
if (isNotLeftDirection()) { // 부정어를 명확하게
  doSomething();
}

// Good 2
if (isRightDirection()) {
  doSomething();
}

📚 해피 케이스와 예외 처리

• 예외가 발생할 가능성을 낮추기
• 어떤 값의 검증이 필요한 부분은 주로 외부 세계와의 접점 -> 사용자 입력, 객체 생성자, 외부 서버 요청 등
• 의도한 예외와 예상치 못한 예외를 구분 -> 사용자에게 보여줄 예외와 개발자가 보고 처리해야 할 예외를 구분

❗내가 질문하고픈 부분을 명확하게 전달하는 능력이 부족하다고 생각한다. "모르겠어요"라는 질문보다는 어디까지 생각을 했고 그 이후의 과정에서의 피드백을 요청하는 것이 가장 좋다.

[ Null을 대하는 자세 ]

• NullPointerException을 방지하는 방향으로 경각심을 가지기
• 메서드 설계 시 return null을 자제한다. -> 만약 어렵다면 Optional을 고민해본다.

[ Optional에 관해 ]

• Optional은 비싼 객체다. 꼭 필요한 상황에서 반환 타입에 사용한다.
• Optional을 파라미터로 받지 않는다.
• Optional을 반환받았다면 최대한 빠르게 해소한다.