일상

스타트업을 선택한 이유 일단 스타트업을 다닌 이유는 SI에서 클라이언트 개발자에서 백엔드로 이직을 하면서 네카라쿠배라는 대기업에서 일하는 경험을 하고 싶었지만 지금 당장 현실적으로는 다른 지원자에 비해 경쟁력을 가진 경험도 없었고 높은 수준의 진입장벽도 존재하기 때문에 당장 준비하기보다는 차근차근 스탭을 거쳐서 올라가겠다는 생각과 드라마 실리콘벨리를 보고 내가 몸을 담고 있는 이 스타트업이 그런 기업이 될 수 있을 것이라는 꿈을 품고 스타트업에서의 여정을 시작하게 되었다. 스타트업의 현실 내가 생각했었던 스타트업의 개발자는 위그림처럼 적어도 3~5명의 엔지니에가 뭉쳐서 밤새 같이 고민하고 개발하는 미래를 생각하고 시작했지만 현실은 단 두명의 개발자분들이 백엔드와 Ios를 담당하여 개발을 진행하고 있었다...

지금은 기술부채에 대해 관대적으로 대하고 프로덕트가 중심을 생각하고 개발하고 있지만 회사 입사 초기에는 많은 개발자들이 추천하던 클린코드, 소프트웨어 장인 정신 등을 읽으면서 클린 코드, 클린 아키텍처, TDD 등에 빠져살면서 이상주의 개발자처럼 개발했었다. 이런 이론만 접하고 공부하다보니 회사에 상황을 충분히 인지하지 못하고 프로덕트를 만들어서 가치를 창출하는 것보다 더 품질 높은 소프트웨어를 만들기위해 집착했었다. 그렇게 회사의 상황을 고려하지 못하고 회사에 기술부채가 너무 많아서 당장 기능 개발이 어렵다고 이야기하고 부채와 기능개발을 같이 하도록 개발자 인력 충원을 요청하고 이상적인 이론에 대해 공부 하다가 어느날 투자가 무산되어 회사가 망하게되면서 회사에 나오게 되었다. 해당 스타트업에 있었던 것..

우아콘에서 글쓰기 세미나를 들으면서 정기적으로 개발자들이 모여서 글쓰기 모임이 운영하고 있다는 것은 알고 있었지만 회사일과 스터디에 치여서 잊고 살다가 커리어리에 있는 어떤 개발자분의 2022년 회고록을 보고 글또를 찾게 되었다. 글또를 참여하기전에도 블로그를 쓰고 있기는 했지만 스터디 때에 제외하고는 내가 공부한 것이나 내가 쓴 글에 대해 되돌아보는 시간이 없었고 내가 쓴 글에 대해 한번 써놓고 방치하는 일이 잦았지면서 주기적으로 쓰던 블로그 글도 점점 드물게 쓰기 시작했다. 이로인한 가장 큰 문제는 글로 남기면서 생각을 정리하지 않고 책이나 래퍼런스만 읽어보고 넘기니 단편적인 기억으로 밖에 남지 않았던게 가장 컸다. 그리고 글을 써야하는 상황은 많아지고 있는데 내가 쓴 글은 제대로 정리되지 않았었고 ..

처음에 학생 때에는 뭔가 목표와 꿈이 있었다기 보다는 흘러가는대로 삶을 살아왔던 것 같다. 그래도 디자인에 관심이 있어서 관련된 과에 들어가서 포토샵, 일러스트, 영상편집 등을 배웠었지만 아쉽게도 디자인이라는 길은 나에게 맞지 않았었고 어영부영 세월을 보내다가 입대를 하고 복학하게 되었다. 그러다가 우연히 화이트 해커 양성 인턴쉽에 들어가게 되었고 거기에서 멘토분이 들려주던 화이트 해커가 되기까지의 이야기와 IT 분야에서 종사하고 있는 여러 사람들이 더 높은 수준의 발전을 위해 거리낌없이 지식을 공유하고 오픈소스를 통해 기여한다는 문화를 듣고 보면서 홀린 것 처럼 관심을 가지게 되었고 그렇게 개발자의 길이 시작되었다. 2019년 ~ 2021년의 정리 2019년 개발이라는 것을 무작정 더 공부해보기 위해 ..

결합도가 낮은 설계는 서로 의존하는 정도가 낮으면 결합도가 낮다고 한다. 하지만 이러한 추상적인 의미는 실무하는데 있어서 크게 메리트가 없는 내용이다. 내가 결합도가 높은 코드를 짰을 때에도 이러한 조건에 충족이 되기 때문이다. 아래의 예제를 보면 public class RevervationServiceImpl implements RevervationService{ public Receipt reservation(List tickets) { for (Ticket ticket : tickets) { if(ticket.getMovieType == MovieType.WEEKEND) { } else if(movieType == MovieType.WEEKDAY) { ``` } else { ``` } } } } 이..

객체지향 설계를 접하다보면 흔히들 하는 이야기가 결합도가 낮고 응집성이 높고 캡슐화가 잘되어 있어야 한다고 한다 하지만 이런 전통적인 관점에서 응집도, 결합도, 캡슐화와 실무적인 응집도, 결합도, 캡슐화는 매우 다르다고 한다. 전통적인 관점 응집도 모듈 내부 요소들이 서로 관련이 있는 정도 모듈 내부의 기능적인 집중도 응집도가 높거나 낮다로 표현하며 좋은 설계는 응집도가 높다 결합도 한 모듈이 다른 모듈에 의존하는 정도 한 모듈이 다른 모듈에 대해 알고 있는 지식의 양 결합도가 강하다/느슨하다고 표현하며 좋은 설계는 결합도가 느슨하다. 캡슐화 상태와 행동을 함께 모음 데이터를 감추고 공용 메서드를 외부의 공개 이러한 전통적인 관점에서 응집도, 결합도, 캡슐화는 설계하는데 있어서 도움이 되긴 어렵다. 코드..