24년 1주차 회고(24.1.1 ~ 1.5)

회고라는 것을 처음 작성해 본다.

 

회사에서 프로젝트 내 스프린트가 끝날 때마다 회고를 하긴 했지만, 목적없는..? 관례적인 회고로 느껴질 뿐 건설적인 회고는 부족한 듯 느껴졌다. 올 한 해동안에는 주마다 회고를 작성하며 더 나은 개발자, 더 지혜로운 사회인이 되고 싶다. 무작정 회고글을 작성하고 있지만, 앞으로는 회고 방법과 좋은 회고글들을 참조하여 내 회고글에도 적용하려 한다. 24년 달려가 보자고!

 

* 개발

개발 관점에서 궁금했던 포인트나 얻었던 인사이트 들이 있을까?

 

개발을 할 때, 관심사의 분리, 단일 책임 원칙 같은 개념에 대해 이야기했었다.

상속 받은 자식 클래스들은 specialized 한 클래스들, 그리고 데이터를 직접적으로 가공하는 곳은 데이터와 연관된 모듈, 클래스들이 되어야 한다는 것. 데이터를 멀리 떨어진 곳에서 가공하는 안좋은 습관이니 데이터가 파생된 가까운 곳에서 고치는 것이 좋다는 것에 대해 이야기 나눴던 경험이 기억난다.

이러한 원칙들은 OOP 내에서 굴직한 개념들인데, 보다 전문적으로 학습하고 실무에서 도입할 필요가 있다.  

 

그리고 맞이했던 특이한 이슈가 프론트에서의 Request 보내는 내용과 백엔드에서 받는 데이터의 내용이 상이한 상황이였다.

프론트에서 보냈는데, 백엔드에서는 못 받고 있는 상황에 크롬 개발자 도구 네트워크 탭에서도 클라이언트의 요청이 확인이 안되는 상황이였다. 이러한 상황으로 인해 fiddler를 사용하여 전송되는 패킷의 데이터를 확인하여 클라이언트에서는 정확하게 데이터를 보내고 있음을 확인했다. 이후 백엔드에서 데이터를 받는 상황이 문제가 됬는데, 이 이슈는 차주(24년 2주차)에도 진행될 부분으로 2주차 회고 때 내용을 마저 적어놓아야 겠다. 무튼 답답하지만 재밌는 상황이였고, 좀 더 통신에 대해 고민하게 되는 시간이였다.

 

마지막으로 쿼리를 보는 시간이 늘었고, 쿼리를 통해 api 요청이 어떤 내용인지 이해할 수 있게 되었다. 클라이언트 단에서 쿼리를 작성하는 graphQL이 데이터를 가져오는데, 프론트 개발자가 직접 개입해서 코딩하니까 빠르게 실서비스에서 데이터를 가져올 수 있을 것 같다. 물론 이에 대한 부작용도 많겠지만. 고로 graphQL을 틈틈히 공부해보면 어떨까 싶다.

 

 

* 커뮤니케이션

컨택팀과 개발팀 사이에서 업무를 조율하는 분과의 소통이 어려웠다. 24년 바뀌는 부분들을 새롭게 적용할 때, 인지하지 못하고 있었던 것(특정 부분에서 영어 값은 대문자로 들어가야 한다)이 기본이 아니냐는 이야기를 하시는데, (동료의 표현을 빌리자면 개발도 기본 아닌지 물을까 하다..)   어디까지 물어보고 작업을 해야하는 걸까 당황스러웠던 것 같다. 최대한 의심스러운 부분들은 전부 물어보는 것이 좋겠다는 생각이 든다.

 

 

* 전반 생활

의료 도메인에 있어 그런지, 24년 심평원에서 새롭게 내리는 공지들에 맞게 코드를 고쳐야 하는 신년 맞이 스프린트를 한 한주였다. 겁나 바빴다. 그리고 차주도 바쁠 것 같은데, 그 바쁜 일정을 제어할 수 있는 방법이 무엇이 있을까 고민하고 해결해보자.