[TIL] 객체 지향 설계 - 사다리 타기 게임 (Java)

1주 동안 코드스쿼드 과정의 사다리 타기 게임을 구현했습니다.

구현하면서 느꼈던 배운 점을 간단히 정리해보겠습니다.

Commit과 PR하기 - 작은 커밋 단위, 의미있는 커밋/PR 메시지

Commit은 마치 게임에서 세이브 포인트처럼 git에서 프로젝트의 상태를 저장하고 있는 객체라고 볼 수 있습니다. 언제든지 특정 시점으로 돌아갈 수 있는데요, 작은 규모의 개발 환경에서는 커밋 로그를 잘 남기는 것이 그렇게 중요하지 않을 수 있습니다. 언제 어떤 작업을 했는지 비교적 잘 기억할 수 있으니 말입니다. 그렇지만 프로젝트의 규모가 커지고 여러 사람이 협업을 하게되면, 어느 시점에 누가 어떤 변경사항을 만들었는지 알기 어렵게되고, 따라서 어느 시점으로 돌아가야할지 로그가 잘 남아있지 않다면 찾기 어려울 것입니다. 그러한 목적에서 정확한 커밋 단위와 좋은 커밋 메시지를 남기는 것이 중요합니다.

 

커밋 단위의 관점에서, 왜 커밋 단위를 작게 가져가는 것이 좋다고 하는걸까요? 보통 개발을 하다보면 기능 단위로 commit을 하려고 해도, 몰입하다보면 commit 시점을 놓쳐서 한 번에 많은 기능을 묶어서 커밋한 경험이 있으실 겁니다. 저도 그런 경험이 많은데요, commit을 통해서 특정 작업을 되돌릴 수 있는데 만약 A라는 기능과 B라는 기능이 묶여서 커밋되어있는데 A라는 기능의 커밋만 수정하거나 복원하고 싶은 경우, 쉽지 않을 것입니다. 그렇지만 A와 B의 수정 사항을 각각 커밋한다면 쉽게 되돌릴 수 있습니다. 그리고 좋은 커밋 메시지로 이러한 커밋 각각을 잘 포장해서 나중에 쉽게 구분할 수 있게 하는 것 또한 중요합니다. 커밋 메시지를 잘 작성하면 코드 리뷰를 받을 때도 리뷰어가 변경 사항을 이해하기 훨씬 수월하고 결과적으로 유지보수에 도움이 될 것입니다. 일반적으로 커밋 메시지를 작성할 때 지키는 commit convention이 있습니다.

이번에 구현한 사다리 타기 프로젝트에서는 udacity의 커밋 컨벤션을 지켜서 작성했습니다.

http://udacity.github.io/git-styleguide/

Udacity Nanodegree Style Guide

commit convention 적용, Imoji를 이용해서 메시지를 작성하는 방법도 좋습니다.

최종적으로 Pull Request을 올려보았는데요, Commit 메시지를 잘 작성하는 것이 중요한 것만큼 PR 메시지를 잘 작성하는 것도 중요하다고 합니다. PR은 풀 리퀘스트의 목적을 정확하고 구체적으로 기술해야합니다. 예시로는 어떤 일을 했고, 어떤 점이 부족한지 등등 협업 환경에 맞춰 다양하게 작성 가능합니다.

EOL 추가의 의미

Github에 마지막 줄 개행(End Of Line, EOL)이 없는 파일을 올리면 빨간색 줄로 EOL이 없다고 나옵니다. Intellij등 IDE에서는 마지막 줄 개행문자를 넣지 않아도 자동으로 개행 문자가 삽입됩니다. 그렇다면 왜 개행을 넣어야 할까요? 이는 여러 UNIX 운영체제 간에 공통된 API와 인터페이스를 정의해둔 POSIX 명세 때문입니다. 시스템과 프로그램들이 POSIX 명세에 따라 구현되는데, 이를 위반 시 예기치 않은 동작이 발생할 수 있습니다.

주석을 활용하기

주석없이 이해할 수 있는 코드가 좋다고 하지만 그런 코드를 짜기 어렵습니다. 최고의 주석은 좋은 설계와 이름짓기라고 합니다. 좋은 설계와 이름짓기를 통해서 주석 없이도 제 3자가 코드를 쉽게 이해할 수 있는지 생각해보고 부족한 부분이 있다면 주석을 정성을 들이고 고민해서 올바른 의미를 전달하도록 노력해야합니다.

코드를 간결하게 유지하자

불필요한 코드를 남겨두지 않아야합니다. 코드를 수정하고 아까우니, 혹은 나중에 쓸 일이 생길지도 모르니 코드를 보관하거나 주석처리해두는 것은 좋지 못한 습관인 것 같습니다. 그보다는 git의 버전관리를 이용해서 커밋들을 남겨놓으면 나중에 필요해진다면 가져와서 사용할 수 있으니 현재의 코드를 항상 깔끔하게 유지하도록 해야합니다.

지역변수, 멤버변수 최소화

지역변수, 멤버변수를 최소화하는 것이 좋습니다. 클래스가 꼭 이 멤버변수를 가지고 있어야하는지에 대해서 고민해보고, 지역변수의 경우는 굳이 지역변수로 가지고 있어야하는 경우가 아닌지 생각해봅니다. 메서드의 인자로 넘기기 위한 지역변수 대신 바로 인자로 넘겨주는 방법으로 지역변수를 제거할 수도 있습니다. 꼭 필요하다면 지역변수를 재활용할 수 있는 경우도 있을 수 있습니다. 지역변수, 멤버변수가 많아질 경우 큰 규모의 프로젝트에서는 메모리가 부족해질 수 있으니 가급적이면 불필요한 변수는 선언하지 않습니다.

magic 넘버 사용하지 말자

magic 넘버를 사용하면 코드를 이해하기 어렵게 됩니다. 항상 naming으로 적절한 이름을 부여해야합니다.

 

Getter와 Setter를 남발하지 않는다

객체는 행동이 상태보다 중요합니다. getter를 쓴다는 것은 무언가 내가 할 일을 다른 클래스가 하고 있거나, 내가 충분한 메소드를 제공하지 않고 있다는 뜻일 수도 있습니다. 불가피하게 getter를 사용해야하는 경우라면 다른 참조하는 객체가 수정할 수 없도록 deep copy를 한 객체를 반환하거나, 불변한(immutable) 상태로 만들어서 반환해야합니다. 대표적으로 list에서는 Collections.tounmodifiableList를 사용하면 수정할 수 없는 상태로 list를 반환할 수 있습니다.