(OLD) Q. 혹시 그러면 코드를 짤 때 설계도를 그리는 방법론에 관해서 작성자님의 생각과 비슷하거나 혹은 작성자님이 추천해주시는 컨텐츠가 있을까요??

주의) (OLD)로 표기된 글은 현재 제 생각과 크게 다르거나 중대한 오류가 있지만
아카이브용으로 유지하는 글입니다

이전 글의 과거 블로그 댓글 중 첫 댓글의 질문에 답하는 내용입니다

A.
저는 혼자서 개발하기 때문에 UML이 나쁘다고 했지만,
협업하는 사람들 다수가 UML을 어느 정도 안다면 꽤나 좋은 의사 소통 수단이 될 거라고 생각합니다.
가볍게 쓰면 괜찮다고 봐요.

저도 어떤 방법이 프로그램의 올바른 설계 표현인지 아직 찾고 있어서 어떤 명확한 답을 드리기는 어렵네요.
이게 문제마다 다르고 참여자마다 달라서 어디에나 적용 가능한 은총알을 찾을 수는 없다고 봐요.

저도 여러모로 시도를 해 보고 있습니다.
프로그램 설계라는 게 다른 공학의 설계도처럼 명확하게 표준이나 올바른 방법이 있지 않아서
아직 다들 본인에게 맞는 걸 찾아야 한다고 생각합니다.

먼저
WHAT: 설계 표현에 무엇이 있어야하는지, 설계 활동에서 무엇을 해야 하는지 설명드리고
HOW: 그래서 설계 표현은 어떻게 표현되어야하는지 이야기해보겠습니다.
그리고 팁 몇가지를 소개드리는 걸로...

WHAT

설계 방법론, 설계로 무엇을 해야하는지는 Rich Hickey의 해먹 주도 개발 Hammock Driven Development에 영향을 많이 받았습니다.
영상|embed
스크립트: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md

그의 말을 요약하자면 프로그래밍은 문제를 푸는 행위이고,
설계 문서는 문제 해결에 도움이 되는 방향으로 작성해야한다는 것입니다.
영상을 보시면 큰 도움이 되리라 생각합니다.

리치 히키의 다른 영상(디자인, 컴포지션, 퍼포먼스)에서도 설계에 대한 이야기가 좀 나옵니다.
영상|embed
스크립트: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md

또한 바텀-업 사고 방식에 대한 생각은 다음 영상에서 영향을 받았습니다.
Bottom Up vs Top Down Desion in Clojure|embed

문제 해결에 대한 책은 아주 유명한 G. Polya의 How to Solve It을 좀 보았습니다.
resource/How to Solve it.jpg
https://en.wikipedia.org/wiki/How_to_Solve_It
http://www.yes24.com/Product/Goods/325507

이 책은 리치 히키의 해먹 주도 개발 영상에서도 소개되는데, 직접 보니까 내용이 좋더라구요.

주의: 이 문단의 내용은 23년 현재의 제가 보기엔 심각한 오류가 있습니다
이 글에 대한 비판과 23년 현재 설계에 대한 제 생각은 [여기]서 확인해 주세요

설계 표현은 여러가지 시도를 해 보았습니다.

처음에는 구글 닥스에 하다가 링크 기능이 부족해서 노션을 썼습니다.
그런데 노션은 문단 접기 기능이 너무 부실해서(로딩이 너무 느립니다) 다른 걸 찾게 되었습니다.

그러다가 생각을 정리하는 방법론으로 Zettelkasten이라는 방법을 알게 되었고,
https://tkim.co/2020/09/15/zettelkasten/

이걸 프로그램 설계 표현에 적용하려 노력해보았습니다.
그래서 Obsidian이란 프로그램을 한동안 썼는데, 그래프 연결 단위가 문서인데다가
블록 인용 기능이 너무 구리고 테이블 기능이 불편해서 결국 RoamResearch로 갈아 탔습니다.

롬리서치는 꽤 괜찮지만 아직도 제가 생각하는 이상적인 설계 표현은 아닙니다.
결국 저는 제가 원하는 설계 표현을 위한 툴을 직접 만들게 될 것 같습니다.
(OLD) 소프트웨어 개발을 위한 지식 기반 시스템 Knowledge Base System for Software Development

다이어그램 툴로는 draw.io를 씁니다. 공짜인데다 그냥 잘 작동하고 iframe을 통한 임베딩도 잘 됩니다!

설계에 대해서 하고픈 말도 많고 아직도 무엇이 올바른 방법인지 계속 찾고 있습니다.
당장 떠오르는 것들만 써볼게요.

프로그래밍은 문제 해결 과정이어야 하며, 프로그램은 문제의 해답입니다.
해답을 만들기 전에 문제를 잘 알아야 하며, 설계는 문제를 풀기 위한 노력의 일환입니다.
문제를 잘 모르고 만든 해답은 문제를 해결하는 게 아니라 또 다른 문제를 만들 수 있습니다.
그렇기에 문제 해결(프로그래밍)에 앞서 문제를 잘 알아야(설계, 다양한 활동) 합니다.

resource/아는_것을_알기_테이블.png

그 글에서 말은 안 했지만 과거 설계 표현에는 이러한 "지식의 상태"에 대한 명시적 표현이 없습니다.
그 또한 큰 문제라고 생각합니다.

설계 표현은 유지보수되어야 하며 반복적으로 작성되어야 합니다.
프로그램 코드는 반드시 설계를 반영하고 설계에 의존해야 합니다.
뭔가 새로 알았거나 요구사항이 변해서 프로그램이 변경될 경우,
반드시 설계를 먼저 수정하고 나서 그에 맞춰 프로그램을 수정해야 합니다.
설계가 프로그램에 의존할 경우 설계는 시간 낭비가 됩니다.

생각의 표현

해답은 하나 이상 내야 합니다. 그리고 문제를 해결하는지 확인해야 합니다.
여러 해답의 장단점 비교, 다양한 사실의 비교, 구체화 등에 테이블이 유용합니다.
사실의 구체화, 문제의 분해를 표현하는데 트리 구조의 다이어그램이 유용합니다.
사실들의 연관관계를 표현하는데는 그래프 구조가 유용합니다.
그 외에도 "가벼운 UML"을 쓰는 것은 도움이 됩니다. 저도 몇개 그려보았습니다.
그리고 그냥 머리속에 뭔가 있다 싶으면 표현에 상관 없이 그림을 그려보면 분명히 도움이 됩니다.
설계 문서로 기록해두지 않고 그냥 그리고 버려도 도움이 됩니다. 그러다 필요하면 저장하구요.

이 블로그에도 여러번 포스팅을 올렸습니다.ㅓ
가능하면 강연 원본을 보시면 좋겠습니다. 정말 많은 도움이 된 영상들입니다.

글이 넘 길어졌네요 ㅋ
도움이 되었으면 합니다.

사실 위 댓글 쓴 사람의 질문에 대답하는 글이다. 이전 글