업무중 개선 사항과 시행착오 기록

업무중에 개선했던 과정과 개발 프로세스 이해도 부족으로 생긴 시행착오 기록

1. 코드레벨에서의 개선 사항

과거에 문제를 해결하기 위해 만들었던 소스가 (이전 개발자의 의도를 정확하게 파악하지 못함 -> 확장)의 과정을 거쳐 거대한(?) 관리포인트를 양산하는 상황이 발생할 수 있다. 이 상황을 예방하기 위해 과거에 만들어진 소스에서 신규 구현을 할 때에도, 이전 코드에 대해 다시 검증하고 생각해보며 더 효율적으로 관리할 수 있는 코드에 대해 고민할 필요가 있다.

내가 업무 과정에서 개선했던 이슈를 공유하고 기록하고자 한다.

이전 코드는 Repository로 추상클래스를 만들고 그 추상클래스를 상속받은 DataSource class를 이용하여 데이터를 호출하는 형태로 구현되어있었다.

신규 요구사항은 기존에 사용했던 외부 api의 제공이 끝남에 따라 새로운 api로 데이터를 호출하는 과정이 적용돼야 했고 호출하는 데이터의 모양도 변경되는 상황이었다.
Repository로 만들어진 추상클래스 안에는 외부, 내부 데이터 호출을 모두 추상화한 상태로 작성되어있었고, 상속받은 각각의 DataSource클래스에는 사용하지 않는 method들이(외부에서만 사용하거나, 내부에서만 사용하는) 구현되어 있었다.

내가 생각하는 최악의 개발 case
: 문제점을 인식하지 못하고, 신규 기능을 붙여넣는 경우
Repository 추상클래스에 신규 기능 추가 -> 구현한 클래스로 기능 구현 (기능이 추가, 수정될 때에 구현 및 변경해야 할 클래스들이 거대해질 수 있음)

내가 해결한 방법
: 포괄기능이 아닌 각자의 기능을 overide해서 각 datasource에 맞는 기능으로 만들어 사용하도록 변경.
현재 Repository의 영향 범위가 넓어 기존 클래스는 남기고 개선한 클래스(변경된 기능에 해당하는 클래스)를 생성하여 나누어 개발함.
기존 Repository 클래스의 영향도가 큰 DataSource 하나만 남겨 상속받고 다른 DataSource들은 다른 추상클래스 생성 및 상속받아 사용하도록 구현함.

장점!
1) 잘못된 추상 클래스의 부피가 커지면 잘못 상속받은 클래스들의 관리포인트가 계속해서 늘어날 수 있고, 그 가능성을 없애기 위해 의도에 따라 추상화 클래스 생성.
2) 잘못된 추상 클래스의 추가 기능들이 생성될 때 협업하는 개발자가 다른 레포지토리의 소스를 확인하여 나뉘어진 의도 파악이 쉬워질 것.

단순 구현 업무도 같은 일정내에 개선할 수 있는 부분을 찾아 개선하며 서비스에 기여하는 개발자가 되고싶다. 같이 일하고 싶은 개발자가 되려면 이러한 과정을 계속 겪으며 고민해야하지 않을까?

2. 업무 초반. 개발 프로세스 이해도 부족으로 같은 업무 다시함

문제 인식

: 앱 사용자가 비즈니스상 의도한 상황으로 움직이지 않는 이슈를 확인했다. 이슈 원인은 서버에서 내려주는 상태값과 클라이언트 상태값의 차이에 따라 발생한 동시성 이슈였다.

그 이슈를 해결하는 과정에서 동기화가 끝날 때까지 비즈니스 프로세스를 진행시키지 않는 것이 필요하다 생각했다.

해결 방법으로 프로세스 진행을 위한 버튼을 비활성화 처리하고 동기화가 완료됐을 때 버튼을 활성화시키는 방향이 적절하다 판단했고 개발을 진행했다.(혼자 서비스만드는게 아닌데..)

개발을 끝내고보니 'UI처리는 UX팀의 의사결정이 필요하지 않을까?' 라는 생각을 하게 되었고, 급하게 UX팀에게 이슈 상황과 처리 방향에 대해 문의했다. 내가 문제를 개선하기 위해 개발했던 방향으로도 처리는 가능하지만 동기화 이슈에 대해 UI 비활성화를 계속 사용자에게 보여주는 것보다는 클릭에 대한 에러 alert으로 처리하는 것이 기존 사용자 경험에 통일성을 줄 것이라는 답변을 받게되었다.

개발했던 비활성화 기능보다 훨씬 간단하게 개발이 가능했고 기존의 사용자 경험에도 영향을 주지 않으면서 개선된 결과를 가져올 수 있었다. 어떤 개발을 하기 전에 정확하게 문제를 인식하고 그 문제를 해결하기 위해 필요한 리소스 파악을 명확하게 해야함을 느끼게 되었다.

평소에도 커뮤니케이션의 중요성, 문제인식의 중요성, 리소스 파악의 중요성에 대해 알고 있다 생각했다. 그러나 실전에서 시행착오를 경험하게 되었다. 과감하게 커뮤니케이션하고, 필요한 것들에 대해 요구하며 함께 고민하는 과정을 통해 같이 서비스를 개발하는 동료로써 생산성을 계속해서 높일 수 있는 개발자가 되려 한다. 내가 낼 수 있는 퍼포먼스에서의 개선 사항을 계속 발견해나가자. 더 좋은 동료가 되기 위해!