Q&A와 스터디
![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:0point (0%), 레벨:0/30"){kind=icon}
30저의 코딩 스타일은 우선 큰 그림만 그려놓고 코딩을 합니다.
그리고 나서 좀더 세부적으로 들어가면 머리로 생각하면서 주석달고 코딩을 합니다.
그리고 나서 결과물이 원하는 대로 작동하는지 확인합니다.
나중에 문서화를 위해 순서도를 그려봅니다.
꼭 위의 순서대로 하는 것은 아니지만 대체로 저의 코딩스타일이 위와 같은데요.
이번에 결과물을 가지고 소스보면서 순서도를 그려보고 있습니다.
그런데 순서도를 그리다 보면 조금씩 고쳐야 할 부분이 나옵니다. 완전하지 않았다는 얘기죠..
얘기를 들어보면 우선 큰 그림 그리고, 세부적인 것도 먼저 그린 후 문서화를 한 다음에 코딩을
한다고 들은 것 같은데요.. 전 이 방법이 잘 안됩니다. 세부적인 것을 코딩도 하기 전에 미리 만들어
본다는 게 생각처럼 잘 안되더라구요.. 여러분들은 어떤 것을 생각하고 만드실 때 어떤 순서와 노하우로
결과물을 만들어 내시나요??
그리고 나서 좀더 세부적으로 들어가면 머리로 생각하면서 주석달고 코딩을 합니다.
그리고 나서 결과물이 원하는 대로 작동하는지 확인합니다.
나중에 문서화를 위해 순서도를 그려봅니다.
꼭 위의 순서대로 하는 것은 아니지만 대체로 저의 코딩스타일이 위와 같은데요.
이번에 결과물을 가지고 소스보면서 순서도를 그려보고 있습니다.
그런데 순서도를 그리다 보면 조금씩 고쳐야 할 부분이 나옵니다. 완전하지 않았다는 얘기죠..
얘기를 들어보면 우선 큰 그림 그리고, 세부적인 것도 먼저 그린 후 문서화를 한 다음에 코딩을
한다고 들은 것 같은데요.. 전 이 방법이 잘 안됩니다. 세부적인 것을 코딩도 하기 전에 미리 만들어
본다는 게 생각처럼 잘 안되더라구요.. 여러분들은 어떤 것을 생각하고 만드실 때 어떤 순서와 노하우로
결과물을 만들어 내시나요??
![[레벨:6]](http://old.lameproof.com/modules/point/icons/default/6.gif "포인트:3967point (62%), 레벨:6/30"){kind=icon}
snowflower
2005.12.29 22:58:30 (*.108.229.251)
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:614point (56%), 레벨:2/30"){kind=icon}
검은달사람낭만달소년 저희 학교에서 항상 세뇌시키는 게 있는데,
'코딩은 그저 슈도코드를 타자로 옮기는 일일 뿐이다' 입니다.
...좀 제가 과장을 섞긴 했지만, 정말 저런식으로 계속 압박을 주는데... 그 말이 맞는 것 같습니다.
숙련된 프로그래머라면 바로 하겠지만, 배우는 입장에서는 처음부터 저런 습관을 들여야 하는 것 같아요.
언제가 설계는 전체 제작시간의 가장 많은 부분을 차지해야 하죠.
'코딩은 그저 슈도코드를 타자로 옮기는 일일 뿐이다' 입니다.
...좀 제가 과장을 섞긴 했지만, 정말 저런식으로 계속 압박을 주는데... 그 말이 맞는 것 같습니다.
숙련된 프로그래머라면 바로 하겠지만, 배우는 입장에서는 처음부터 저런 습관을 들여야 하는 것 같아요.
언제가 설계는 전체 제작시간의 가장 많은 부분을 차지해야 하죠.
2005.12.29 23:19:39 (*.109.25.114)
![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:2288point (3%), 레벨:5/30"){kind=icon}
kallru 제 설계는 UI 식으로 합니다. 가장 먼저 클래스 단위로 짜른 후에 어떤 식으로 쓸껀지 먼저 정합니다. 이를테면
CHero* pTest;
pTest->CreateHero(.....);
pTest->Move() or pTest->Render()등등..
그리고 나서 각 함수를 만들어 갑니다.
물론 이 부분에서 "범용성"과 "안전성", 그리고 "독립성"을 생각해야되겠죠.
보통 엔진 -> 매니저클래스 -> 실제적인 알고리즘 클래스 식으로 만듭니다. 독립성을 살리고 범용성을 살리기 위해서
실제 계산하는 알고리즘 클래스를 따로 만들고, 이것을 엔진에서 관리하는 매니저클래스를 만들지만......비슷비슷한 변수이름들로 인해 햇갈릴때가 많더군요 -_-;
CHero* pTest;
pTest->CreateHero(.....);
pTest->Move() or pTest->Render()등등..
그리고 나서 각 함수를 만들어 갑니다.
물론 이 부분에서 "범용성"과 "안전성", 그리고 "독립성"을 생각해야되겠죠.
보통 엔진 -> 매니저클래스 -> 실제적인 알고리즘 클래스 식으로 만듭니다. 독립성을 살리고 범용성을 살리기 위해서
실제 계산하는 알고리즘 클래스를 따로 만들고, 이것을 엔진에서 관리하는 매니저클래스를 만들지만......비슷비슷한 변수이름들로 인해 햇갈릴때가 많더군요 -_-;
2005.12.29 23:22:40 (*.235.122.34)
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:4676point (19%), 레벨:7/30"){kind=icon}
Excelsis 일단 어떻게 만들지 구상하고, 서브시스템으로 나누면서 인터페이스부터 짭니다.
인터페이스를 짜면서 주로 사용하게 되는 방식은, 클래스도를 그리는 대신 헤더파일을 먼저 만들어서 함수와 멤버변수들을 미리 준비하며 인터페이스 자체에 대한 절차는 주로 UML의 시퀀스 다이어그램 방식으로 '각각의 통신패턴'마다 대강 막 종이에다 그려봅니다. 이상하게 저는 순서도는 정말 별로 그릴 일이 없더군요;; 순서도로는 뭔가 서술하기 힘든 경우가 많아 주로 시퀀스 다이어그램을 씁니다.
구조는 위에서 이야기했듯이 헤더파일을 만들면서 구성합니다. 물론 가끔 종이에다가 클래스도 그리듯이 끄적거리기도 하는데 그럴 일은 자주 일어나지 않는 편이네요.
... ... 이 과정에서 뭐 간단한건 빼먹고 넘어갑니다(........)
간단한건 빼먹고 지나간다고는 해도, 웬만하면 헤더에다가 변수와 함수의 용도는 대부분 주석을 달아놓고 지나갑니다. 이름만으로도 정말 화끈하게 알아먹을정도로 당연한 이름은 주석 안달고 가는 경우도 많습니다.
예를 들면 저는 싱글턴 클래스는 Get() 함수는 모두 공통적으로 싱글턴 객체를 받는 함수로 쓰기 때문에 패스하고 지나가는 경우가 많습니다(...)
인터페이스가 대충 잡히면, 서브시스템 중에서 작업절차상 가장 먼저 필요한 것 순서대로 cpp 파일을 채워나갑니다.
서로 필요할때마다 서브시스템을 채워나가다보니 이것저것 돌아가면서 작업하게 되는 점이 있는데, 여기서 좀 산만해지는 경향이 있네요. (문제라면 심각한 문제입니다; )
하다보면 늘상 인터페이스상에 생각못한 문제점이나 '빈 곳'이 발생합니다. 그런 부분이 발생할 때마다 이 부분에 수정을 가할 때 영향을 받을 범위를 생각해보고, 경우에 따라 처음으로 돌아가서 재검토를 들어가서 최종적으로 수정점을 찾아내거나, 아니면 부분적인 추가/수정으로 끝내기도 합니다. 운 나쁘면 그냥 울어야죠. 엎습니다(........)
인터페이스를 짜면서 주로 사용하게 되는 방식은, 클래스도를 그리는 대신 헤더파일을 먼저 만들어서 함수와 멤버변수들을 미리 준비하며 인터페이스 자체에 대한 절차는 주로 UML의 시퀀스 다이어그램 방식으로 '각각의 통신패턴'마다 대강 막 종이에다 그려봅니다. 이상하게 저는 순서도는 정말 별로 그릴 일이 없더군요;; 순서도로는 뭔가 서술하기 힘든 경우가 많아 주로 시퀀스 다이어그램을 씁니다.
구조는 위에서 이야기했듯이 헤더파일을 만들면서 구성합니다. 물론 가끔 종이에다가 클래스도 그리듯이 끄적거리기도 하는데 그럴 일은 자주 일어나지 않는 편이네요.
... ... 이 과정에서 뭐 간단한건 빼먹고 넘어갑니다(........)
간단한건 빼먹고 지나간다고는 해도, 웬만하면 헤더에다가 변수와 함수의 용도는 대부분 주석을 달아놓고 지나갑니다. 이름만으로도 정말 화끈하게 알아먹을정도로 당연한 이름은 주석 안달고 가는 경우도 많습니다.
예를 들면 저는 싱글턴 클래스는 Get() 함수는 모두 공통적으로 싱글턴 객체를 받는 함수로 쓰기 때문에 패스하고 지나가는 경우가 많습니다(...)
인터페이스가 대충 잡히면, 서브시스템 중에서 작업절차상 가장 먼저 필요한 것 순서대로 cpp 파일을 채워나갑니다.
서로 필요할때마다 서브시스템을 채워나가다보니 이것저것 돌아가면서 작업하게 되는 점이 있는데, 여기서 좀 산만해지는 경향이 있네요. (문제라면 심각한 문제입니다; )
하다보면 늘상 인터페이스상에 생각못한 문제점이나 '빈 곳'이 발생합니다. 그런 부분이 발생할 때마다 이 부분에 수정을 가할 때 영향을 받을 범위를 생각해보고, 경우에 따라 처음으로 돌아가서 재검토를 들어가서 최종적으로 수정점을 찾아내거나, 아니면 부분적인 추가/수정으로 끝내기도 합니다. 운 나쁘면 그냥 울어야죠. 엎습니다(........)
2005.12.30 09:39:40 (*.249.67.108)
어쌔신 UML에서 중요한 다이어그램 몇가지만 그려서 해도 디자인은 충분하다고 봅니다.
유지보수의 성격이 있어서 코딩량은 좀 많아지기 때문에 작은 프로젝트에는 불필요하지만요...
소프트웨어공학에서 절차적인 설계와 UML같은 수업은 안하시는지요?
검은달사람낭만달소년// 저희학교도 그렇습니다. -_-;;;
유지보수의 성격이 있어서 코딩량은 좀 많아지기 때문에 작은 프로젝트에는 불필요하지만요...
소프트웨어공학에서 절차적인 설계와 UML같은 수업은 안하시는지요?
검은달사람낭만달소년// 저희학교도 그렇습니다. -_-;;;
2005.12.30 10:10:59 (*.107.113.189)
안군 순서도 보다는 시퀀스 다이어그램이 더 직관적이라 좋아요~ ^^;;
그리고, 슈도코드를 따로 작성하고, 그걸 가지고 코딩을 하는게 귀찮으시면,
맥코넬 아자씨의 Code Complete에 나오는 "주석으로 코딩하기" 방법을 써보세요...
단순한 프로그램(간단한 툴이나, 테스트 모듈...)일때에는 별 도움이 안되지만, 좀 복잡한 구조를 짜야 하는 경우에 도움이 많이 됩니다.
그리고, 잘못된 구조는 나중에 고치면 된다고 생각해요. 너무 지나치게 심각하진 마시길... (하지만, 그걸 자꾸 미루다 보면 문제가 걷잡을 수 없...)
그리고, 슈도코드를 따로 작성하고, 그걸 가지고 코딩을 하는게 귀찮으시면,
맥코넬 아자씨의 Code Complete에 나오는 "주석으로 코딩하기" 방법을 써보세요...
단순한 프로그램(간단한 툴이나, 테스트 모듈...)일때에는 별 도움이 안되지만, 좀 복잡한 구조를 짜야 하는 경우에 도움이 많이 됩니다.
그리고, 잘못된 구조는 나중에 고치면 된다고 생각해요. 너무 지나치게 심각하진 마시길... (하지만, 그걸 자꾸 미루다 보면 문제가 걷잡을 수 없...)
2005.12.30 11:14:32 (*.255.59.11)
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:947point (21%), 레벨:3/30"){kind=icon}
박현만 그렇군요.. UML 수업은 다음 학기에 있어요 4학년1학기에 가르쳐주는군요 ㅋ;; 모두들 감사합니다 많은 도움 돼었습니다~ 꾸벅(__) 그런데 여러분들은 자신이 짜놓은 소스가 완벽하다고 생각하십니까?? 그러니까 어떤 제어문이나 작은 기능이 여기에 들어가는게 맞다고 생각하고 코딩을 했는데 혹시 더 좋은 장소가 있지는 않을까?라는 생각이 안 들 정도로 말입니다..
2005.12.30 11:16:37 (*.229.212.224)
Atoz 음.. 저같은 경우는 혼자서 작업을 하다 보니 혼자 볼펜으로 끄적 끄적 그리는데..
일단 저는 작은거 부터 그려 봅니다. 공성전에서 성을 먹는걸 짠다고 할때 유저의 행동 -> 길드의 행동 -> 연합의 행동 -> 연합 vs 성 연합
이렇게 나가게 작업을 합니다. 왠지 큰거 부터 하면 빼먹는게 많다 보니;;
코딩 스타일은 음.. 모랄까 팀단위라면 그 팀의 스타일을 따라야 된다고 보고 혼자 할때는 자신만의 스타일대로 가도 된다고 봅니다.
머리로 세부적인걸 생각을 하셔서 하시다 보니 빠지는게 있으신것 같은데 일단 코딩하시기 전에는 좀더 많은 생각을 하시고
꼭 UML이나 순서도가 아니여도 메모장에서 이것 저것 해야 될것들은 기록해 두시는것도 한 방법일것 같습니다.
일단 저는 작은거 부터 그려 봅니다. 공성전에서 성을 먹는걸 짠다고 할때 유저의 행동 -> 길드의 행동 -> 연합의 행동 -> 연합 vs 성 연합
이렇게 나가게 작업을 합니다. 왠지 큰거 부터 하면 빼먹는게 많다 보니;;
코딩 스타일은 음.. 모랄까 팀단위라면 그 팀의 스타일을 따라야 된다고 보고 혼자 할때는 자신만의 스타일대로 가도 된다고 봅니다.
머리로 세부적인걸 생각을 하셔서 하시다 보니 빠지는게 있으신것 같은데 일단 코딩하시기 전에는 좀더 많은 생각을 하시고
꼭 UML이나 순서도가 아니여도 메모장에서 이것 저것 해야 될것들은 기록해 두시는것도 한 방법일것 같습니다.
2005.12.30 11:56:53 (*.107.113.189)
안군 박현만// 한번도 제가 작성한 코드가 완벽하다고 생각한 적은 없어요.. 언제나 아쉬움이 남죠.. ^^;;
그래서, Vtune 같은 퍼포먼스 측정 도구 등을 이용해서, Code coverage나, 퍼포먼스 프로파일링 등을 해 보는 거구요.
그리고, UML의 State Diagram은, 순서도와 무척 비슷하면서도, 더 눈에 잘 들어오는거 같아요. (전적으로 제 경우에만... 아닌 분들도 많아요 ^^)
저의 나름대로의 코딩 철학이라면.. "코딩은 최대한 엘레간테하게!" 정도랄까요.. 함수/변수 네이밍 등에 신경 많이 쓰고,
자잘한 문법... (괄호 앞뒤로는 빈칸을 넣는다던지, 선언문 등은 tab을 이용해서 보기 좋게 정리한다던지, enum문을 적극적으로 쓴다던지..)
뭐, 이런 것들에 신경쓰다 보면, 나중에 유지보수 하는데 도움이 많이 되더라구요. ^^;;
그래서, Vtune 같은 퍼포먼스 측정 도구 등을 이용해서, Code coverage나, 퍼포먼스 프로파일링 등을 해 보는 거구요.
그리고, UML의 State Diagram은, 순서도와 무척 비슷하면서도, 더 눈에 잘 들어오는거 같아요. (전적으로 제 경우에만... 아닌 분들도 많아요 ^^)
저의 나름대로의 코딩 철학이라면.. "코딩은 최대한 엘레간테하게!" 정도랄까요.. 함수/변수 네이밍 등에 신경 많이 쓰고,
자잘한 문법... (괄호 앞뒤로는 빈칸을 넣는다던지, 선언문 등은 tab을 이용해서 보기 좋게 정리한다던지, enum문을 적극적으로 쓴다던지..)
뭐, 이런 것들에 신경쓰다 보면, 나중에 유지보수 하는데 도움이 많이 되더라구요. ^^;;
2005.12.30 19:06:42 (*.255.59.11)
박현만 처음부터 완벽하게 만들려고 작정하고 시작하는 것은 아니다. 그러나 나중에 고칠 수 있다는 생각을 염두하고 설계하고 코딩하라.
이 같은 생각을 가지게 되었습니다 모두들 답변 감사합니다^^
이 같은 생각을 가지게 되었습니다 모두들 답변 감사합니다^^
2006.01.02 17:20:26 (*.107.113.189)
안군 결론이 없다는게 결론이겠죠? (이런 무책임한!!) 그냥, 자신만의 코딩 철학이랄까.. 그런게 있다면 좋겠네요.
물론, 헝가리안 표기법이니, Extream Programming이니, 디자인패턴이니, 리팩토링이니... 여러가지 방법론들이 제시되고 있지만,
그 와중에서 자기만의 스타일이 있다면, 어무래도 코딩하는데 도움이 많이 되겠죠?
혼자서 소규모의 프로젝트를 하는 경우에야, 애초에 생각해놓은 스펙 이상의 구현을 하지 않아도 되기 때문에
처음부터 완벽하게 뭔가 할 수 있을지 몰라도, 실제 규모가 있는 프로젝트를 할 때에는, 유지보수, 디버깅, 기능확장 등에 더 많은 시간을 투자하게 됩니다.
그럴 경우를 대비할 수 있는 방식으로 (기왕이면 재사용성까지 좋다면 금상첨화겠죠!!) 코딩할 수 있다면, 충분하다고 생각합니다.
물론, 헝가리안 표기법이니, Extream Programming이니, 디자인패턴이니, 리팩토링이니... 여러가지 방법론들이 제시되고 있지만,
그 와중에서 자기만의 스타일이 있다면, 어무래도 코딩하는데 도움이 많이 되겠죠?
혼자서 소규모의 프로젝트를 하는 경우에야, 애초에 생각해놓은 스펙 이상의 구현을 하지 않아도 되기 때문에
처음부터 완벽하게 뭔가 할 수 있을지 몰라도, 실제 규모가 있는 프로젝트를 할 때에는, 유지보수, 디버깅, 기능확장 등에 더 많은 시간을 투자하게 됩니다.
그럴 경우를 대비할 수 있는 방식으로 (기왕이면 재사용성까지 좋다면 금상첨화겠죠!!) 코딩할 수 있다면, 충분하다고 생각합니다.
크게 잡고 작게 내려오면서 하는 현만님하고 비슷한 스타일이랄까
어차피 .. 설계란게 완벽할 수는 없습니다.
코딩을 하다보면 생각지도 못한 문제에 부딪힐수도 있는거구요
소스는 항상 고칠 수 있다는 생각(리팩토링 할 수 있다)으로 짜시면
고치는게 그렇게 큰 문제가 아니라는것을 느끼실 수 있지 않을까요!?!