솔직하게 주니어레벨에서 이러한 것을 적어봤자 무슨 의미가 있나 싶을 수 있다...
회사에서 처음 입사하자마자... 서비스 리뉴얼 작업을 처음부터 맡아서 기존의 J2EE로 되어 있는 프로젝트를 Java Spring 부트로 설계, 작업 하는 일원의 베이직으로 참여하였다.
이제 다음주면 QA인데, QA가 진행되는 주에 앞서서 개인적인 생각을 3가지 정리하고, 마음을 다 잡아보려고 한다.
마이너한 설계라고 간과하지 말자
회사에서의 서비스는 인공지능을 활용한 교육관련 서비스였다.
그렇다면 여기서 주된 서비스는 인공지능 그리고 교육에 대한 데이터를 어떻게 보여주는가 이 부분과 어찌되었던 유저부분일것이다.
나는 갓신입 0년차 아무것도 모르는 처지로 게시판을 맡게 되었는데, 마이너한 부분의 설계여서 초기에는 의욕 가득한 상태로 생각나는대로 작동만 되게 막 만들었다.
어찌되었던건 내 파트는 서비스에서 가장 중요한 핵심이 아닌 서비스에서 사용자의 편의를 돕는 부가적인 기능이라고 여겼기 때문이다.
분명 이걸 보는 사람들은 어리석고 오만하다고 생각할 것인데, 그랬었다... 인증과 인가에 대한 간과 그리고 설계시에 각 게시판의 성격에 맞는 유저들에게 호출해줘야하는 API등등의 고민이 덜 되어 있는 상태로 작성하니... 결국에는 탄탄한 설계의 구조와 다른 형태로 진행되어, 후에 진짜 메이저한 기능을 할당 받았는데 게시판 버그로 1달여의 시간을 소모하여 고생하게 되었다.
처음 설계부터 문서화 시켜놓는 버릇을 무조건 습관들여야한다.
내가 이해하는 설계가 아니라 다른 사람이 이해하는 설계를 하자
배우는 과정에서는 내가 이해하는 설계를 최대한 사용하고, 내가 이해하는 개념들을 녹여서 같이 공부하는 친구들, 동료들과 진행을 하였다.
학교에서는 C#을 한국에서는 자바를 공부하면서 두 언어의 특징인 객체지향과 그것을 활용하기 위한 다양한 노력들 그리고 그에 대한 원칙을 지켜가면서 개발을 하게 되었다.
그 중 내가 지키고자 하는 원칙하나가 다형성인데 다형성과 함께 Five Lines of Code 라는 책을 읽고 코드의 라인이 길어지는 것을 극도로 꺼려하려다 보니, 한 로직을 위해 여러 클래스를 타고 들어가고 공통적인 부분을 추상화 시켜서 사용하다 보니 확장성이 깨지는 문제점도 발생하게 되었다.
물론, 인터페이스나 아니면 다양한 기술을 활용하면 되겠지만, 중요한것은 실무에서는 내가 이만큼 알고 이만큼을 할 수 있으니 이걸 이해할거면 이정도는 알아야지? 라고 할 수준이 내가 아니라는 것이다... 그렇다는 것은 본투비 베이직으로 돌아가서 내가 이해하는 설계가 아니라 다른 사람이 나의 설계를 이해할 수 있는가?
- 내가 피치 못할 상황이 되어도 이 코드를 리팩토링할 누군가가 있는가?
- 코드의 오류가 있다고 누군가 말 할 수 있을정도로 코드를 꼬아놓지 않았는가?
이러한 부분을 고려해 타인이 이해하는 설계가 중요하다
아니, 매우 심각하게 정말 엄청 중요한 사항이다.
결국 이러한 부분은 서비스가 확장될 수록 나역시도 이해를 할 수 없는 지경에 이르러 버린다.
긍정적인 설계를 하자
그냥 마인드적인 부분이다...
사실, 버그가 많은데 그 버그에 스트레스 받고, 내 실력에 스트레스 받고 회의에서 이해 못함에 스트레스 받고, 일정에 스트레스 받고... 스트레스 받을 일들이 많다.
하지만, 긍정적으로 생각해보자...
내가 어떻게 미천한 0년차 응애 아가가 이런 귀한 경험을 할 수 있을까?
아니... 0년차가 아니더라도 이런 경험은 귀할것이라고 생각한다...
나는 부정적인 에너지를 생각할 바에 그 힘으로 집에가서 공부를 좀 더 하는 편인거 같다..
다음주 QA... 기대가...된...다...ㅠㅠㅠ
모든 나와 같은 처지에 있는 사람들 화이팅! @_~
