UML이나 개발 방법론같은건 언제배워야 할까요?
음.. 저는 전산과를 다니고 있지만 프로그래밍 실력은 형편없습니다.
대신에 서버나 네트워크쪽을 만지는걸 좋아하지요..
그러다보니 학과공부는 안하고 엉뚱한 짓만 하고있는것같습니다.
다른게 아니라, 절실한 필요에 의해서 휴과관리/당직관리 프로그램을 개발하려고 생각했습니다.
비록 프로그래밍 구현능력은 떨어지더라도 이것저것 알아봤더니 생각보다 꽤 많은 방법이 나오더군요.
휴과관리 <-> 당직관리 프로그램을 모듈처럼 만들어서 연동시키려고 생각하여, 웹프로그래밍을 해야할것같다는 생각이 들었습니다.
뭐라도 해보려고 열심히 자료를 모았는데, 정작 이것이 머릿속에는 어떻게 해야할지 생각은 되지만,
이걸 어떻게 구현하느냐는 큰 문제더군요.
그러다보니 아주 옛날에 배운 플로차트 같은 일종의 개념을 도식화하는 법이 필요하게되서 찾아봤더니
UML이라는 제법 몸집큰 것도 나오고, 개발 방법론이란것도 나오고- 이것저것 검색되더군요.
얌전하게 처음부터 다시 책보며 하나하나 하고있지만, 언젠가는 저런방법을 배워야 할때가 있을것이란 생각이 들더군요.
프로그래밍 구현수준이 한없이 낮은 제가 개발방법론부터 시작한다는건 건방진 짓인가요?
잘 생각해보면, 옛날에 베이직 배울때도 플로차트로 개념을도식화 하는것에서 출발해서,
뼈와 살을 붙이는 코딩으로 나가는것으로 기억이 나네요..
개인적으로도, 뭔가 추상적인 개념을 눈에 보이는 도식으로 그려놓고 시작하는게 편한것같고요..
언제쯤 시작하는게 좋을까요?
프로그래밍 문법을 다 익힌후에?, 아니면 배우기전에 해도 괜찮을까요?
개발 방법론이
개발 방법론이 님께서 진행하고자 하는 프로젝트에 필요한 것인가요?그 질문을 먼저 해야 할것 같습니다. uml, 개발방법론이 좋기는 하지만, 필요없는 상황도 있습니다.
"잘 생각해보면, 옛날에 베이직 배울때도 플로차트로 개념을도식화 하는것에서 출발해서,뼈와 살을 붙이는 코딩으로 나가는것으로 기억이 나네요.."
이 방법이 오히려 좋아보입니다. 어디선가 주워들은 이야기로는 "말밥을 자신에게 먹여보라"라고 하더군요.(기억이 정확하지 않습니다.) 이 이야기의 의미는 자신이 만든것을 자신이 사용해보면 그것의 문제점들을 잘 볼수 있다는 이야기로 알고 있습니다.
(테스트가 아니라 실제의 상황에서 사용해보라는 이야기입니다.)
봄들판에서다
봄들판에서다
베이직쓰던 때야
베이직쓰던 때야 GUI가 아니니까 사용자의 행동이 어떤 순서로 진행될지 비교적 예측 하기 쉽고, 절차적인 프로그래밍이 대세이므로 플로우 차트를 짜서 하는게 유효했다고 알고 있습니다.
goto가 안좋다는 말도 goto를 쓰다보면 이 플로우 차트에서 이리저리 뛰어댕기고 결국 스파게티코드가 되기 쉽기 때문이란 말도 들은적 있는 것 같습니다.
그런데 GUI프로그래밍같은 경우는 어떤 상황에서 사용자가 취할수 있는 수가 매우 많기 때문에 미리 예측하기 힘들고, 그래서 각각의 구성 요소가 알아서 처리하게끔 객체지향프로그래밍을 한다고 배운것 같은데...이런 경우도 플로우차트가 유효한가요...?
플로우차트를
플로우차트를 goto방식으로 사용하면 문제가 많겠죠.(한여름 망아지 뛰어다니듯한... :) ) 데이터의 논리적 흐름을 그리는데 사용해보면 좋을것 같다는 의미에서 드렸던 말입니다. 생소한 uml을 배우는데 시간을 투자하는것 보다는 익숙한 플로우차트를 사용해 개괄적인 모습을 그려보라는 것입니다.
봄들판에서다
봄들판에서다
프로젝트에
프로젝트에 소스코드버전관리툴을 도입하시는것이 조금더 프로젝트 진행에 도움이 될거 같습니다.
개인이 지정한 디렉토리별로 관리하다보면 차후 코드분실시 난감한 상황이 을왕을왕나오더군요. :)
봄들판에서다
봄들판에서다
프로그래밍에 대한
프로그래밍에 대한 개념만 있으시니 언제든지 방법론 공부를 하셔도 된다고 생각합니다.
개인적인 견해론 프로그램 구현보다는 방법론이나 프로젝트 관리 쪽으로 자신을 차별화시키면 훨씬 더 유리하지 않을까 싶습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
해결할 문제가
해결할 문제가 무엇인지 찾아내고 이 문제를 해결하기 위한 기능을 정의하는 단계가 설계 이전이겠습니다. 이것만 잘해도 어디가서 좋은 대우를 받을 겁니다.
이것 다음에 설계가 이루어질텐데... 제가 조언하고자 하는 것은 설계를 위한 설계가 아니라 문제 해결을 위한 설계를 해야 합니다. UML이 멋진 기술이라서 도입하는게 아니라 지금 해야할 프로젝트를 성공적으로 이끌어가는데 최선의 방법일 때 도입하십시요.
어쨌튼 UML을 배운다는 생각보다는 프로젝트를 성공적으로 만들기 위한 방법을 배운다는 목적으로 공부하는게 좋을 것으로 생각합니다. 이런 내용은 책으로 익힐 수 있고 실제로 작업을 하면서도 많이 배웠습니다. 기본적인 프로그래밍 기술은 반드시 익히도록 하십시요. 실제로 프로젝트에 참여하십시요. 그리고 성공적인 프로젝트를 만들기 위해서 고민하십시요. 이 과정에서 프로그래밍 기술을 비롯하여 전반적인 능력이 향상될 것입니다.
----
내 블로그: http://unipro.tistory.com
내 위키: KLDPWiki:unipro
내 블로그: http://unipro.tistory.com
"사용자 스토리"라는
"사용자 스토리"라는 책을 한 번 읽어보시길 권합니다. 뭔가를 개발해야 하는데 뭘 어떻게 시작해야 할지 모를 때 괜찮은 가이드가 될 겁니다.
댓글 달기