개발자 모드

최근 감사하게 1차 서류를 합격한 곳이 있어 면접을 보러 갔다. 면접을 준비하는 중에 빼놓을 수 없는 질문이 바로 프로젝트에서 힘들었던 점이나 프로젝트에서 중요한 것이라고 생각한다. 실제 면접 준비를 하면서 이 질문에 대해 생각해보았을 때, 답이 나오기까지 오랜 시간이 걸리지 않았다. 뭔가 지금까지 개발 프로젝트를 포함해서 모든 팀 프로젝트를 진행하며 느낀 점이 있었기 때문이다. 나에게 있어서 프로젝트에서는 소통이 중요하다. 팀원들끼리 서로에 대한 불만이 없어야하고, 이 프로젝트에 대해서 불만이 없어야한다. 과거 이런 경험이 존재했고 이를 통해서 느낀 점이다.  내가 진행했던 프로젝트 중에서 팀원 한명이 자신에게 주어진 할당량을 해오지 않았던 경우가 있었다. 이유가 조금 당황스러웠는데..

최근 좋은 기회로 우테캠 7기 과제테스트를 볼 수 있는 기회가 주어졌다. 1차 코딩테스트와 다르게 과제테스트는 문제에서 요구하는 API 개발을 하는 것으로 정말 실무와 연관된 실력을 엿볼 수 있는 기회라고 생각한다. 그동안은 '작동하기만 하면 됐지' 라는 마인드가 조금 컸던 것 같다. 프로젝트에서도 어차피 내가 맡은 부분은 내가 유지보수하는 경우가 대다수였으니까.. 이쁘고 깔끔하게 짜려고 생각하지는 않았던 것 같다.  하지만 이번 과제테스트를 준비하면서 '객체지향이란 무엇인가'와 같은 조금 체계적인 설계에 대한 고민이 많아진 것 같다. '어떻게 해야 메서드가 하나의 기능을 하지..?', '어떻게 해야 확장성이 좋아질까'처럼.. 그러다보니 자연스레 다른 사람들의 코드를 보았다. 어떤게 클린코드..

과거 내가 add했던 기록과 같은 모든 것을 지우고 다시 레포에 올리는 방법.  rm -rf .gitgit init 이 두개만 해도 충분히 초기화가 되지만.. git 폴더를 삭제했다면 원격지 주소와 유저 정보를 다시 입력해야한다. git remote add origin [repository 주소]git config --global user.email [사용자 email]git config --global user.name [사용자 name]

내가 좋아하는 언어는 단연 자바다. 백엔드 개발자에 관심을 갖기 전부터도 그랬고 현재도 마찬가지다.(사실 지금은 이제 할 줄 아는 언어가 자바밖에 없는 것 같기도..) 그 시절(개발자에 대한 꿈이 없을 때)에는 자바의 캡슐화, 상속, 추상화, 다형성(a.k.a 캡상추다) 이 어렵기만 했다. 그런데도 왜 자바를 좋아했냐고?? 어려움 속에서의 놀라움이 있었기 때문이다. 가장 먼저 파이썬으로 언어를 시작했던 나는 너무 쉬웠다. 지금보면 내가 좁은 시야로 보았기에 쉬웠지만.. 자바에 비해 쉬운건 사실이다. 그렇게 프로그래밍 언어를 배우고 컴퓨터공학과에 들어왔을 때 자바를 입문했었다. 파이썬보다 코드짜기가 어려웠으며.. List를 배우기 전까지 배열로 사용해야해서 참 애를 먹었다. 자바로 알고리즘을 짜다보면 파이..

SW 아카데미에서 뵈었던 김송아 강사님의 언그래머 슬랙에 어쩌다보니 참여하게 되었다. 매주 아티클을 올려주시는 것만으로도 정말 감사하게 트렌드를 따라가고 있었는데.. 이번에 글쓰기 클럽을 모집한다고 하였는데, 마침 졸업하고 나니 글도 쓰기 귀찮아지고.. 그래서 다시 마음가짐한다고 생각하고 신청했다. 그래서 이번 주제는.. ‘나는 왜 개발자가 되고싶은가?’이다. 우선 나는 개발을 접한지 얼마 되지 않았다. 학부에서 배우는 것들인 알고리즘, 시스템 프로그래밍들은 ‘개발’에 초점이 맞춰져있다기 보다는 근본적인 컴퓨터에 대한 지식인 CS 지식의 학습에 초점이 있는 듯 하다. 그래서 실제 개발이라는 분야를 늦게 접했다. 학부 수업과 학점을 꽤나 중요하게 생각했던 나는 개발은 졸업 프로젝트 때 할거니까~ 라는 마음..

이펙티브 자바 Item 58에서는 for-each를 사용을 추천한다. 하지만 for-each를 사용할 수 없는 부분을 명시하고 있었다. for-each에서는 컬렉션의 원소를 수정할 수 없다고 한다. 이 또한 코딩테스트에서 나도 경험했던 부분이다. 그런데 스터디원이 자세한 예시를 요구하여, 코드를 작성했는데.. 어머나..?? 갑자기 삭제가 되는 것이다. 코드는 아래와 같다. 그런데 놀랍게도 예상하는 결과가 나왔다. 이펙티브 자바의 말에 의하면, 그리고 여러 사람들의 글에 의하면 이것은 불가능했어야했다. 처음에는 래퍼 클래스와 기본타입은 가능한가..?? 라는 생각도 했었지만, 너무 자기합리화로 끝내는 것 같아서 조금 더 정확하게 파고들고 싶었다.(개발자의 본성이랄까 ㅋㅅㅋ) 우선은 remove의 원리를 알고..

프로젝트를 생성하고 엔티티의 골격만 짜보았다. 자바는 트렌드를 따라가기 위해 더이상 11을 사용하지 않고 17을 사용해보기로 했다. 스프링부트도 3.2버전으로 생성했다. 프론트가 없는 관계로 템플릿 엔진을 이용해야한다. 우리는 머스테치와 타임리프를 두고 고민하였다. 머스테치는 쉬운 문법이 강점이라고 하였지만, 현재 김영한 선생님의 강의를 듣고 있는데 자꾸 타임리프 칭찬을 하신다.. 아무리 봐도 문법이 쉬워보이지는 않은데 쉽다고 하신다... 우리도 타임리프로 하기로 했다. (줏대없어 ㅋㅅㅋ) DB는 국룰 mysql로 가지 않을까 싶긴하다. 개발용으로는 단연 h2. 앞선 글에서 변경된 erd를 소개했다. 정말 좋은 것 같아서 그 erd를 반영하여 골격을 세팅했다. 아직, 임베디드 타입의 적당한 패키지를 정하..

ERD가 변경되었다. 내가 없는 사이 팀원이 ERD를 다시 구상하였다고한다. 우선, 우리가 초기 구성한 ERD를 살펴보자. 우리가 이 ERD를 구상하면서 가장 고민이 되었던 부분이 바로 old_XX 엔티티이다. old_XX 엔티티를 만든 이유는 사용자에게 과거 사진 교환 목록을 제공하기 위함이다. sending과 matching에 과거 사진 교환이 성공한 이력을 저장하고자 하였지만 테이블이 누적되는 것도, status를 갖고 있어야하는 것도 조금 걸렸다. 그래서 완료된 데이터를 저장하는 테이블과 진행 중인 테이블을 분리하였는데.. 위와 같은 erd에서는 user_id가 주어졌을 때, 사진 교환 이력을 불러오는데 다음과 같은 복잡한 과정을 거친다. user_id 기반으로 old_sending_id를 찾는다..

현재까지 고안해낸 ERD이다. 내가 작성하는 방식과는 다르지만, 이것도 꽤나 잘 눈에 들어오는 것 같아서 좋은 것 같다. 우선 User가 존재한다. 회원가입을 할 예정이며 소셜 로그인같은 기능보다는 간단한 아이디, 패스워드로 시작해보려고 한다. User는 Sending이라는 행위를 한다. 사진을 매칭할 대상을 찾는 과정인 것이다. 서버 내부에서 real time algorithm으로 인해 서로 사진을 주고받은 User 두 명이 검색되었다면, Sending 2개의 데이터가 묶여 Matching에 등록된다. Matching에 등록된 데이터들은 서로 사진을 교환하는 과정을 거친다. 이러한 일련의 과정(사진 교환)을 거치게 되면 matching과 sending에서 앞선 처리된 상황의 데이터가 삭제되고 old_X..

Random Photo Matcher라는 이름의 RPM. 과거 팀원의 경험을 떠올려 기억에 남았던 어플의 핵심 기능을 가져와서 우리만의 서비스로 만들어 보려고 한다. Rando. 랜덤으로 사진을 교환하는 서비스이다. 현재는 서비스를 중단하였다고 한다. 우리는 이러한 핵심 기능을 구현하고 그로부터 필요한 부가기능을 넣어서 4월 한달동안 구상해보려고 한다. 화이팅..!! 새로운 마음으로.