[완료]프로그래머를 꿈꾸는 학생입니다. 프로그래밍스킬에 대해 너무 혼란스럽습니다....
안녕하세요
이제 막 프로그래밍을 공부중인 컴공학생입니다.
나름대로 매일 많은시간을 집중해서 공부한다고 해도 실력이 잘 안느는것같네요...
각설하고...
오늘 교수님께서 과제를 내주셨습니다.
어느 데이터파일에서 데이터를 읽어들여 계산하는 간단한 프로그램입니다.
코딩은 전혀 문제가 안될정도로 쉬운 것이었지만..
문제는 ... 제가 이상한걸까요
전 왠만하면 유동적인 상황에 대처할 수 있게 프로그램을 짜려고 합니다. (물론 잘짠다는 소린아닙니다..)
데이터파일에 얼마만큼에 데이터가있고, 어느 데이터가 있을 지 모르는 일이니
최대한 프로그램이 많은 경우에서 돌아갈수있도록 프로그래밍을 해왔습니다.
그리고 오늘 받은 데이터파일은 몇개의 데이터가 들어있는지 알수있습니다.
근데 오늘 친구가 한걸 봤는데 주어진 데이터파일에서 몇개의 데이터를 읽어들일지 알고있으므로
딱 그만큼만 배열과 메모리를 할당해서 쓰더라고요..
확실히 코드도 간결하고 라인도 짧았습니다.
반면 전 데이터파일이란게 언제든 변할 수 있다고 생각해서(실무경력이 없는 초짜로써 왠지 실무 뛰기 시작하면 수많은 데이터를만지게될것같아서)
자료구조 리스트를 이용해서 수십종류의 데이터를 읽어들일수있도록 코딩했습니다.
여기서 충돌이 생겼습니다.
제 코드는 그 친구에 코드에 비해서 확실히 길고 약간 복잡하더라고요..
나도 몇개의 데이터가 들어올줄아니까 딱 그만큼만 배열선언할까 혹은
데이터는 유동적이니까 몇개의 데이터든 받아들일수 있도록 할까...
교수님도 이미 알고있는 정보를 활용해서 하라고 하시더라고요..
제가 너무 미래지향적(?)으로 코딩하는걸까요. 쓰잘때기없는 걱정으로 코드를 더럽히고 있는건 아닌지 걱정되서 이렇게 질문해봅니다..
어떻게 만들든 모름지기 프로그램이란 잘 돌아가면
어떻게 만들든 모름지기 프로그램이란 잘 돌아가면 장땡입니다.
유동성있게 만들어서 잘 돌아가면 가장 좋지만, 유동성있게 만드느라 마감날짜를 놓친다거나 정상작동을 안한다거나 하는건 나쁩니다.
그 경우에는 유동성을 포기하고 적당히 잘 돌아가게 하세요.
피할 수 있을때 즐겨라! http://melotopia.net/b
당연히 프로그램은 어떻게 짜든 잘 돌아간다는 가정하에서...
어떻게 하든 둘다 잘 돌아간다면... 코드가 좀 길어지고 복잡해지더라도 유동성있게 짜는게 좋을까요?
-_-
Wing_나노님이 잘 하고 계시는거라고 생각합니다.
학부생의 과제에서야 문제가 발생해도 코드를 훑어보고 찾아낼수도 있겠지만, 실무에서 예외처리를 대충 했다가는 문제발생시 그 포인트를 찾아내는데 밤을 새게될수도 있습니다.
예외처리를 철저하게 하시고, 하나의 팁을 더 드리자면, 예외처리시 그곳에 log기록 코드를 추가해넣는것도 좋은 방법입니다.
문제발생시 log를 열어봄으로써, 어디서 예외상황이 발생해서 프로그램이 뻗었는지등을 쉽게 찾아낼수도 있습니다.
물론 그게 좋긴 하죠. 그런데 아마 나중에 돈받고
물론 그게 좋긴 하죠.
그런데 아마 나중에 돈받고 직업으로 프로그램을 만들다 보면, 요구사항에 적혀있지 않은 것까지 세심하게 고려해서 만드는 것이 얼마나 번거롭고 귀찮은 일인지 알게 될 거예요. 왜냐하면, 발주처에서는 요구사항에 적혀있지 않기 때문에 해당 내용에 대해 돈을 더 주지는 않지만 요구사항에 적혀있지 않은데도 불구하고 은근히 고려해주기를 바라고 있거든요.
그런 경우가 아니라면, 발생할 수 있는 여러가지 상황을 가정하고 예외처리를 잘 해주는 것은 좋은 습관이죠.
피할 수 있을때 즐겨라! http://melotopia.net/b
잘만 돌아간다면 짧고 보기 쉬운 코드가 더 좋은
잘만 돌아간다면 짧고 보기 쉬운 코드가 더 좋은 법입니다.
유연하게 작성하는 것은 유연함이 필요할 때나 하는게 맞습니다.
유연하지 않아도 되는 상황에 유연하게 작성하면 그냥 시간낭비라고 봅니다.
차라리, 과제는 빨리해서 내시고, 과제에서 배운 것을 실습할 수 있는 개인 프로젝트를 시도하는게 더 나을 듯 합니다.
프로젝트를 하다보면 자연스럽게 유연함이 필요하게 됩니다.
상상만으로 어떻게 변할지 짐작해서 프로그래밍 하는 것보다는 실제로 문제를 맞딱뜨린 다음에 프로그래밍하는게 배움에도 더 도움이 된다고 생각합니다.
------------------------------
How many legs does a dog have?
실무 입장에서 얘기를 하자면
개발자 입장에서는 "general한 모듈을 만들어야 한다"라고 하고, 사업하는 입장에서는 "일단 돌아 가게 해야 한다" 라고 하고... 지금 학생의 입장에서 느끼시는 갈등(?)은 나중에 현업에 와도 그 의견 차이는 그대로 존재하고 있습니다. 저야 개발자이니까 전자(어느 상황에나 잘 돌아 갈 수 있도록 모듈을 조금이라도 더 완벽해 하고 싶은 욕망)입장이지만요.
중요한 것은 A가 맞느냐, B가 맞느냐가 아닙니다. 그 정답은 사람마다 / 상황마다 / 시대마다 다 다를 수 밖에 없습니다. 이 때 중요한 것이 바로 상대방의 의견을 존중해 줄 수 있는 커뮤니케이션의 능력이죠. 사회 생활은 결국 컴퓨터와 나와의 싸움이기도 하지만, 남과 나의 의견 조율도 그만큼 중요합니다. ^^
ps : 말씀하신 내용(fixed size array 혹은 memory)은 STL(TR1) 만 잘 쓰면 간결한 코드만으로, 그만큼 성능도 나오면서, 개발 기간도 충분히 충족시킬 수 있습니다. 물론 STL을 자유자재로 쓸 수 있다는 것을 가정해야 하겠지만요.
www.gilgil.net
오버스펙은 피하세요.
오버스펙은 피하세요.
오버 엔지니어링은 (실무에서는) 대체로 좋지
오버 엔지니어링은 (실무에서는) 대체로 좋지 않습니다.
하지만 이 경우(학교 숙제)에는 교수님의 성향을 파악하는 것이 우선입니다.
제가 학부시절에 만난 교수님중에 한분은 자신의 생각에 아름답다고 생각되는 코드는 만점에 +20% 가산점을 주셨습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
프로그래밍의 시작은 요구사항 분석
저는 프로그래밍 할 때 제가 정한 5단계 절차를 반드시 지키려 노력합니다.
1. 요구사항분석
2. 입출력설계
3. 알고리즘설계
4. 코딩/컴파일
5. 오류검증/디버깅
이 5단계 절차는 뒷쪽으로 갈 수록 일의 양도 많고 방법도 다양해 집니다.
같은 이유로 앞쪽 절차에서 정했던 내용에 변경이 발생한다면
뒷쪽은 훨씬 더 많은 시간과 노력을 투자해서 그에 맞춰가야 합니다.
그래서
"설계가 가장 중요하다"
"설계에 시간을 많이 투자하고..."
"설계가 변경되지 않도록 최선을 다 해야하고.."
이런 말을 항상 하고 있습니다.
앞선 분들의 말씀 처럼 기초 설계를 너무 복잡하게 하면
뒷 단계에서 불필요한 내용을 너무 많이 담게 되고 분석이 힘들어집니다.
요구사항 분석 단계에서 한 두 가지 정도의 변경사항을 고려하고
설계를 하는 것이 좋다고 생각합니다.
수용하기 힘든 설계 변경 요구가 들어온다면
일단은 협상을 진행하고 (현 단계에서 마무리 or 취소)
프로젝트를 다시 시작하는 것이 좋습니다.
학생이시니 이정도 유연성은 충분히 경험하고 진행할 수 있으리라 생각되네요.
다만... 우리나라 현실은 이렇습니다.
"갑: 이거 이러저러하니 좀 바꿨으면 합니다!"
"을: 음... 이 부분은 요구사항에 없던 부분으로 설계 단계부터...."
"갑: 한번 해 봅시다!!!"
"을: 그럼 설계 변경부터 해서 3주 정도 시간이 필요할..."
"갑: 3주는 무슨... 다음주에 한번 보여 주세요"
웃으라고 하는 얘기니 너무 담아두지는 마세요.
정말 감사합니다.
많은것을 배웠습니다... 좀 정리가 되네요..
댓글 달기