경험을 통해 전하는 개발 노하우
http://www.zdnet.co.kr 의 기사내용 일부입니다. 전체 내용은 관련 링크를 참조하십시오.
"경험 많은 개발자로부터 나온 최적화된 코드와 초보 개발자의 나열식 코드간의 성능 차이는 그 세월과 경험의 차이다. 숙련자의 수많은 경험은 초보자가 넘볼 수 없는 부분이다. 이런 경험은 스스로의 단련과정 없이 축적하기 힘든 부분이다. 고수 대열에 합류하는 지름길은 다름 아닌 '수많은 좌절과 그것의 극복'임을 이 글을 통해 확인할 수 있을 것이다.
개발자로 살아가는 사람이라면 'Hello World'와 함께 시작했던 추억을 갖고 있을 것이다. 독수리 타법으로 떠듬떠듬 예제 코드를 보고 작성한 몇 줄의 프로그램을 실행한 후 그 결과를 화면에서 보는 순간, '아! 나도 프로그램을 만들 수 있구나'하는 놀라움과 자신감으로 충만해진다.
그러나 이러한 기쁨도 잠시, 좀 더 깊은 내용의 예제를 접하고, 수십 개에서 수백 개에 이르는 에러 메시지 속에서 고뇌의 시간을 수없이 보내게 된다. 그러나 몇 날 며칠을 고생하다가 에러를 모두 수정하고 그 결과가 나타난 화면을 볼 때의 흥분은 Hello World 예제의 몇 배에 이른다.
이것을 실제로 경험을 안 해 본 사람은 동감하기 힘들 것이다. 또는 다른 개발자와의 토의를 통해 그 결과를 얻는 시간을 단축해 본 경험을 갖고 있는 사람들은 또 다른 놀라움을...."
이글을 쓰신 분이 나름대로 정리하신 개발자로서의 노하우는 다음과 같네요.
-막힐 때는 주변을 살펴보자
-예제를 통해 배워라
-기획자가 되라
-개발자 커뮤니티를 활용하라
-오랜 경험의 개발자가 필요하다
여러분의 노하우는 무엇인가요?
제가 이런말을 할 처지가 되는 지는 모르지만...저처럼 완전 초보자라
제가 이런말을 할 처지가 되는 지는 모르지만...
저처럼 완전 초보자라면 두꺼운 기초책 한권정도는 보고서 실전에 접해야 할 것 같네여...
처음부터 코딩과 함께 디버깅연습부터 하면은 이 짧은 인생 너무나 아까울 것 같습니다..
기초책 한번정도 보고 자주쓰는 내장함수 수첩이라도 있어야 하지 않을까 생각합니다...
꼼꼼하게 한번보면 전체적인 틀이 짜여 질거라 생각됩니다...
너무 작은것부터 시작할려다보면 조금만 벗어나도 헤매기 일쑤거든여...
초보자라면? 매뉴얼과 바이블 항상 옆에 끼고 다녀야 할 것 같네여...
괜히 언어자체에 부딪혀서 디버깅하기엔 인생은 너무 짧습니다..
경력..10년이 되었다니 엔터프라이즈급 국책 프로젝트에참여했다니..이
경력..10년이 되었다니 엔터프라이즈급 국책 프로젝트에
참여했다니..이런것이 중요한것은 아닙니다.
단 1개월을 했어도 FM(정식)대로 "아"를 "아"로 읽고
제대로 학습을 하고 해야지 비슷하다고 또 효율이 높다고
"어"로 발음하는식으로 자기 노하우를 만들다가는
인간의 기억력의 한계로..나중에 큰 한계에 부딫치게 되고
결국 뿌리는 깊지만 길게 뻗어진 잔뿌리인걸 스스로 알지
못해서 그런데로 논리적 오류가 생기게 됩니다..
버그? 그건 정말 인간적인 실수이고 착각입니다.
제대로 정식대로 배운 사람이라면 논리적 버그가 발생할
이유가 전혀 없습니다.
(정식대로라는 말이 무슨 전산과 나오고 비트? 인가 그런
학원 거쳤다 그런 말이 아닌.. 글 하나하나 정확한
뜻을 알고 오자 하나 틀리지 않고 제대로 쓴다는 뜻)
코드의 최적화나 효율성의 기준이 아닌
초급자와 고급자의 차이는 이런것입니다.
(외국 유명한 프로그래머가 기사에 소견 적은것입니다.)
베테랑 경력 초급자->
몇번의 버그 수정 ,기능 향상 후 꼭 컴파일 해서
확인작업후 다시 오류수정과 수정된 부분의 문서화 작업
★주로 하는일:새기술 익히기에 부단한 노력
업계 신기술 최고의 지식및 실용기술 구현 보유자
베테랑 경력 고급자->
알고리즘 설계에 따른 정확한 더도 덜도 없는 구현
그리고 설계도 체크에 따른 이삿집 박스만큼의
발생할수 있는 논리오류체크 결과 보고서 샇이고..
제품출시 한달전 5번 이내의 오류발견과 컴파일 끝내고
정확히 문서화에 기재된 내용만 완벽한 기능 구현후
베타버전 발표
★주로 하는일:
언제나 자기언어에 대해서는 책임감을 가지고
신기술보다는 예전에 학습했던 초보자 책을 틈틈히
다시 보면서 장인정신으로 한부분만 계속 파고 드는게
취미
많은 분들이 좋은 말씀을 올려주셨는데 정상적인 개발 노하우를 가진 회사라
많은 분들이 좋은 말씀을 올려주셨는데 정상적인 개발 노하우를 가진 회사라면 뭔가 문제를 발견했을 때,
우리 회사(팀)은 어떻게 대응한다라는 구체적인 얘기로 발전하지 못하고 잘해봅시다~라고 구호만 외치는 것은 문제 해결에 큰 도움이 되지 못한다는 것이 저의 개발 경험입니다.
잘 해 봅시다라는 식의 대응은 같은 실수를 반복하게 함으로써 개발자의 시간과 노력을 헛되이 쓰게 합니다. 결국 밤샘해서 문제를 미몽해버리고, 다시 문제가 도졌을 때는 더 고생하게 되고...
문제에 대한 대응은 case by case로 해야 합니다. 그리고 문서화가 필요하고 이 지식을 공유하며, 신규 개발자가 오면 코딩하기 전에 숙지 시키는 것이 꼭 필요하다고 생각합니다. 그렇지 못하면 병이 또 도지게 되죠.
UML, OOP, 분석툴등이 훌륭한 개선책이 될 수 있지만 이의 장점과 동시에 한계를 인정하고 현실과의 괴리를 제대로 이용하지 못한다면 안쓰느니만 못한 결과를 가져올 수 있습니다.
그게 개발방법론이란겁니다.
그게 개발방법론이란겁니다.
개발방법론과는 성격이 좀 다른것 같군요
개발방법론과는 성격이 좀 다른것 같군요
전적으로 동감합니다.경험상 조직차원에서의 노하우 관리가 되는곳이 거의
전적으로 동감합니다.
경험상 조직차원에서의 노하우 관리가 되는곳이 거의 없더군요.
(겪어본 회사가 두군데이긴 하지만 우리나라의 거의 모든 회사가
그럴거란 생각이 드네요)
바로 할수있는 것과 그렇지 못한것을 부별한다.두가지 경우 모두 간단히
바로 할수있는 것과 그렇지 못한것을 부별한다.
두가지 경우 모두 간단히 테스트 가능할정도의 코드를 만들어본다.
테스트 결과 만족 스러우면 덜 만족 스러운 쪽을 해결한다.
잘 될거 같았는데 테스트 해보니 안될경우가 있을수있고
쉽게 되었다면, 잘 안될거 같은 것을 시도해본다.
가장 어려울거 같은게 무었인지 생각해본다. 일단 해보고 안되면 무었이 안되는지 생각해본다. 주위에 도움을 청할 만한 사람에게 정확히 무엇이 문제이며 어떻게 해결 해야 하는지를 물어본다. 대충 '이거 안되요...'가 아니라 'A를 수행하는 쓰레드 에이전트를 통해서 쓰레드 그룹핑하는거 하려는데..' 하는 식으로 자세히 물어본다.
문제의 힌트를 얻었으면 다시 시도한다.
...
...
위에 과정을 계속 되풀이다한다.
-영희-
저는 단계별로 원하는 결과가 나오는지 검사하면서 진행합니다. 고로 항상
저는 단계별로 원하는 결과가 나오는지 검사하면서 진행합니다. 고로 항상 컴파일이 될 수 있을 정도의 단위로 작업을 하고, 컴파일 해서 오류를 해결하고 진행하죠. 꽤 번거롭기도 하고 오버헤드도 큰 편이지만, 디버거가 좋지 않을 경우엔 이 방법이 최선이죠. 솔직히 VS로는 작업을 안하다가, 얼마전부터 써 오고 있는데 다른건 몰라도 디버거 만큼은 예술이더군요. 디버거가 좋다면야 이런 오버헤드는 줄일 수 있겠죠.
아무생각없이 무조건 코딩부터한다..
아무생각없이 무조건 코딩부터한다..
저두요...하다보면... 이게 아닌데라는 생각이 들때도 있지만....
저두요...
하다보면... 이게 아닌데라는 생각이 들때도 있지만....
쩝.. 그래도.. 프로그램은 완성된다.
공동 작업할 때의 법칙 (4) 전역변수가 없으면 코딩을 못하는 사
공동 작업할 때의 법칙 (4)
전역변수가 없으면 코딩을 못하는 사람들이 있다. 지역변수만으로도 완벽하게 코딩할 수 있음은 누구나가 아는 사실이고, 전역변수가 상용된다는 것은 이런 경우를 창자가 배밖으로 나와 있는것 만큼 위험하다. 어쩔수 없이 빼야한다면... 구조체로 묶어서 빼낼것.
그리고 구조체를 양파처럼 겹겹이 정의하는 사람도 있다. 임시값도 구조체 멤버를 이용하는데 정말 죽음이다. 구조체 따라가다보면 죽음이다. (살의마저 느낀다)
공동 작업할 때의 법칙.. 이란 글로 적혀있는 글들은 경험을 통해 전하는
공동 작업할 때의 법칙.. 이란 글로 적혀있는 글들은 경험을 통해 전하는 개발 노하우란 포럼의 주제와는 핀트가 좀 비껴나 있는 듯한 느낌이네요.. 주제를 코딩스타일과 일치화 하기에는 너무 좁고, 낮은 영역이다 싶기도 하네요..
변수이름 예외나 에러처리등의 코딩스타일의 훨씬 위에서 올바르게 개발하기 위한, 혹은 개발에 있어 문제에 부딪힐 때 해결하기 위한, 혹은 문제에 직면하지 않기 위한이라는 그러한 시야에서 바라보시고 다시 글을 써주시면 어떨까 싶네요~
공동 작업할 때의 법칙 (3) 문법을 정의해서 사용하지 말 것.
공동 작업할 때의 법칙 (3)
문법을 정의해서 사용하지 말 것.
c의 #define문은 양날의 칼과 같아서 잘못쓰면 여러사람 고생합니다. 따라서 사용블럭을 최소화 하는 것도 매너입니다.
#ifndef HELLO
#define HELLO 정의
사용영역
#endif // HELLO
공동 작업할 때의 법칙 (2) if~else좋아하는 초보들이 있습
공동 작업할 때의 법칙 (2)
if~else좋아하는 초보들이 있습니다. 블럭을 피할 수 있음에도 불구하고 블럭을 만드는 바람에 자신을 포함한 여러사람 피해를 줍니다. 예를 들어.
FILE *fp;
fp = fopen("sample.txt", "r");
if (fp == 0) return(-1);
라고 만들 수 있는 코드도 멋있게 짠다고 아래와 같이 만들어 버리면 결국 if가 if를 만드는 모순에 빠져 버린다.
FILE *fp;
if ((fp = fopen("sample.txt", "r") != NULL)
{ ...
}
else
{ return (-1);
}
공동작업에서는 if 블럭을 최소화 하면서 코딩하는 것도 실력중의 하나입니다.
C로 프로그램 해서 먹고 산지가 근 12년이 넘어가고6 명이상과 공동
C로 프로그램 해서 먹고 산지가 근 12년이 넘어가고
6 명이상과 공동 작업한 횟수만 해도 수십번인데
전 아직도 if 문은 블록문으로 항상 둘러 싸 놓습니다.
제 경험상 if 문 단독으로만 쓴다면 모를까..
else 문을 쓴다면 멋으로서가 아니라
디버깅과 방어 코드를 만들기 위해서
블럭문을 사용합니다.
또한 만약 블럭문이 자꾸 들어가는 구조가 발생한다면
3단계 이상 들어 간다면 빼 내야죠...
그걸 그냥 두면 진짜 초보죠....
귀하가 초보시군요.리턴값이 있는 모든 함수는 반드시 블록화 해야합
귀하가 초보시군요.
리턴값이 있는 모든 함수는 반드시 블록화 해야합니다.
그이유는 첫째 디버깅 때문이고,
둘째는 언젠가는 그 부분에 기능을 추가하기때문입니다.
제 의견은 몇 십명과 동시에 버젼 관리해 가면서 소스 코드만 몇십메가
제 의견은 몇 십명과 동시에 버젼 관리해 가면서
소스 코드만 몇십메가 되는 다국어 버젼의 제품을 개발해
본 경험입니다. 저와 같이 일하는 동료 모두가 느끼는 공통점입니다.
생각만큼 실천에 옮기기 힘들뿐
다른 개발자가 작성한 10단 if를 각 함수마다 만난다면 이걸 따라갈 수 있을까요?
그것도 실시간 디버깅이 불가능한 제품 - 핸드폰같은 - 을 개발할때...
님과 같은 이유로 반론을 제기하고자 합니다.
(1) 디버깅의 문제로... 코드는 풀루차트에 가까울 수록 좋습니다.
문제가 생기면 옆길로 빠져서 처리하고 리턴하는 것이 좋습니다.
(2) 해당 부분에 기능을 추가해야하기 때문에 더욱 편리합니다.
return;
을
{ 추가코드; return; }
으로 만들어 주면 되기 때문입니다.
계속 이 논박을 해야하는 지 모르겠지만, 이번까지만 하고저는 그만 두
계속 이 논박을 해야하는 지 모르겠지만, 이번까지만 하고
저는 그만 두겠습니다. 만일 제게 더 의견을 제시할 필요가
있으시다면, 지금 논제와는 벗어나니, 제 이메일을 이용해
주시기 바랍니다.
(1)번은 제가 제시한 문제는 아니고 님께서 말씀하신 (2)번은
이미 제가 말씀드린 내용에 의해 불합리성을 갖습니다.
"return;
을
{ 추가코드; return; }
으로 만들어 주면 되기 때문입니다."
물론 그렇게 하면 됩니다. 하지만, 그 '추가코드'에 해당하는
부분은 return 되지 않은 경우 그 아래에서도 동일하게 다시
필요하게 되는 경우가 많을 겁니다. 다른 분들이 지적하시는
것 중에 분명 이 내용이 간과되지 않습니다.
이 추가 코드부분을 일관된 하나의 위치에서 처리할 수
있어야만, 다시 다음 수정에서 관리가 가능해집니다.
(함수로 동일부분을 묶어 처리하는 것은 대안이 못됩니다.
문제를 계속 복잡하게 만들겁니다.)
그래서, 다른 분들이 반론을 제기하신 것처럼 코딩해야만
현재와 미래에서도 관리가 수월해질 겁니다. 저도 경험에서
말씀드리는 겁니다.
Self made RDBMS + 4GL Tool + winSQL + ne
Self made RDBMS + 4GL Tool + winSQL + network library 제작경험을 가지고 님과 같이 소스코드만 몇십메가되는 다국어 버전의 제품을 여러개 개발하는 "팀장"으로 7년을 보낸 사람으로서 반론에 대해 답하고자합니다.
첫째, 님이 말씀하신 "다른 개발자가 작성한 10단 if 함수를 따라 가는식"으로 프로젝을 했다면 그 프로젝은 관리가 잘못된 것입니다.
그 이유는 C든 C++이든 큰 프로젝은 함수 또는 메쏘드(이하 함수)가 철저히 은닉(capsulation)되어야 하며 해당 함수를 사용하는 다른 개발자는 단지 명세에 의해서만 그것을 사용하여야 한다는 사실입니다.
이는 라이브러리를 작성하는 개발자도 마찬가지인데 오로지 명세에 의해서 충분히 인지되고 사용되어 질 수 있을 정도로 해당 함수를 작성하지 않으면 그 함수는 반드시 사용단계에서 문제를 일으킵니다.
결과적으로, 10단 if함수를 따라가야할 정도로 구성원들간에 함수에 대한 정확한 명세작성과 커뮤니케이션이 부족했다는 이야기이며 이는 팀장 책임입니다.
둘째, 플로차트가 갑자기 디버깅의 문제에 왜 나왔는지 모르겠지만, 본인이 지적한 이유는 님이 처음 제시한 사례가 전형적으로 디버깅을 어렵게 하는 스타일이기 때문 입니다.
이것이 올바른(디버깅이 확실히 가능한) 코딩법입니다.
FILE *fp;
if ((fp = fopen("sample.txt", "r") != NULL)
{
/* fread(fp)등이 while loop내에서 수행되어 일을 한다 */
/* fclose(fp)가 수행된다 */
}
else
{
ferror(fp);
또는
switch( errno ) { /* 시스템 errno 체크 */
case 0 :
case 1 :
.
.
}
문이 수행된다
return (-1);
}
위에서 fread()나 fclose()도 반드시 조건문 내에서 써야 합니다.
(분명히 실패하는 경우가 발생함)
이런식의 코딩은 노가다를 많이 하게 만들지만 디버깅을 확실하게 하고 다른사람 또는 후임자를 배려하는 방법입니다.
.
.
PM은 끝없이 이런 원칙을 지키도록 팀원들을 단련해야 합니다.
구체적인 코딩 스타일 문제 같은데, 논제와 맞는지는 모르겠지만, 님께서
구체적인 코딩 스타일 문제 같은데, 논제와 맞는지는 모르겠지만, 님께서 말씀하신
의견이 항상 그런 것은 아닙니다. 두가지 정도로 예를 들어 보면,
(1)
if( ok1 ) {
if( ok2 ) {
...;
return SUCCESS;
}
}
/* do exception handling here */
return FAILED;
예외 처리 부분을 ok1 과 ok2 에 대한 예외 상황에 대해 하나의 일관된
위치에서 처리할 수 있게 합니다. 때로는 이것을 위해 goto 를 쓰기도
하지요.
(2) 만약 님께서 추천하신 다음과 같은 코드를 사용했을 때,
FILE *fp;
fp = fopen("sample.txt", "r");
if (fp == 0) return(-1);
만일 이 다음에 어떤 코드가 추가되고, 그 코드에서 메모리를 해제하는
등의 예외 처리가 필요하다면, 위와 같이 임의 위치에서 리턴하는
경우를 다시 재검토해야 됩니다. 그래서 저는 오히려 필요에 따라
겹겹이 if 를 쓰는 경우도 있고, goto 를 쓰는 경우도 있습니다.
되도록 임의 위치에서 return 하는 것은 배제하는 게 좋다고 봅니다.
pseudo code는 정말 공감가는 글입니다.저도 비록 시작할때
pseudo code는 정말 공감가는 글입니다.
저도 비록 시작할때는 별 필요성을 못느꼈지만
나중에는 비록 3줄짜리 코드라도 힘을 덜어주는 결과가 되더군요..
개발방법론, 디자인, 도큐먼트팀.. 결국 코딩이전에 좋은 디자인과 그것을
개발방법론, 디자인, 도큐먼트팀.. 결국 코딩이전에 좋은 디자인과 그것을 실행할 수 있게하는 인프라가 있어야 한다는 말씀들에 많은 공감을 합니다. 전 디자인 이전단계에서 목적과 디자인자체에 큰 영향을 미칠 수 있는 기획부분과 그 부분에 대한 공유도 못지않게 중요하다는 생각을 하는데요.. 그러한 이유로 개발자는 단순한 코더라 할지라도 기획자의 입장과 의도등을 이해하고 있어야 한다는 생각입니다.
몇몇 연구,개발회사의 경우 기술에 대한 스펙, 프로토콜의 공유 등에 대해서 중요하게 생각하지만, 큰 줄기의 목표라던가 기획, 개발의도와 목표와 그러한 목표를 선택하게 된 원인 등에 대해서는 너무 가볍게 여긴 결과, 종종 문제가 발생하는 경우를 봤습니다.
여럿이 공동으로, 혹은 모듈별로 팀이 나누어져 파트별 디자인이 이루어지는 상황이라면, 특히나 눈에 보이게 문제가 발생하는데, 종종 최초 디자인 단계에서도 이러한 부분의 문제가 개입되어 개발막바지에 이른 단계, 혹은 개발이 종료된 후에서야 그 사실을 알고, 엎는 경우도 있죠.^^;;
역시나 학교 레포트 양식에도 매번포함되는 요구사항분석, requirement analysis란 것은 괜히 폼으로 있었던 것은 아니였겠죠.. :)
레퍼런스를 정독하는 것, 적어도 그 순간 쓰고자 하는 기능 범위 안에서는
레퍼런스를 정독하는 것, 적어도 그 순간 쓰고자 하는 기능 범위 안에서는 숙지하고 있어야 좋은(=최선에 가까운) 코딩이 나온다고 봅니다. (모든 언어에 다 해당되는 거겠죠? 한국어부터 XML까지)
PHP 같은 경우엔 레퍼런스를 읽지 않아서 이미 구현된 기능을 다시 만드는 사례가 빈번하죠. 제 경우, GTK+ 레퍼런스를 대충 알고 만들 수 있는 기능엔 한계가 있었구요.
--
from [ke'izi] : where is [r]?
코더이던 프로그래머든 에러를 난발하는 코딩을 하는 사람들의 공통점은
코더이던 프로그래머든
에러를 난발하는 코딩을 하는 사람들의 공통점은
사용하는 프로그램언어의 이해부족, 운영체제에 대한 오해, 개발툴사용의 미숙등인데
특히 초보들이 자기나름대로의 상상(?)에서
코딩을 하기때문이란 생각^^...
에러로 부터 자유로와 지려면
프로그램언어, 운영체제, 개발툴등의 창조자(?)의
의도을 충분해 이해하는 데서 부터란 생각이죠..
우주 그리고 인간을 잘 이해하고 표현(수학적 언어등..)하는 과학자는 아마 창조자의 입장에 서서 생각
하기를 즐기는 사람들 일 껄....
야 정말 좋은 방법이군요.저희 회사도 이런저런 방법들을 도입해보고 실
야 정말 좋은 방법이군요.
저희 회사도 이런저런 방법들을 도입해보고 실험해보고 있는데
역시 적은 인원으로 원하는 성과를 내기란 여간 만만한게 아니군요.
특히 다큐멘트의 부담은 그렇습니다.
요즘은 팀원중에 한명을 다큐멘트전담으로 운영해 볼까 생각중이었는데 이런 주제가 올라오네요 ^^
저희 팀은 지금 총6명인데
코딩을 모르는 기획&디자이너가 있고, 앞으로 전담 다큐멘터를 운영할까 합니다.
그럼 말씀하신 외국회사와 형태는 비슷해지겠네요.. 규모는 작지만 ㅋㅋ
(void*)
가장 중요시하는 건... "어떻하든(최후의 순간까지-.-) 코딩을 뒤로
가장 중요시하는 건... "어떻하든(최후의 순간까지-.-) 코딩을 뒤로 미룬다" 입니다. 초보냐 경험자냐의 차이도 그렇지만, 코더이냐 프로그래머이냐의 차이도 이런점에 있지 않나 싶네요.
*** 얼마전에 본 정말 좋은(?) 환경의 소프트웨어 개발팀이 생각나서 한문장 적습니다. (외국회사입니다)
그곳엔 도큐먼트 팀이 따로 있었습니다. 디자인팀(큰 와꾸를 짜는 곳-보통 10년이상의 프로그래머들로 구성)에서 어떤 스펙을 정하면, 바로 프로그램팀(코딩하는 곳-초짜부터 디자인팀으로 가기 전까지의 프로그래머들)으로 가지않고 항상 중간에 도큐먼트 팀에서 검토하게 되어있더군요. 재미있었던건 도큐먼트 팀구성원들은 거의 코딩은 할줄 모르는 사람들입니다. 소프트웨어공학전공이죠. 그곳 책임자의 설명또한 인상깊었었는데, 보통 프로그래머(몇년이하의)들이 가장 범하기쉬운 오류가 코드자체(혹은 언어자체)에 구애받는다는 겁니다. 전체를 놓치기 쉽다는 거죠. 도큐먼트 팀이 따로 있는 이유도 숙련된 10년이상의 프로그래머라도 그 바탕(코드)에서 자유롭기가 힘들기때문에 실제로 원했던 디자인과 다른 프로그램이 나오기가 쉽다는 겁니다. 어찌 보면 코딩에 무식(?)한 도큐먼트팀에서 이런걸 견제할수 있는거죠. 우리나라 현실로 보면 부럽기 짝이 없읍니다만, 그래도 타산지석으로 삼을만 하지 않나 싶어서 적었습니다.
적고나니 주제랑 좀 관련이 없는듯 하네요... 죄송함다.
딴지인데요...타산지석은 타인의 허물에서 교훈을 얻는걸 말합니다.
딴지인데요...
타산지석은 타인의 허물에서 교훈을 얻는걸 말합니다.
"어떻하든(최후의 순간까지-.-) 코딩을 뒤로 미룬다"공감하는 부
"어떻하든(최후의 순간까지-.-) 코딩을 뒤로 미룬다"
공감하는 부분입니다! :)
최소한의 디자인이라두 하구 코딩하자 입니다.그리구 부분적으로 나누
최소한의 디자인이라두 하구 코딩하자 입니다.
그리구 부분적으로 나누어서 하나씩 하나씩
디바이드 엔 퀀커
막힐 때 주변을 살피는 건, 잠시 생각을 전환할 티타임을갖는다던가하는
막힐 때 주변을 살피는 건, 잠시 생각을 전환할 티타임을
갖는다던가하는 게 포함되는 것 맞나요? 그런 건 정말
필요한 것 같구요. 특히 버그 잡을 때...
개발자 커뮤니티는 적극 활용할 필요가 있다는 데에도
동감합니다.
실제 코딩하는 데 제가 경험적으로 알고있는 몇가지
내용은...
- 사소한 경우라도 테스트 코드를 만들어 시험해보고
내용을 정리해서 축적한다.
- 다른 예제 코드를 참조하되, 자기의 코드로, 특정
목적에 대해 최대한 단순화된 예제 코드를 축적한다.
- 프로젝트에 대한 버그리스트를 작성하고 문서화한다.
- 수정할 부분을 표시해두고, 이전에 만들었던 코드를
주기적으로 다시 검토해 본다.
- 속도 최적화가 필요한 코드는 어셈블리 코드를 생성해서
검토해 본 뒤, C 코드에 대응하는 어셈블리 코드에 대한
감각을 익힌다.
- 여러 플렛폼에서 프로그래밍해본다.
등등 여러가지가 많겠죠... 잘 정리는 안되네요. -_-
공동 작업할 때의 법칙 (1)같은 기능을 하는 함수의 갯수는 개발
공동 작업할 때의 법칙 (1)
같은 기능을 하는 함수의 갯수는 개발자 수에 비례한다. 따라서 프로그램의 전체크기는 실제 필요한 크기의 2배보다 크다.
: 만약 내(A)가 a라는 함수를 만들었는데, B라는 동료가 a를 사용하고 있는데 필요에 의해서 내가 함수 a의 내용을 고친다. 그럼 결국 B는 버그땜시 고생하게 된다.
이런 일을 아는 B는 함수 b를 만들게 되고, 같은 일을 하는 함수 a, b가 생기게 된다. 여기에 신입 C가 열심히 일하게 되면 c라는 함수가 생기게 된다.
대책 : 개발자 출신 우리 사장님 왈~ 개발이 끝난 공용 함수는 문서화 해서 모두가 이용할 수 있도록 할 것. 공개 문서화 비율은 50%가 적당.
참고: c함수도 private속성이 있었으면 좋겠다. 예를 들면, 특정 함수만 이 함수를 억세스 할 수 있음
엄청시리 초보라서 잘은 모르지만.. 특정한 함수에서만 사용가능하게
엄청시리 초보라서 잘은 모르지만..
특정한 함수에서만 사용가능하게 할려면
젤 첨에 함수를 선언하지 않고
특정한 함수내에서만 선언을 하면 되는거 아닌가요?
예를 들면
#iclude
//함수선언부
int func_1(int) ;//func_3는 func_1에서만 호출
int func_2(int) ;
int main() ;
{
......
return 0 ;
}
int func_1(int x)
{
//함수호출
int func_3() ;
..
}
int func_2(int y);
{...}
int func_3()
{...
}
주석이 잘못됐네 함수호출이아니라 함수내 함수 선언 뭐 이런식으로
주석이 잘못됐네
함수호출이아니라 함수내 함수 선언 뭐 이런식으로 쓴다면..
이게 그건가??
source safe를 쓰면 간단한것을;;;
source safe를 쓰면 간단한것을;;;
Large Scale C++ Software Design이라는 괜찮은 책
Large Scale C++ Software Design이라는 괜찮은 책이 있습니다.
C에 대해서도 왠만큼 나왔있죠. 큰 프로젝을 하시는 분들은 한번쯤
읽어볼만한 책인듯 합니다.
제가 알기론c에서 private 기능을 하는 것이 있습니다.
제가 알기론
c에서 private 기능을 하는 것이 있습니다.
외부 파일에 정의된 함수를 호출 할 때 static이란 키워드가 이런 역할을 합니다.
A Book on C 등의 책에 나와 있습니다.
이런 글이 왜 튀어 나왔나요 :-)말씀하신 방법을 이용하여 C에서
이런 글이 왜 튀어 나왔나요 :-)
말씀하신 방법을 이용하여 C에서도 OOP구현이 가능하고, 또한 우리가 잘 알고 있는
툴킷들도 존재합니다. 다만 C++보다는 그 구현이 불편하다는 것입니다.
왠만하면... 머릿속으로 디버그해라...머릿속으로 컴파일 해라....
왠만하면... 머릿속으로 디버그해라...
머릿속으로 컴파일 해라....
너무 자동화 도구에 의존하지 마라...
자동화 도구가 그대들을.... 망칠것이다... ^^*
--
늘...