BEYOND SW 캠프 15기 5주차 회고

전체 교육과정의 1/6이 지나간 시점에서 회고를 작성해본다.

학습 내용

1. Java 프로그래밍 기초
   Java 프로그래밍의 기본적인 문법, 자료형, 명령어 등에 대해 학습하였다.

2. 객체 지향 프로그래밍
   Java의 큰 특징인 객체 지향 프로그래밍의 개념과 이를 구현해주는 클래스, 객체, 상속에 대해 다루었다.

배운 점

1. 타인의 코드를 참고하는 게 공부가 많이 된다는 것
   실습 시간에 작성한 코드는 GitHub 공개 저장소에 올리고 자신의 저장소 링크를 공유하고 있다. 다른 수강생의 코드를 참고하다보니 같은 문제를 해결하는 여러 가지 방법도 배우게 되고, 복잡하다고 느껴 사용하지 않았던 방법을 깔끔하게 구현해낸 코드도 발견하였다. 예를 들어 로또 번호 추첨 실습 문제의 경우 크게 다음의 두 가지 방법이 가능했다.

1. 이미 뽑힌 숫자인지 체크하며 반복문으로 6개의 숫자 추첨
2. 45개의 숫자를 담은 배열을 잘 섞은 다음 길이 6만큼만 추출

스스로 실습 코드를 작성해보는 것도 중요하지만 작성이 완료되면 다른 사람의 방법도 꼭 확인해 봐야겠다. 개발자가 되면 내 코드를 작성하는 시간보다 남의 코드를 보는 시간이 훨씬 많다고 들었다. 프로젝트 준비를 하지 않는 기간 동안 코딩테스트 스터디를 진행하고 있는데, 문제 해결 후 다른 스터디원의 코드에 리뷰하는 시간을 가지려고 한다.

2. 아는 만큼 보인다.
   필자는 이전에 모 부트캠프에서 운영하는 1개월 프리코스에 참가하며 과제를 해결해본 경험이 있다. 과제가 끝나면 해당 과제 코드에 대한 리뷰를 주고 받았는데, 당시에는 Java 코드 작성 경험이 적고 배경지식도 부족하다보니 좋은 코드를 보면서도 이 코드가 왜 좋은 건지 알지 못했다. 수업 수강을 통해 개념을 보강하고 실습 문제를 풀며 당시에 봤던 코드를 떠올려봤는데, 유지보수성을 고려한 좋은 코드였다는 것을 깨닫게 되었다.
   개념과 실습 경험은 서로를 보충해주는 상호 보완적 관계이고 둘 다 중요하지만 굳이 둘 중 하나를 고른다면 실습 경험이 더 중요하다고 생각한다. 그래도 어떤 코드가 좋은 코드인지 아닌지를 판단하기 위해서는 어느 정도의 개념 공부가 필요하니, 개념 공부 또한 게을리하지 않는 것이 좋겠다.

유지보수성

Java 하면 객체 지향 프로그래밍(OOP, Object-Oriented Programming)이라는 키워드가 항상 딸려오며 OOP의 장점으로는 유지보수성, 재사용성 등을 꼽는다. 실습했던 내용을 바탕으로 유지보수하기 좋은 코드란 무엇인지 정리해본다.

1. 중복을 없앤다.
   코드에서 동일한 작업이 여러 번 반복된다면 그때마다 별도로 코드를 작성하기보다는, 해당 부분을 별도의 메서드로 분리하고 호출한다. 이는 재사용성 및 가독성 측면을 고려했을 때도 좋은 방법이다.
2. 수정을 최소화한다.
   로또 번호 추첨을 예로 들면 1부터 45까지의 숫자 중 6개의 숫자를 추첨하는 방식이다. 그런데 이 숫자들을 하드코딩 해놓았다면 나중에 요구사항이 바뀌어 숫자가 변경될 때, 코드 창을 보며 직접 수정해야 한다. 게다가 45나 6이라는 숫자가 등장한다면 그게 어떤 맥락에서 등장했는지를 바탕으로 수정이 필요한 지 아닌 지를 판단해야 한다. 예를 들면 6이라는 숫자는 추첨하는 숫자일 수도 있지만 1+2+3을 계산한 결과일 수도 있고 3*2를 계산한 결과일 수도 있다. 따라서 메서드 안에 직접 45, 6과 같은 숫자를 집어넣는 것이 아니라, 아래와 같이 상수로 관리하고 호출하는 방식으로 작성하는 것이 요구사항의 변화에 대응하기 좋다.

public class Lotto {
	static final int MIN_NUMBER = 1;
    static final int MAX_NUMBER = 45;
    static final int CHOOSE = 6;
    
    // 생성자 선언, 메서드 선언 등
}

위와 같이 상수로 관리하면 1부터 50까지의 수 중 7개를 뽑는 게임으로 변경되었을 때, 긴 코드 창을 확인하지 않고 딱 2줄만 고치면 된다.

이전에는 변수를 선언하면 메모리 공간을 사용하는 것이기에 많이 쓰지 않는 것이 좋지 않나 생각했었는데, 유지보수성 좋은 코드에 대해 고민하다보니 수정을 최소화하기 위해 적절히 활용하는 것이 좋은 것임을 알게 되었다.
또한, 위에서 언급한 메서드 분리는 수정을 최소화한다는 관점과도 일치한다. 100번을 사용한 기능에 수정이 필요하면 100번을 직접 고쳐야 하는데, 메서드 분리를 하고 호출했다면 메서드만 한 번 고치면 된다.

문제 상황

이번주에 겪은 문제 상황을 정리해본다.

IntelliJ에서 import한 패키지를 인식하지 못해 경고를 띄움

• 설명: 수업시간에 필기한 코드와 강사님이 올려주신 코드를 한 번에 관리하기 위해 pull 받아오는 구조로 디렉터리를 관리하고 있었는데, 사진과 같이 Calculator 클래스를 인식하지 못해 빨간색 경고를 띄웠다. 보통은 이름에 오타가 있거나 경로를 잘못 작성한 경우인데, 전부 해당하지 않았으며 심지어 compile했을 때도 문제 없이 작동하였다. 또, 필기 파일에서는 문제가 없었고 강사님 코드 쪽에서만 발생한 문제였다.
  경고를 띄우는 것과는 달리 실행에는 문제가 없었지만 이 현상의 원인을 알고 계실까 해서 강사님께 질문드렸고, 강사님께서도 같은 문제가 반복되는 것을 한참 겪으시다가 원인을 모르겠는데 찾고 싶다며 구글링을 해보셨다.

• 해결 방법: 파일 > 캐시 무효화를 적용하여 재시작
  이후 정상적으로 클래스를 인식하여 더이상 빨간 글씨가 뜨지 않았다. 강의를 듣는 과정에서 파일 이름이나 패키지 이름이 잘못 설정되어 수정한 적이 몇 번 있고, 강사님 코드를 pull 받아오는 구조를 만드는 데 어려움이 있어 디렉터리를 복사 및 삭제하거나 .git 폴더를 삭제하고 다시 클론 받아오는 등 우여곡절이 많았는데, 그 과정에서 캐시가 망가져서 생긴 문제로 보인다.
  이전 직장에서 개발팀이 수정 완료한 내용이 작업 환경에 반영되지 않았는데 쿠키 삭제로 해결한 적이 있었다. 이 두 건의 사례를 바탕으로 다음과 같은 해결법을 상기해볼 수 있다.

  알 수 없는 현상이 발생할 때는 쿠키나 캐시를 지워본다.

개선할 점

노션 개념 정리가 밀리고 있다. 아직 저번주 리눅스 개념 정리도 끝나지 않은 상태인데, 자바 실습 문제를 풀다보면 수업이 끝나다보니 스터디 문제도 풀다보면 노션 정리 할 시간이 나지 않는다. 우선은 지금처럼 수업시간에 간략하게 필기를 해두고, 주말에 시간 나는대로 채워나가야겠다.

느낀 점

지난주 일요일에 문득 든 생각인데 부트캠프에 들어와 한 달 정도 지내는 동안 이전에 즐겨하던 게임의 존재 자체를 잊고 있었다. 그렇게 쓰던 시간에 노션 정리를 하거나 집 앞 하천에서 달리기 하며 보내고 있는데, 내가 보기에도 열심히 살고 있는 지금의 모습이 좋다. 전에 했던 게임은 반복되는 일상에 지치고 힘들 때 가끔 찾고, 앞으로 주어진 시간은 좀 더 생산적으로 보내봐야겠다.