제가 공부했던 방식이 좋지 않은 방법이었다는걸 알게 되니까 이때까지 뭐한거지..라는 생각도 드는군요..
제 공부 방식이..
문제를 보고 대략적인 알고리즘을 떠올립니다.
그 알고리즘을 바탕으로 생각나는데로 코딩을 쭈우욱 해요.
얼추 코딩이 끝나면 프로그램을 돌려봅니다.
잘못된 값이 나오면 코드를 읽어보면서 수정해나가고..
원하는 값이 나오면 코드 분석.
이해가 안되면 구글링..
이런 형태였기에 프로그래밍하는데 시행착오도 많고, 처음부터 원하는 값이 나오기가 힘들었죠..그리구 코딩한게 맞는지 점검을 계속 해본다는거..
허나 중간고사는 코드를 손으로 종이에 쓰라고 하더군요..ㄷㄷ
그렇다보니 제가 종이에 작성한 코드가 완벽하게 돌아가는지 확신할 수가 없었고..결과도 좋지 않았죠..
처음부터 완벽하게 코드를 쭈우욱 작성하기 보다는 생각나는데로 구성을 얼추 해보고 점검하면서 코드를 보안해나가는 방식이었던지라..점검이 안되면 코드를 완벽하게 쓴다는게 불가능..
그나마 자신있던 전공 과목이 이 모양이니 멘붕와서 외삼촌께 하소연을 했습니다..
그랬더니 이 방법이 잘못된 방법이니 보안해야할거 같다고 하시네요..
머리 속에서 프로그램 알고리즘을 완벽하게 구현하는게 자신이 없어서 택한 방법이 오히려 독이 된거 같습니다..ㅠㅠ
하..시험 보고 나니까 제 문제점을 찾아가는건 좋은데..
중학생 때부터 익혀온 방식이다보니 고치는게 쉽지가 않네요..ㅠㅠ
지금은 주석 기능으로 프로그램 설계를 나름대로 적어보고 나서 그걸 바탕으로 코딩하는 방법을 연습하고 있는데..
귀찮게 순서도 같은거 언제 그리고 앉았습니까(...)
지금 하시는 방법이 꼭 잘못된거는 아닙니다
머리로 고민만 하는 분들은 최적화, 퍼포먼스에 강점이 있긴한데 느리더군요.
예외적으로 선언형(함수형/논리형) 언어의 경우는 머리속에서 작성이 끝나야 코드작성이 가능한 그런식이긴 합니다.
습관만 잘 개선하면 오히려 잘 짜실듯 하네요
시게되면 요세 기업에서 알고리즘 시험 보는데 많이 늘어나고 있습니다 머리에서 대략 생각하고 코딩 디버깅 만 하시는분들은 은근 이런 시험에 약하고 필드에서 아애 무에서 분석설계해서 프로그램밍에 약합니다 여튼 화이팅 하세요 IT경력 10년차로써 설명 드립니다
차이점이 있다면 프로그래밍하기 전에
알고리즘 구조를 얼마나 더 넓게 세밀하게 생각하냐에 차이일 뿐입니다.
원래 알던 방식으로 알고리즘을 더 구체화시키고 더 넓게 발전시키면 됩니다.
그냥 함수나 파일 앞에 코멘트로 처리할 기능을 코딩할 순서대로
1.
2.
2-1.
2-1-1
3
3-1
(1)
(2)
뭐 이렇게 해서 의식의 흐름대로 적어놓고 코딩 하네요
그래서 첨에 제대로 된 설계를 하는게 중요합니다.
그냥 바로 코딩 들어가기 시작하면... 모듈이라는게 존재하질않으니 뭐 하나 고치면 다 뜯어고쳐야되죠.
로직 완성도를 올리는데 노력해야겠군요..
저도 오래 되다 보니 쓰던거 쓰려는 습성이 강해져서.. 그런데 개발자들은 그러면 안된다고 봅니다.
목적에 따라 다른거죠.
회사에서 기일에 맞춰야 하는건지
취미생활로 하는건지 등등
코딩 방식론이야 어느것이 효율적이다 하며 매번 찾는거지요.
동작만 잘한다면 방식은 여러가지 일듯 합니다 ㅎ
1. 대략적으로 큰 그림 그려가면서, 변수지정, 조건문..등등을 한글로 주석문을 작성
2. 반복문, 조건문, 예외.. 얘네들은 큰 번호로 주석처리 합니다. 1, 2, 3
3. 2번에서 안쪽으로 들어가는 처리문들은 소번호로 주석처리 하죠. 1.1, 1.2
4. 한참 하다보면, 한글로 프로그램 짜는 듯 한 착각에 빠집니다.
ㅡㅡ ;;
1. 로직생각하면서 바로 함수나 클래스 인터페이스 부분만 작성
2. 경계부분 테스트케이스 작성
3. 테스트케이스 보면서 함수 작성
4. 수시로 함수, 변수명 리팩토링
이렇게 하네요.
요래하면 로직은 생각하면서 시간도 아낄 수 있더라고요.
단박에 완전하게 잘 도는 코드를 짜는 사람은 없다고 봐야...
구조적설계론이나 객체지향론 하나를 선택하셔서
C 개발자이시면 구조적설계로 Dataflow Diagram이나 Flow chart, sequence diagram등을 활용하여 본인이 작성하는 코드를 구조화 하시고 그 안에 들어가는 알고리즘을 flow chart로 도식화해보세요. 디버깅할때도 코드를 막연히 쳐다보는거보다 다이어그램으로 논리적 오류를 파악하고 그다음 코드상으로 비교해나가는것이 디버깅이 빠릅니다. 이렇게 설계 단계를 무시하고 개발을 하게 되면 간단한 프로그램조차도 버그를 양산하게 되고 말씀하신것처럼 시스템화 되지 못한 프로그래밍을 하게 되는것이지요.
걱정 마세요. 하다보면 늘어요.
코딩만큼 재미있는게 없죠. 재미있게 하는게 중요해요.