기능적으로 무엇을 만들지 정했다면, 이제 코드를 작성해야 한다. 디자인패턴에 능한 사람들은 동일한 기능을 구현하더라도 어떤 것이 더 장기적으로 좋을지 빠르게 판단할 수 있다. 잘 다듬어진 명세를 가진 작은 함수나 클래스의 정의(ref2,ref3)에, 적절한 디자인 패턴을 적용한 결과물(ref1)을 언어모델에 요청하면 만족스러운 결과를 얻을 가능성이 매우 높다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
- (인용) 스타크래프트 프로게이머가 빌드를 익히는 것과 비슷합니다. 빌드만 잘따라하면 평범한 선수 이상 못될 수 있지만 빌드도 모르면 아예 프로게이머가 되기 어렵습니다. 디자인 패턴을 공부하지 말라는 건 프로게이머 지망생에게 빌드만 외우면 최고가 못되니 처음부터 빌드도 보지 말고 다른 선수 리플레이도 참고하지 말고 혼자 게임만 하라는 거나 똑같습니다. 창의적인 전략도 기본을 자신의 것으로 소화한 다음에 가능한 것입니다. 그리고 디자인 패턴은 보통 리팩터링과 같이 생각해야 합니다. 디자인 패턴은 반복되는 문제에 대한 일반적 해법을 정리한 것이기 때문에 애초에 무엇이 문제인지, 또 그걸 다른 방법으로 풀면 어떤 문제가 있는지에 대한 감이 없으면 유용성이 반감될 수 있습니다. 디자인 패턴을 다 외울 필요는 없습니다만 최소한 그런 부류의 문제를 접하면 비슷한 수준의 접근을 제시할 수 있는 능력이 있어야 하고, 다른 사람이 짠 코드에서 그런 패턴을 발견하면 코드의 의도를 알 수 있는 수준은 되어야 합니다. 그래서 리팩터링 수준의 감이 없는 개발자에게 무턱대고 디자인 패턴 암기를 강요하면 안되겠지만, 그렇다고 디자인 패턴 같은 거 다 필요없으니 코딩만 하다보면 다 알게 된다는 식의 뜬구름 잡는 조언은 더 위험한 이야기입니다.
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
- a0_4.1_1. [entry] title: 생성형 AI와 포멀하고 딱딱한 소프트웨어공학의 조합
- 과거에도 언어모델과 전통적 소프트웨어공학 지식이 어떻게 시너지를 낼 수 있을지를 고민한 적이 있었다.
- ‣
- 이 메모는 군대에서 시간을 잘 소비할 방법을 고민하다가, ‘점진적으로 커질 수 있는 소프트웨어를 정말 빠르게 만들 수 있는 능력’이 나의 고슴도치 컨셉트에 얼라인되는 능력이겠다는 생각으로부터 시작됐다.
- 3_3_8. title: 용어가 잘 정의되었음은 언어의 사회성을 만족했음을 의미한다. 프롬프트 엔지니어링의 본질은 잘 정의된 용어들로 원하는 결과물을 정확히 정의하는 것이다.
- 디자인 패턴에 대한 용어, 유즈케이스는 이미 잘 정리되어 있다.
- [a0_4.1_1.2. title: 내가 소프트웨어를 만드는 속도가 느린 이유는 아직 무엇을 만들지(문제와 핵심 로직에 대한 인식), 가진 도구들을 가지고 할 수 있는 일은 무엇인지(사용하는 도구의 핵심 코드 조각) 명확하지 않은 상태에서 코드를 작성하기 때문이다. 이런 상황에서, 코드가 점진적으로 확장할 것을 지나치게 염두에 두면 과한 추상화가 된다. 무엇을 만들지와 무엇이 가능한지가 명확하지 않으면 패턴이나 클린 코드같은 단어를 머리에서 지워라.](https://janghoo.notion.site/a0_4-1_1-2-title-1b0547ddc2ba80a9bf02f036c152f5e6)
- 이 메모에서 말하는 디자인 패턴에 대한 생각보다 앞의 메모가 훨씬 중요하지 않을까 느꼈음을 잊지 말자.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
None