230713 목요일 업무 TIL

'오늘 나에게 한마디'
비가 계속해서 내려서 힘들지만, 그래도 힘내자!



'오늘의 고민'
팀원분이 자신이 신입때 많이 어려워했던 주제라며 java의 'call by value'와 'call by reference'에 관한 글을 보내주었다. 나도 한동안 잊고 살았던건데, 자신도 이 글을 보며 배열 값 등에서 현재 업무를 할때 많이 도움이 되었다고 한다. 나는 이런 생각도 하지 못하고 살았는데.. 이런 글을 보내준 팀원이 정말 감사했고 나도 이를 기반으로 더 공부해야겠다는 생각이 들었고 약간은 부끄럽기도 했다.

프로젝트마다 하위 업무 채널이 있으면 좋지 않을까?라는 생각이 들었다. 계속 작업자가 여러 사람에게 팔로업을 해야 하는데 비효율적이라는 생각이 들었다.



[잘한점]
상황1) 날씨에도 굴하지 않고 식지 않는 일에 대한 열정!

액션1) 비가 와서 몸이 축 처지긴 했지만, 그래도 내 맡은 일들은 책임지기 위해, 집중력이 떨어지지 않기 위해 팀원들과 업무에 대해 소통하며 집중력을 잃지 않으려고 했다.

칭찬1) 힘든 상황에도 굴하지 않고 일을 하려는 열정을 높게 사고 싶다 :)

[개선점]
문제1) 다른 팀원의 코드에 내 코드를 추가할때 사이드 이펙트를 생각해야하는게 어렵다.

원인1) 로직 작성에만 시간을 쏟다보니 내가 추가한 로직의 사이드이펙트를 고려하는 것에 대해서 아직까지 크게 와닿지가 않는 것 같다. 머리로는 '내 코드 때문에 혹시 다른 쪽에서 영향을 받으면 어떡하지?'라는 생각이 드는데, 우선 이 로직을 해결해서 코드에 추가하는 것 밖에 생각이 들지 않아 사이드이펙트를 고려하는데 아직까지 어려운 것 같다. (신입일때 이거 고려하기 어렵다는 팀원의 썰..)

액션플랜1) 내가 로직을 추가하고자 하는 API(다른 팀원이 만든)에서 이게 어디서 어떻게 쓰이고 있는지 미리 파악을 해야 하고, 로직을 추가하기 전에 이 API의 데이터 response 형태가 어떻게 되는지 postman으로 먼저 테스트를 해봐야 한다(응답값 형태가 어떻게 내려오는지, 어떤 응답값들을 내려주고 있는지 등)

[배운점]
배움1) 브랜치가 너무 많이 생기면 난잡해지니까 Develop 브랜치에 반영되면 하위 작업 브랜치는 지우는 것이 좋다고 한다.  

의미1) 파일 크기도 줄어들고, 작업 depth를 찾는데 오래 걸리지 않게 되니 앞으로 사용하지 않는 브랜치는 모든 작업이 끝나면 지우는 습관을 들여야겠다.

배움2) 우리 백엔드 팀은 원래 develop > main 브랜치로 바로 배포하였다. 하지만 이번에 무언가의 계기로 다른 팀원이 main에 develop브랜치로 반영을 해서 라이브 환경에 develop환경이 나가는 이슈가 있었다. 그래서 develop브랜치와 main브랜치 사이에 hotfix 브랜치를 두자는 의견이 있었다.

의미2) hotfix 브랜치는 main에 바로 배포되어야 할 것이 이곳에서 출발하므로, DEV 소스가 main 브랜치에 반영될 일이 없다. 이런 의미에서 hotfix 브랜치를 둔다고 한다.
*  feature/JIRA 이슈명으로도 브랜치 이름이 많이 만들어진다고 한다.

배움3) unstash된 부분은 그때그때 정리를 하자. 안쓰면 롤백!
의미3) commit을 push 하려고 했는데 reject되었었다. 알고보니 unstash된 내용들이 있었는데 이거 때문에 eject된 것 같다. 그래서 reject되었다는 팝업이 떴을때 console detail 열어서 왜 commit이 reject 됐는지 확인하자.

배움4) undefined, null은 항상 예외처리가 필요하다
의미4) 프론트엔드단에서 두 값을 받을때 차이가 있다고 한다(이 차이에 대해서는 아직 잘 모르겠다.) 프론트엔드단에게 값이 없을때 undefined/null/0 중에서 어떤 형태로 값을 내려주면 좋을지?에 대한 상의가 필요하다.