모던보이의 雜說

한국 내의 인기 순위와는 큰 차이가 있는 것 같네요. 흥미롭군요.

프로그램 언어를 쓰는것은 컴퓨터로 워드나 파워포인트를 자유자재로 사용하는것이나 별반 차이가 없다는 것을 encapsulation이라는 개념을 배운 컴퓨터과학도들은 잘 알것이다.

이 그래프를 보다가 이런 설문조사표가 떠우르는건 왜일까?
노가다 연장중 어느 스타일의 곡갱이가 좋은지에 대한 설문조사표.

우리 한국 컴퓨터과학도들은 외국의 무수한 투어링 어워드를 받는 분들을 닮아야 하지 않을까?

C++이 후져서.. 진심입니다.

name이라고 하면 char*인지, char[100]인지, wchar*인지, std::string인지, std::wstring인지, CString인지, boost::string인지 알 수 없잖아요?

pszString 아니면 szString이라고 하면 뭐 LPSTR이나 LPTSTR, LPWSTR이겠구나 싶은거죠 뭐..

저도 윈도우로 프로그래밍을 시작한 서버 프로그래머지만, 요즘 남아있는 습관은 std::string 은 strXXXX, char[] 는 szXXXX 정도만 남아있는것 같네요. 이 2개는 혼용해서 쓰면 치명적인 경우(cin, cout, printf 등이 었던걸로 기억합니다)가 생겨서 좀 구분을 해서 썼었습니다. 나머지는 좀 번거롭기도 하고, 실효성이 생각보다는 많지 않더라구요.

KLDP에서 글을 보다 여기까지 왔습니다. 좋은 정보 얻고 갑니다. 오픈소스에 관심을 가진지 얼마되지 않지만 수혜자의 역할에서 벗어나 기여자로서 역할을 어떻게 하면 좋을까 고민하고 있습니다. 한번 시간이 되시면 만나뵈면 좋겠습니다. 저는 www.polypix.com을 98년부터 운영하고 있습니다. jaison63@naver.com

와.. 꽤 정리가 잘 되어 있네요..
음.. VCS 관련으로 개인적인 추천을 하자면...

1. Branch 활용에 대한 언급이 없으시네요... 활발하게 이용하고 계신가요? 저희 회사에서는.. 수정사항이 생길때 Branch를 이용하고는 있습니다면... 아무래도 Subversion의 Branch 기능은 좀 불편한 부분이 있어서.. 개인적으로 Git - Subversion 연동을 통해 로컬 Branch를 활용하고 있습니다. 배워야 한다는 단점만 제외하면... 아직까지는 제일 편한 방법이네요.

2. http://www.infoq.com/articles/agile-version-control 글을 꼭 한번 봐 주시기 바랍니다. VCS 활용을 극대화 하려면.. 아무래도 VCS "이용"에 대한 전략이 필요하다는 생각을 오랜기간 하고 있었는데... 상당히 정리를 잘 해 놨더라고요.

1. Branch를 쓰고 있습니다만, 사내에 불편해 하는 프로그래머들이 많더군요. 한번도 다른 대안에 대해 생각해 본 적이 없는데, Git + Subversion 검토해봐야 겠네요. 감사합니다.

2. 정리가 잘 되있네요. 좋은 자료 감사합니다.

메일로 주소 알려 주시면 PDF-Pro 4 한개 보내드리겠습니다. ㅎㅎ
jeong@pdfpro.co.kr

vcs 는 어떤 것이든 유사한 문제가 있는 것이 대부분입니다(변경을 관리할 때 공통적으로 생길 수 밖에 없는 근본적인 문제들). cvs 10년 이상 사용하다가 약 3개월 전부터 mercurial 사용하고 있는데, 공통된 문제점도 있고, 더 나은 점도 있더군요. 하나 이상의 vcs를 사용하는 것은 그리 좋은 아이디어는 아닌 것 같습니다. (참고로 저와 동료들은 꼭 필요한 변경은 주저않고 수행하지만, 그렇지 않은 경우 최대한 보수적 관점을 유지합니다. 즉, 뭔가 해결할 수 없는 문제가 없는 한 절대 툴을 바꾸지 않습니다. 반면 개발 프로세스는 쉽게 바꿉니다)

tracking system을 오픈하는 것도 그리 좋은 생각은 아닌 것 같습니다. 물론, 이메일로 버그보고를 받으면 ts에서 id부여후 답장을 자동으로 보내는 등의 자동화 정도는 괜찮을 듯 합니다. jira 쓰고 있는데, 기본적 기능만 사용하므로 별 어려움 없이 씁니다.

빌드와 테스트는 거의 동시에 일어나야 하지 않나 생각합니다. 즉, 개별 작업의 change set이 vcs의 메인라인에 커밋되기 전에 머지후 빌드 및 테스트가 돌아간 후 메인라인에 커밋되는 프로세스라면 데일리 빌드는 큰 의미가 없어집니다. 물론 이렇게 되려면 각 개발자가 언제든 돌려볼 수 있는 테스트 케이스가 있어야 합니다(개별 코드라인 전략은 위의 링크에 이미 있는 것과 유사하면 되겠죠. 제 기억이 맞다면, mercurial로 바꾸면서 동료가 알려준 perforce ppt(pdf?) 파일 내용과 유사하네요. tofu scale 만 기억나네요)

저는 개인용 위키도 사용합니다. http://www.tiddlywiki.com/ USB 메모리 스틱에 truecrypt로 무장한 위키 갖고 다니면서 잡동사니 들을 기록합니다.

개발툴이 양이면, 프로세스가 음인데, 프로세스에 대한 언급은 없어서 약간 아쉽네요. (적고나서 보니 거의 '프로세스' 이야기가 되버렸네요)

건승하시길...

남의 개발환경을 훔쳐보는 기분이네요. 저 있는 곳과 거의 비슷한 환경이네요. 다만 저희는 문서 관리도 SVN을 쓰고 있습니다. 복잡한 툴 배우게 하기가 쉽지 않아서요... alfresco는 처음 봤는데 한번 검토해봐야겠습니다.

좋은 글 감사합니다.

http://www.pdfpro.co.kr/blog/jeong/entry/Warning-무시하지-맙시다

이 주소로 오니깐...바이러스가 감지되네요...ㄷㄷㄷ

웃어야 할지 울어야할지 모르겠군요.

재밌네요, ㅋ
IT 계열 나름대로의 관련 개그가 많이 있죠.
근데 그런 개그는 그 분야 사람들만 알아듣기 쉽다는..!ㅋ

공감 백번하고 침튀겨가며 웃고 갑니다. 크핫핫핫핫..

우연히 링크 따라 여기까지 오게 되었습니다.
재밌고 느낌이 팍팍 오는 시조들이네요^^

제 블로그에 담아가도 될런지요?

우연히 들르게 되었는데, 너무 재미있네요~
저도 담아가겠습니다 ^^
번창하세요~

시조 내용은 서글픈 프로그래머들을 노래하지만,
유쾌해져서 돌아갑니다. ^^

너무 재미있어서 퍼갑니다. (출처 밝히구요)
좋은 하루 되세요. ^^;

3칸탭을 쓰는 저는 뭘까요 ㅠㅠ

갓 학교에서 프로그래밍을 조금씩 배우기 시작한 저로써는 뭔지 모르겠군요 ㅡ,ㅡ

8칸 탭으로 된 소스를 심심치 않게 봤는데....VC만 몇년을 써와서 그런지...적응이 안되더군요-0-;

탭에 대한 고민을 저도 많이 했었는데, 꽤 의미가 있군요...탭8칸이 결벽증이 있다는거는 동의합니다...ㅋㅋㅋ

4칸탭 주의자 입니다. 8칸탭이 아니면 네스팅을 많이 하게 된다는건 근거가 없는 말 같은데요. 아무리 생각해봐도 논리적 연관성이... -_-; 네스팅을 많이 못하게 되서 배수의진 때문에 그렇게 된거라면 모르겠습니다만..

저도 3칸 쓰긴 하는데^^;
예전에 다른 곳에서 위 내용의 글을 봤을 때는 몰랐는데
위에 4칸과 8칸의 코드를 비교해서 보니 8칸도 먼가 매력이 있어보이네요-_-!

아직 학생이라 코딩 스타일이 정해지지는 않았는데
딱히 이유가 있는 것은 아니고 가로 세로 비율이 맞지 않는다는 느낌을 받아서요~=ㅁ=;
글자 크기보다 인덴트 간격이 넓은거 같아서 3칸으로 설정했어요^^;
우리 과 교수님께서는 3칸을 강요하시더군요 그 이상 띄게되면 가독성이 떨어진데나 어쩐데나-_-;
4칸과 8칸의 차이점은 분명 존재하겠지만 단지 그 이유 하나만으로 인재를 채용하지 않겠다고 발언하는 것은 무슨 심보일까요? 그렇게 독단적이고 융통성이 없어서야-ㅁ-;

전 프로그래머는 아니지만 가끔 코딩을 할때는 6칸탭을 씁니다. --;
4칸으로 하면 탭 부분이 한눈에 보이지 않는 경우가 꼭 급할때 생기더군요. 그렇다고 8칸으로 하면 가로스크롤 문제도 있거니와 너무 삭막해서. :)
요즘은 80컬럼 이상을 쓰는 경우가 많으니까 8칸도 크게 문제될건 없을 것 같기도 하네요. 터미널 환경에서 작업을 해도 80컬럼 이상 표기되니까요.
여튼 4컬럼은 중요한 순간에 잘 보이지 않는다가 결론. ㅋ

8칸이라....흐미....전 2칸씁니다. 제가 보기 힘든 케이스가 된건가요? 2칸으로 해서 wrap 사이즈를 132로 세팅해놓고 작업하는데...텔넷도 그렇게 ....전 어떤 성격일까요..ㅎㅎ
참고로, 전 2칸 강박이 있는 것 같네요. 다른 분의 소스를 분석할때도 2칸으로 만들어놓고 분석한다는;;;;;

전 탭안씁니다. 특히 VC쓰는 사람들 소스 보면 탭썼다 스페이스로 했다하는 사람들이 있는데--자기도 모르게 쓰는지 아니면 남의 코드에 약간 덧붙이다 그리 됐는지 몰라도-- 인덴트가 맞지않아 들쭉날쭉됩니다. Editor를 U-Edit 썼다가 J-Edit 썼다가 다른거 썼다 하면 몽땅 들쭉날쭉됩니다. 그래서 탭 안씁니다.. 그냥 스페이스로 2칸.. 잘 안보인다구요? 쓱 훌터봐서 되는일이면 Edit할 일 없습니다. 자세히 보면 한칸도 잘 보입니다. 전 특히 길게 한줄 쓰는거 싫어합니다. 보기좋은게 결국 생산성도 좋은것 같아요.

재미있는 주제인 듯 하네요. 요즘은 직접 개발하는 일보단 봐주는 입장이지만 ( 실력은 뛰어나진 못합니다 :D )
4탭, 8탭은 본인의 기호 아닐까요?
전 눈이 나쁘지만 안경을 잘 안쓰는 편이라 VS에서 폰트를 24정도로 하고 4탭으로 작업 했던 기억이 나네요.
하지만 모니터등 작업 환경에 따라 조금씩 틀리게 썼던 것 같네요.
그리고 개인적으로 예전에 {} 를 어떻게 놓을까로 고민을 많이 한 적이 있었는데
while문은
while(1)
{
}
if문은
if ( ){
}
이렇게가 보기가 좋더라구요.(지극히 개인적입니다)
아 결론은 개인의 기본적인 스타일이 있어야 하겠지만 회사내에선 기본 적인 코딩 가이드라인이 있어야 된다고 생각됩니다. 나중에 동료들과의 커뮤니케이션을 조금 더 도와 준다고 생각하고 있으니까요.

KLDP의 글을 읽다가 여기까지 왔네요.. ^^

전에는 8칸탭을 썼었는데 가독성 때문에 4칸탭으로 바꿨습니다. (저는 똑똑한 편은 아니라..)

대신 80칼럼에는 좀 민감한 편입니다.
신입사원이 들어오면 80칼럼으로 갈구기 놀이도 종종해서 이상한 취급을 받긴 하지만.. ㅎㅎ

저도 KLDP의 글을 읽다가 오게 되었네요 ㅎ;
전 스페이스로 띄워진 텝이 아니라면 텝 넓이를 개인이 어떻게 쓰든 자유라고봅니다.
텝 칸수 만큼 또 중요한건 블럭 규칙을 어떻게 쓰느냐 로 생각됩니다. if다음에 공백을 넣건 안넣건 실제 불편함은 없지만 블럭을 어디에 두느냐는 눈에 확 들어 오기 때문이죠 ㅎ;

여담이지만 씨샵이 기본으로 스페이스로 된 공백이 텝을 누르면 들어가기 때문에 맘에 안들었었는데 그냥 그런대로 쓰니 씨샵에서 만큼은 신경 안쓰게 되네요.

암튼 2칸 4칸 좋은데 8칸은... 블럭이 3~4개만 되도 저 멀리서 부터 시작 되는 코드 때문에 싫더군요. 그리고 특정한 IDE를 정하고 사용 한다면 아무래도 텝 칸수를 기본 그대로 쓰는게 더 득이 되지 않나 싶습니다.
씨샵을 예로 들어도 어느 개인이 스페이스로 된 텝을 전부 텝문자로 바꾸게 된다면.. 나중에 메모장으로 보게 되면 종종 썪이는 스페이스 텝 때문에 보기 힘들더군요.

그런데 가장 중요한건 텝이든 블럭이든 팀 내에서 확실하게 정하고 코딩을 시작 하면 두가지가 개인의 취향이 어떻든 지장이 있나 싶네요 -0-;;

(그러고 보니 델파이 IDE에선 스페이스 2칸텝이 익숙하네요 =_=;;)