제목 : 한글변수 사용에 대하여
글쓴이: 손님(guest) 2006/03/03 18:15:28 조회수:10114 줄수:16 |
|
증권업무관련 프로그래밍을 하다보면 금융용어가 굉장히 많고 그의미를 명확하게
이해하기가 어렵습니다 게다가 프로그램을 할라치면 콩글리쉬변수명 때문에
가독성에 굉장한 어려움을 가지고 있읍니다. 물론 프로그램마다 콩글리쉬변수명이 틀려지죠
단어장이 있는게 아니라서, 지금 개발유지보수 하는 곳은 VB6.0을 사용합니다
한글변수, 함수명 사용가능합니다 하지만 기존의 개발자들은 한글변수사용하는 것을
무지 꺼려합니다 굳이 콩글리쉬를 쓰려고 합니다. 이유는 그렇게 배웠기 때문이라생각하는데
문제가 되는 것은 소스를 보고 굉장히 많은 구조체의 변수들이 다 콩글리쉬라서
이런 코딩스타일에 익숙하다고 할지라도 소스를 보고 한눈에 알수가 없다는 것입니다
요즘은 테이블명도 한글화를 하고 있읍니다. 사용해 보니 문제가 없읍니다
처음엔 한글이라서 문제가 발생할거라 생각했는데 테이블명만 보고도 어떤 테이블이고
성격을 빠르게 알수 있어서 네이밍루울을 굳이 암기할 필요가 없습니다
프로시저나 패키지명도 한글을 사용해서 상당한 가독성을 높혔읍니다.
한글변수를 사용시 속도면에서는 떨어진다고 할수 있겠으나
비지니스로직이 주가되는 프로그램에서 굳이 한글변수가 가능한데 계속 영문변수를 써야 할까요 ?
물론 한글변수와 한글테이블명을 10년차 되면서 최근에 써보았는데 써보니 굉장히 효율적이라
판단해서 여러개발자분들의 의견을 듣고 싶어 이렇게 글을 올립니다
|
제목 : Re: 전 찬성입니다.
글쓴이: 멍멍(guest) 2006/03/04 01:28:54 조회수:933 줄수:5 |
|
과감하게 고정관념의 틀을 깨고 실용성을 추구한 것에 경의를 표합니다.
저도 수 차례 한글로 테이블 설계, 코딩을 해봤는데 아무 문제 없었습니다.
업무 로직이 복잡할수록 가독성 향상은 엄청납니다. 특히 우리나라 공무원, 기업의
조직 구조 엄청 복잡하죠. 콩글리시조차 힘든 경우가 많습니다. 아예 한글 발음대로
영문명을 쓰는 경우도 적지 않죠. 그러느니 그냥 한글 쓰는 것이 훨씬 실용적입니다.
|
제목 : Re: 막연한 두려움 때문이 아닐까요?
글쓴이: 손님(guest) 2006/03/08 17:46:34 조회수:984 줄수:15 |
|
저도 테이블명이나 칼럼명이 모두 한글로 되어 있는 곳에서 일하다
영문으로 된 곳에서 일을 하려다 많이 힘들었던 기억이 납니다.
업무로직이 복잡하거나 칼럼이 수십개 되는 테이블로 개발 할때 칼럼명이 아니라
commment를 보고 일을 하는것은 엄청난 능률의 저하를 가져옵니다.
특히 그 업무를 처음 접하는 사람은 수백라인의 sql만 보고도 질리게 됩니다.
시스템이 수용하지 못하면 어쩔수 없지만 요즘은 한글과 한자도 충분히 사용할 수 있는 것으로 압니다.
|
제목 : Re: 흠...
글쓴이: 손님(guest) 2006/03/09 00:53:40 조회수:809 줄수:1 |
|
그럼 아예 자바코드도 다 한글로 쓰시고 나중에 스크립트로 영문으로 바꾼후 컴팔하시는것은?
|
제목 : Re: 한글쓰는것에 적극 찬성합니다.
글쓴이: 손님(guest) 2006/03/09 08:42:46 조회수:867 줄수:7 |
|
관성때문에 영문을 줄곧 쓰고 있지만, 일전에 10년차 넘는 개발자분이
테이블부터 변수이름까지 모두 한글로 쓰는 분을 본바 있습니다.
실제 그렇게해도 아~무런 문제 없습니다.
관성때문에 제 자신은 영문을 더 편하게 느끼지만,
한글써서 문제 없이 할수 있다면, 굳이 영문을 고집해야 할 이유가 있을까요?
|
제목 : Re: 변수명과 값이 혼돈되진 않을까요?
글쓴이: 손님(guest) 2006/03/09 15:59:12 조회수:874 줄수:19 |
|
키 벨류에서도 혼동되진 않을런지?
List 현재여신처리리스트;
현재여신처리리스트 = 현재여신처리리스트가져오기( 현재시각 );
Iterator 현재여신처리리스트이터레이트객체 = 현재여신처리리스트.iterator();
while( 현재여신처리리스트이터레이트객체.hasNext() ) {
여신처리오브젝트맵 = (여신처리오브젝트맵).next();
log.info ( 여신처리오브젝트맵.get("여신고객번호") );
}
이렇게 되는건가요?
음, 전 왠지 적응이 어려울듯해요 ^^;
|
제목 : Re: 과연 문제가 없나요...
글쓴이: 손님(guest) 2006/03/09 20:26:11 조회수:816 줄수:4 |
|
변수명 생각하느라...보내는 시간도 만만치 않은데...
무척 고무적인데요...
|
제목 : Re: 살짝 테스트해봤는데...
글쓴이: 손님(guest) 2006/03/10 08:21:09 조회수:878 줄수:11 |
|
신기하군요.
메소드명과 변수명을 한글로 했는데 정상적으로 작동합니다.
커헉~ 고정관념이 무섭긴 무섭군요...
반드시 영문자로 작성해야하는 줄 알았습니다.
한글로 작성한다면 가독성은 휠씬 좋아질 것같습니다.
다만, 한글에 맞는 컨벤션이 필요할 듯한데요.
영문자처럼 대소문자 구분이 되는것도 아니구...
혹시 정리되신 게 있을라나요?
|
제목 : Re: 콩글리쉬보다 더 낫지 않을까요?
글쓴이: 손님(guest) 2006/03/10 09:42:27 조회수:780 줄수:10 |
|
Derives (파생상품)을 paseng이라고 쓰거나 Futures(선물)을 sunmool이라고 쓰는것보다
한글로 쓰는게 훨씬 더 체계적이고 직관적인것 같습니다.
아예 영문을 쓰려면 확실하게 제대로 된 영어를 쓰던지, 그게 안되면 한글을
쓰는게 모두에게 낫지 않을까요?
사실 한글로 변수명, 파일명, 테이블명, 필드명 써도 문제없게 된지는 십수년이
넘었습니다. 시스템은 충분히 뒷받침이 되는데, 단지 기술자들 생각이 바뀌지
않은것 뿐입니다.
고정관념 그거 무섭습니다.
|
제목 : Re: 한글 변수명을 안쓰는 이유가...;;
글쓴이: Marty(guest) 2006/03/10 10:20:23 조회수:846 줄수:4 |
|
써도 된다는 것은 알고 있었지만
이제껏 주욱 안쓰던 이유가.. 코딩 중간중간 한영키 바꾸는게 너무 귀찮아서 -_-;;
뭐 이런 별거아닌 이유로 그러는 사람도 있긴 합니다.. ㅎㅎ
|
제목 : Re: 개발시야 문제가 없지만...
글쓴이: 정준원(guest) 2006/03/10 10:59:19 조회수:812 줄수:7 |
|
한글코드들이 다양한 OS들로 올라가서는 문제가 많이 되지요..
character set 자체가 os에 없을 수도 있고,
(제 경우 유럽쪽이나 일본쪽 서버에와 app 몇몇에서는 경험상 상당히 치명적인 문제가 된 적이 있답니다.)
encoding에 따른 컴파일 문제라던가...
왠만하면 코드와 주석은 모두 영문으로 작성하시는게 좋답니다. ^^
(음냐~ 이렇게 추천드리면 더 주석 않다시겠지요? *^^*)
|
제목 : Re: i18n 준수가 안되는 환경이 지금도 있나요?
글쓴이: 손님(guest) 2006/03/10 11:48:15 조회수:881 줄수:12 |
|
IBM계열처럼(x86아니고 Mainframe계열) EBCIDIC코드 쓰는경우 한글처리에 좀 문제가
있는 경우는 본적이 있습니다만, 오픈계열(Unix, Windows, Linux)에서 한글처리가
문제가 되는건 본일이 없습니다만...
( 그 문제가 되는것도 문자변환상의 문제이지, 소스코드나 오브젝트 이름들이
한글이라서 문제였던적은 못본것 같습니다. )
Unicode쓰는 경우는 아예 문제가 안되고, Character Transcoding해주는 어플들에
보면 한글코드셋들 기본적으로 다 들어 있습니다.
그리고 그 문제가 된다는 게 어느정도인지에 따라서 한글네이밍룰을 적용할지 안할지
여부를 결정해야 하지 않을까요? 어느정도 문제가 되도, Fixing하는데 드는 노력을
감안하고, 한글네이밍룰이 적용될 경우의 이득을 비교해보아야 겠지요.
|
제목 : Re: 메소드명은 영문으로 하는게 좋다고생각합니다.
글쓴이: 이규주(29zu) 2006/03/10 12:47:33 조회수:938 줄수:21 |
|
처음 개발시점부터 ..지금도 그렇고 부분적으로 변수등에 한글사용을
하는 편입니다만... 이용하다보니....
내부적으로만 사용하는건 한글을쓰건 일본어를쓰건 전혀 문제가 없다고생각합니다.
변수말이지여...
하지만 외부로 공개되는 변수 혹은 그 변수에 접근하는 메소드는..한글이 되면 안되더군요.
... 결국 그렇게되면..다른사람이 이용못하는 경우가 발생하거나 에러가 발생하거든요..
(jsp파일 헤더 조작해서 엑셀파일로 출력하는 것 같은경우 만일 한글변수를쓰게되면
에러가 납니다..)....
또다른 딜레마로는. 변수는 한글로 쓰는데 거기 접근하는 메소드는 또 영문으로 생각
해야한다는 ...(이중으로 고민되게만드는)...문제가 생기더군요...
(몸 소스분석입장에선 어떤 알수없는 이름의 메소드를 들어갔더니 한글변수를 이용
하는게하는게 더 나을수도 있습니다..^^)
그래서 요새 개발할때는...
내부적으로만 쓰는 변수등은 한글을 사용하지만.....
외부에서 접근할 여지가 있는 것은 한글사용을 하지 않는...방향으로 개발합니다..;;;;
|
제목 : Re: 참신하나 별로 동의은 안되네요
글쓴이: 손님(guest) 2006/03/11 02:56:55 조회수:984 줄수:59 |
|
한글로 써도 직관적으로 이해하기 힘들 수도 있다는걸 알아야 합니다.
특히나, 영어는 논리적인 언어이기에 정확히만 쓴다면 그 의미가 명확하지만
한국어는 논리적인 언어는 아니라고 봅니다. 각종 조사에 접미사 접두사 등등...
쓰는 사람에 따라 담고 있는 의미가 다를 경우가 허다하고
또 읽는 사람도 다르게 이해하는 경우가 많습니다.
특히나 인터넷에서 수많은 글을 읽으며 느끼지 못하셨나요?
나는 분명히 정확하게 이런 말을 했는데 저 사람은 전혀 딴판으로 이해를 하더라...
사실 프로그래머가 알파벳에 익숙치 않다는건 말이 않되는 소리일진데
사실 문제는 두가지 소지에서 발생한다고 생각합니다.
1) 정확한 단어를 쓸 수 있느냐
2) 축약어를 남발하는게 아닌가
1번 같은 경우 PM이 용어의 표준안을 제시할 필요가 있다고 생각하고요, PM의 역량이겠죠.
같은 선물이라도 gift라고 쓰는 사람이 있고, present라고 쓰는 사람이 있지요.
2번 같은 경우 PM조차 말도 않되는 축약어를 남발 하는 경우를 숱하게 봤습니다.
리스크는 이런 축약어를 외우는 데서 생긴다고 봅니다.
국내 기업으로 표준안을 그래도 제시하고 따르는 편인, SDS 같은 경우는 항상 완전한
단어조합으로 변수명을 만듭니다. 변수명이 길어져도 길어지는 대로 쓰더군요.
대신 이클립스 같은 자동화 툴이 변수명을 치는 불편함을 덜어줍니다.
사실, 한글로 쓰더라도 한국 사람끼리만 공유하는 소스라면 문제는 없다고 보나
오히려 단기적인 개발 시간 단축이라는 성과도 낳을 수 있다고 보나
잠재적으로는 개발자들의 발전을 막고 기술을 공유하는데 장애를 낳을 수 있다는데 주목을 할 필요가 있습니다.
JAVA에 있어서 관습적으로 쓰던 네이밍 룰등이 있지요?
가령 객체명은 소문자로 시작한다. 언더바는(_ , -) 넣치 않는다. 대문자는 상수(static) 변수다. 등등...
이런 세계적인 관습은 포기 해야 한다는 리스크가 있을 것입니다.
이건 자칫 더 큰 문제를 낳을 수 있습니다.
가령 객체와 클래스 구분이 되지 않는다거나, 의미는 분명히 전달할 수 있지만
이거이 상수인지 일반 변수인지 구분이 되지 않는다거나 등의 문제가 일감으로 떠 오르겠지요
DB의 경우에서도 관습적으로 공유하던 네이밍 룰을 포기함에 따른 리스크가 있을 것입니다.
요건 제 내공이 부족해 예를 못들어 드리겠군요.
효율 물론 중요하지만, 가장 심각한 문제는 자신의 소스를 세계의 프로그래머들과 공유할 수 없는 것인데
무슨 소린고 하니, 개발은 레퍼런스가 제일 크다고 봅니다. 참고할만한 무언가...
막혔을 때 한국 사람들 끼리 해결하지 못한 것들을 google 에서 찾을 때가 더 많고
외국 사람들에게 질문해서 해결한 경우가 더 많습니다. 심지어 자바 서비스넷에서도
안되던것이 google에선 쉽게 답이 있는 경우가 많았습니다.
문제되는 나의 소스를 질문하고자 할 때, 기꺼이 답변을 해 주는 세계의 개발자들이
있음에도 문제와 해결책을 공유할 수 없다는 것이지요. 특히나 개발자 급으로 올라 갈수록
이부분은 큽니다. 체감상... 당장 해결해야 하는 시급한 안이 있는데 한국 사람들끼린 해결이 안될경우
많거든요.
그리고 이건 언급하기엔 좀 약한 이슈같지만, 한글 변수가 모든 프로그램에서 잘 돌아간다는 보장은 없습니다.
가령 자바 컴퍼일러와 DB에선 잘 작동하던것이
이클립스에서 변수명을 Tracking 할 때, 클래스 명이 한글일 때 문제가 생길지 장담할 수 있나요?
웹스피어 개발툴은? 또 새로운 무언가 개발의 표준으로 떠오를 만한 S/W가 나왔을 때는 문제의 소지가 없는가?
등입니다. 요건 좀 작은 부분일 수 있으므로 패스.
결론으로
저의 조심스러운 의견으로는 영어를 피하는 건 졸속하지 않나 싶습니다.
개발자들이 노력해야 할 부분이라고 생각합니다.
먹고 살려면 아무래도 좀 더 부지런 해야 하지 않을까요...
비록 토익 800은 못 받아도, 개발 수준의 영어 정도는 구사할 수 있는 역량은 있어야
세계 다른 나라의 개발자들끼리 기펴고 당당할 수 있지 않을까 생각해 봅니다.
ObjectClass와 objectClass를 구분 못하는 차이, 참 새삼 크게 느껴지네요
|
제목 : Re: 오픈 계열이라 하더라도...
글쓴이: 손님(guest) 2006/03/11 11:52:49 조회수:838 줄수:22 |
|
음 오픈 계열에서의 문제라...
jsp나 xsl처럼 런타임시 컴파일을 해야하는 was에게... encoding이나 character set문제로
코드 자체를 파싱하지 못하기 때문에 문제가 되는 경우는 부지기수입니다.
특히 특정 인코딩하에 무의식중에 저장된 텍스트문서에는 다른 character set이나 os에서
오픈 될때 눈으로 보이지 않는 메타문자가 포함되는 경우도 많구요.
(이 경우 정말 골치아픈 문제가 되지요...)
경험상 헝가리쪽에서 작성된 ap를 euc-kr이나 utf-8로 포팅하는 과정에서 코드는 고사하고
주석안에서 있는 한글 윈도우에서는 보이지 않는 문자열 때문에 jsp컴파일 자체도 않되는
경우도 있었네요. (누가 상상이나 하겠어요? 주석 때문에 jsp가 컴파일이 않되다는 걸... @@)
물론 native2ascii 같은 툴로 변환을 하면 된다고는 하지만 실제 ap를 다른 문자셋에서 포팅
해보면 변환은 커녕 다른 OS에서 문서를 열기 때문에 실수로 문서 자체를 깨먹는 경우도 많구요.
원소스 코드 작성자가 자신의 코드를 유니코드로 변환해서 배포하는 경우는...
글쎄요 과연 실제로 코딩하는 실태를 볼 때 코딩후 자신의 코드를 일일이 유니코드로
변환하는 사람이 얼마나될까요?
그리고 위에서 지적하신 컨벤션문제도 심각하구요...
|
제목 : Re: ...
글쓴이: 멍멍(guest) 2006/03/11 21:35:20 조회수:785 줄수:47 |
|
인코딩 문제 중에 해결 불가능한 문제는 없습니다. 다만 삽질을 좀 더 할 뿐입니다.
자신의 코드를 일일이 유니코드로 변환할 필요는 없죠. 처음부터 유니코드로 작성하면
되니까요. 다른 에디터나 OS 문제는 상상 속의 문제일 가능성이 큽니다. 실제로
popular한 OS와 에디터 대부분이 유니코드를 지원하는 상황에서 별 문제가 되진 않습니다.
이런 코드를 예시하셨는데....
List 현재여신처리리스트;
현재여신처리리스트 = 현재여신처리리스트가져오기( 현재시각 );
Iterator 현재여신처리리스트이터레이트객체 = 현재여신처리리스트.iterator();
while( 현재여신처리리스트이터레이트객체.hasNext() ) {
여신처리오브젝트맵 = (여신처리오브젝트맵).next();
log.info ( 여신처리오브젝트맵.get("여신고객번호") );
}
저라면 이렇게 쓰겠습니다.
List 현재여신목록 = 현재여신.처리목록();
while (Iterator iter = 현재여신목록.iterator(); iter.hasNext();) {
현재여신 = iter.next();
log.info(현재여신.get('고객번호');
}
한글이든 영어든 쓰는 사람이 얼마나 가독성을 고려해서 썼느냐가 가장 중요한 것이죠.
다만 똑같이 가독성을 고려해서 쓰는 사람이라면 모국어로 쓸 때 더 정확한 표현을
찾아낼 가능성이 높습니다.
변수는 한글인데 메소드는 영어로 생각해야 한다? 메소드도 한글로 쓰면 됩니다.
클래스, 메소드, 변수 다 한글로 가능하고 또 그렇게 쓰는 경우 많습니다.
영어를 잘하고 못하고는 한글 변수 문제랑 다른 문제입니다. 영어를 못해서 한글
변수를 쓰는 것이 아니라 영어가 한국의 SI에서 필요한 요구사항을 다 만족할 수
없기 때문에 한글 변수를 쓰는 것입니다.
오히려 영어를 잘하는 사람이라면 한글로 된 코드를 짜다가 문제가 생겨서 질문하고
싶을 때 질문할 부분을 금방 영어로 만들 수 있을 것입니다. 질문할 부분을 그렇게 요약할
능력이 없는 사람이라면 영어로 질문해서 좋은 답을 얻을 가능성이 높지 않겠죠.
|
제목 : Re: 허거덩...
글쓴이: 손님(guest) 2006/03/11 23:56:26 조회수:853 줄수:6 |
|
음 얼마나 많은 포팅 작업을 해보셨는지는 모르지만...
다른 사람들의 소중한 경험과 충고가 상상속의 문제이고...
해결이 불가능한 인코딩 문제는 없다는 장담을 하실 정도로 엄청난 경험을 가지신 분...
유윈이어여...
|
제목 : Re: 헐..
글쓴이: 멍멍(guest) 2006/03/12 00:10:41 조회수:708 줄수:7 |
|
그렇다면 당신의 경험 속에서 해결할 수 없었던 인코딩 문제나 에디터, OS 문제의
예를 좀 들어봐 주시겠습니까? 저의 짧은 경험 속에는 한글 문제로 삽질한 경험은 이루 셀 수
없이 많았지만 프로그래머로서 해결할 수 없는 문제는 없었기에 과연 실제로 어떤
문제가 있는지 몹시 궁금합니다.
머, 20년 전에 리눅스에서 한글 제대로 안되었다..라거나 unununium 같은 OS에서 한글 제대로
안 나오더라...같은 사례를 드시진 않으리라 믿겠습니다.
|
제목 : Re: 컨벤션에 관해 짧게 작성합니다.
글쓴이: Lamp(guest) 2006/03/13 10:47:43 조회수:1008 줄수:59 |
|
아래처럼 리펙토링 하셨지요..
List 현재여신목록 = 현재여신.처리목록();
while (Iterator iter = 현재여신목록.iterator(); iter.hasNext();) {
현재여신 = iter.next();
log.info(현재여신.get('고객번호');
}
하지만, 좀 더 심사숙고 하셔서 리펙토링 하셔야 할 듯 합니다.
oop 지향 프로그램을 만드신다면, 명확한 속성 정의는 물론, 객체에 대한 책임과
권한을 부여 하여야 합니다.
List 현재여신목록 = 현재여신.처리목록();
메서드는 행위를 나타내어야 합니다.
"처리목록" 이란건 명사일 뿐입니다. 현재여신 역시 앞의 List 란 타입이 있기때문에
목록이란건 알 수 있겠습니다만, 데이타의 진행 상태는 빠져 있습니다.
여기서 여러가지 접근법이 존재하겠습니다만. 저같으면 아래 둘중 하나로 처리 하겠습니다.
List 현재여신처리목록 = 현재여신처리.목록가져오기(); // 목록가져오기는 스테레오타입
List 현재여신처리목록 = 현재여신.처리목록가져오기(); // 처리목록가져오기는 스테레오타입
그리고 아래처럼 축약성 코드는 바람직하지 않습니다.
while (Iterator iter = 현재여신목록.iterator(); iter.hasNext();) {
현재여신 = iter.next();
log.info(현재여신.get('고객번호');
}
아시겠지만, 객체는 라이프 사이클에대한 가성과 범위를 나타내어야 합니다.
try-catch 구문을 감싼다고 가정해 보세요.
try {
while (Iterator iter = 현재여신목록.iterator(); iter.hasNext();) {
// ...
}
}
catch(){
}
위의 코드는 iter 레퍼런스에대해 catch 영역에선 잡아낼 수 없습니다.
될수있음 아래처럼 화일문 위에서 명확히 객체 할당을 하는것이 좋습니다.
Iterator iter = 현재여신처리목록.iterator();
|
제목 : Re: 글쎄요..
글쓴이: 멍멍(guest) 2006/03/13 11:02:30 조회수:830 줄수:41 |
|
OOP는 우리의 지향점이 아닙니다. 우리의 지향점은 알기 쉽고 제대로 동작하는 프로그램이죠.
OOP적이냐 아니냐가 그리 중요한 것은 아니라고 봅니다.
그러나...
대개의 경우 알기 쉬운 코드를 향해 가다보면 자연스럽게 OOP에 가까워집니다.
메서드명이 동사가 되어야 한다는 것 역시 일종의 고정관념입니다. 메서드명은
명사일수도, 부사일수도, 형용사일수도 있습니다. 그럼에도 불구하고 아주
읽기 쉬운 코드가 될 수 있습니다.
Mock Framework 중 하나로 JMock이란 게 있습니다. 이걸 사용하는 방법은 이렇습니다.
mockSubscriber.expects(once()).method("receive").with( eq(message) );
말씀하신 원칙대로라면 참 비 OOP적인 코드겠죠. 그런데 읽어보십시오. 무슨 말인지
금방 알 수 있지 않습니까?
좀더 aggressive하게 말한다면, 메서드가 동사형이 되어야 한다거나, 타입이 명시가
되어야 한다거나 하는 건 OOP와는 오히려 좀 거리가 있습니다. 타입을 명시하는 건
오히려 헝거리안 표기법적 발상이고 점점 지양해야할 것이 아닌가 싶습니다.
물론 자바라는 언어의 한계점을 감안하면 지양해야하는 정도는 아닐지도 모르겠지만요.
iter의 문제에 관해서는 DoTheSimplestThingThatCouldPossiblyWork의 원칙을
말씀드릴 수 있을 것 같습니다. 나중에 catch에서 iter에 대한 처리를 해야하는
상황이 올지도 모릅니다만 실제로 그런 일이 없는 상태에서 그런 코드를 작성하는
것은 리팩토링의 원칙으로 따지면 추측성 일반화에 해당하는 것입니다.
여기서도 좀더 aggressive하게 말해본다면, 오히려 객체의 라이프사이클을
고려할 때 for문 안에 iter이 들어가는 것이 더 바람직합니다. 대개는 for문
밖에서 iter이 쓰이지 않거든요. 그런데 Lamp님께서 예시하신 코드는 for나 while문
바깥에서 예외 처리 다 끝나고 나서도 레퍼런스가 살아 있습니다. 살아 있지 말아야할
공간에서 살아 있는 것이죠. OOP의 encapsulation은 이런 경우에도 해당될 수
있는 원칙입니다. 노출되지 말아야할 곳에 노출시키지 않는 것.
거기에 java 1.5에 추가된 for loop 간소화 문법을 생각한다면 제 주장에 좀더
설득력이 더해질 수 있을 것 같습니다. 1.5 문법상으로는 iter는 내부적으로만 쓰고
코드에선 있는지도 모르고 쓰게 됩니다. 1.5를 좋아하진 않지만 이런 간소화 문법은
중요한 발전이라고 생각하고 있죠.
|
제목 : Re: 물론 동의를 합니다
글쓴이: Lamp(guest) 2006/03/13 12:21:18 조회수:782 줄수:43 |
|
제목 : Re: 간만에..
글쓴이: 멍멍(guest) 2006/03/13 12:46:22 조회수:855 줄수:17 |
|
간만에 자바서비스넷에서 기술적인 이야기들이 오고가니 기분이 좋네요. ^^
근데 이번에 예시하신 코드가 어떤 점이 잘못이라는 의미에서 예시하셨는지
잘 모르겠습니다. userInfo라는 것을 일반화된 Hashtable이라는 객체로 사용하는
것에 대한 문제를 말씀하시는 것 같기도 하고 하여튼 좀더 부연 설명을 해주시면
감사하겠습니다.
컨벤션 이야기는 저도 공감합니다. 근데 이번에 제가 생각이 약간은 바뀌게 된 부분이 있는데..
워드 커닝험이라고 XP 창시자 중 한 사람인데 이 사람이 작성하는 코드를 보면
컨벤션도 잘 안 지키고 동사 명사 개념도 없고 그냥 막 씁니다. 근데 막상 그 사람이
작성한 코드를 그냥 쭉 읽어보면 아! 하고 금방 뭐하는 코드인지 알 수 있습니다.
말이 되는 코드를 작성하는 거죠. 위의 JMock 예시처럼요.
그래서 그런 걸 보면서 좀 생각이 바뀔려는 중입니다. 컨벤션을 지켜서 아, 저게
클래스고 이게 객체고 이건 메쏘드고 이건 변수고 이런 걸 금방 아는 것도 중요하지만
더 중요한 건 이것이 뭐하는 코드인지를 금방 알 수 있게 하는 것이 아닌가..그런 생각이 듭니다.
|
제목 : Re: 잘못이라고 표현하기엔 그렇고 NOTICE 정도로 인지하시는게.
글쓴이: Lamp(guest) 2006/03/13 13:46:24 조회수:2511 줄수:41 |
|
전 그저 단순히 루프안에 선언되어지는 userInfo 레퍼런스를 말한것이고
메모리 측면에서 레퍼런스와 메모리가 같이
반복적으로 생성되어지는것은 바람직하지 않아 보여서요.
사실 여러 프로파일링 리포트에서도 위의 형식은 피하라고 조언하고 있습니다.
멍멍님게서 말씀하신 커닝험이 작성한 코드는 본적이 없어 직접 찾아가 보았습니다.
http://www.artima.com/weblogs/index.jsp?blogger=ward
그분이 과거 MS 진영에 계실때 만든 c 코드와
위키 프로젝트에서 내놓은 Prototype Based Language Io 에 관한 랭귀지(?)
를 보았는데, 고수의 내공이 느껴집니다.
http://www.iolanguage.com/
제가 말씀드릴수 있는건, 그 분 역시 코드에서 엄격한 컨벤션을 지키고 있어 보입니다.
물론 동사와 명사를 명확히 지켜지는것 같진 않지만, 그것 보다 엄격 해야 할 쓰임새를
잘 표현하고 있기에 그분의 코드는 깔끔하고
느낌이 있는 코드라고 말씀 드리고 싶습니다.
위의 랭귀지 Io 는 어노테이션에 의한 프로그래밍 입니다. 이미 이것에 대한 사상은
자바 1.5 에서 흡수 했고, 구현된 아키텍쳐도 존재하며, 다양한 프레임워크에서도
사용되고 있습니다.
xdoclet 에서도 그렇고, ejb3.0 스펙과, javadoc를 위한 api 제네릭, 그리고 하이버 네이트,
omondo 이클립스 uml 툴에서도 사용하고 있죠.
개발자 여러분, 하나하나 터득해 가며, 즐거운 프로그래밍을 평생 할 수 있기를
희망합니다. ( 이거 안좋은 말인가요?, 전 좋은띃으로 말한겁니다. )
|
제목 : Re: 네
글쓴이: 멍멍(guest) 2006/03/13 15:01:45 조회수:713 줄수:24 |
|
적당한 예가 잘 기억이 안나서 그냥 방금 찾아본 거 하나 정도..
http://c2.com/~ward/java/parser/
맨 아래 쯤에 보시면 _를 쓰는 네이밍 룰과 CamelCase가 혼합되어 있는 코드를
볼 수 있죠. 이외에도 FIT 같은 것도 자바 패키지 네이밍 룰을 따르지 않고 그냥
fit에서 시작한다든지 등등 컨벤션을 절대적으로 생각하지 않는 코드를 종종 보여줍니다.
그리고 사실 자바보다는 다른 언어에서 좀더 그런 현상이 많은 것 같고 글 중에
예시로 드는 코드에서도 그런 모습이 종종 보입니다.
뭐, 고수가 한다고 다 옳은 것은 아니겠지만 다음 링크 정도로 생각하면 어떨까 싶습니다.
http://gene.kias.re.kr/~newton/wiki/moin.cgi/BreakTheRulesWhenItCompensates
그나저나 Io 언어 재밌죠? 저도 요즘 Io를 배우기 시작했는데 재밌네요.
점점 자바가 싫어지는 중입니다-_-
근데 루프 내 변수 선언 문제는 걱정하지 않으셔도 될 겁니다. 컴파일된 바이트코드를
보면 컴파일 단게에서 이미 최적화되는 것 같습니다. 이미 여러 뉴스그룹에서
관련 논의가 있었는데 대체로 상관 없다는 결론이 나오는 것 같습니다.
|
제목 : Re:예
글쓴이: 가가멜(guguly) 2006/03/15 14:28:23 조회수:794 줄수:19 |
|
재미있는 주제라서 저도 글을 올려봅니다.
OOP에 대해서도 네이밍룰에 대해서도 잘 모릅니다.
그러나 위 첫글에 나온 내용처럼 프로그램 가독성에 대해서는 한글이던 영어든 공감합니다.
그럼 왜 가독성이 좋은 코드가 필요할까. 자문해 봅니다.
저는 복잡한 프로그램이고 종류가 비슷한 프로그램 또는 처리가 같이 있기 때문입니다.
답은 간단한 프로그램으로 만들면 되지 않을까 싶습니다.
간단하다는것은 독립적이고 연결성이 좋다는 의미 입니다.
물론 때론 속도가 느릴수도 있는 결점을 가지고 있다고는 생각합니다.
코딩을 하면서 좀던 간단한 코드는 안나올까 자주 생각해 봅니다.
그러나 코딩이 주가 아닌 업무가 주이기 때문에 항상 벽에 부딫입니다.
업무에서의 복잡성을 코드화 하느라 가독성이 좋은 프로그램을 만들어야 한다.
업무가 간단하다면 이라는 생각을 해보지만 물론 그것은 저의 권한 밖에 있는일이라서.
코드 변수가 1,2,3,4 ABCD ㄱㄴㄷㄹ 이되건 몇개 안된다고 하면 코딩컨벤션 같은건 필요를 느끼지 못하지 않을까 싶네요.
말하는 요지는 프로그램이란것이 유니크하게 만들어져서 굳이 구별을 하지 않아도 알아볼수 있게
하자..입니다. 물론 어떻게 유니크 하게 라는 물음이 있는데 ... 그건 자답이 곤란하네요.
|
제목 : Re: 토드에서 함수명과 프로시저명이 ?????? 이렇게 나와서
글쓴이: 손님(guest) 2006/03/20 11:47:40 조회수:889 줄수:19 |
|
처음 글을 올렸던 사람입니다
한글변수 사용에 대하여 고민을 하게 되었던 이유는
우리나라 SI에서의 현실때문입니다
터무니 없이 짧은 기간에 업무분석시간도 안주는 상황,
소스를 까보고 분석하라는 ...
증권용어뿐 아니라 모든 업무용어가 그렇겠지만
구조체에 2~30개 용어가 들어가면 영문으로 쓰면 개발자마다 다틀리죠
그거 맞추다가 시간 다가고 게다가 영문이니 또 주석달아야 하는데
그것이 또 엉망입니다
시간 쫒기다 보니 프로그램이 돌아가면 그만인듯 합니다
이제는 교과서 처럼하는 FM사이트가 존재할까 라는 의구심마져 듭니다
지금 또 기존개발자가 영문으로 바꿔달라고 합니다
오라클 패키지의 프로시저를 한글로 바꾸었는데
토드에서 함수명과 프로시저명이 ?????? 이렇게 나와서 ....
제 생각에는 볼수있도록 토드의 문자설정을 바꾸면 될거 같은데 ...
알고계시분 좀 알려 주십시요
|
제목 : Re: 그냥
글쓴이: 손님(guest) 2006/03/20 12:50:45 조회수:809 줄수:1 |
|
제목 : Re: charset 설정이 어떤지..
글쓴이: 손님(guest) 2006/03/20 13:15:58 조회수:745 줄수:3 |
|
charset 설정이 어떤지 말씀해주시면 좀더 도움이 될 것 같군요.
오라클 클라이언트와 서버의 charset만 맞으면 toad에서 잘 나왔던 걸로
기억합니다만.
|
제목 : Re: 슬픈일..
글쓴이: cat(catbus) 2006/03/23 13:42:05 조회수:894 줄수:32 |
|
한글로 프로그래밍 하고 싶은 욕구는 모든 한국
프로그래머들에게 있습니다..
그러나 결론적으론 반대입니다..
한국에서 만든 os가 있습니까?
한국에서 만든 컴파일러가 있습니까?.
하다못해 한국에서 기본 아이디어를 낸
프로그래밍 언어가 있습니까?..
실질적으로 전혀 없습니다..
한글로 된 소스는 사용시간이 길수록,
여러 환경을 거칠수록 반드시 문제가 됩니다..
우리가 아는 모든 컴퓨팅환경은 모두 한글을 모르는
미국인들이 만든 거니까요...
그들이 아무리 조심스럽게 외국어를 고려해 준다고 해도
어딘가에선 반드시 문제가 생깁니다..
...
슬픈일이죠....
|
제목 : Re: 영문변수와 한글변수 사용예
글쓴이: 손님(guest) 2006/03/23 15:42:46 조회수:844 줄수:94 |
|
아래는 영문변수와 한글변수 사용입니다
기존개발자가 영문을 고집하느라
아래와같이 바꾼후에도 말을 많이 들었읍니다
별차이가 없어 보이지만 막상 복잡한 업무로직을 적용해 보면 틀립니다
적절하게 네이밍룰을 적용해서 한글사용을 하는 것이 현명하리라 판단합니다
업무도 제대로 이해하지 못하는 상태에서 소스까지도 암호니 ...
1.영문변수
Private Const SPD1_WITAKSANAME As Integer = 1 '위탁사명
Private Const SPD1_SANGPUMGB As Integer = 3 '상품구분
Private Const SPD1_MAMAECHEO As Integer = 4 '매매처
Private Const SPD1_SUMAMT As Integer = 5 '금액
Private Const SPD1_DEASAGB As Integer = 6 '대사
Private Const SPD1_COMMENT As Integer = 7 '적요
Private Const SPD1_GEORAECODE As Integer = 8 '거래코드
Private Const SPD1_SUDOBB As Integer = 9 '수도방법
Private Const SPD1_WITAKCODE As Integer = 10 '위탁사
Private Const SPD1_GEORAESEQ As Integer = 12 '거래번호
Private Const SPD1_CHURIGB As Integer = 13 '처리구분
'
Private Const SPDHWAN_WITAKSANAME As Integer = 1 '위탁사명
Private Const SPDHWAN_DATAGUBUN As Integer = 2 '데이타분류
Private Const SPDHWAN_DATAGUBUNNAME As Integer = 3 '데이타분류명
Private Const SPDHWAN_TABALJUM As Integer = 4 '타발점
Private Const SPDHWAN_SUCHIIN As Integer = 5 '수취인
Private Const SPDHWAN_CHIGYULIN As Integer = 6 '취결인
Private Const SPDHWAN_SUMAMT As Integer = 7 '금액
Private Const SPDHWAN_DEASAGB As Integer = 9 '대사
Private Const SPDHWAN_HWANSEQ As Integer = 9 '환일련번호
Private Const SPDHWAN_HWANCODE As Integer = 10 '환코드
Private Const SPDHWAN_SEQ As Integer = 11 '일련번호
중략 ~~
For iLoop = 1 To tmpRs.RecordCount
spdList_susin.SetText SPDHWAN_WITAKSANAME, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!위탁사명, ""))
spdList_susin.SetText SPDHWAN_DATAGUBUN, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!데이타분류, ""))
spdList_susin.SetText SPDHWAN_DATAGUBUNNAME, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!데이타분류명, ""))
spdList_susin.SetText SPDHWAN_TABALJUM, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!타발점, ""))
spdList_susin.SetText SPDHWAN_SUCHIIN, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!수취인, ""))
spdList_susin.SetText SPDHWAN_CHIGYULIN, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!취결인, ""))
spdList_susin.SetText SPDHWAN_SUMAMT, iLoop, Format(gCom.DB.IsNullDef(tmpRs!금액, 0), "#,##0")
If tmpRs!환입금확인 = "K" Then '대사
spdList_susin.SetText SPDHWAN_DEASAGB, iLoop, "1"
Else
spdList_susin.SetText SPDHWAN_DEASAGB, iLoop, "0"
End If
spdList_susin.SetText SPDHWAN_HWANSEQ, iLoop, Format(gCom.DB.IsNullDef(tmpRs!환일련번호, 0), "00000")
spdList_susin.SetText SPDHWAN_HWANCODE, iLoop, Trim(gCom.DB.IsNullDef(tmpRs!환코드, ""))
spdList_susin.SetText SPDHWAN_SEQ, iLoop, Format(gCom.DB.IsNullDef(tmpRs!일련번호, 0), "00000")
tmpRs.MoveNext
Next iLoop
2.한글변수
'/***********************************************/
'/* Spread List Index */
'/***********************************************/
Private Const SPD_펀드코드 As Integer = 1
Private Const SPD_펀드명 As Integer = 2
Private Const SPD_종목코드 As Integer = 3
Private Const SPD_종목명 As Integer = 4
Private Const SPD_구분 As Integer = 5
Private Const SPD_매매처코드 As Integer = 6
Private Const SPD_매매처명 As Integer = 7
Private Const SPD_좌수 As Integer = 8
Private Const SPD_금액 As Integer = 9
Private Const SPD_위탁사코드 As Integer = 10
Private Const SPD_위탁사명 As Integer = 11
중략 ~~
For iLoop = 1 To tmpRs.RecordCount
spdInfo.SetText SPD_펀드코드, iLoop, Trim(tmpRs("펀드코드"))
spdInfo.SetText SPD_펀드명, iLoop, Trim(gCom.DB.IsNullDef(tmpRs("펀드명한글"), ""))
spdInfo.SetText SPD_종목코드, iLoop, Trim(tmpRs("종목코드"))
spdInfo.SetText SPD_종목명, iLoop, Trim(gCom.DB.IsNullDef(tmpRs("한글종목명"), ""))
spdInfo.SetText SPD_구분, iLoop, Trim(gCom.DB.IsNullDef(tmpRs("구분"), ""))
spdInfo.SetText SPD_매매처코드, iLoop, Trim(tmpRs("매매처"))
spdInfo.SetText SPD_매매처명, iLoop, Trim(gCom.DB.IsNullDef(tmpRs("매매처명"), ""))
spdInfo.SetText SPD_좌수, iLoop, Format(gCom.DB.IsNullDef(tmpRs("좌수"), 0), "#,##0")
spdInfo.SetText SPD_금액, iLoop, Format(gCom.DB.IsNullDef(tmpRs("금액"), 0), "#,##0")
spdInfo.SetText SPD_위탁사코드, iLoop, Trim(tmpRs("위탁사"))
spdInfo.SetText SPD_위탁사명, iLoop, Trim(tmpRs("위탁사명"))
tmpRs.MoveNext
Next iLoop
|
제목 : Re: 슬퍼할 필요까지는 없는 것 같은데요..
글쓴이: 손님(guest) 2006/03/24 14:02:40 조회수:787 줄수:16 |
|
저한테
사과 하고 바나나 중
뭘 드시겠습니까. 라고 물어본다면
그때 기분에 따라 사과를 먹는다고 할 수도 있고
바나나를 먹는다고 할 수도 있습니다.
내가 사과를 먹는다고 할때 바나나를 먹는 사람에 대해
슬퍼하거나 기분나빠 할 필요가 없겠죠.
한글 변수명은 그때그때
프로젝트나 개발자 성격에 맞게 결정하면 될 사항이지
"쓰면 안된다" "써야 된다" 라고 할 사항은 아니라고 생각합니다.
|
제목 : Re: 고민 한번 해 봤습니다.
글쓴이: 사랑전쟁(lovewar) 2006/03/24 18:58:25 조회수:833 줄수:56 |
|
원론적인 이야기라 생각하시기 바랍니다.
금융권에서 일해 본적이 없기에
한글 변수를 사용해야 하는지, 원어를 약식으로 사용하는지에
대해서는 뭐라 말할 수 없을 것 같습니다.
단, 한글을 소리나는 대로 쓰는 기법은 이제는 좀 버려야 할
것으로 생각합니다.
그래서 이렇게 정의를 해 두면 좋지 않을까 생각합니다.
우선, 용어를 정리해 두는 것이 좋겠습니다.
한글로 되든 영어로 되든 정확한 의미를 지니수 있도록 하는 것이 좋겠습니다.
---업무별 용어 사전---
위탁사 : 거래를 위탁한 자(client, customer),
매매 : 사고 파는 행위 (trade),
종목 : 사고 파는 물건 (item),
좌수 : 당좌수표(check, cheque), 개인 가계수표(personal cheque : pcheque)
// check란 용어는 전산에서도 많이 쓰기에 혼동을 없애는 차원에서 cheque란 단어를사용함.
금액 : 총합계(amount), 가격(price)
구분 : 애매성을 없애기 위해 XX구분을 두는 것이 좋다.
처리구분 : 처리 상태(transaction state: TX state)
등등...
단순한 한글: 영어 형태라도 정리된 문서가 있으면 차후에도 도움이 될것이라 생각합니다.
이것을 wiki 시스템에서 관리하면 더욱 효과를 얻을 수 있을 겁니다.
아래 사이트는 예제입니다.
http://ko.wikipedia.org/wiki/%EB%8C%80%EB%AC%B8
그래서 다음과 같이 변경해 봤습니다.
Private Const SPD_FUNDCODE As Integer = 1
Private Const SPD_FUNDNAME As Integer = 2
Private Const SPD_ITEMCODE As Integer = 3
Private Const SPD_ITEMNAME As Integer = 4
Private Const SPD_TYPE As Integer = 5 // 구분이란 용어가 애매합니다.
Private Const SPD_OFFICECODE As Integer = 6 // 매매처가 뭔지 몰라 office로 정했습니다.
Private Const SPD_OFFICENAME As Integer = 7
Private Const SPD_CHEQUE As Integer = 8
Private Const SPD_PRICE As Integer = 9
Private Const SPD_CLIENTCODE As Integer = 10
Private Const SPD_CLIENTNAME As Integer = 11
조금씩 금융용어에 대해서 영어를 알고 있다면 차후에 도움이 될겁니다.
-- 덧붙이는 글 --
눈앞에 닥친 일이 아니라서 이렇게 글을 쓰고 있을지도 모릅니다.
전문화된 분야일수록 원어(?, 영어)에 대해서도 알고 있는 것이 좋다고 생각합니다.
|
제목 : Re: 시간이 문제입니다
글쓴이: 손님(guest) 2006/03/28 21:56:05 조회수:787 줄수:19 |
|
변수 하나 하나에 고민을 하고 의미있는 명칭을 줄수있는 시간이 없습니다
그리고 비슷한 용어가 나올경우 쥐약입니다.
물론 단어장을 만들어 사용하면 되지만 그렇게 하는곳도 별로 없지요
Gubun00 As Long '환일련번호
Gubun01 As String '환코드
Gubun02 As String '타발점
Gubun03 As Double '금액
Gubun04 As Long '일자
Gubun05 As String '수취인
Gubun06 As String '취결인
Gubun07 As String '내용
환일련번호를 영어로 하면 어떻게 ....
ExchangeSerialNo
하지만 용어가 워낙 비슷하게 많아서 업무에서 쓰는 용어 그대로를 한글로
쓰는 것이 가독성이 높은거 같습니다.
|
제목 : Re: 한글변수명 사용은 필요한 곳에서 꼭 시도해봐야겠습니다.
글쓴이: 오비완(guest) 2006/04/25 11:20:30 조회수:674 줄수:36 |
|
많은 분들이 써 놓으신 글들을 다 읽어보진 못했지만
정말 필요한 주제인듯합니다.
저도 평소에 한글 변수명 사용에 대해서는 반대적인 입장이긴 합니다.
솔직히 별 귀찮은걸 다....이런생각이지요
하지만 앞서 나왔듯이
증권사업무같은곳에서는 꼭 한번 사용해 보고 싶네요
제가 주로 하는 업무가 인트라넷 개발이라서 궂이 한글 변수명을 사용하지 않더라도
회사 업무라는 것이 다 비슷비슷한 면이 있기에 어려움이 없지만
가끔 학교사이트나 은행권사이트를 보게되면 상당히 어려움이 있습니다.
제가 경영학과 출신이라 증권용어나 은행용어 면에서 상당히 친숙한 면이 있지만
개발자 입장에서 그걸 한글로 작성해 놓으면 얼마나 좋을까라는 생각이 듭니다.
뭐 사이트 개발같이 궂이 범용성이랄까..이런거 고민안해도 되는곳은
영어를 고집하지 않아도 될듯 하네요
앞으로 한글 변수명을 사용하고 영문으로 주석처리하는 소스를 볼날이 올듯도 합니다.
개발하시는 분들은 전문용어를 많이 접하시겠지만
가끔 이런 생각도 있지 않나요?
'차라리 영어 원문을 써 놓으면 이해하기 편하겠다...'
변수명은 대표적인 한글로 작성하고 주석을 영어로 달아놓으면 오히려 이해가 편할수도...
솔직히 다른분들이 개발한 소스 많이 보지만
영어도 된 변수명을 보고 이게 무엇일까 이해가 잘 안가지만
그 옆에 한글로 써놓은 주석보면 더 이해가 안가는 경우도 많습니다.
어짜피 한글이냐 영어냐는 그 필요성에 따라 선택되어질테니
증권사이트 같은곳에서는 꼭 한번 사용해 보는것이 좋을듯 합니다.
윽....코딩하다가 글을 써다 보니 넘 두서가 없어서 죄송합니다.
|
제목 : Re: 변수명은 영문으로 하는것이...
글쓴이: 김신일(rootguy) 2006/08/25 10:59:01 조회수:741 줄수:14 |
|
요즘엔 신기술을 정말로 많이 나오고 방법적인 측면도 빠른속도로 개선이 되서 여러
웹사이트에 공개가 되는데, 보통 외국계열 사이트에 많은데, 더이상 개발자들은
영어공부를 미루지는 말아야 할 것 같습니다.
요즘에 야후영한사전 정말 좋던데.. 변수명은 야후영한사전을 검토해서 사용하는게
유지보수인력부터 여러사람들에게 좋지 않을가요? 변수명을 모르면 사전 검색을
하다보면 단어의 여러가지 의미도 알고, 영어공부도 하면서 1석2조의...
처음에는 다소 귀찮지만,
지식 = 귀찮다 * 귀찮다
무식 = 노력안해 * 노력안해
|
제목 : Re: 도데체 용어사전은 무었에다 쓰는 물건인지?
글쓴이: 손님(guest) 2006/08/30 17:05:16 조회수:781 줄수:2 |
|
|
