Reflections of July

1월 1일에 소래산 가서 지키지 못할 여러 목표들을 다짐했던게 최근일 같은데 벌써 3분기다.

회고 쓰는 일은 정말 귀찮지만 뭘했는지 확인하기 좋다. 그리고 다음달에 어떤걸 할지도 생각할 수 있다.

평소에는 생각을 해도 금방 잊기 때문에... 다음 달에는 어떤 게시물을 읽었는지, 어떤 생각을 했는지도 써야겠다.

 

7월에 나는 뭘 했을까?

---

팀장님과의 코드 리뷰

80개의 댓글 🫣

새로운 프로젝트를 시작했는데 모든 정보를 만들어주면 해당 정보를 가공해서 이메일, 알림톡을 보내는 부분을 구현하게 되었는데 

마침. 팀장님이 알림통지서버 건설을 진행중이셨다.

아직 예약발송 기능이 없었기 때문에 살짝쿵 얹어서 PR 했는데 수많은 관심과 댓글로 삼진 에바 기각 되었다.

 

동료분이 보내주신 짤 (ㅋㅋㅋㅋㅋㅋ)

공통적으로 사용하는 기능이기 때문에 최대한 '라이브러리' 처럼 만드려고 하셨다고 했다.

코드 리뷰중 놓친걸 많이 잡아내는 과정에서 내가 참 섬세하지 못하구나 생각하게 되었다. 프로젝트 마감일이 다가와서 그랬는지 몰라도 항상 마음이 급한것 같다. 정말~~~~침착해질필요가 있다. 시간 걸려도 꼼꼼하게 하자!!!!!!!!!!!!!!!!

 

마인드셋

요즘은 어떻게 하면 더 잘읽히는 코드를 작성할 수 있을까 라는 고민을 제일 많이 했는데,

최근의 같이 일하는 동료분과 이야기를 나누다가 머리가 띵해 졌던 경험이 있었다. 

내가 개발한 기능이 아니라도 어쨌든 사내 운영팀에서 사용하는 기능인데 내가봐도 불편해보이거나 혼란스러운 부분은 당연히 책임을 지고 개선해 줘야 하는것이 아닌가에 대해서 생각하게 되었다.

결론은 개발자는 내가 작성한 코드가 범용성있고, 아름답게 작성하는것도 중요하지만

최종적으로는 내가 작성한 코드의 기능이 쓸모있는지, 오류 없이 잘 작동하는지가 제일 중요한 목표인것 같다.

 

그렇게 해서 ... 최근에 운영을 많이 하게 되었는데 단발성으로 처리해도 되는 일이지만 리팩토링을 진행하면서 처리하고 있다보니 시간이 오래걸리고 이미 잡혀있는 일정도 처리해야 해서 스트레스를 많이 받고 있다...

 

딱 이런 생각을 하고 있을 때 최근에 팀장님이 관련된 글을 공유 해주셔서 고개를 끄덕거리면서 읽었다.

내가 원하는게 문제 해결형 개발자라고 하는구나. 워딩이 멋지다.

이 글을 작성하신 개발자분은 변수 네이밍을 기막히게 만드실 것 같다.

 

https://velog.io/@eddy_song/problem-solver

내 코드 리팩토링

이전에 해당하는 여러 업체의 사용중인 카테고리 개수를 확인하는 목록에서 타임아웃 버그가 있었는데

급하게 프론트에서 요청 시간을 늘려서 해결했었다. 이번에 다시 확인하게 되었는데 

(모든 카테고리 - 제외된 카테고리) 에 대한 개수를 구하는데 모든 업체 만큼 for문을 돌려 새로 구하고 있었다.

    return targetList.stream()
        .map(this::createDto)
        .collect(Collectors.toList());
  }

  private Dto createDto(Target target) {
    return Dto.builder()
        .dto(toDto(target))
        .categoryCount(count(target))
        .build();
  }

    return createDto(targetBranchList);
  }

  private List<Dto> createDto(List<Target> targetList) {
    Target target = targetList.get(0);
    int countCategory = count(target);
    return targetList.stream()
        .map(b -> Dto.builder()
            .dto(toDto(target))
            .categoryCount(countCategory)
            .build())
        .toList();
  }

모든 카테고리 개수는 모든 업체가 같기 때문에 한번만 구하는 방식으로 수정했다.

사소한 수정이지만 속도 개선이 크게 이루어졌다.

 

리팩토링을 하면서 역시 업무시간에는 불가능하다고 생각했다. 처음부터 클린하게 코드를 짜고 싶지만 내 능력 부족이고 시간도 부족하다. 그래서 심심할 때, 공부도 끝났을 때 틈틈히 해야할 것 같다. 개발을 일로 생각하지 않도록.

내가 좋아서 선택한 길 투자해서 좋아하는일을 더 잘하고 만족을 느끼는것을 목표로 꾸준히 하자!

 

사내 인터뷰

회사에서 사내 정보 공유 차원에서 뉴스레터를 제작하고 있는데 참여했던 프로젝트 관련하여 인터뷰를 작성 해달라는 요청을 받았다. (급하다고 해서 급하게 써서 제출했는데 아무런 소식이 없어서 어떻게 된지 모르겠다.)

 

8월에 나는 뭘 할까

---

• 계속 미루고 있는 미라클 모닝 시작하기
  • 그냥 무작정 빨리 일어나고 싶은것 보다는 패턴이 생기면 좋겠다.
•  주2회 운동 하기
  • 운동을 안했을 때 항상 어깨가 아팠다.
  • 운동을 시작하니 어깨가 아프지 않다. 
  • 3일 이상 운동을 하지 않으면 어깨가 아프다.
• 세미나 발표 퀄리티 높이기
  • 최근에 회사에서 한달에 한번씩 세미나를 하고 있어서 회사 내부에서 하고 있는 스터디 내용을 발표하고 있다. 처음에는 너무 과하게 준비해서 스터디 지속성 에 대해 우려를 표현 하셔서 이후에 가볍게 발표했는데 그러다 보 니 퀄리티가 낮아지고 있는게 아닐까 생각하게 되었다. 발표를 많이 안해봐서 정보를 전달하는게 어렵다.
• 스터디 마무리
  • 테스팅 스터디가 끝나고 다음엔 어떤 스터디를 할까? 고민중
• 제품 코드에 테스트 코드 적용하기
  • 8월 부터 12월까지 해야할것을 생각하고 있다.
  • 현재 사용되고, 파악 가능한 코드 테스트 작성하기.
  • 단위테스트 위주로 작성하되 엄청 중요하다 생각하는 로직은 통합 테스트 하기.
  • 테스트 환경 구축하기 (DB 세팅 등 ...)