Reimaginer

소프트웨어 개발은 항상 새로운 것을 배우고 문제를 해결하기 위해 끊임없이 노력하는 분야입니다. 이러한 작업에서 적절한 질문을 하고 이를 해결하는 것은 매우 중요합니다. 그래서 나는 "좋은 소프트웨어 개발자는 좋은 질문을 하는 사람이다"라는 주장에 동의합니다. 우선, 좋은 질문을 하는 것은 자신이 직면한 문제나 과제를 이해하고, 문제의 본질을 파악하는 데 매우 중요합니다. 좋은 소프트웨어 개발자는 문제를 분석하고 해결책을 찾기 위해 깊이 있는 질문을 할 수 있어야 합니다. 그들은 단순한 예/아니오 질문이 아니라, 왜 그렇게 생각하느냐는 것을 물어봄으로써 문제의 본질을 파악하려고 노력합니다. 이를 통해 좋은 개발자는 복잡한 문제를 해결할 수 있습니다. 또한, 좋은 질문을 하는 것은 다른 사람들의 경험과 지식..

최근 소프트웨어를 만드는 개발자의 연봉 상승이 언론 기사를 통해서 주목받고 있다. 주변의 개발자 지인들도 그런 흐름에 마음이 싱숭생숭하여 이직을 준비한다는 이야기를 듣는다. 그리고 몇번의 이직을 경험해본 나에게 이렇게 묻는 경우가 종종 있다. "뭘 공부해야 할까?" 나는 이 질문 자체가 잘못되었다고 생각한다. 공부해서 이직을 하는 것이 아니라고 생각하기 때문이다. 그 이유를 설명하기 위해서는 내가 생각하는 이직의 정의를 먼저 이야기할 필요가 있다. 이직이란? 이직은 원래 다니고 있는 직장에서 비슷한 업무를 하고 있는 다른 직장으로 옮기는 것을 의미한다. 만약 업무가 바뀐다면 나는 이것을 이직이라기 보다는 전직이라고 말한다. 그리고 기존의 업무 경험이 없는 상태에서 직업을 얻는 것은 신입으로 구직을 했다고..

최근의 나의 주요 작업은 하나의 도메인 단위로 서비스를 재구성하는 것이다. 예를 들어, 포인트 관련된 기능이 하나의 DB를 가지고 여러 서버 애플리케이션에서 구현되어 있다면, 포인트 관련된 서비스를 만들고 각 서버 앱들이 포인트 서비스 API를 호출하도록 변경한다. 그리고 포인트 서비스용 DB를 따로 분리한다. 포인트 서비스는 API 수준의 기능을 노출하고 DB는 숨기는 것이다. 작업 방식은 보통 기능을 추출하고 기능단위로 API를 구현하고, 기존 서버 앱들이 해당 API를 호출하도록 작업한다. 굉장히 위험한 작업이기 때문에 기존 서버앱의 수정을 최소화 하고 롤백가능한 구조로 작업을 진행한다. 오늘 적어볼 나의 시행착오는 도메인 모델의 이름에 대한 것이다. 보통 기존 서비스들은 DB의 테이블과 거의 비슷..

요즘도 꾸준히 좋은 개발자란 무엇인지 고민하고 있다. 최근에 좋은 개발자의 덕목 세가지를 다시 한번 생각해보고 정리해 보았다. 과거에 정리했던것과 내용이 많이 달라졌다. 참고: 좋은 개발자의 덕목 달라진 내 생각을 여기에 정리해두었다. 앞으로는 어떻게 달라질지 또 궁금하다. 협력 능력 대다수의 문제는 함께 해결해야 합니다. 그래서 좋은 개발자는 협력에 대해서 고민하고 개선하려고 노력해야합니다. 협력 능력을 두가지로 분류해보겠습니다. 첫번째는 소통능력입니다. 자신의 문제를 효과적으로 전달할 줄 알아야합니다. 그리고 친화력, 공감 능력, 갈등 조정 능력 같은 대인관계 기술들도 꾸준히 훈련하도록 노력해야합니다. 개인적으로 강조하고 싶은 것은 잘 듣고 설득 당하는 것입니다. 이는 문제를 해결함에 있어서 타인의 ..

회사에서 마틴 파울러의 리팩토링 책으로 스터디를 시작했다. 첫번째 맛보기 예제를 내가 맡아서 발표를 하게 되었다. 발표를 준비하고 발표를 하면서 역시 공부가 많이 되었다. 이번 포스팅에서는 리팩토링 책 1장에 대한 나의 생각을 적어보려 한다. 발표 자료 : https://github.com/voyagerwoo/refactoring-first-example/wiki 예제 소개 이 예제는 비디오 대여점에서 사용할 만한 간단한 프로그램이다. 고객별 고객이 빌린 영화와 영화의 대여료, 적립 포인트를 출력해주는 기능을 가지고 있다. 영화의 타입에 따라서 대여료와 적립포인트가 다르게 계산된다. 현재 영화의 타입은 최신작, 어린이용, 일반 이렇게 세가지로 분류되어 있다. Customer, Rental, Movie 세..

지난 10월 16일 오마이랩의 CTO 이규원님이 진행한는 TDD 참관에 참여했다. 내가 이 참관에서 가장 궁금했던 점은 실제 TDD 루틴을 확인하는 것이고 어떤 프로세스와 문화 안에서 작업을 하는가였다. 그리고 어디까지 TDD로 커버해야할까에 대한 힌트를 얻기를 기대했다. 만남이 끝나고 돌아오면서 생각해보니 많은 도움이 된거 같은 참관이었다. 그때 이야기 했던 내용들을 정리해볼까 한다. RED GREEN REFACTOR 처음에 만나서 이야기를 시작하며 규원님이 TDD는 RED, GREEN, REFACTOR를 반복하는 것이라고 말씀을 해주셨다. 그러면서 RED, GREEN, REFACTOR가 무엇인지 여쭤보셨다. 그래서 TDD by Example에서 읽어서 알고 있던 이야기를 해보았다. "우선 개발할 내용..

참고: 좋은 개발자의 덕목 V2 우아한 형제들 입사 지원 폼의 질문들은 개발자라는 직업에 대해서 깊숙하게 질문한다. 지원자가 개발자라는 직업에 대해서 어떻게 생각하는지 어떤 성향의 개발자인지 확인하려는 듯 하다. 질문들 중에서 이런게 있었다. 좋은 개발자가 되기 위해 갖추어야 한다고 생각하는 덕목 셋을 고르고 그 이유를 말해주세요. 이 질문에 대해서 굉장히 고민을 많이 하여 답변을 완성했다. 내 생각을 공유하고 피드백을 받고 싶어서 그 답변을 여기에 올려두려고 한다. 저는 신체의 물리적인 능력이 아닌 사고의 능력이라 할지라도 근육을 키우듯이 꾸준히 훈련해야한다고 생각합니다. 좋은 개발자는 어떤 근육이 발달해 있을까 고민해보았습니다. 대화 근육 이 근육은 팀웤과 관련된 근육입니다. 우리는 다른 개발자, 혹..

컴퓨터관련 학과를 나와서 프로그래밍 과제를 풀고 개발자로 일도 하고 있는 나는 코드를 자연스럽게 읽게 되었던것 같다. 아니면 처음 코드를 보았을 때의 어려움을 잊었거나. 오랫동안 비전공에 프로그래밍 경험이 전무했던 신입 개발자를 가깝게 멘토링하면서 그것이 당연햐지 않음을 알게 되었다. 내가 깨달았던 많은 깨달음들을 전수했지만 그 친구는 더 어려워했다. 내가 했던 조언은 다음과 같다. 우선 막 따라 쳐봐라. 그러면 언젠가 이해가 간다. 코드는 한줄 한줄 실행된다. 한줄 한줄 다 이해할줄 알아야 한다. 코드는 규칙이다. 외우고 지켜야한다. 그 친구는 내 조언을 듣고 이렇게 생각했다. '막 따라치라며. 근데 어떻게 한줄 한줄 다 이해할줄 알아야함? 그리고 그냥 외우면 한줄 한줄 어떻게 이해함?' 그런 이야기를..