공지사항
초심을 잃을 땐 이걸 보도록,,!
옛날 생각이 떠오를 것이다!
개발은 오직 요구사항에 맞춰서만 하도록하자
개발 시 [요구사항 70%] [개발 20%] [테스트 10%] 이라고 한다.
불필요한 코드는 짜지 않으며, 요구사항에 맞게 개발을 하자.
요구사항을 혼자 잘못 이해하고 개발한다면 다시 엎어야 한다. 관련 분들께 요구사항 수집을 하자.
내 노력 선에서 할 수 있는 일이 있다면 끝까지 파고들자
어디선가 에러가 발생했고 인입이 됐다.
[나랑 관련 없다], [모르겠다], [다른 분이 담당하신다] 가 아니라 [특정 서비스에서 이러한 이유로 발생한 것 같다] 와 같이 대응을 하자.
물론 그 때는 귀찮겠지만 이걸 통해 다른 서비스에 대해서 이해하는데 도움이 될 수도 있다.
개발이 일정보다 빨리 끝났다. 어떻게 해야 할까?
내가 잘했거나, 일정이 넉넉해서 일정보다 빠르게 개발을 완료한 것 같다.
[조금 더 개선 해 볼까?] [놀아볼까?] [다른 코드 정리 좀 해볼까?] 가 아니라 개발이 완료된 걸 알린 뒤 이번 버전을 빨리 배포할지, 다른 기능 개발에 들어갈지 관련한 분들과 정하도록 하자.
특정 기능을 개발해야 하는데 잘 모르겠다,,!!
검색도 좋지만 주변에 도움을 요청하도록 하자.
그러나 단순히 "이 기능을 어떻게 개발할까요?" 이런 건 절대 하지말자.
적어도 [이 기능 개발이 처음이에요. 그래서 검색해보니 이런 기술을 이용하면 될 것 같은데 어떻게 생각하세요] 정도는 되어야 한다.
남에게 떠밀지 말자
누군가 나에게 "~~ 이거 가능할까요?" 라고 물어본다.
바로 "가능해요" 가 아니라, 우선 알아보자.
항상 성급히 판단하지 않도록 하자. 내가 성급히 판단했는데 그 분께서 고객사 또는 서비스 사용자에게 이미 전달을 했다.
굉장히 불편한 상황이 온다.
개발하는데 느낌이 쎄하다. 좀 이상한 것 같은데,,,?
개발 도중에 전체적으로 코드를 보는데 뭔가 느낌이 이상하다. 나중에 보면 잘 이해가 가지 않을 것 같거나 구조가 더럽다.
이 경우 그냥 넘어가지 말고 다시 구조를 설계한 뒤 다시 개발하자. 다시 개발이 힘들면 적어도 구조는 변경하도록 하자. (그 말이 그말이지만 ㅋㅋ)
이런 경우가 오지 않도록 처음에 어떻게 개발할지 정리해서 이슈든 노션이든 어딘가에 남겨놓으면서 정리한 뒤 개발을 시작하자. flow chart 도 좋다.
기능 개발을 했다. 로컬 테스트 패스하고 그냥 테스트 요청할까,,?
적어도 내가 개발한 기능이라면 책임감을 가지자. 테스트 도중 오류가 발생하거나 아예 테스트 시작도 전에 뭐가 안된다. 이럴 때는 내 코드가 욕먹는게 아니라 내가 욕먹는 거다.
추가로, QA 하시는 분의 피로도 증가한다.
이러다가 실서버에서 에러나서 핫픽스 나간다.
잠깐의 귀찮음이 추후 평가에서 안 좋게 평가된다.
이 기능이 필요하다네,,! 바로 개발 하면 되나,,,?
바로 개발을 들어가는게 아니라 최소한 개발하기 전에 요구사항 수집이 필요하다. 난 소프트웨어 공학 수업을 받았으니 항상 생각하자.
여기서 요구사항 수집이 잘못 돼 잘못 구현하면 누구의 잘못도 아닌 내 잘못이다 ㅜ
항상 문제정의를 잘 해야 한다.
시간이 좀 빈다. 뭘 할까?
혼자 개발을 하고 있다면 서버 개선을 해보도록 한다. 코드도 좋고,, 인프라도 좋고,,
그렇지 않다면 다른 분들이 풀리퀘 보내지 않았어도 다른 분들 코드를 보거나, 깃허브에서 오픈소스를 보면서 어떻게 구현을 했는지, 어떤 디자인패턴 이용했는지, 어떻게 동작하는지 한 번 보도록 하자.
번아웃 관리는 어떻게 할까
나는 번아웃이 오면 코드를 보면 화가나고 땀이 나고 열이 난다.
컨디션 관리를 잘하자. 주변 사람들과 얘기를 나누면서 좀 분위기 환기를 하거나 다른 분들에게 도움을 요청하자.
나는 다른 분들이 멘탈 케어 해주는게 제일 좋은 것 같다.
프로젝트 구조만큼 네이밍도 중요
프로젝트 구조를 잘 정해놓고 메소드를 잘 분리해 놓아도 네이밍이 길면 가독성이 떨어진다.
최대한은 모르겠고 우선 간결하고 명확하게 하자. 패키지 네임에서 사용하는 단어를 클래스 네임에 중복되지 않도록 할 때도 있으니 참고하자.
길어서 좋은 것은 메소드 네임 정도이며 필드 이름까지는 아니다.
클래스 이름에서 이미 표현했는데 필드명에서까지 표현할 필요는 없다.
코드들은 나중에 정리하자고 하지 말고 당장하자
이렇게 말하는 개발자 치고 나중에 수정하는 사람들 잘 보지 못 했다. (물론 나도 그렇다. 완전 나중에 한다.)
클린 아키텍처에서 말한다.
"코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야!" 라는 흔해 빠진 거짓말에 속는다.
나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다.
왜냐하면 개발자에는 다음 기능이 계속 기다리고 있기 때문이다.
빨리 가는 유일한 방법은 제대로 가는 것이다.