|
:: 게시판
:: 이전 게시판
|
- PGR21 관련된 질문 및 건의는 [건의 게시판]을 이용바랍니다.
- (2013년 3월 이전) 오래된 질문글은 [이전 질문 게시판]에 있습니다. 통합 규정을 준수해 주십시오. (2015.12.25.)
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
21/01/11 15:59
여러 의견이 있을 것 같기는 한데..
제 사견으로는 혼자 개발하는 사이즈에서는 다이어그램 없이 그냥 클래스 구조, 함수명, 변수명에 신경 쓰셔서 코드 가독성을 좋게 하는 정도로 충분하다고 생각합니다. UML을 공부하고 다이어그램을 그려보는 것보다는 (물론 나름 용도는 있겠지만) 기본 객체지향 및 디자인 패턴 공부에 시간을 쏟고, 실제로 리팩토링을 여러번 해 보는게 더 효율적일 것 같습니다. 일단 솔루션 탐색기 쫙 펼쳐놓고 클래스 이름과 네임스페이스만으로 구조파악이 안되는 부분부터 하나씩 고쳐보는건 어떨까요.
21/01/11 16:37
댓글 감사합니다~ 잘 참고하겠습니다
부끄럽지만 아직 디자인패턴이 정확히 무엇인지도 모르는데 공부부터 더 해야겠습니다ㅠ 솔루션탐색기는 아마 VS의 기능인것 같네요..
21/01/12 10:26
현재 단계에서는 굳이 모든 컴포넌트, 행위 등을 다이어그램으로 그리실 필요 없습니다.
UML의 마지막 L은 Language 입니다. 다른 사람과 구현 결과물 만들기 전에 의사소통을 하기 위해 사용하는 언어라는 뜻이죠. 나만 보기 위한 메모를 쓰시거나 일기를 쓰실 때 규약이나 형식을 지키는 경우는 별로 없잖아요? 아직 필요성을 크게 못 느끼시고 다른 개발자와 같이 설계 검토를 하거나 설계 기반에서 코드를 만드실 단계가 아니십니다. 다이어그램 작성에 노력을 투입하고 작성한 다이어그램이 잘 작성되었는지 고민하고 불안해하는 시간이 클수록 하시는 일에 흥미를 잃고 두려움이 생기실 수 있습니다. 그냥 지금은 코드 많이 지지고 볶고 하세요. 에러도 많이 보시고 해결하시고 그렇게 재미나게 프로그램 짜시면 됩니다. 굳이 뭔가 다이어그램 그려야겠다 하시면.. 유스케이스면 내 게임이 이런 걸 했으면 좋겠다 하는 것을 동그라미로 그리세요. 동그라미 바깥에 게이머(사람) 그려놓으시고요. 클래스 다이어그램도 코드 다 작성하고 나면 구현 결과물과 다이어그램이 차이가 나게 되어있습니다. 내가 만들 인터페이스, 구현 클래스, 대략적인 메소드 선언 정도만 해놓으시면 됩니다. 시퀀스 다이어그램 제대로 그리는 사람 거의 없습니다. 스테이트 차트 다이어그램(순서도 레벨로)도 크게 크게 흐름 정도만 그리세요. 내 게임에 대해서 공책에 연필로 쓱쓱 스케치한다는 마음가짐이시면 됩니다. 귀찮으면 안해도 된다는 얘기고요.. ^^
21/01/25 05:46
에고 댓글을 달았다고 생각했는데 다시 답변주신거 참고하려고 읽으러 오니 답을 안달았었네요
2주전 글인데.. 그동안 배우다보니 2주전의 코드는 제가 더럽게 짰기때문에 못알아볼만했다라고 생각하게 되었습니다. 누군가의 추천으로 클린코드라는 책을 조금 일단 알아볼 수 있는 명칭으로 작성하면 되더군요.... 좋은 답변 감사합니다!
|
||||||||||