%EC%84%A4%EA%B3%84

도전적인 제목이다. 예전에는 무려 어떤 컨퍼런스 자리에서 설계 담론을 정리해보겠다고 선언만 하고, 용두사미로 내용없는 발표를 한 일도 있었다. 흑역사다. 그럼에도 불구하고 또 무모한 도전을 해볼 생각이다. 난 직업 작가가 아니라 글 내용으로 욕을 좀 먹어도 괜찮다. 다만, 내가 직업으로 하는 일에서 축적한 내용이 매우 빈약하다는 사실이 무모한 도전을 하게 만든다고 해두자. 대충 그정도로 '구상' 따위를 왜 발표하는지 명확히 한다.  그렇지만, 실제로 이 글을 타이핑 하고 있는 직접적인 동기는 따로 있다. 아침에 페이스북에서 만난 질문과 답변하는 과정에서 내가 느낀 찜찜함...

커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글) 1편. 커머스 혹은 유통 도메인 설계에 대한 연작 오랫동안 추적한 일이다. 생각으로는 금방 정리할 수 있는 내용이지만, 실제로 구현할 수 있도록 정의하는 일은 그와는 다른 일 [4] 이다. 여튼 또 기회가 왔다. 시작은 한 개발자가 엑셀 업로드 기능을 만들었는데, 동료 기획자가 마음에 들지 않는다고 했다. 아이디어를 구하기에 당장 목표로 삼을만한 범위를 그림으로 그렸다. [caption id="attachment_20064" align="alignright" width="600"]...

1부에서는 기술블로그 구독서비스(이하 서비스)를 왜 만들게 되었고 어떤구조로 만들가에 대해 이야기를 해보았다면, 이번 포스팅에서는 만들면서 만나게 된 각종 트러블슈팅 종합세트(?) 를 하나씩 풀어보고자 한다.  물론 개발을 하면서 아무 문제 없이 잘 되면 당연히 좋겠으나 잘되도 이상한게 개발이라는 세계가 아니던가. 잘 안되면 문제, 잘 되도 문제 ㅠㅠ, 출처 : https://www.clien.net/service/board/park/9111495 1부 : 왜 만들게 되었는가 그리고 어떤 구조로 만들었는가...

설계에 최소한의 노력만 하라 고 말하면서 UML 모델을 남용할 수는 없다. 그렇지만, 가끔 그리고 싶은 충동을 느낄 때가 있다. 대부분은 대화과정에서 즉흥적으로 매직으로 그린 경험이다. 대화할 때 흔히 쓰는 UML 도해 popit에 올려둔 글만 보아도 대화하며 설명을 위해 그린 흔적이 있다. 대략 쓰임새를 요약해보면 다음과 같다. 어떤 개념(예: 판매처가 다양할 때)을 분류하고 싶은 경우 그리는 클래스도 프로그램 호출순서를 확인 할 때 (동료 코드를 보고, 호출 순서에 대해 묻거나 제안할 때) 순차도 작성...

이 글은 우연히 발견한 오래된 [1] 글, Is Design Dead? 가 반가워서 뭔가 쓰려고 했는데, 앞서 썼던 두 개의 글과 라임을 맞추느라 제목을 이따위(?)로 붙였음을 이실직고합니다. 그래서 설계는 죽었는가? 마틴 파울러의 긴 글 을 만났을 때, 마치 어릴 적 주고받은 편지를 우연히 발견하고 반가워하는 마음이 들었다. 그의 글 마무리가 그래서 설계는 죽었는가?(So is Design Dead?)이다. 잠시 그의 글을 보자. [2] 그래서, 디자인은 죽었는가? - So is Design Dead? 전혀 그렇지 않다. 다만 디자인의 성향이 바뀐것이다. XP 디자인은 다음과 같은 기술을 요구한다....

요즘 글쓰는 것이 즐겁다. 이런 시절이 길지 않기 때문에 최대한 뽑아야(?) 할 것 같다. 구인공고 올리려고 백년만에 들어간 트위터에서 마틴 파울러의 excellent post란 표현을 보고 링크를 눌렀는데,  글쓰려는 욕구를 자극하는 글감이 등장했다. [caption id="attachment_13775" align="aligncenter" width="600"] 마틴 파울러의 한 트윗[/caption] 마틴 파울러가 칭찬한 글 에서 글쓰기를 자극한 구절은 바로 아래 단락 제목이다. engineering decision-making is a socially constructed activity 내 번역은 이렇다....

지난 주 기고 에 이어서 모듈 구현을 위한 (중국) 동료 개발자와의 코드 리뷰 이야기를 계속한다. M은 자신이 만드는 모듈인 Tenancy와 다른 두명(X와 C)이 개발하는 모듈인 Shipping 사이의 연관성을 충분히 이해했다. 그래서 다른 둘에게 자신이 이해한 것을 설명해서 코드를 수정하게 하라고 요청했다. 다음 날, 코드 수정이 완료되어 리뷰 요청을 받았다. 마침, M이 UML 작성에 재미를 붙인 상황이라 내가 그려준 아래 그림을 참고로 해서 기능을 완료한 상태를 UML 순차도(Sequence diagram)로 그려서 코드 리뷰할 때 보여 달라고 했다. X와 C에게 UML 지식 공유를 하자는 시도였다....

개발자들과 대화를 통해 설계를 개선하는 상황에 대한 글입니다. 이번 글에서는 권한 관리 기능에 대한 설계를 어떻게 진행했는지에 대한 글입니다....

우리 팀은 새로운 도전으로 SaaS를 릴리즈 한 후, 비즈니스 속도를 맞추느라 개발 품질이 낮아지는 부담을 안고 있다. 비즈니스 속도를 늦추지 않는 선에서 틈틈이 이를 복구하는 상황이다. SW 본토인 미국(?) 표현으로 바꾸면 Technical Debt이 쌓여 있고, 너무 커지기 전에 빚을 갚는 상황이다. 이렇다 보니 일상속에서 자연스럽게 글감이 쌓이는 행복(?)한 나날이다....

팀원들간에 가볍게 소통하면서 설계에 참여하는 경험 공유입니다....