[JAVA] 키오스크

트러블 슈팅

 

1. 배경

• 전에 했던 과제를 반복해서 좀더 현업에서 진행하는 것과 같은 형식의 코딩을 진행하였다.
• 기본적으로 자바 기능을 재 학습하는 목적으로 사용된 프로젝트였다.

2. 발단

• 기본적으로 눈에 띄는 에러는 없었다.
• 다만 코드가 요구사항이 길어짐으로서 복잡해지는 점이 문제가 되었다.

3. 전개

 

• 기본적으로 코드가 길어지고 클래스가 늘면서 위와 같이 한 폴더에 7개의 파일이 생성되게 되었다.
• 많은 수는 아닐지 모르지만 가장 중요한 점은, 이 파일이 100개가 넘어가면 한 폴더에서 다 처리하기엔 가시성이 너무 떨어질 수 있다는 점이다.
• 두번째는 코드의 조건문의 형식으로 인해 가시성이 많이 떨어져 보인다.
• 실제로 객체 지향적인 코딩을 진행했지만, 이것만으로는 부족한지 내용에 수정이 필요해 보인다.

 

4. 위기

• 역시 폴더를 임의로 바꾸니 에러가 나기 시작했다.
• 내용은 패키지의 지정이 되어 있지 않아 생기는 오류였다.

5. 절정

• 검색해 보니 단순히 패키지 지정을 해주지 않아서 생기는 오류였다.
• 실제로 코드가 복잡해지고 나면 이런 저장소 위치나 수정 일시 등의 정보는 자주 기록하는 것이 좋다.

 

6. 결말

• 기본적으로 사용했던 기능을 복습하는 코드였다보니 어려운 응용은 없었지만, 아직 파일의 분리와 가시성에 대한 부분이 자연스럽게 진행되지 못한 다는 것을 깨달았다.
• 이는 유지보수에도 관련이 있지만 AWS와 같은 외부 요인의 업데이트로 발생하는 오류를 처리하는데도 도움을 줄 수 있다.
• SOLID원칙 객체지향 프로그래밍 등, 클린 코드를 위한 기법은 다양하게 많고 실제로 모든 상황에 앞선 기술들이 적용되진 못한다는 것을 감안하면, 앞으로의 코딩은 수행 - 검수 - 수정의 과정을 거쳐야할 것 같다.
• 즉, 스승이 필요하다..

 

7. 회고

• 확실히 전 보다 감이 오는 부분은 객체지향인 것 같다.
• 실제로 이 코드가 완전한 객체 지향을 수행한 것은 아니겠지만, 적어도 왜 객체지향이 필요하고 왜 요구사항이 중요한지는 파악할 수 있었다.
• 정확한 설계가 있어야 추후 문제가 없다. 완벽한 설계는 무리일지언정, 적어도 필요한 기능과 구현에 대한 정리는 머리속에 있어야한다는 것
• 이게 완료되면 다양한 설계 패턴과 디자인 패턴을 이용하여 최대한 코드를 알아보기 쉽게 짤 수 있어야한다.
• 이 과정에서 어노테이션과 주석이 정말 중요한 역활을 할 수 있다고 생각하게 되었다.
• 주석이라는 것이, 혼자 코딩할때는 대강 기능에 대한 설명을 단촐하게 서술하는 경우가 많았지만, 이렇게하면 추후 알아보기 힘들어질 수 있다.
• 실제로 혼자서 2000줄정도 넘어가면 코드를 짜던 나 조차도 이게 뭐지 하는 경우가 많이 있었다.
• 스프링은 특히 어노테이션으로 이루어져 가시성도 좋은 만큼 많이 활용할 수 있으면 장점이 클 것 같았다.
• 과거의 프로젝트도 이런 식으로 진행했으면 아마, 지금에 와서 다시 수정해서 사용해볼 수도 있었을 것 같다.
• 다만 셀레니움처럼 외부의 데이터가 자주 변경되는 경우 대응이 힘든 코드는 대체 어떻게 관리를 하는건지 여전히 모르겠다는 생각이 든다.
• 다음에는 이 유지보수 방법에 대해 깊게 공부하는 편이 좋을 것 같다.