DEV

⌨️ 개인의 편리를 위해 규약을 느슨하게 해선 안된다결론부터 말하자면 살짝 느슨해진 것 같다.일을 하다 보니 어느새 귀찮은 것들에 대해 피하고 싶어 졌고, 그것이 곧 옳지 못한 구현으로 이어지기도 했다.이 글은 그런 날을 돌이키며 기억해 두고 채찍질하기 위함이다.  🤔 쿼리스트링이 긴게 문제일까? 동료가 다른 일을 하는 동안 나는 작업하기 편하게 프론트를 조금 만져주는 걸로 일을 나누었다.프론트에서 `Get` 요청을 보낼 때 쿼리스트링으로 만들어 주길 요청했으나. 나는 쿼리스트링이 너무 길어져서 불편해서 그런데 `Post`로 RequestBody에 담아도 될까요?라고 했다. 이런저런 이야기가 오고 갔지만, 결과적으론 쿼리스트링이 길어서 불편하다는 내 의견은 그냥개인의 불편함을 호소하는 것뿐 합당한 이유..

⌨️ 유연한 사고?유연하게 사고하는 것은 생각보다 문제 해결에 있어서 중요하다고 생각합니다.생각보다 사고는 더욱 경직되어 있어서 유연한가? 싶어도 돌아보면 딱딱한 상태더군요.  🤔 불필요한 데이터를 삭제하는 일요구사항을 구현하기 위해 만든 기능에서, 불필요한 데이터가 남는 상황을 발견했습니다.이 외에도 간간히 이런 것들에 대해 고민을 한 적이 있습니다. 예를 들어 이미 올라온 파일(이미지나 동영상) 등의 참조가 변경되어 더 이상 사용하지 않는 자료가 되어 버린다든지 어찌 됐든 나의 저장소로 차지하는 것에 있어서 해결을 하고 싶었던 적이 있었습니다.  ✅ 지연 처리가 나쁜 건 아니잖아?제가 꽤 자주 하는 실수 중 하나가 바로 '즉각성'에 너무 과몰입하는 것입니다. 즉각적으로 요청과 응답이 주고받아지고 그..

⌨️ 주니어의 관점에서?최근 신규 기능을 추가하고 기존 기능들을 개선하면서 배우거나 생각해 볼 만한 것들에 대해서 정리를 했다.일전의 모 유튜브에서 이런 말을 본 적이 있다. 입문 수준의 개발자들은 기능을 구현하기에 급급해서 코드의 품질이 떨어진다. 이전에는 이 말이 단순히 코드의 가독성이나 짜임새를 말하는 줄 알았는데, 최근에서야 어떤 시야가 트이게 됐다. 혼자서 느낀 건 아니고 지속적으로 통찰점을 제시해주는 동료분이 있어서 가능했다고 생각한다.1. PDF 파일 생성 후 메일 발송 기능우선 간단히 제한 사항에 대해서 말해보자면 1. 클라이언트에서 한번에 대용량의 파일이 전송된다.2. 서버에 데이터를 저장할 필요는 없으며 메일 발송 시 어차피 byte []로 다시 넣어준다.3. 서버의 성능은 그리 좋지 ..

📚 정보분야 : 개발..?난도 : ☆☆☆☆☆추천 : 👍⌨️ 다양한 경험에서 우러나오는 종이 멘토이 책을 작성해주신 두 분 다 다양한 경험을 해서 그런지 많은 간접 경험을 할 수 있었다.그리고 쉽게 읽힌다. 어려운 기술서적이 아니라 오고 가며 대중 교통 혹은, 쉬는 시간에 한 꼭지씩 읽기 괜찮다 ✅  개발자로써의 나란 사람이 책을 다 읽고 가장 처음 든 생각은 개발자로써 나는 어떤 사람인가? 이다. 내가 왜 개발자가 되고 싶었고, 어떤 개발자가 되고 싶은 지, 무엇을 만들고 싶은 지 한번은 돌아 봐야할 필요성을 느꼈다. 그리고 나만의 원동력을 찾아야겠다. 동력은 생각보다 크게 작용하여 이게 없는 일을 할때는 배터리가 다 나간 전기자전거 마냥 그냥 끄는게 더 힘이 든다.반면 동력이 있다면 쉽게 쉽게 쭉쭉..

⌨️ 언제 적 코딩 테스트? 이미 한국 패치가 잔뜩 들어간 코딩 테스트에 대해 회의적인 시각이 많아진 현재다.그러나 그런 시각과 별개로 여전히 코딩 테스트는 유효한 검증 수단이다. 애석하게도 수능에서 5등급을 맞은 학생이 1등급을 맞은 학생에게 수능이 중요한 게 아니야라고 말하는 것만큼 우스운 꼴이 없을 거다.그리고 잔혹하게도 현실은 1등급을 맞은 학생이 더욱 좋은 대학에 갈 확률이 높다.  이것은 어찌할 수 없는 현실이다. 자 그럼 여러분은 빠르게 현실을 받아들였다고 가정하자. a) 필요성을 느껴 열심히 준비해 좋은 결과를 낸다.b) 현재는 여력이 없다 반수나 편입을 노리자.c) 만족하자 보통 이 세 가지의 경우로 수렴할 것이다. 나의 경우 여러 상황을 고려하여 b를 택했고, 개발 직군으로의 전향 혹은..

📚 정보분야 : 자바/스프링난도 : ★★★☆☆추천 : 👍⌨️ 입문과 고급 그 사이무엇이든 중급 과정이 어렵다. 입문은 많고 고급은 어렵고, 누군가 나에게 입문에서 고급으로 갈 수 있는 중간다리를 놔주었으면 하는 생각이 많이 들 때, 우연찮게 발견한 이 책은 나에게 많은 도움을 주었다.1. 기술 보다 개발신입 개발자 혹은 취준생들에게 많이 보이는 경향이다. 이 책의 저자는 개발실력보다는 기술적 스펙트럼만을 넓히려는 신입/취준생들에게 안타까운 맘을 비치는 스탠스이다. 그러나 개요에서 말한 바와 같이 입문은 쉽고 고급은 어렵다, 그렇다면 중급이 있어야 하는데 실상 중급은 접하기 어렵다.(기술적 수준이 아니라 강의나 자료의 수와 접근성 그리고 강의 내용의 관점) 그렇기에 나 포함 많은 신입 혹은 취준생들이 ..

항상 뭉쳐 다니는 데이터는 한 곳으로 모아두는 것이 좋다. 여러 클래스에 존재하는 비슷한 필드 목록 여러 함수에 전달하는 매개변수 목록 관련 리팩토링 기술 "클래스 추출하기"를 사용해 여러 필드를 하나의 객체나 클래스로 모을 수 있다. "매개변수 객체 만들기" 또는 "객체 통째로 넘기기"를 사용해 메소드 매개변수를 개선할 수 있다.

기능 편애 어떤 모듈에 있는 함수가 다른 모듈에 있는 데이터나 함수를 더 많이 참조하는 경우에 발생한다. (결합도 높음) 예) 다른 객체의 getter를 여러개 사용하는 메소드 관련 리팩토링 기술 "[[Divergent Change#2. 함수 옮기기 (Move Function)|함수 옮기기]]"를 사용해서 함수를 적절한 위치로 옮긴다. 함수 일부분만 다른 곳의 데이터와 함수를 많이 참조한다면 "[[Duplicated Code#1. 함수 추출하기|함수 추출하기]]"로 함수를 나눈 다음에 함수를 옮길 수 있다. 만약에 여러 모듈을 참조하고 있다면? 그 중에서 가장 많은 데이터를 참조하는 곳으로 옮기거나, 함수를 여러개로 쪼개서 각 모듈로 분산 데이터와 해당 데이터를 참조하는 행동을 같은 곳에 두도록 하자 예..

산탄총 수술 어떤 한 변경 사항이 생겼을 때 여러 모듈을(여러 함수 또는 여러 클래스를) 수정해야 하는 상황 "[[Divergent Change|뒤엉킨 변경]]"과 유사하지만 반대의 성향 예) 새로운 결제 방식을 도입할면 여러 클래스의 코드를 수정해야 한다. 변경 사항이 여러곳에 흩어진다면 찾아서 고치기도 어렵고 중요한 변경 사항을 놓칠 수 있는 가능성도 생긴다. 관련 리팩토링 기술 "[[Divergent Change#2. 함수 옮기기 (Move Function)|함수 옮기기]]" 또는 "[[#1. 필드 옮기기 (Move Field)|필드 옮기기]]"를 사용해서 필요한 변경 내역을 하나의 클래스로 모을 수 있다. 비슷한 데이터를 사용하는 여러 함수가 있다면 "[[Long Paramater List#3. ..