같이 일하고 싶은 개발자

과거에 해당 부분에 대해서 팀 내 논의가 있어 해당 내용을 간략하게 정리하고 공유하고자 합니다. 팀 내 진행되는 프로젝트에선 API 컨벤션 및 협업과 관련된 컨벤션 논의가 활발하게 이뤄지지 않은 상태였습니다.그렇기 때문에 과거 정리해둔 글을 기반으로 회고하고 생각을 나누기 위해 글을 정리했습니다. 해당 아래의 내용은 과거의 내용입니다  당시 팀 내 진행되는 프로젝트에선 객체 조회 시 객체가 존재하지 않으면 정의된 예외를 발생하고 예외 핸들러를 통해 HttpStatus를 404로 전달하고 있었습니다. 주로 200Status 는 성공을 의미하는, 400번대는 잘못된 요처에 관한 내용을 담고 있기에 HttpStatus에 관한 나름의? 규칙을 준수하고 있다고 생각하고 있었습니다. 그러나 오늘 문득 코드를 작성하..

[ 바로가기 목차 ] 들어가기 알아보기 마무리 [ 들어가기 ] 여러 테이블 혹은 DB에서 데이터를 가져와서 원하는 작업을 하는 방법에는 여러가지가 있습니다. 가져온 데이터를 원하는 형식이나 여러 객체를 하나의 객체로 합치는 일은 매우 흔한 일입니다. 이때 이러한 매핑 작업을 직접 개발자가 하게 된다면 문제가 발생할 수 있습니다. - 코드의 중복 - 생산성 저하 - 실수로 인한 데이터 누락 - 복잡한 로직까지 추가된다면 코드 가독성 저하 이러한 문제를 해결하기 위해 스프링(Spring)에서는 라이브러리를 지원합니다. - Mapstruct - ModelMapper 맵 스트럭트(MapStruct) 와 모델 매퍼(ModelMapper)의 차이점을 간단하게 설명하자면 객체의 생성 방식에 조금의 차이를 가지고 있습..

올해 상반기에 대학 졸업 이후 취업에 성공하고 백엔드 개발자로 일한 지 어느덧 3개월이라는 시간이 흘렀습니다. 이 과정에서 많은 일이 있었고, 많은 것을 경험하고 느끼며 내가 개발자로서, 어른으로서 더욱 성장할 수 있었습니다. 치열한 현장에서 직접 땀을 흘려보니 과거의 노력이 값진 순간임을 알게 되었고, 겸손하고 더욱 노력해야 함을 알게 되었습니다. 학부 시절에 작은 프로젝트를 진행하면서 느낀 부분들과 현업에서 느끼는 부분은 크게 다르지는 않았지만, 그 '농도'는 달랐습니다. 자신의 직군에서 다른 직군을 이해하기는 어렵습니다. 그러나 특히 현업에서는 그러한 이해관계들이 매우 중요하고 좋은 관계를 유지할 수 있도록 노력해야합니다. 그러나 이 이상적인 내용을 적용하기 어려운 상황도 분명히 존재하기 마련입니다..

웹에선 HTTP 통신 프로토콜을 이용해 서버와 클라이언트 사이에서 통신을 한다. 그 프로토콜등을 이용해 우리는 원하는 데이터를 전달받을 수 있는데, 이러한 과정 속에서 궁금한 점이 생겼다. 우리는 그저 프론트에서 요청하는 데이터를 정확하게 전달해주면 백엔드는 그 역할이 끝났다고 생각한다. 원하는 데이터에 대한 로직을 검증하고 수행하는 역할은 백엔드에서 진행하고, 그 결과에 맞춰 프론트가 요청하는 데이터를 전달해주면 된다. 그럼 프론트 입장에서는 프론트로 전달되는 데이터들은 유의미한 데이터이며, 유의미해야만 한다고 생각이 들었다. 기존에 미니 프로젝트나 명세가 있으면 요구하는 데이터를 전달하면 되는데, 만약 그것이 없다면 어떤 데이터를 전달해야할까? 백엔드는 결국 요청에 대한 응답을 진행하는 거니까? 이 ..

저번에 신청한 스파르타 코딩클럽의 내일배움캠프의 사전캠프가 시작되었다. (보니까 모집일부터 시작해서 4기의 3번째 사전캠프-> 그전부터 하고 계신분들은 있었음!!) 아침부터 부랴부랴 일어나서 컴퓨터를 켜서 사전 캠프 장소인 ZEP으로 이동했는데, 게더타운보다 너무 좋았다. (게더타운 너무 무거움 인정? 어 인정) 내일배움캠프를 선택하기 전에 다른 교육도 하나 신청했었고, 그 교육이 먼저 발표가 났는데, 뭔가 이 스파르타 코딩클럽의 네임드에 매료되어서 결국 이 교육 과정을 선택하게 되었는데 전공자로서 느낀 것이 아! 교육에 포커스를 맞춘다기 보다는 이 긴(5개월)의 과정에 있어서 케어와 전반적인 관리?에 중점을 둔 느낌이 들었다. 매니저님들의 이야기와 전체적인 흐름이 전공 비전공 불문하고 누구나 쉽게 접할..