⚠️ 이 글은 단지 재미용ㅇ미ㅕ 실천한다면 사회생활에 큰 문제를 일으킬 수 있으며 작성자는 어떠한 책임을 지않습니다.

JDD 를 실천하기 위해서는 쉬지 않고 험난한 길이지만 꾸준하게 노력해야 한다. 중요한 것은 관련된 힙한 용어를 들먹이면서 실제 문제에 대한 답변을 회피하는 것이다. 꾸준한 연습이 필요하다. - 주인백

자세히보기 https://github.com/Lee-WonJun/JDD-Description

JDD 는 코드 작성보다 변명거리를 미리 생각하여 수많은 버그를 양성할 수 있는 개발 방법론이다.

JDD 는 아래와 같은 중요 가치를 따른다.

우리는

- 남이 쓰는 기술보다는 내 것을

- Clean 한 코드보다는 Tricky 한 것을

- 버그 Fix 보다는 변명을

- 귀찮음보다는 편함을

가치있게 여긴다. 이 말은, 왼쪽에 있는 것들은 귀찮고 오른쪽에 있는 것들은 편하기 때문에 더 높은 가치를 둔다는 것이다.

JDD 를 실천하기 위해서는 쉬지 않고 험난한 길이지만 꾸준하게 노력해야 한다.
중요한 것은 관련된 힙한 용어를 들먹이면서 실제 문제에 대한 답변을 회피하는 것이다. 꾸준한 연습이 필요하다.

JDD 를 위한 지침서

JDD 를 위한 소양

JDD 의 기초가 되는 소양을 항상 명심하자.

참된 리더

잠든.. 아니 참된 리더는 부하직원을 괴롭히지 않는다.

- 누군가 PR 을 했다는 사실 자체가 보기 좋은 일이다. LGTM(Looks Good To Me).

- 누군가 PR 을 날리면 자동으로 LGTM 를 날리는 CI/CD 를 활용해라

진짜로 만들어뒀다. 😂

방어적 프로그래밍

방어적 프로그래밍은 개발자의 기본 소양이다.

- 방어적 프로그래밍을 해라 코드로 방어하지 말고 너에게 들어오는 일감을 방어해라

- 작업량이 많은가? 그냥 특정 테스트 케이스에서만 돌아가게 짜고 나머지는 "고도화" 작업에서 한다고 해라. "고도화" 작업 전에 이직하자.

성과 위주 회피

일 잘하는 척 편안한 생활을 위해 성과 위주로 행동해야 한다.

멀티 쓰레드

동시성은 어렵고, 성과가 눈에 띄지 않는다.

- 멀티 쓰레드 환경에서 가변 변수 사용으로 인한 오류는 가끔 발생한다.
가끔 발생한다는 거에 비하여 사용은 너무 편하다. 누가 뭐라고 하면 그럴 일 없다고 하면 그만이다.

- 어쩔 수 없이 멀티 쓰레드 업무가 들어오면 언어를 욕하면서 이 작업이 왜 어려운지 설명해라,
아 이 언어는 Actor 모델이 빈약해서요, CSP(Communicating Sequential Processes) 구현체가 없어서요, STM(Software Transactional Memory) 이 지원 안 돼서요.
욕을 할수록 작업 기한이 늘어난다.

- 비동기 흐름 내에서 동기함수를 몰래 써도 된다. 나중에 병목 찾는 작업 + 비동기로 개선하는 추가 작업 기한까지 함께 받을 수 있다.

문서화

우리의 본분을 잊지 말자.

- 주석은 절대 작성하지 않는다. 누가 뭐라고 하면 클린코드를 들먹이자. 물론 그렇다고 해서 코드가 리더블하지는 않다.

- 우리는 개발자다, 어떠한 이유에서든지 문서 작성은 금물. 누가 뭐라고 하면 "코드가 곧 문서".

- 히스토리는 필요 없다. 과거에 연연하지 말자

- 인수인계 문서는 필요 없다. 누가 뭐라고 하면 내 코드는 보면 바로 이해가 간다고 하자. 미련 없이 떠나자.

협업

단어부터 현기증이 온다.

- 여럿이서 동시에 같은 코드를 작성해야 한다면 어떻게든 나눠서 따로 작업한 뒤 합치자고 하자. 상대방도 하나를 두고 부대끼며 작업할 생각 따위 없다.

- 브랜치 머지(Merge) 중 충돌 날 것 같은 시점에 휴가를 쓰는 건 필수다.

- 페어코딩은 의외로 괜찮다. 내가 코드를 짤 때는 머리를 좀 비워도 되고, 다른 사람이 코드를 짤 때는 오타 정도만 잡아주면 충분하다. 최대 장점은 작성된 코드에 대한 책임이 줄어든다는 점이다.

- 무슨 작업인지 별로 알리고 싶지 않다면 커밋 메시지는 `chore: trivial`이라고 하자. 변태가 아니고서야 이런 커밋을 읽어보는 사람은 없다.

- PR 을 머지(Merge)할 때에는 Squash merge 를 최대한 활용해서 중간중간에 들어간 뻘짓들을 숨긴다. 누가 뭐라고 하면 '커밋 로그를 간략하게 유지하기 위해서'라고 하자.

- 커밋은 나눌 때는 작업이나 기능 단위가 아니라 내가 한 번에 고친 만큼을 기준으로 한다. 어차피 머지 되면 다 Squash 돼서 잘 안 보인다.

- PR Description 은 작업 관리 툴의 task 링크만 티켓으로 넣어 준다. 물론 링크를 타고 가도 설명 같은건 없다.

- 협업에는 커뮤니케이션 스킬이 필수다. 풍둔 주둥아리의 술로 상대방을 현혹시켜 PR 에 내 게으름이 토론 내역으로 남겨지지 않도록 대화를 유도한다.

- 허락보단 용서가 쉽다. 어떻게든 빠르게 머지(Merge) 해야한다.

- 동료의 코드에서 오류나 오타, 간단한 실수(중복된 변수, 팀 코드 규칙, Lint와 같은)를 찾더라도 공유하지 마라. 동료가 당신이 조화롭게 어울린다는 것을 은은하게 눈치채게 하라. 동료도 내 실수를 눈감아 줄 것이다.

JDD 는 어떠한 제약조건도 없습니다.
단 책임도 지지 않습니다.

마치며

오랜만에 재밋는 글을 찾아서 다른분들에게 알리고자 글을 작성합니다.
글의 일부를 발췌해 온것이며 자세한사항은 글위쪽에있는 깃허브 링크를 방문해주세요 누구에게나 PR이 열려있다고합니다. 😂