426 객체지향의 사실과 오해 5장 7장 부록 총 112페이지 2024 06 14

[jongfeel]

드디어 2024 academic conferece의 마지막 모임이군요.

여기까지 책을 읽고 논의를 잘 해주신 여러분들께 감사드립니다.

이번에 논의 주제는 Discussions2.md 파일에 적었습니다.
그 이유는 파일 안에 적어 두었습니다.

워크샵때 많은 분들이 오셨으면 좋겠네요.

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[hemil0102]

논의 주제를 보고 처음 든 생각은 UML 클래스 다이어그램과 같은 툴을 사용해서 관리해보면 어떨까 싶습니다.
아직 개발 경험이 많지는 않지만, 프로젝트를 같이 협업할 때 클래스 다이어그램처럼 추상화된 그림을 보면서 소통을 하면,
현재 코드와 달라진 부분을 조금 명확히 알게되서 좋았던 것 같아요.
뭔가 약간 여행할 때 지도를 보면서 계속 나아가는 기분이 듭니다.

그런데 정말 바쁘거나 설계를 하다보면 구조가 계속 변경되어서 또 하나의 업무가 될 수도 있지만,
길잡이를 잘 해준다는 점에서 시간 투자를 할 가치가 있다 생각합니다.
따라서 업데이트가 잘 안이뤄지는게 어떻게 보면, 툴의 접근성 문제일 수도 있지만,
구성원들이 바빠서 시간이 없거나, 작성할 기술력이 없을 수도 있기에 다방면으로 고려해도 좋을 것 같습니다.

요즘은 공용툴로 UML을 같이 작성할 수 있어서, 작성을 같이하고 버전 관리를 해봐도 좋을 것 같아요.
GPT는 사용해본적 없지만 그림 그려주기도 하니 내용을 넣어서 업데이트 사항을 뽑아보는 것도 시간 절약에 좋아보이기도 합니다.
요즘은 피그마 같은 디자인 툴이 모든 UI를 인공지능이 생성해주기도 하여서,
다이어그램을 인공지능이 그려주는 툴도 분명 있을 것 같습니다.

시각적인 도구를 소통에 활용하면 좋아보여요.

[yeslee-v]

굉장히 공감가는 질문입니다.

설계 내용을 업데이트 해 달라고 요청하는데 그게 잘 안되고 있어서 뭔가 잔소리 하고 있는 느낌을 많이 받는데

잘 되고 있지 않는다는 것은 결국 까먹는 경우가 대부분이라고 생각이 듭니다.(각자의 성향도 있을 것이고요.)
종필님께서는 잔소리를 하고 있는 느낌이라고 하셨지만, 그렇게라도 지속적으로 인지시킬 필요가 있다고 생각합니다.