최근에 설계부터 누가 시키지 않은 것들을 스스로 구현해나가며 개발을 하는 포폴을 하다보니
DDD(Domain Driven Development) , TDD(Test Driven Development),BDD(Behaviour-Driven Development) 등의 개발을 자연스럽게 많이 듣게되었다.
장난스럽게 홀맨님(메가테라 대표님)께 그럼 앞에 다 가져다 붙인 개발법은 없냐고 했는데 단호하게 '네 없어요' 라고 하셨다.
최근 코딩의 신 아샬님과 트레이너 님께 피드백을 계속 받으면서 느낀 것은 사실 개발 공부를 막연히 정보를 끌어다 쓰는 느낌보다는
내가 만들고자하는 법을 명확히하고
내가 가진 자원(시간 금전 등)에 기반하여 그것으로 향하는 가장 최적 최선은 무엇인지를 생각하고
중간에 수정도 거치면서 완성본을 만들었을 때에는
왜 이 코드가 이래야만 하는지
를 잘 설명할 수 있어야 하는 식으로 개발을 해야한다고 생각했다.
그러기 위해선
내 코드가 안정성이 있어야하고 ( 테스트 주도 개발의 필요성)
내 코드가 최적이라는 것을 증명하기위해 배경지식을 쌓고 더 나은 방법은 없는지 고민 또는 조사해야하며 ( 다른 방법 시도 및 조사 )
수많은 선택지 중에서 이것이어야만 하는 것을 내 상황과 연관시켜 설명해야만 한다.
즉 위의 방식이 우선이 아니라 로직(내가 이래야만 하는 이유, 근거 논리)이 나오고 그것을 뒷받침 하기 위해서 위의 방식이 따라온다고 생각한다.
그래서 사실... 개발은 내가 세운 논리에 의해서 최적의 해를 찾아가는
논리 주도 개발(Logic Driven Development)이 아닌가 라는 강아지 소리를 적어본다.
아직은 배운 것들을 활용하며 모든 행동, 작은 코드 하나하나에 내 이유를 가지는 레벨이 아니지만 일단 이러한 습관을 가지고 계속 탐구하고 논리를 쌓으려고 노력한다면 이 코드가 왜 이랬어야하는지 의미를 더 잘 찾을 수 있을 것 같다.
액션플랜
다음주 스프린트때에는 어떤 가치를 전달하고 무엇을 하기 위해서 이것을 만들고 코드를 짜는지 이유를 하나라도 적어볼 것.
티아이엘에 녹여볼것
'개발 관련 학습 및 문제해결' 카테고리의 다른 글
서비스의 사용성 생각하며 다시 설계하기[20221114-TIL] (0) | 2022.11.14 |
---|---|
최소기능만 구현하기[20221112-TIL] (0) | 2022.11.12 |
CKeditor 리액트에서 테스트 코드짜기[20221110-TIL] (0) | 2022.11.10 |
@ElementCollection , 모델(엔터티)에 List, 배열 넣는 법[20221109 TIL] (0) | 2022.11.09 |
백엔드 Layered Architecture 구조와 모델 설정시 유의할 점[20221108-TIL] (0) | 2022.11.08 |
댓글