프로그래밍전의 준비 작업은?
글쓴이: yootiong / 작성시간: 일, 2001/05/20 - 3:30오후
전 어설프게 오픈소스 프로젝트를 운영(?)하고 있는 코더입니다. 전 프로그래밍을 하면 무조건 vi부터 열고 봅니다. 그리고 생각나는 데로 주욱 써내려 가지요. 그래서 그런지 코드가 점점 길어질수록 코드가 점점 지저분해지는 것을 느낍니다.
저도 프로그래밍을 시작하기 전에 계획을 짜려고 몇번인가 종이에 펜을 들고 고민을 해봤는데 뭘 해야 할지를 모르겠더군요. 그래서 또 그냥 vi를 열고 생각나는 데로 주욱 써내려 가기 시작하지요....
프로그래밍을 하기 전에 준비작업으로는 무엇을 해야 하나요? 순서도를 그려보아야 하나요? 순서도를 하나하나 다 그리기엔 너무 양이 많지 않나요? 그럼 순서도를 요약해서 중요한 부분만 그려 보아야 하는 건지....
프로그래밍을 하기 전에 준비작업으로는 무엇을 해야 하는지에 대해 이야기해 보았으면 합니다. 참고문헌 같은 것을 추천해 주셔도 좋습니다 :-)
P.S 참고로 전 C언어를 사용합니다.
댓글
전 웹개발자인데요저는 코딩하기 전에 디자이너한테서 디자인된 HTML
전 웹개발자인데요
저는 코딩하기 전에 디자이너한테서 디자인된 HTML 페이지를 받으면 그걸 다 프린트해서 한장 한장 봐가면서 종이에 체크를 합니다. 빠진 내용은 없는지 각 페이지들간에 링크와 인자는 어떻게 되는지 데이터베이스를 사용한다면 테이블 구조를 어떻게 잡으면 좋을지...기능을 구현하기 위해서 어떻게 할건지..( PHP 나 ASP 같은 Server Side Script 로 처리할 건지 자바스크립트로 HTML 페이지에 포함시킬건지...) 에러 체크나 예외 처리해야할 상황은 어떤게 있는지 등등을 종이에 다 적습니다. 그리고 한페이지 한페이지 종이를 보면서 코딩을 하죠...^^
프로그램 하기 준비작업은...뭐... 일에 따라 많이 틀리지만..
프로그램 하기 준비작업은...
뭐... 일에 따라 많이 틀리지만...
좀... 복잡한 알고리즘과, 태크닉이 필요한 engine 과 같은 부분을 작성 할때는...
그냥... 멍하니... 책을 읽어요... 필요할것 같은 책을...
그러다가... 하나 둘씩 필요할것 같은 코드들을 생각하죠...
그렇게 몇날 이고 있다가...
머리속에서 작성한 코드를... 머리속에서 이리 저리 붇여 보고...
알고리즘을.. 이리 저리 적용해보고..
진짜 어려운 일이면... 머리속에서.. 이건 된다.. 안된다...
그런 싸움이 일어나고...
처음에는 이건 안된다... 라는 의견이 우세하고....
점차 이건 된다.. 라는 결론이 나오고...
그때 쯤이면... 머리속에서 슬슬 module 단위로 시물레이션되고...
그게... 점점 커지고... 커지다가 커지다가....
머리가 폭팔할것 같으면... 종이에 쓰고...
그러다가... 될것 같으면.. 코딩을 하죠...
그래서.. 저의 프로그램 준비 단계는... 책좀 읽다가... 멍하니 망상하다가.. 종이에 그리다가... 시작 합니다...
PS... 그런데... 정말 분야에 따라 많이 틀려요... ^^*
전체 개발기간중 코딩시간이 20 - 30 % 에 동감을 대부분 하실것이라
전체 개발기간중 코딩시간이 20 - 30 % 에 동감을 대부분 하실것이라 생각합니다.
작은 프로그램에서는 그럴필요는 없겠지만.. 그럴려고 노력 합니다.
저의 경우는 두가지 유형으로 나누어 지는데.
웹 이던 어셈블리어든 비주얼베이직이던 다른 어떤 언어를 사용하건간에
익숙하지 안아서 공부를하면서 프로그램을 하는경우를 제외하면 대충 맡는것 같습니다.
첫번째 유형은 의뢰자가 어떤 프로그램을 요구하는지 주변 환경을
둘러봅니다. 그리고 상담을 하고 같이 밥을 먹습니다.
다음엔 프로그램을 쓰는광경을 상상해봅니다.
그리고 실제 일하는모습을 살펴보면서 다시 생각을 합니다.
어떤 유형의 결과가나올수있을지 설명을 해주고 가능하면 다른 모델을 될수있으면 많이 보여줍니다.
그리고 프로토타입들을 계획하고 자료구조에 대하여 고민합니다.
그리고 프로그램코딩을 시작합니다.
디버깅을 합니다.
수정 요구를 받아들입니다.
다시 수정하고 디버깅하거 결과를 보여주는 과정을 반복합니다.
관련 서류들을 모아서 문서를 만들기 시작합니다.
중간 중간 도장을 꼭 받아놓습니다.
당연히 코딩시간보다 딴시간이 더들겠져..
하지만 사용자들은 문서를 보길 원하지 소스를 보고싶러하는 경우는 많지않습니다.
두번째는..
일단 그래픽 툴을 이용하여 그림을 그립니다
마음에 들때 까지 띁어 고집니다.
코딩을 합니다.
사용자의 입장에서 프로그램을 사용해보면서..
인터페이스를 수정 합니다.
다음 버전에 추가할 기능을 생각해봅니다.
디자인에 신경을 많이쓰면 뽀대가나져..
연습장과 펜.그리는 것 : 1. UI 모양새 대강.2. 자
연습장과 펜.
그리는 것 :
1. UI 모양새 대강.
2. 자료구조 대강 도안.
3. 자료구조 갯수 보고 클래스 몇개나 나올까.. 궁리. 클래스 도안(?)
4. 실전 : 막코딩..
* 아직 큰 규모의 녀석을 짜본적이 없어서.. -_-; SE 가 위력을 발휘할때라면 좀 큰 규모의 프로그램의 경우라 생각됩니다. 각 일에 맞는 연장을 선택하는 것이라는 개인적 견해.
* 물론.. 간단한 프로그램때부터 습관들여놓는게 좋겠지만영..~
일단 google.com(검색 사이트 아무거나 좋다)에 관련된 단어를 입
일단 google.com(검색 사이트 아무거나 좋다)에 관련된 단어를 입력한다.
예를들면, 쓰레드 관련 프로그래밍이라면 thread java source라고 친다.
나온 검색 결과를 찾아서 쓸만한 놈을 고른다.
그다음 해당 부분을 copy & paste한다. 그다음 아무생각 없이
대충 고친후 컴파일하고 실행한다. 안돌아가면 소스를 한참 째려본다.
옆에 사람한테 물어본다.
안되면 다른 소스를 검색한다..
정말 허접하지여... -.-
문서화....제가 다니는 회사는 모든 프로젝트에 관해서 문서화를
문서화....
제가 다니는 회사는 모든 프로젝트에 관해서 문서화를 합니다.
짐.. 열심히 문서화중........ 지겨..ㅡ.ㅡ
그럼..
개인적으로 권하는 방법은 일단 비주얼 모델링을 하기 위해Unifi
개인적으로 권하는 방법은 일단 비주얼 모델링을 하기 위해
Unified Modeling Language(UML)을 배우시고 소프트웨어 구현전에
요구사항 분석, 초기 유스케이스 모델링, 액티비티 다이어그램, 시퀀스
등등을 그린후 세부화 시키겠죠.. 이때 Rational Rose를 사용하구요
그리고 전체 Process는 Rational Unified Process를 이용한 방법론을
연구하심이 어떨지 하는 생각이 듭니다.
여하튼 문제는 공통적으로 지금가지 프로그래머들이 겪고 있었던
문제라고 생각하는데 이런 문제점들을 해결하기 위해 모델링 단계에서
UML을 사용하고 방법론은 RUP를 사용하는거죠
여하튼 OMG에서 RUP도 UP로 표준화 하기 때문에 이제 개발자들은
배워야 합니다. 코딩도 중요하지만 훌륭한 프로젝트를 이끌러면
역시 방법론을 써야하고 그리고 모든 개발자가 이해할 수 있는
모델링 언어를 써야겠죠.. UML을 배워보세요
저희는 특이하게도 철저한 문서와화 구조화를 한 후에 그 스펙대로코딩으
저희는 특이하게도 철저한 문서와화 구조화를 한 후에 그 스펙대로
코딩으로 들어갑니다. 회의를 정말 오래 했지요.
1. 기능분석, 필요한 entity 도출.
2. 그 사이의 프로토콜 정의
3. ERD 제작
4. 모듈 분담 및 스케쥴 조정
뭐 이런 식으로 해나가는데 물론 그 사이에도 끝임없이 계속해서 회의를
해나가며 조정하고 또 조정하며 문서를 남겨댑니다.
다른 회사에서 주먹구구식으로만 작성하다가 지금 몸담고 있는 회사에
와서 꽤 놀랬습니다. 처음엔 적응하기도 힘들었는데 역시나 도움이 많이
되더군요.
정말 좋은 회사를 다니시고 계시군요.철저한 문서화와 구조화, 그리고
정말 좋은 회사를 다니시고 계시군요.
철저한 문서화와 구조화, 그리고 끊임없는 회의와 고객과의 상담....
바로 이것이 개발자가 갖추어야 할 자질이 아닐까 합니다.
물론 그렇다고 해서 제가 그렇다는 것은 아니지만 저 또한 그렇게 하려고
노력 중입니다.
시간이 지나면 지날수록 모든 개발자들이 피부로 진하게 느끼는 점들이 아닐까 생각됩니다.
보다 나은 제품과 질 높은 서비스의 이면에는 바로 위와 같은 덕목들이 있다는 것을 기억해야 할 것 같습니다.
냐하하하...초보들은 어떻게 짤깨요?우선 변수는 메모하고...
냐하하하...
초보들은 어떻게 짤깨요?
우선 변수는 메모하고....
나머지 흐름은 주석을 달아 놓는뎅....
아직까지 큰 프로그램을 짜보지 않아서 모르겠지만....
워떻게들 하고 계세욤?
저는 우선 어케 짤까 대충 생각합니다.글구 나서 짜구 짜던 중간에 중
저는 우선 어케 짤까 대충 생각합니다.
글구 나서 짜구 짜던 중간에 중간 점검 다시 대충 생각한 내용을
상기하면서 잘못된 부분이나 수정을 가할부분을 수정합니다.
또다시 짭니다 중간에 또 수정및 재점검..
반복하다보면 세세한 부분까지 생각하게 됩니다.
이때 문서로서 정리하고 다시 위의 루틴을 돕니다 -_-
음,, 저는 코딩할때 주로 느끗하게 하는 편입니다.
이것 저것 생각하면서,, 주로 코드가 얼마만큼 성능을 낼수 있을까 입니다.
순서적인 프로그래밍 - 1st: 우선 연산(함수)을 생각할 것. 자신
순서적인 프로그래밍 -
1st: 우선 연산(함수)을 생각할 것. 자신이 만들고자 하는 프로그램이 필요로 하는 연산을 생각할 것.
2nd: 프로그램의 전체적인 동작순서를 생각할것.
3rd: 프로그램에서 메인 데이타를 어떤 식의 데이타 구조로 표현한 것인지 생각할것.
4nd: 각각의 연산이 필요로 하는 데이타와 데이타 구조를 생각할것.(함수의 이름과, 함수에서 사용하는 데이타 이름을 한번 적어두는 것이 좋다.)
5th: 각각의 연산에서 공통적으로 필요로 하는 데이타와 데이타 구조를 생각할것.
6th: 메인함수에서 입력 받아야 될 데이타를 생각할것.
7th: 프로그램을 짤것.(짜다가도 프로그램은 자꾸 자꾸 변함.)
객체지향 프로그래밍은 순서적인 프로그래밍보다 설계 자체가 엄청 쉽습니다. 다만 많은 분들이 데이타를 추상화 하는 낮선 방법에 많이 적응하지 못해서 그렇습니다. 데이타와 데이타의 동작(메소드), 입력함수만 설계하면 끊입니다.
즉, 자신이 선택한 언어의 철학에 따라 행동하시면 됩니다.
짜고 나서 반드시 할것은 문서화 입니다. 프로젝트를 할때는 문서화가 먼져 이루어 져야 합니다. 계획부분에 포함되어 있지요. 그러나 개인 혼자서 짜는 프로그램은 설계 부분에서의 문서화는 프로그램의 구조(연산, 데이타) 정도 입니다. 프로그램 짜고나서, 순서도 그려 놓으면 정말 좋습니다. 한 6개월 뒤에 보아도 프로그램이 한 눈에 보입니다.
그리고, 프로그램의 오류는 프로그램이 완성되고 나서 잡는 것이 아닙니다. 능동적으로 프로그래머가 오류에 대해 미리 생각해야 합니다. 수동적인 오류만을 생각할 것이 아니라 능동적으로 해야 합니다.
프로그래머의 자질에 따라 source code가 간결할수도 있고 복잡할 수도 있습니다. 둘다 다 장단점이 있습니다. 간결하면 한눈에 보기에는 좋지만 논리적으로 이해 하기가 힘듭니다. 복잡하면 논리적으로 이해하기가 그 만큼 쉽지만 프로그램을 한눈에 보기 힘듭니다.
데이타 구조에 대해서 어떤 것이 자신이 짤려고 하는데 효율적인가 하는 것은 반드시 프로그램 짜기전에 생각을 해야 합니다.
프로그램을 읽을때는 순서적 프로그램은 메인함수 보다 연산, 즉 함수를 먼져 읽고, 이 함수가 무슨 동작을 하는지를 알고, 메인함수를 읽습니다. 객체지양 프로그래밍은 객체가 구성된 데이타를 먼져 보고 그 데이타가 어떤 연산(메소드)를 필요로 하는지를 읽고 메인 함수를 읽으면 됩니다.
기사 과목에도 있는 소프트웨어 공학과목은 우리나라 회사에서는 쓰레기 취급 받습니다. 그러나, 이것은 정말 프로그램에서 논리적인 부분을 없애는 것과 마찬가지 입니다. 원서로 된 책 2권정도를 보았는데 정말 느끼는 바가 많았습니다.
그리고 위의 것들 보다 중요한 것은 항상 생각을 하는 것입니다.
왜 라는 질문을 많이 하세요.
그럼 쬐금이라도 도움이 되길 바랍니다. 많은 분들이 저보다 좋은 말씀들 많이 써 주셨군요.
다들 자기 잘났다고 쓰는구만..
다들 자기 잘났다고 쓰는구만..
자신이 잘나서 쓰는게 아니라,자기가 사용하는/적용하는 방법에 대한 다
자신이 잘나서 쓰는게 아니라,
자기가 사용하는/적용하는 방법에 대한 다른 개발자들의 객관적인 평가를 워하는 겁니다.
이 바보 돌대가리 같은 사람아..
님과 같이 "모가 똥인지 된장인지 구분못하는 엉터리"들이
언제나 남의 조언을 무시하고 독단적으로 살아가죠,...안그런가요? 이 밥탱아?
"벼는 익으면 고개를 숙이고, 사람은 아는게 많으면 겸손해 지는법 ...
"벼는 익으면 고개를 숙이고, 사람은 아는게 많으면 겸손해 지는법 ..."
모르면 남이 정성들여 쓴글을 읽고 자신을 돌아보고 반성하든지 해야지, 무신 지 못난 탓을 남에게 돌려가며 자신(김완섭)의 이름에 똥칠을 하나?
바보 같은 놈아!
내가 널 위해 니 이름으로 3행시를 지어주마!
김 : 김완섭이... 너
완 : 완전 돌삐아이가? 니 대가리!
섭 : 섭불리 까불면 대가리 확 쪼개뿐데이!
신기하다, 이런 딴지맨들은 언제나 존재한다!
신기하다, 이런 딴지맨들은 언제나 존재한다!
제겐 이런 잘난척(?)이 많은 도움이 된답니다 :-)
제겐 이런 잘난척(?)이 많은 도움이 된답니다 :-)
--
나는 언제나 하이파이브에 목마르다.( 유수영, 2002 )
"주먹"주먹 구구식으로 짜야 하기 때문에....
"주먹"
주먹 구구식으로 짜야 하기 때문에.... ^^
규모가 큰 프로그램의 경우, 머릿속에서 코딩함에 있어서 가장 햇갈리기 쉬
규모가 큰 프로그램의 경우, 머릿속에서 코딩함에 있어서 가장 햇갈리기 쉬운것이 프로그램 내부에서 사용할 특정한 자료구조의 형태가 아닐까 합니다.
필요한 자료구조가 있다면 그것이 어떤 변수를 포함하고, 몇개를 포함하며 그것의 확장성은 어느정도일 것이다를 먼저 예측해보는 것도 필요하지 않을까 싶어요.
개인적으로 OOP는 참 적응하기 어렵습니다.클래스는 우리의 인식상 명
개인적으로 OOP는 참 적응하기 어렵습니다.
클래스는 우리의 인식상 명확하게 어떤 형체와 경계가 존재하는
그런 존재입니다. 즉 클래스에 붙여주는 이름은 명사형이 되어야만
합니다. 이건 책에도 많이 나오는 얘기입니다. 클래스명은 명사형으로
지어라.. 그런데 이 이름짓기가 장난이 아닙니다.
여기에 어떤 클래스가 있습니다. 분명 존재하고 어떤 일정한 종류의
작업을 일관적으로 수행합니다. 여기에 이름을 붙여줘야 하는데
기존의 명사가운데 어떤 명사도 이 클래스를 표현하는데 적당하지
않습니다. 그래서 우리는 엄청난 작명실력을 발휘해야만 합니다.
Factory니 Iterator니 Adapter니 Facade니 Mediator니..
전 미국사람이 아니라서 잘 모르겠습니다만 어쨌든 도저히
단어 자체만 가지고선 뜻을 짐작할 수 없는 온갖 새로운 명사들을
신조어들을 마구 만들어냅니다.
제길 Iterator라니.. 이거 이름만 보고서 뭐하는건지 도대체
누가 어떻게 알 수 있단 말입니까? 물론 공부하면 알게 되지만.. ^^;
이름이란게 일단 보게되면 '이건 이런거구나' 하고 알 수 있어야하는데
거대한 프로젝트에서 클래스가 수백개 단위로 쏟아지게 되면
전 이름 지을 재주도 없을뿐더러 그 이름만 보고서 이 클래스가
뭐하는 클래스인지 구분할 재주도 없습니다..
그 반면에 함수이름은.. 척보면 대충 이 함수가 뭐하는 함수일지
상상이 되죠. 쉽게 읽히니까요..
어쨌든 OOP는 이런 문제점이 있다.. 이런걸 말씀드리고 싶습니다.
아 밥먹으러 가야하기 때문에.. 나중에 또..
디자인 페턴에 대해 공부해 보셨다면 Factory, interator,
디자인 페턴에 대해 공부해 보셨다면 Factory, interator, Adapter라는 문구만 보고 그 클레스의 기능 뿐만 아니라 내부 구조까지도 어느정도 이해 할수 있습니다. 그래서 작명에 신중해야 한다는 말은 저도 동의 합니다. 괜한 오해를 이르키기 쉬우니까요. 디자인 페턴에서 이름은 기능과 구조를 같이 지칭하고 있으니까요.
반대로 생각하는 사람도 많습니다.메쏘드 오버로드에 대해서는 어떻게 생
반대로 생각하는 사람도 많습니다.
메쏘드 오버로드에 대해서는 어떻게 생각하실지
궁급하군요...
메소드 오버로딩이나 연산자 오버로딩은 이른바 양날의 검입니다.잘쓰면
메소드 오버로딩이나 연산자 오버로딩은 이른바 양날의 검입니다.
잘쓰면 좋지만 두서없이 쓰면 코드를 더더욱 난공불락의 철옹성으로
만드는 그런 것이죠. 최근의 추세는 메소드 오버로딩은 다시 허락하고
연산자 오버로딩은 제한하거나 한정된 연산자에 대해서만 허락하는
것으로 압니다. 아마 C#이 그럴껄요?
개인적으로는 오버로딩은 없는게 낫다고 봅니다. 자기가 혼자
쓸때는 편하지만 남이 쓴 오버로딩은 읽는데 너무너무 방해가 됩니다..
그래도 가끔은 메소드 오버로딩이 그립더군요. (전 델파이 씁니다.
오브젝트 파스칼이죠..)
설계-코딩-테스트로 이어지는 폭포수 모델은 이른바꿈속의 모델일 뿐입니
설계-코딩-테스트로 이어지는 폭포수 모델은 이른바
꿈속의 모델일 뿐입니다. 현실에선 그렇게 개발할 수
있는 경우는 거의 없습니다.
그래서 RUP같은 경우도 Iterative를 강조하지 않았습니까?
반복적으로 같은 종류의 프로젝트만 수행해서
엄청난 경험이 축적되지 않는한 한번의 설계로 모든걸
끝낸다는건 정말 무리라고 생각합니다.
또 반면에 어떤 한 종류의 프로젝트에 경험이 축적되면
이번엔 설계조차 필요없어집니다. 그냥 구지 문서화할
필요도 없이 손가는대로 두드리다보면 하나 짤 수 있는..
그런 경지도 있더군요.
어쨌든 프로그래밍을 하기 전에 필요한 것은 해당 도메인에
대한 이해와 분석입니다. 자신이 프로그램을 짜는 동안에
필요한 사전지식은 이미 머릿속에 다 들어와 있어야죠.
일일이 책찾아보며 동시에 프로그램도 짠다면 그야말로
걸레...같은 코드가 나오겠죠. 어차피 다시 짜게 되고
그럼 시간낭비가 심할겁니다.
그 다음은 아키텍처 디자인입니다..
이른바 [큰 그림]이죠. 서로 표현하는 방법이 틀릴뿐
누구나 프로그래밍을 시작하기 전에는 이 큰 그림은
그려놓고 시작합니다. 종이에 그리든 머리에 그리든 말이죠.
UI가 있는 프로그램인 경우 이 UI가 큰 그림을 대체하는
경우도 많습니다.
세부적인 알고리즘이나 구현방식은 그다지 중요하지 않습니다.
그보단 이른바 '인터페이스'가 훨씬 중요하다고 생각합니다.
저는 Naming에 굉장히 신경을 씁니다.
정확한 이름이야말로 코드에 대한 보증수표라고 생각합니다.
만약 자신의 함수에 맘에 드는 이름을 붙일 수 없다면 그경우엔
코드가 문제가 있을 경우가 많습니다.
이 함수는 이런 일을 하는 함수다! 그러니까 이렇게 이름붙이면
정확하게 이 함수를 표현할 수 있다..
뭐 이런거죠. 그런데 하나의 함수 안에서 연관되지 않는
2가지 이상의 일을 하던가 아니면 명확하게 말로 표현하기 어렵게
긴 작업을 수행하던가 그것도 아니면 지나치게 짧은 작업을
수행하던가 그러면 대번에 '이름 붙이기가 곤란해집니다.'
OOP라고 해도 크게 틀리지 않아서.. 클래스명은 결국 명사로
지어줘야만 하기 때문에 함수명보다 짓기가 더욱 까다로울 때가
많습니다.
이름 붙이기가 어려우면 뭔가 잘못된거다..
뭐 이건 제 이론입니다만.. 나름대로 참고하실 수 있을겁니다.
그럼 이만
설계-코딩-테스트의 싸이클이 왜 꿈속의이야기죠? 상식 아닌가요?
설계-코딩-테스트의 싸이클이 왜 꿈속의
이야기죠?
상식 아닌가요?
-물론 울 나라에서는 상식이 기이한 것으로
받아 들여지기도 하지만...
설계-코딩-테스트는 분명 개발의 기본이 되는 싸이클입니다.이 싸이클을
설계-코딩-테스트는 분명 개발의 기본이 되는 싸이클입니다.
이 싸이클을 단 한번만에 끝내는게 불가능하다는겁니다.
제 글을 읽어보시면 설계-코딩-테스트가 아니라 폭포수 모델이
꿈속의 모델이라고 했습니다. 폭포수 모델은 저 싸이클을 한번에
끝내는 모델이죠. 현실적으론 거의 불가능한.. SE책 맨앞에
항상 나오는 모델입니다.
대개의 경우 설계는 완벽할 수 없으며 코딩단계에서 구현의
어려움 또는 퍼포먼스가 안난다던가 하는 문제로 다시 설계
단계로 피드백하는 경우는 비일비재합니다. 무작정 설계기간을
오래잡는다고 해결되는 문제는 아니고 코딩에서 다시 설계로
피드백하는걸 금기시해서는 안됩니다.
그리고 프로젝트가 진행됨에 따라 요구사항이 늘어나고
그러한 요구사항을 받아들이기에 설계가 한계를 보일때 설계를
처음부터 다시 하기도 합니다.
무엇보다도 요구사항이라는게 설계 직전에 완벽하게 도출된다는게
불가능하죠. 대개의 프로젝트는 시작하고 나면 점점 더 덩치가
커지지 않습니까? 고객도 뭔가 좀 알게 되면서 점점 더 요구사항도
많아지구요.
고객의 요구사항이 아니라 혼자서 만드는 프로그램이라고 해도
만들면서 뭔가 기능을 추가하고 싶어지는건 인지상정입니다.
그럴때도 처음에 한 설계는 언제나 한계에 부딪치게 되죠.
그럼 이만.
문서화란 결국 [다른 사람]을 위해서 하는 것입니다.그 문서를 볼 다
문서화란 결국 [다른 사람]을 위해서 하는 것입니다.
그 문서를 볼 다른 사람의 수준에 따라서 문서화의 범위는
달라진다고 봅니다. 그 사람이 나와 같은 수준의, 또는
나를 능가하는 수준의 프로그래머라면 그리고 이 프로그램에
대해서 경험과 지식을 충분히 가지고 있다면 문서화는 별로
필요없습니다. 그저 전체적인 구조와 몇가지 주의할 점..
정도면 됩니다. 이런건 따로 문서화할 필요도 없이
주석만 갖고도 충분히 전달할 수 있습니다.
SI쪽은 더더욱 그렇지 않습니까? DB프로그램이란 결국
데이터 입출력과 UI가 조합되는 비슷한 패턴의 반복이
압도적으로 많습니다. 이런 경우 서로 짜는 패턴이 비슷하다면,
표준화된 코딩 양식이 있다면 코드 자체가 거의 문서가 됩니다.
문서화를 위한 문서화, 그저 보여주기 위한 산출물로서의
문서화도 많습니다. 만약 코드가 잘 짜여져 있다면 같은 시간동안
문서를 읽으나 코드를 읽으나 결국 똑같이 해당 프로그램을
파악할 수 있습니다.
만약 문서화가 필요하다면 개별 프로그램 하나하나에 대해서
필요한게 아니라 '코딩 표준'에 관한 문서가 필요합니다.
열사람이 짜든 백사람이 짜든 한사람이 짠 것과 똑같은 코드가
나오게 할 수 있는 그런 철저한 코딩 규칙이 있다면 그리고
그 규칙을 엄격하게 준수시키고 검사한다면 문서화의 양은
대폭적으로 줄어들고 유지보수도 훨씬 편하게 될 것입니다.
하여튼 문서 많이 만든다고 그게 꼭 잘하는 일은 아니라는겁니다..
전 지나친 문서화는 전근대적인 개발방법론의 유물이라고 생각합니다.
그럼 이만
우리나라 플그머들 문서화 안한다고 말하는데요 사실 우리나라 기업 문화가
우리나라 플그머들 문서화 안한다고 말하는데요 사실 우리나라 기업 문화가 그런 플그머를 양산한다고 보는 것이 더 정확하겠네요..
이게 뭐 보통 설계기간을 인정하지않는 것이 우리나라의 프로그램 작업관행이죠.. 글다보니 일단 코딩하고 돌려보고 잘못되어있으면 수정하고 또돌려보고 또 수정하고...(ㅡ,ㅡ;)
하이간 플그머들 절라 땀나게 만듭니다.
업무보고로 설계했다하면 "놀았네!!"라는 응답이 옵니다.(ㅡ,ㅡ;)
전 저위에 양키넘들은 이렇게 하더라 하고 쓴글있는데 우리나라사람이 그렇게 하면 들인돈 아깝다고 열라 난리날껄요..(기업의 사대주의 ㅡ,ㅡ;)
하이간 저는 양키넘들처럼 일할수 있는 곳에서 프로그램 한번 짜봤으면 싶네염(^_^;)
뭐...이런 질문이 나오면 늘상 원론적이고 엄청 지당하기 이를 데 없는
뭐...이런 질문이 나오면 늘상 원론적이고 엄청 지당하기 이를 데 없는
그런 답변들이 나오죠. 다 맞는 얘기들입니다.
SE개념에 입각하야 설계하고 코딩하고 문서남기고... 정론이죠.
근데 '한국'이라는 범위로 축소해 볼까요?
유지/보수? 필요한가요?
대개의 '돈 좀 있는' 대기업이나 중견기업에서 일 해 보신분은 아시겠지만,
유지보수 하나요?
외주 업체 맡겨서 만들고, 운영시키고, 좀 버벅거린다 싶으면...
다른 외주 업체 맡기면 끝.
그럼 외주 업체에서는 유지보수 필요하나요?
회사 10,20년 해먹을 것도 아니고
주식값 올려서 1,2년 해먹고 말건데 훗날은 무슨...
게다가 큰 업체에 SI 해줘도, 내년에 또 자기회사랑 계약할지 안할지
모르는 상황에서는 결과물만 '싸게','빨리' 나오면 그뿐이죠.
(거기다 덧붙이면, 돈만 좀 주면 노다가 코딩이라도 하겠다는 사람
열나 많은데 코드 더러우면 뭐 어때요? 노가다 시키면 되지.
일단은 계약 맺는게 더 중요하지)
따라서 결론은,,,
(외국 나갈 비행기값도 당체 구할 수 없는 저로서는)
한국에서 먹고 살려면 코드 더럽더라도 빨리만 만들어 내면 된다
라는게 제 생각입니다.
이런게 악순환의 고리라고 하는거죠? --;
음...윗글 쓴 사람입니다. 쓰고 나니 원래 글에 대한 답변을 전혀 안해
음...윗글 쓴 사람입니다. 쓰고 나니 원래 글에 대한 답변을 전혀 안해서리... ^^;
나름대로 답변을 하자면, '코딩 전에 뭘 해야 하나요?' '일단 생각을 해야 합니다'
순서도 그리고 설계하고 뭐 그런 생각 말고,
어떻게 하면 '빨리' '힘 안 들이고' (가능하다면) '쉽게' 만들 수 있는지를 말입니다.
'쉽게'...
즉, 링크드 리스트같은걸 만들면 효율적일 것 같은 부분에,
'이 부분은 나중에 누군가 노가다를 할 부분임에 확실하다'싶으면
그냥 무식하게 어레이로 하고 마는 겁니다.
(그래야 코더들의 고민거리를 약간이라도 덜어 주죠.
이 배려를 모르는 의욕만 가득한 코더들이 왜 이리 짰냐고 욕하는 걸 듣긴 했지만,
진짜 알고리즘을 써서 만들었다면 그들은 손도 못 댈 겁니다
...이들이 손 댈 수 있게끔 문서화를 해야 하는거 아니냐...라고 말들 하실지 모르지만,
대개의 프로젝트에 그럴 시간은 없지 않습니까? 한 프로젝트 끝났다고 노는 시간이
있는 것도 아니고, 대개 한 번에 하나의 프로젝트만 하는 것도 아니니 말입니다.)
'빨리'...
그리고... 이런 펑션을 구현해야 하는데... 이건 어딘가 있을 거 같다 싶은거
(이건 순전히 경험에서 오는 감입니다. 저같이 아직 경험이 부족한 사람들일지라도
이런 느낌이 올 때가 상당히 많지 않나요? ^^;)
그런걸 찾아서 URL 적어 놓고, 소스 받아와서 파라미터와 리턴값 정도 파악해 놓고...
'최소한의 공력'...
다른 사람과 협동해서 만들어야 하는 프로그램일 경우 (대부분이 그렇지만)
에는, 저 사람들과 내가 어떻게하면 대화를 적게 나누고 '확실하게' 니 할 일,
내 할 일을 가를 수 있을까를 고민하고...
(뭐, 여기에서는 약간의 문서화 작업을 하기도 합니다. 말로 해놓으면 다 까먹으니까요
^^;;)
한 프로그램을 놓고 사람들의 대화가 '최소한'이 되게 만드는 것이 핵심입니다.
그러기 위해선 프로젝트마다 일을 공평하게 배분하는건 무리가 있습니다.
따라서, 저번 프로젝트에서는 니가 좀 많이 했으니, 이번 프로젝트에서는
내가 이 기능을 하는 부분은 다 만들겠다...라는 식의 접근이 더 효율적이었습니다.
다른 사람의 펑션을 갖다 쓰고 어쩌고 하는 것은 작업 속도를 느리게 하니까요.
음... 어쩌다 보니 나는 허덥한 코더다...를 아주 자세하고 길게 서술해 버렸는데...
한국에서 먹고 살려고 노력하다 보니 이리 되버렸습니다.
저두 대학때 SE배우면서 '그래, 바로 이거야...여태껏 난 너무 무식하게 코딩했어'
라며 무릎을 칠 때도 있었는데.. T_T
말씀들이 분분하군요..언제나 그랬듯이...울 나라 코드들의 특징인
말씀들이 분분하군요..언제나 그랬듯이...
울 나라 코드들의 특징인듯 보입니다. 울 나라, 코드들...저도 3년정도 했었는데..지금은 잠시 보류중이지만...문서화는 참..힘든 일입니다..그리고, 잘들 하지 않습니다..외국의 사례는 제가 일해보지 않아서 뭐라고 말하지 않겠습니다..다만, 울나라 사람들이 외국에 나가면 졸나게 고생하는게, 바로 문서화, 요구분석에서 딸린다고들 말하더군요..
친구놈이 외국에서 코드로써 일할때였습니다..
( 참고사항 : 어디까지나, 모든 회사가 같지는 않습니다. 울나라 중에도 문서화 잘 하는 회사 많습니다..저희 회사도 장난아니게 잘 합니다..처음 왔을때, 정말 기겁할 정도였으니까...프로젝트 하나 가지고, 세미나도 졸나게 많이 합니다...흘흘....회의는 당근 다반사고.. )
2년짜리 프로젝트에 참가하게 되었다고 합니다...정확한 일은 잘 모르겠는데, 처음 10달동안 이놈의 양키놈들 코딩한줄 안했다고 합니다...첨에는 그 친구 인터넷 졸나게 뒤지면서 관련 자료들 소스들 졸나게 모으고, 미리미리 코딩했다고 하더군요....그런데, 이 양키들은 정말로 코딩한줄 안하고, 온통 찾는것이라곤, 해결책에 대한 원론 적인 문서들만 졸나게 찾더라더군요...그러면서 10달 동안 거의 12동안 한 일은 요구분석인였다고 하더군요...흘흘...울나라 같으면 말도 안되는 애기죠..하하하...
이건 농담이 아닙니다...물론, 다시 강조하지만, 다 그렇치는 않습니다...
그리고, 나서야...1년을 넘기고, 문서가 무려 몇천장이나, 만들고 나서야 직성이 풀렸는지...해당 업무를 나누고, 업무와 관련된 함수들, 모듈...모두 분배를 했다고 하더군요..물론, 그전에, 함수에 사용될 인자하나 하나 까지 설명이 잘 되어 있었고..(문서에) 역활은 당근이고, 흐름도, 모든게 다 기록이 되어 있었다고 하더군요..그 친구...졸나게 어려웠다고 합디다..
지놈은 맨날 테스트 하고...디버거 하면서 그 짓을 했는데..이 양키놈들...코드 한줄 안 만들고, 그걸 다 했다고합니다..
그리고, 딱 3개월만에 프로그램 만들어서 완성했다고 하더군요..그리고, 테스트 기간만 무려 3개월....디버깅 하고..해서 1년 10개월 정도 되니...거의 완성이 되어서, 그때부터..또 문서작업 했다고 합니다..크크크크..
장난이 아니더군요..애기들어보니....2년 프로젝트에서 실제 코딩 기간은 3-4개월이 다였다고 하더군요...푸하하하하..
웃긴 노릇이죠..그런데, 유지보수가 졸나게 쉽다고 하더군요...왜냐면..
너무나도 체계적으로 잘 만들어서져서리...푸후후후....
호환성/확장성은 기본이고, 매뉴얼부터 시작해서...변수선언된 하나까지
모든 설명이 문서화 되어 있으니...누가 백업을 받더라도 다 할수 있겠져..당근.....
이게 외국의 스타일이라고 친구놈이 입에 침이 마르도록 애기하더군요.
물론, 여기에 올라온 글들중, 흐름도, UML물론 이건 다 포함된 애깁니다..기본이죠......이거 못하는 사람은 이것부터 공부하시길....권고합니다..실은 저도 UML공부한지 얼마되지 않습니다..
버전관리도 좀 아셔야 하구요....제대로 할려면 해야 할일도 좀 많지요..공부할것 보다는 노가다 성의 잡무들이.하하하...
자신을 단순히 코드로 만드느냐..진정한 프로그래머가 되느냐는 이런 아주 사소한 것들입니다..하지만, 정말로 중요한 것들이죠....아직도 코드로 남고 싶습니까?????
저의 개인적인 주장입니다..
코드 = 단순 노무직
프로그래머 = 진정한 프로라고 말입니다....
반대하시는 분들도 계시겠지만...이건 제 생각이니까요..리플은 좀 삼가해 주셨으면...^_^;...
마지막으로, 울나라에도 좀 빨리 이런 문화가 정착되었음 합니다..
말없이 모니터만 쳐다보며...혼자 하는 코딩은 정말 코드가 되는 지름길이란건 잊지 마십시요...혼자서 얼마나 큰 프로젝트를 수행할 수 있을것 같습니까..??? ....여럿이 할때도 그러하실지..후후후..잘 돌이켜...자신을 생각하시고, 추스르시길....바랍니다......
저역시 항상 애쓰고, 노력하는 사람입니다..
그럼...
답글 달아 죄송합니다.친구분이 예기하신 걸소프트웨어 공학이
답글 달아 죄송합니다.
친구분이 예기하신 걸
소프트웨어 공학이라고도 하지요..^^;
많은 사람들이 알지만...
하지 않는것...
^^;
그럼.
http://redage.net
크흑...저도.. 그냥.. 쌩 노가다.. 일단.. 에디터 열고 시
크흑...
저도.. 그냥.. 쌩 노가다..
일단.. 에디터 열고 시작!
했었는데...
이번에 새로 맡은 건... 우어어억...
1주일 정도 하다가... 접어놓고..
플로우차트 그리고 있어요...
그러고나서.. 노트만 수십장 쓴듯...
(이건 이렇게 이건 이렇게.. 하고 써놓은 것만.. 으악!)
정말.. 나 자신을 위해서도..
문서화는 필요합니다...
문서화를 하지 않으니..
중간에 자꾸 방법이 바뀌려고 해서.. -_-;;;
ㅇㅜ ~~ㅇ기냥 허접 프로그램은 암 준비없이 짜구여~~ 님 같
ㅇ
ㅜ ~~
ㅇ
기냥 허접 프로그램은 암 준비없이 짜구여~~ 님 같이~~ ㅎㅎ
돈되는 프로젝트면..
준비물:
샤프펜슬, 지우개, 볼펜, 빨강볼펜, 초록싸인펜, A4지 여러장, 유사 프로젝트 백업소스, 셰어웨어 에디터 최신본(한달짜리),
레퍼런스(기초도서1~2권), 이전 프로젝트 작업문서, 프로젝트를 위한 북마크편집(참조용),
MP3 CD 몇장, 유서, 사발면 한박스, 근처식당 식권 몇장, 수건, 면도기
가족사진, 알람시계, 핸폰 충전기, 성인잡지, 게임기... 또 머가있지?
하여간..
작업 순서는.. 그림그리기 부터..
1.전체 밑그림그리고
2.상세 블럭 그리고
3.DB나 로직 설계
4.UI설계(피씨용 어플이던 웹이던)
5.이전 작업 문서 참조(문서작업용)
6.기초 문서 작성
7.라이브러리, 주요 모듈 임포트(이전작업 또는 작성해서)
8.코딩 --> 이 단계만을 위한거라면.. 그냥 짜져.. 뭐.. vi던 notepad던..
9.컴팔..스크립팅.. 확인
A.짜 맞추기, 끼워 맞추기, 잘라 붙이기
B.동작확인
C.수정 및 확인
D.검수
E.지겨운 Documentation..
F.납품 (또는 설치)
....
다른분들은여? 비슷하지 않나?
중노동에.. 가족과의 생이별에..
쥐꼬리만한 노동의 댓가..
일감만 구준히 있다면.. 차라리 프리랜서가 나은데.. 요즘은 아니구..
희유~~
차라리 고시공부할껄..
쓰다보니.. 한숨만..
예~~
저 같은 경우 프로그램을 작성하기 전에 전체적인 아키텍처에 대해 생각합니
저 같은 경우 프로그램을 작성하기 전에 전체적인 아키텍처에 대해 생각합니다. 즉 내가 해야 할 부분이 전체 시스템의 어느 부분이며, 이 부분을 연동해야 하는 부분이 어디인지 그리고
여유가 있다면 향후 확장에 대해 되도록이면 유연하게 프로그램을 짜려고 노력합니다...
음...
프로그램을 짤때 가장 먼저 생각해야 할 부분은
이 프로그램이 어느 정도까지 지원을 해야 할지에 대해
프로그램의 범위에 대해 먼저 정의하는 것입니다.
그리고 둘째로 전체 아키텍쳐에 맞게 작성하는지
그리고 아래의 분께서도 말씀하셨듯이 되도록이면
쪼개서 재활용 가능하도록 하는 것입니다.
제가 게을러 같은 부분을 되도록이면 다시 짜지 않을려고
하기든요.. ^^
그러다 보니 쪼개면 재활용이 쉽더군요...
그럼...
쪼깨는 것도 방법이져.어떤 문제가 있으면 그 문제를 세부적인 문제로
쪼깨는 것도 방법이져.
어떤 문제가 있으면 그 문제를 세부적인 문제로 잘라놓고,
그걸 하나하나 정복해가는 겁니당.
Divide and Conquer라고도 하져 XP라는 방법론에서 강조하는 내용인데.
나누고 해결하고 합치고, 이걸 반복하는 방식입니다.
... 연습장 많이 필요함.
저야 머 만들려면 밤샘대비 체력비축하고. 담배사놓고. 그리고 편안한 옷을 준비하져 ^^
Let's be engineers!
여기도 여러 시행착오를 겪으신 경험 많은 프로그래머가 많은거 같습니다.
여기도 여러 시행착오를 겪으신 경험 많은 프로그래머가 많은거 같습니다.
글쎄여. UML도 좋고... 객체 지향소프트웨어 개발 방법론이라는것도 많이 알아야 할거 같더군여.
문제는 처음부터 너무 무식하게 짜내려 가는 어리석음은 안해야 한다는건 그냥 누가 가르쳐 주지 않아도 대충은 알거 같군여. 누구나 마찬가지겠지만 설계 방법론이 얼마나 개발하는데 중요한가를 다시금 새삼 깨닫게 할테니깐여. 자바 프로그래머로서의 얘기였습니다.
제가 볼땐 원서를 많이 참조해 보세요.. 여러 좋은 책들이 많더군여...
알고리즘, 데이타 스트럭쳐, UML등 여러 좋은책들이 많은거 같아여...
많이 조직화된 모형과 그렇지 않은건 다 지어놓고서 판가름 나겠지여.
계산기,반으로 자른 A4 이면지 수십장연필, 지우개, 영한사전, 한영
계산기,반으로 자른 A4 이면지 수십장
연필, 지우개, 영한사전, 한영사전 -_-;;;
기도합니다.
기도합니다.
전 PHP+DB 쪽이라서 그런지생각하고 DB설계 하는 시간이 50
전 PHP+DB 쪽이라서 그런지
생각하고 DB설계 하는 시간이 50% 정도의 시간을 차지하고
30% 는 알고리즘 20% 정도가 코딩하는 시간입니다..
코딩을 빨리하는게 아니라 다른 시간이 길죠 ^^;;
날밤을 새기위해 잠을 잡니다. --;;콜라와 담배를 준비합니다.
날밤을 새기위해 잠을 잡니다. --;;
콜라와 담배를 준비합니다.
전 라면과 커피를 +_+
전 라면과 커피를 +_+
저두 전산관련을 전공하지 않아서알고리즘이나 구조론등을 배운 적이 없습
저두 전산관련을 전공하지 않아서
알고리즘이나 구조론등을 배운 적이 없습니다.
그리고 우리나라에서는 웬만큼 큰 기업에서도,
그리고 정말로 큰 프로젝트를 하기전에는
그렇게 플로차트나 프로그램 설계도를 만들거나
혹은 문서화해서 두는 경우가 거의 없습니다.
프로그램의 알고리즘을 문서화하거나, 프로젝트 제출시에 제출하는 경우가 거의 없습니다.
이게 문제인데,,
순서도 혹은 구조도, 차트 등의 문서가 필요한 이유는
자신이나 자신의 팀이 어떤 프로젝트를 진행시키면서
의사소통이나 진행을 위한 것이 절대 아니라는 것입니다.
그건 약간의 부수적인 면이 더 강하다고 할 수 있습니다.
정말 중요한 목적은,
시간이 지나거나, 팀이 해체되거나 혹은 다른 팀이
그 프로그램을 수정할 때, 그 때 도움이 되고자 하는 것입니다.
제 경험상 이런 문서를 만들어 주는 곳은 거의 없더군요.
물론 프로그램의 메뉴얼들은 있습니다.
이건 형식적이나마 해주긴 해주는데, 그건 운영자를 위한 것이고...
실제 프로그램의 운영이 아니라 유지보수를 위해서라면 즉 프로그래머를 위해서라면,
최소한 플로차트 정도는 있어야죠.
아마도 보통 프로그래머들은 다른 사람이 작성한 프로그램을 보수하다, 결국은 지쳐서 새로 짠 경험이 있을 겁니다.
저도 그럴 때 참이라는 소리가 목에 메인 적이 많습니다.
.....
제대로 작성한 알고리즘은 잘 짠 프로그램보다 가치가 더 높다는 말을
어디선가 들은 것 같군요. 그 알고리즘만으로 노벨수학상인가를 받고 특허까지 있다고 알고 있습니다.
프로그래머는 코딩이 아니라 생각할 수 있는 능력이 더 중요하다고 합니다. 작은 단 10줄짜리 프로그램이라도 알고리즘을 구상하고 문서화해야 합니다. 꼭..
자신이 프로그래머로 생을 유지할 것이라면?
싸구려 코디너가 되지 않으려면!
말이 길어 졌군요..죄송.
노벨 상엔 수학상이 없습니다. :)
노벨 상엔 수학상이 없습니다. :)
노벨에 수학상이 없다는 것은 치명적인 오류로 여겨지고 있습니다.노
노벨에 수학상이 없다는 것은 치명적인 오류로 여겨지고 있습니다.
노벨과 사이가 안좋았던 사람이 수학에 매우 뛰어나서
만약 노벨 수학상을 만든다면 그 사람이 받아야 될 상황이었다더군요.
그래서 노벨은 수학상을 빼 버렸다고 합니다.
이런것에 개인적인 감정이 섞였으니....쩝....
그래서 노벨 수학상 대신 캐나다의 필드상(?)이던가 하는 것이 있다고 들었습니다.
전 자바 프로그램을 주로합니다. 그러다보니 UML를 많이 이용하지요.
전 자바 프로그램을 주로합니다. 그러다보니 UML를 많이 이용하지요. 일단은 객체지향적인 분석 설계가 쉬어지고, 프로젝트가 길어질경우 프로젝트의 일관성을 유지시켜 줘 도움이 많이 되더군요. 디자인 페턴도 분석과 적용이 쉬어져 보다 나은 객체를 만들수 있죠.
요즘 많이 느끼는 건데 초기 요구분석이 정말 중요하던군요. 작은 프로그램이라면 별 상관없겠지만 지속적이고 계발기간과 유지보수 기간이 길어 질수록 초기 분석과 분석이 중요해 집니다. 처음부터 코드를 만든다는 것은 지아무리 천제라도 좋은 프로그램을 만들지 못할 겁니다. 시간이 걸리더라도 보다 많을 분석 시간을 가지고 설계구현 해야 한다고 생각합니다.
저 같은경우는 좀 시간을 활애하죠대부분의 코드들이 그렇겠지만 이렇습니
저 같은경우는 좀 시간을 활애하죠
대부분의 코드들이 그렇겠지만 이렇습니다
첫번째로 이건 중요하다고 생각하는데 먼저 자신이 만들 프로그램
이 무엇을 정확하게 할것인지를 확실하게 정의하는거죠
만약 이렇게 확실해 해 두지않고 코딩부터 해버리면 님도 아실거에요.코딩하면서 아 이거좋겟다 싶어서 코드 넣어버리고 그렇게
이거 저거 끼우다 보면 소스가 엉망이 되게 쉽죠.그래서 입출력
부분이나 자기가 사용할 알고리즘을 같은걸 코딩중에 변경할 필요
없이 정확하게 연습장에다 적어두는거죠.
그 다음 두번째로 자신이 사용할 사용자 함수들의 이름을 죽 써놓습니다.그리고 그 함수들이 뭘 할건지를 대충 적어두고 만약 분활
컴파일하실게 아니라면 함수이름하고 블록만 써서 소스화일자체를
한번 그려보죠.저 같은경우는 작은 프로그램이라도 분활컴파일을
하기 때문에 저딴게 필요는 없습니다.이게 버그 잡기도 편하고..
그리 큰 프로그램이 아니라면 이정도면 전 충분하다고 생각은
합니다.이 정도 계획잡는데 많아봐야 30분정보다 활애하면 될끼고
순서는 그리 중요하다고 생각은 하지 않지만 텍스트 코딩할때는
역시 만들 프로그램이 무슨 프로그램인지를 정확하게 그려보고
그리고 그 프로그램을 어떻게 구현할지를 그려보는면 끝이죠
저 같은 경우는 프로그래밍전기획서랑 DB설계 해놓은것을 서류로 만들어
저 같은 경우는 프로그래밍전
기획서랑 DB설계 해놓은것을 서류로 만들어 가지고 있습니다.
여러명이 작업하는 거라... 혹시 의도와 다른 방향으로 갈수
있기때문이죠... 처음에는 그냥 머리속으로 계산하면서
프로그래밍을 했거든요..
나이가 먹다보니(ㅠ.ㅠ) 잘 기억이 안되서 요즘은 서류를 많이
남기는 편입니다.
여러분들이 말씀하신 내용 충분히 공감합니다.한마디 더 보태자면,그
여러분들이 말씀하신 내용 충분히 공감합니다.
한마디 더 보태자면,
그 문서화 조차도 경험입니다.
여러번 시행착오를 거치면서
구조화하고,
함수와 구조체들을 적절히 포장하는것,
모두가 경험입니다.
수많은 시행착오로부터 얻어지는 자신만의....
잘 짜여진 프로그램은 그 자체로 문서가 됩니다.
난 언제쯤이나 프로그램 자체가 문서가 되는 경지가 될까요... -_-;
bottom-up 코딩 -> 한계를 느낌
-> 종이에 그림 그려서 그거 보고 코딩 -> 점점 숙달
-> 그림 그릴 필요가 없어짐 -> 소스 자체가 문서인 경지
난 bottom-up 코딩에서 한계를 느끼는 정도이군요 -_-;
걍 자기 편한대로.....>.<;;
걍 자기 편한대로.....>.<;;
프밍에서의 문서화는 두말할필요 없습니다.무조건 필요하며 그 효용성
프밍에서의 문서화는 두말할필요 없습니다.
무조건 필요하며 그 효용성은 경험해본사람만이 압니다.
백문이 불여일견 머 직접체험해보세요...
프로그램 제작초기부터 문서화에 길들여진 프로그램은 그만큼 손도 덜가고 깔끔합니다 하지만 문서화에 길들여지지 않은 프로그램은 손도 많이 가고 좀 지저분해지는 경향이 많아지죠... ^^;
프로그램의 개요 , 필요기능 , 운영환경 , 함수목록 , 등등........ 필요에의해 만들어지는 문서들은 만들면 만들수록 그수를 헤아릴수는 없을겁니다. 하지만 문서의 수량을 조절하는건 순전히 프로그래머의 자질 차이라고 생각하니까... ^^;
참고로 전 프로그램을 만들기전 전엔 저위분이 말씀하셨듯이 그냥 읇조리듯이 써내려갔었습니다. 그런데 언제부턴가는 플로차트로 그려나가는게 편하더군여.. 그리고 그 플로차트를 기반으로 새로운 분서를 또 만들고 그문서엔 필요한 함수 변수 기능등을 나열하고 그런것들이 끝나면 비로서 프밍에 들어갑니다. 그게 나중에 손이 덜가고 프로그램의 해석 및 수정 보완이 편하더라구여... ^^;
이거 다들 아시는 내용을 쓸데없이 나열한거 아닌가 모르겠네여.. ^^;
어설플 프로그래머를 바라보는 썽후니 였습니다.. ^^;
생각나는 대로 써내려가는 것도 좋은 방법이라고 보는데요..실제로 실행
생각나는 대로 써내려가는 것도 좋은 방법이라고 보는데요..
실제로 실행시켜 보기 전까지는 그게 과연 가능한지 모르고, 미처
생각하지 못한 케이스의 발생을 미리 알 수 있습니다.
물론 결국 나중에 코드를 뒤집어 엎어 다시 만들어야 겠지만 그래도
충분히 가치있는 작업입니다.
덩치가 있는 프로그램 만들어 보세요. 그렇게 돼나..절대 못할 걸요.
덩치가 있는 프로그램 만들어 보세요. 그렇게 돼나..
절대 못할 걸요.
소스 전체 크기가 4~5만줄 이상.. 되는거..
혼자 만들어보는 계산기 프로그램 같은거야 생각나는데로 해도 별 다른 문제는
없겠죠. 하지만 팀 단위로 하느 프로젝트라면 얘기가 확 바뀌죠.
생각나는 대로 써내려간다. 1000라인정도 짜리는 가능할것도 같네요.
문제는 그러한 문서들에 맞춰 개발을 했을때, 사용자가 한번에 만족하는게
문제는 그러한 문서들에 맞춰 개발을 했을때, 사용자가 한번에 만족하는게 아니라는거죠, 대부분,정말 대부분의 경우 프로그램이 수정되는것 같습니다.
문서화를 요구하는 프로젝트가 아니라면, 최대한 문서화 하지 않고 싶습니다. -_-
그래도 개발 전에 문서화를 하고 그것을 갖고 사용자를 최대한 설득한 경우
그래도 개발 전에 문서화를 하고 그것을 갖고 사용자를 최대한 설득한 경우..
수정 요청이 적은 편입니다.
사용자는 개발자가 아니므로 당연히 개발자가 작성한 문서를 이해하지 못하고
이해하려고 하지도 않습니다.
열심히 설명해서 조금이라도 이해하게 해주고 나면..
나중에 개발하기가 참 편합니다. -_-; 뒤통수도 좀 덜때리고요..
문서화는 개발자가 필요해서 하는 작업이지 사용자가 원해서 해주는 작업이
아니라는 이야기를 하고 싶었던건데.. 제대로 적은건지 모르겠네요.
좋은 하루 되세요.
문서화의 필요성에 대해선 전적으로 동감 합니다. :)
문서화의 필요성에 대해선 전적으로 동감 합니다. :)
간단한 20페이지 정도의 홈페이지를 맹그는데도...엄청난 양의 문서가
간단한 20페이지 정도의 홈페이지를 맹그는데도...
엄청난 양의 문서가 소요됩니다.
작업전, 작업중, 작업후...
적을 것들..준비할 것들 엄청나게 많이 있습니다.
플로우차트 있음 작업할때 편하구..
함수 명세서(전 일케 부릅니다만..)있음 정말 편하구...
프로그램 구조를 대강 그려놓은 거
있음 또 편합니다.
취미로 플밍하려는데 이정도면 충분하다구 생각됩니다.
직업으로 하신다면...
헉..책한권 사서 보시는 것이..^^;
근데 이런거 관련된 책은 번역본이 드물다는 것이...
문제이긴 합니다. ^^;
그럼..이만..
꾸벅.
http://redage.net
근데 플로우차트가 머에여?-_-a
근데 플로우차트가 머에여?-_-a
--
나는 언제나 하이파이브에 목마르다.( 유수영, 2002 )
플로우 챠트 = 흐름도.프로그램의 대강의 흐름을 잡아주는 것...
플로우 챠트 = 흐름도.
프로그램의 대강의 흐름을 잡아주는 것...
네모, 마름모꼴 같은 것들이 선들로 이어져 있는..^^
http://redage.net
음..그럼 순서도랑 같은 말인가여?제가 순서도는 볼 줄 모름니다만
음..그럼 순서도랑 같은 말인가여?
제가 순서도는 볼 줄 모름니다만은 순서도가 네모, 마름모꼴 같은 것들이 선들로 이어져 있어서 프로그램의 흐름을 알아 볼 수 있다는 거는 아는 데... ^^;;
--
나는 언제나 하이파이브에 목마르다.( 유수영, 2002 )
마자요..플로챠트 = 순서도..제가 괜히 이상한 용어를 써서리..
마자요..
플로챠트 = 순서도..
제가 괜히 이상한 용어를 써서리..-_-;
지송..
http://redage.net
아녀 제가 무식해서리... -.-;;
아녀 제가 무식해서리... -.-;;
--
나는 언제나 하이파이브에 목마르다.( 유수영, 2002 )
일반적인 개발방법론을 공부해 보세요.SDLC(Software Deve
일반적인 개발방법론을 공부해 보세요.
SDLC(Software Developement Life Cycle)에 관한 거요.
정보공학 방법론과 객체지향 방법론의 차이가있지만 취향에 맞게 선택하고요.
제일 중요한 것은 Goal과 Objective를 정하는 것입니다.
대부분의 문제는 이걸 제대로 안해서 발생하거든요.
다음으로는 자기가 사용자의 입장에서 요구사항을 리스트업해보라는 겁니다.
그뒤의 기능분석,설계,코딩,테스트등은 상식적인 것이니까 생략...
저도 밑에 분들과 비슷합니다.프로그래밍은 글쓰기와 비슷하다고 생각
저도 밑에 분들과 비슷합니다.
프로그래밍은 글쓰기와 비슷하다고 생각합니다.
1000줄 이내의 코드도
계획을 세워서 짠 거와 그렇지 않은 것의 차이는 엄청납니다.
학교 다닐 때 국어시간에 꼭 글쓰기 전에 개요를 써라고 하는게
엄청 짜증났는데..
지금 생각해보니 그만큼 중요한 게 없더군요.
저는 다음과 같은 식으로 합니다.
1. 우선 이 프로그램의 목적이나 갖추어야 할 기능 등을
하나하나 써내려 갑니다. (그냥 말하듯이..)
2. 그 기능들을 구현하기 위한 방법을 생각합니다.
자료구조나, 객체, 함수 사이의 연관성을
그림으로 그립니다.
3. 각 객체 혹은 함수에 대한 인터페이스를 정의합니다.
(이걸 깔끔하고 완벽하게 해 두면 여러모로 편하더군요..
특히 혼자가 아닌 여럿이서 작업할 때는 필수적으로..)
4. 복잡한 객체 혹은 함수에 대해서는 순서도같은 것도 만들어 봅니다.
하나하나 자세하게 그리지는 않고..
최대한 서술식으로..
5. 윈도우 프로그래밍일 경우에는 각 component들과 layout을
상당히 상세한 정도로 그려봅니다. 그리고, 그 component들의
계층관계도..
이제 실제로 3, 4 번을 참조하여 코딩에 들어갑니다.
코딩하다 보면 생각지 못하던 문제가 발생할 수도 있는데..
그럴때에는 다시 3, 4 번으로 돌아가서 고칩니다.
좀 귀찮을 것 같지만 이런식으로 2, 3번 정도 loop -_-;를 돌면 그 다음에는
별 문제가 생기지 않더군요..
프로그래밍은 예술이다.전 프로그램짜기 전에 생각부터하죠.제 머리가
프로그래밍은 예술이다.
전 프로그램짜기 전에 생각부터하죠.
제 머리가의 메모리가 64Kb도 안되는 지라... 아주 단순하면서
명료하게 생각을 하고, 아무것도 없는 선이 점은같은게 전혀 없는
A3나 A2용지에 삼색펜을 옆에 놓고 예술을 합니다.
전 그림 그리기라고 하는데, 프로그램의 전체적인 아웃라인과
자료처리시 메모리사용구조 설계등 여러가지를 하죠.
이거 그리는것만 한 3~4일 걸립니다.
그리고 나서 그 그림을 토대로 다시 정리해서 또 그림을 그리죠
그걸 보면서 코딩합니다.
저도 가급적 .B Kluz 님이 하시는 방법을 따라가고자 합니다. 간
저도 가급적 .B Kluz 님이 하시는 방법을 따라가고자 합니다.
간단한거야(사실 아직 복잡한것도 해본적이 거의 없긴하지만) 대충 네모와 선을 조잡하게 그리는것으로 가능이야 하겠지만, 확장하려고 한다면 전혀 손을 댈 수가 없더군요. 결국 처음부터 노가다 작업을 하는 방법외에는 없더군요.
습관은 들기 마련이듯이, 가급적 잘 그리지는 못하는 그림이라도 몇개 그려놓고 모니터 옆에 덕지 덕지 붙이면서 하려고 한답니다.
댓글 달기