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