ALL

⌨️  프로젝트라고 했지만 정확히는 사이드 혹은 토이포트폴리오를 위해서든 아니면 개인적인 실력의 향상을 위해서든 사이드나 토이 프로젝트를 하고 싶어 하는 개발자는 많다.그러나 혼자 하든 팀을 꾸리든 중간에 엎어지는 경우도 많고 뜻대로 되지 않는 경우가 부지기수다. 최근 들은 생각을 정리하여 프로젝트를 대하는 자세에 대해 기록하려 한다. ✅  하고 싶은 건 지 해야만 하는 건 지?다시 한번 내 마음에 물어보게 되었다.나는 이걸 하고 싶은거야? 아니면 해야 하니까 하려 하는 거야? 돌이켜봤을 때 대부분의 내 마음은 '해야 하니까' 였던 것 같다. 의외로 해야 한다는 동기는 나에게 지속적이지 못했던 것 같다. 해야 하는 이유가 쉽게 희석되기 때문이다.상황과 마음의 변화가 있을 수도 있고, 해야 할 이유가 없어..

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

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

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

⌨️ 개요벌써 입사 한 지 두 달이 지났습니다. 비록 작은 업체이지만 다니면서 느낀 점을 회고하고 남은 24년의 목표를 설정해보려 합니다.  1. 업무업무에서 회고 할 부분 크게 3가지로 나눌 수 있을 것 같습니다. 1. 소통2. 한정된 자원에서의 최적화3. 알고있는 지식의 깊이 그리고 이러한 부분들이 저와 같은 신입 혹은 취준생 분들에게도 도움이 될 것이란 생각에 글을 남깁니다.  1.1. 소통 소프트스킬에 포함되는 역량 중 하나인 소통은 생각보다 더욱 중요합니다.일을 진행함에 있어서 서로가 이해한 방식이 다르다면 일을 여러번 하게 될 가능성이 있기 때문입니다. *여기서부터는 저의 주관적 견해입니다. 그렇기에 저는 문서화가 더욱 중요하다고 생각합니다.제가 원하는 기능 구현을 설득시킬 때에도, 혹은 상대..

1. 열거형이 필요한 이유1.1. 타입 안정성 - String 활용 시// DiscountServicepublic class DiscountService { public int discount(String grade, int price) { int discountPercent = 0; switch (grade) { case "BASIC" -> discountPercent = 10; case "GOLD" -> discountPercent = 20; case "DIAMOND" -> discountPercent = 30; default -> System.out.println(grade + ": ..

⌨️ 외부 API 호출에 대한 유연한 테스트 환경 구축하기 어찌어찌 취직은 했다, 작은 SI 기업이지만 첫 발을 디뎠다는 것에 의미를 두고 싶다. 실무에 들어와서 코드를 받으니 이런 말을 많이 들었다. 그 기능은 외부 API라서 테스트가 안 돼요 실제로 일을 하면 생각보다 뜻대로 안 되는 일이 많다. 이런 간단한 불만 사항도 맘대로 수정할 수가 없다. 하물며 해결책을 알아도 말이다. 어찌 됐든 일단 문제없이 돌아가는 서비스 코드를 수정하는 것이고 아무리 SM이더라도 현실적으로는 공수 없이 무료 봉사할 일은 아니라는 의견이 전적이다. (주관은 아니지만) 개인적으로는 지속적인 관리를 위해서 할 수 있는 역량이 있다면 해결하고 가는 것을 선호하긴 한다. 1. 외부 API 호출과의 문제점 우선 실제 개발에서 외..

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

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