프로그래밍할때 제일 나쁜 버릇..

bxhs의 이미지

프로그래밍이란게 참...알다가도 모를 것입니다.^^;;
제가 생각하기에 젤 나쁜 버릇은
아무래도 완벽주의가 아닌가 합니다.

저에겐 끊임없이 회의를 하는 버릇이 있어서,
이게 가장 적절한 코드인가, 이게 더이상 최적화할수 없는 함수인가..
이런걸 항상 생각하다가..시간을 많이 소비하고 말죠..
이게 제일 안좋은 습관인거 같습니다.

분명 처음부터 완벽한 설계란 있을수 없는 것인데..

완벽주의자보다는 무데뽀가 확실히 더 낫다는걸 느낍니다.
ㅋㅋㅋㅋㅋ..여러분의 생각은??

sorcerer의 이미지

정말 골치아픈 문제이지요.
그런걸 생각하는게 정상이지만 역시나 그러면 너무 비효율적이 되고
ㅡ.,ㅡ;
중도를 찾는게 제일일 듯 하네요.

SOrCErEr

펑키의 이미지

내가 나를 볼때...

1. 의자에 앉는 자세 나쁘게 하기
2. 회의를 않해도 너무 않하기(부서직원이 제발 회의줌 하자구 회의 개최합니다)
3. 백업 않해놓기(가끔 망칠때가 종종 생깁니다)
4. 바탕화면 어지럽혀 놓기(평균 아이콘 40개)
5. 기록해놓지 않기(유틸리티 함수가 중복되는게 꽤 됩니다)
6. 저녁엔 일않한다고 해놓고 가끔 집에서 슬그머니 컴터 켜놓고 일할때(이거 정말 병이죠. 이거 않해도 세상 않망하는데)

내가 남을 볼때...

1. 회사에서 프로젝트 할때 기술 연습의 장으로 생각하기(동호회 혹은 보이스카웃이나 환경운동 연합이 아니라 회사이니깐, 온갖 기술 실험해봅니다.).
2. 회의만 죽어라 하기(무능력의 표상으로 낙인 찍음).
3. 협의를 충분히 않하고 나중에 일 뒤집기 혹은 잘못 인정 않하기
4. 메신저 켜놓기(정말 일 않하는 사람의 표상)
5. 일과중 실제 일하는 시간은 2-3시간 미만(곰곰히 생각해볼만한 부분)이지만 늘 밤샌다고 밤에 남아 있기.
6. 남과 일할때 바퀴벌레 처럼 혼자 숨어 들어가기(예전에 저희 팀에 이런 사람이 하나 있었는데 얼마 일하다 내보냈습니다. 출근 시간 내키는데로, 퇴근시간 저는 무조건 6시에 퇴근 시킵니다. 늦게 오거나 어쩌거나, 유틸리티 함수 만드는데 변수명이 a, b, c 이런거 말 죽어라 않듣습니다. 부분 프로그램 짜는데 레쇼널 로즈를 가지고 하세월입니다. 나중에 PM되면 쓰라고 해도 않듣습니다. 집에서 알바 하는게 적격입니다.)
7. 수정 사항 나오면 다 뜯어 고쳐야 된다고 엄포를 놓습니다. (저에겐 않통하죠. 애지간해서는 수정사항 요구를 하지 않는데 어쩌다가 그럴땐 복도로 데려가서 담배 한대 주면서 꼴밤 때립니다.)

기타 등등...

제 생각에 가장 나쁜 버릇은

1. 회사인지 집에서 노는건지 혼돈될때.
2. 생산성이 최우선 되어야 하는 상황인데 무슨 예술 하는 사람으로 착각할때.

이것이 아닐까 생각됩니다. 프로그래밍 할때라기 보다 회사에서 라는 편이 맞겠네요. 에구 세네.. ㅎㅎ 결국엔 남욕만 하네요. 쩝

alfalf의 이미지

주석 안달기...
그런데 주석 다는일도 쉬운건 아니더군요.
주석 다는 일이 플밍만큼 어렵게 느껴지는 사람인데
쉬운 방법이 없을까요?

mykldp의 이미지

펑키님, "않하기", "않한다고", "않듣습니다" 등은 "안하기", "안한다고", "안듣습니다" 로 쓰셔야 합니다...^^;

sorcerer의 이미지

저는 하다보면 주석을 너무 달게 되던데;;
주석까지도 잘 만들어야지 라는 생각을 해서 그런게 아닐까요?
그냥 변수 옆에 간단하게 얘는 머 하는 놈이다 부터 시작해서 함수나 특정 루틴 시작할 때 여기는 머하는 곳이다 정도 달아놓는것 부터 시작하는것도 한 방법이겠지요. 책 같은데서 예시로 보여주는 주석들, 특히 함수에 대한 설명을 적은 주석을 보면... 참 귀찮을 것 같단 생각이 ㅡ.,ㅡaa

SOrCErEr

idlock의 이미지

charsyam의 이미지

펑키 wrote:
내가 나를 볼때...

1. 의자에 앉는 자세 나쁘게 하기
2. 회의를 않해도 너무 않하기(부서직원이 제발 회의줌 하자구 회의 개최합니다)
3. 백업 않해놓기(가끔 망칠때가 종종 생깁니다)
4. 바탕화면 어지럽혀 놓기(평균 아이콘 40개)
5. 기록해놓지 않기(유틸리티 함수가 중복되는게 꽤 됩니다)
6. 저녁엔 일않한다고 해놓고 가끔 집에서 슬그머니 컴터 켜놓고 일할때(이거 정말 병이죠. 이거 않해도 세상 않망하는데)

내가 남을 볼때...

1. 회사에서 프로젝트 할때 기술 연습의 장으로 생각하기(동호회 혹은 보이스카웃이나 환경운동 연합이 아니라 회사이니깐, 온갖 기술 실험해봅니다.).
2. 회의만 죽어라 하기(무능력의 표상으로 낙인 찍음).
3. 협의를 충분히 않하고 나중에 일 뒤집기 혹은 잘못 인정 않하기
4. 메신저 켜놓기(정말 일 않하는 사람의 표상)
5. 일과중 실제 일하는 시간은 2-3시간 미만(곰곰히 생각해볼만한 부분)이지만 늘 밤샌다고 밤에 남아 있기.
6. 남과 일할때 바퀴벌레 처럼 혼자 숨어 들어가기(예전에 저희 팀에 이런 사람이 하나 있었는데 얼마 일하다 내보냈습니다. 출근 시간 : 내키는데로, 퇴근시간 : 저는 무조건 6시에 퇴근 시킵니다. 늦게 오거나 어쩌거나, 유틸리티 함수 만드는데 변수명이 a, b, c 이런거 말 죽어라 않듣습니다. 부분 프로그램 짜는데 레쇼널 로즈를 가지고 하세월입니다. 나중에 PM되면 쓰라고 해도 않듣습니다. 집에서 알바 하는게 적격입니다.)
7. 수정 사항 나오면 다 뜯어 고쳐야 된다고 엄포를 놓습니다. (저에겐 않통하죠. 애지간해서는 수정사항 요구를 하지 않는데 어쩌다가 그럴땐 복도로 데려가서 담배 한대 주면서 꼴밤 때립니다.)

기타 등등...

제 생각에 가장 나쁜 버릇은

1. 회사인지 집에서 노는건지 혼돈될때.
2. 생산성이 최우선 되어야 하는 상황인데 무슨 예술 하는 사람으로 착각할때.

이것이 아닐까 생각됩니다. 프로그래밍 할때라기 보다 회사에서 라는 편이 맞겠네요. 에구 세네.. ㅎㅎ 결국엔 남욕만 하네요. 쩝

아, 제 얘기를 하시는 것 같습니다. 온갖 실험을... 실 근무시간 2시간 이내
상주시간은 12시간 이상... 하하하...

그럼 고운 하루되시길...

=========================
CharSyam ^^ --- 고운 하루
=========================

sh.의 이미지

mykldp wrote:
펑키님, "않하기", "않한다고", "않듣습니다" 등은 "안하기", "안한다고", "안듣습니다" 로 쓰셔야 합니다...^^;

덧붙여서....
안 을 써야할때와 않 을 써야할때는,

'안'일 경우 '안'을 빼도 말이 되고
'않'은 그걸 빼면 말이 이상해질때입니다^^

xjiwoox의 이미지

'완벽주의'도 정도가 심하면 안 좋은(?) 프로그래밍 습관... 이 되는게 맞습니다.
물론 결과물의 질은 나아질 수 있겠지만 시간 대비 능률이라는 면에서 마이너스
되는 부분이 많습니다... 적당한 선에서 타협을 해야겠지요.

주석 안 다는 것과 생각없이 변수명 짓는 것은 제 개인적으로 가장 혐오하는
코딩 스타일입니다.(이것도 스타일이 되려나 모르겠지만...)
평생 그 소스 자기 혼자 볼거라면 모르겠지만, 회사 업무와 관련된 산출물일
경우 인수자나 후임자, 또는 유지보수 개발자에게 엿먹으라고 말하는 것과
다를 바 없습니다. 물론 주석 없이도 이해하기 쉽도록 코딩하면 되지 않겠느냐
하지만 그 정도 레벨이 되는 사람도 그리 많지 않거니와 C와 같은 언어의 경우
주석 없이 명확한 코드의 의미를 전달하는게 상당히 어렵다고 봅니다.
그리고 혼자 볼 소스라고 해도 나중에 절대 수정 안 할거라는 보장도 없고,
결국에 가서는 유지보수나 추가작업시에 비능률적인 작업결과를 낳게 되죠.

s(˘∼˘*)z,·´″"`°³о$ √(´∀`√)... (˘ヘ˘ㆀ)a

hyunuck의 이미지

밥안먹는거.
건강이 최곤데...:-)

fender의 이미지

주석의 유용성은 언어에 따라 다른 것 같습니다. 저는 자바를 짜는데 Javadoc을 제외하면 거의 주석을 달지 않습니다. 단, 아직 처리가 안되어 있는 부분이나 꼭 설명이 필요한 workaround 같은 경우 TODO, FIXEME 등을 붙여 IDE의 Task에서 별도 관리가 되게 합니다.

자바와 같은 OOP언어에서 가장 좋은 코드는 클래스 구조와 이름, 상속관계만 보고도 명확히 의도를 알 수 있는 코드라고 생각합니다.

객체지향적으로 사고하고, 널리 알려지고 안정적인 프레임워크를 사용하며, 커뮤니티에서 일반화된 컨벤션과 프로세스를 따르고, 무엇보다 가능한한 '꽁수'를 피한다면 굳이 모든 코드에 주석을 자세히 달 필요는 없다고 봅니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

Bini의 이미지

bxhs wrote:
프로그래밍이란게 참...알다가도 모를 것입니다.^^;;
제가 생각하기에 젤 나쁜 버릇은
아무래도 완벽주의가 아닌가 합니다.

저에겐 끊임없이 회의를 하는 버릇이 있어서,
이게 가장 적절한 코드인가, 이게 더이상 최적화할수 없는 함수인가..
이런걸 항상 생각하다가..시간을 많이 소비하고 말죠..
이게 제일 안좋은 습관인거 같습니다.

분명 처음부터 완벽한 설계란 있을수 없는 것인데..

완벽주의자보다는 무데뽀가 확실히 더 낫다는걸 느낍니다.
ㅋㅋㅋㅋㅋ..여러분의 생각은??

맞습니다. 그리고 프로그래밍의 흥미와, 재미를 포기하는 지름길이라고
감히 말씀드릴수 있습니다. 자신은 발전이라 생각하지만 알고보면
전혀 발전이 아니죠...
나중에 시간이 흐른뒤에 자신의 예전코드를 보면 약간은 자유분방하고,
즐거움을 가지고 짠 코드가 훨씬더 깨끗하고 완전하다는걸 알수있습니다.
인간은 무슨일을 하던 재미를 느낄때가 그일을 제일잘하는 순간이라서...

breaknet의 이미지

-

Talk hard!

익명 사용자의 이미지

C언어적인 관점에서만 보면.. 제 생각은....

1. 에러가 나는 상황에 대한 조치없이 에러나면 exit만 호출하는 것.
2. 디버그메세지가 다른 사람이 볼때 전혀 알아볼수 없게 되어 있을때
예> printf(">>>>>>> %d <<<<<<<<<", s_Value);
3. Makefile이 거의 스크립트 수준일때 (알아보기 힘들게 만들때)
4. 함수의 에러를 전혀 안나겠거니 가정하고 에러검사 안할때
(포인터가 null인지 검사 안할때도 포함.)
5. 들여쓰기 규칙이 일관된 모습이 아닐때.

펑키의 이미지

아...... 맞춤법이........ 쩝.. oops

맞춤법 리풀이 무지 만네요. ㅎㅎ

bkbm의 이미지

:shock: 털썩~

무지 만네요 -> 무지 많네요

입니다.^^;;;

쿨링팬의 이미지

여러 날에 걸쳐 짜지는 프로그램은

매일마다 어느 정도의 진척이 있더군요.

그래서 저는 매일마다 진척된 정도를 파일에 기록하여 백업을 하고 있습니다.

백업을 안 할 때는 수정을 하다보면 잘 되던 부분도 다시 안 될때도 있고,

옛날의 아이디어를 시간이 많이 흐른 다음 다시 쓰게 될 경우도 있고...

아무튼 프로젝트를 시작하는 날부터 디렉토리가 하나 생기고

날짜순으로 디렉토리가 쭉~ 늘어납니다. :D

wather의 이미지

필요없는 건 안 보여줬음 좋겠습니다.
그냥 딱 필요한 것만 인터페이스로 빼서 보여주면 가져다 쓰는 입장에서 얼마나 편합니다.

필요없는 건데 보이면 괜히 생각만 더 복잡해 집니다. =.=

coupling은 객체 사이에만 존재하는 게 아닙니다.
프로그래머 사이에도 coupling이 존재할 수 있습니다.

물론 실제 인간관계는 coupling이 강할 수록 좋겠지만요. ^^;;;

신승한의 이미지

손끝 군살 뜯어 씹다 여기저기 뱉기 :oops:

익명 사용자의 이미지

주석 안다는 것보다 더 나쁜 것은 로그 안붙이는 것 아닐까요? 옆 사람이 무엇인가를 고쳤는데 소스만 보고는 왜 고쳤는지 도저히 몰라 cvs를 살펴 봤더니 "no log message" :twisted: 그런데 마침 그날은 옆 사람 회사 안나오는 날(휴가갔거나, 출장갔거나, 기타 등등)...

펑키의 이미지

정신적으로 좀 문제가 있으신분들 같네요. 맞춤법 맞추어 쓰기 토론도 아니구 참나... 뭐 달리 해석할 방법이....

HongiKeam의 이미지

1. code and fix 로 밀어 붙이기.

2. 한번 만든 알고리즘 너무나도 아끼기.

3. 기본에 충실하지 않기.

저는 이정도가 있습니다. TT

p.s : bs0048님 반가워요~~~ 이번주 일요일에 BoA요~


----
God take what you would.

ukira의 이미지

bs0048 wrote:

덧붙여서....
안 을 써야할때와 않 을 써야할때는,

'안'일 경우 '안'을 빼도 말이 되고
'않'은 그걸 빼면 말이 이상해질때입니다^^


'않~' 은 '아니 하~' 또는 '안 하~'에 기원을 둡니다.
결과적으로 보면 bs0048님의 말이 맞을 수도 있지만,
원래의 의미는 이렇지요.
Gargoyle의 이미지

펑키 wrote:
정신적으로 좀 문제가 있으신분들 같네요. 맞춤법 맞추어 쓰기 토론도 아니구 참나... 뭐 달리 해석할 방법이....

틀린 것 지적해주는 것 뿐인데 "정신적으로.."운운 하신 것은 좀 심하신 듯 합니다. 다들 잘못된 것을 바로잡아주시는 것인데요.

bxhs wrote:
프로그래밍이란게 참...알다가도 모를 것입니다.^^;;
제가 생각하기에 젤 나쁜 버릇은
아무래도 완벽주의가 아닌가 합니다.

제 생각에 가장 나쁜 것은 새로운 것에 대한 두려움이 아닐까합니다. 두려움까지는 아니더라도 쓰는 것만 쓰게 되고 다른 것은 손이 잘 안가게 되다보니 실력은 재자리 걸음을 반복하고... 그러다보니 점점 퇴보되는 듯한 느낌도 들고요. 요즘은 틈날 때 마다 이 문서 저 문서 읽어보려고 노력은 하는데 아직까지는 그저 읽는 것에 그치고 있습니다. 쩝.

morison77의 이미지

전 주석을 달아놓으면 짧은 영어 실력때문에
말 그대로 콩글리쉬가 되서 나중에 제 자신의 코드를
봐도 이게 무슨 뜻이지 라고 잠시 생각해봐야 한다는.. :cry:

light my fire

seoleda의 이미지

전 다른사람이 짜놓은 코드는 그냥 대충 대충 읽는 버릇이 있는데요.

대충 어떤 기능을 하는 것이다라는 말만듣고,

아무 생각 없이 그냥 copy & paste 했다가 좀 헤멨던 기억이 있네요.

totohero의 이미지

제가 생각하는 나쁜 버릇 : 한 프로그램 내에서 비슷하면서도 약간 다른
코드가 다수 필요할때 공통 분모를 찾아내어 함수(나 클래스)로 만들어
재사용 가능토록 하지 않고, copy & paste 한 다음에 부분적으로 수정
하는 행위입니다. 당장 급해서 그런 식으로 코딩하게 되는데, 나중에 손볼
일이 있으면 참 마음이 아픕니다.

B00m의 이미지

프로그램 짤때 너무 생각을 안하거나 너무 생각을 많이 오래 하는 것이 안좋은 습관인 것 같습니다..

주위에 보면 설계 같은거 전혀 없이 그냥 짜고 기능 추가 되면 어떤 통일성도 없이 그냥 코드 추가하면 짜는 사람이 있습니다.
당연히 버그도 많죠..
그러다보니 버그 수정하고 소스는 어지러워지고 스파케티가 되죠..
저같으면 그냥 첨부터 다시 짤거 같습니다..
뭐 이건 누가 생각하나 안 좋은 코딩 습관이고..

그런데 어떤 사람은 또 넘 구상과 설계를 오래 하는 사람이 있습니다..
종이에 써가며 구상하고 설계하고 그렇게 심하게는 몇일을 보내고 코딩에 들어가죠..
물론 아무래도 설계를 잘하고 코딩을 하면 코드가 깔끔하게 잘 만들어 질 수는 있지만..
회사 입장에서 보면 넘 시간이 오래 걸린다는 단점이 있죠.
그리고 아무래도 사람이다 보니 그렇게 설계를 열심히 하고 생각을 많이 하고 코딩에 들어가도 실제 코딩을 하다보면 실수를 하고 생각하지 못한 설계상의 오류를 발견할 때가 있습니다..
그러면 또 넘 많은 개발 시간이 소모되게 되죠..

적당한게 좋겠죠..^^

은빛연어의 이미지

머리속에 시작부터 끝까지 구조가 잡히지 않은 상태에서 코딩들어갈때... 모하는 짓이지??? 제일 않좋은 습관입니다... 일단 시작하고 보는것은 그이상의 시간이 필요하죠..
시는 시상이 떠오르면 자연스럽게 물흐르듯이 써지는것!! 연필들고 종이폈다고 써지는것은 아니죠...
충분한 검토를 이룬뒤~~ 코딩은 젤 나중에!!!