|
|
| 지상현 2011-05-15 PM 3:27:00 |
|
|
|
참고: 퍼포먼스나 명확성 면에서는
문자창보여("0123456789");
도 괜찮겠지요? |
|
|
|
| 성인e 2011-05-16 PM 6:14:59 |
|
|
|
| 지상현 // 확장성이 있고 무엇보다 반복문에서 거의 필수로 들어가는 실수 변수가 포함되지 않았다는 점에서 '이렇게도 코딩이 가능하구나' 는 걸 보여주고 싶었습니다. 이를테면 00에서 99까지 붙여서 출력할때에 유리합니다. |
|
|
|
| 지상현 2011-05-16 PM 10:47:43 |
|
|
|
네. 그렇기에 저는 일부러 반대로 제시한 것입니다.
코딩을 할 때는 어떤 알고리즘을 쓰는 것도 좋지만 사람이 읽었을 때 무엇인지 바로 알 수 있는 명확성이 더 중요할 때도 있으니까요.
그 점에서 일부러 풀어서 나온 예를 제시했습니다.
또한 위에서 적으신 구조로는 자릿수가 한 자리일 때만 해당하는 것이고, 00에서 99까지 출력할 때는 012345678910 까지 출력한 다음에는 11이 나오지 않고 01234567891013 같은 식으로 나오겠지요?
즉, 말씀하신 확장성이 실제로는 위 코드에선 결여되어 있다는 부분을 지적하고 싶었습니다. 여기서 신경쓸 만큼 중요한 부분은 아니지만 대부분 반복문에서는 그냥 카운터 변수를 두는게 좋습니다.
물론 말씀하신 것 같은 방법이 필요한 곳도 많겠지요.
그렇지만 오히려 그 반대의 방법으로 가는 것이 이득이 더 많을 때도 있다는 것을 말하고 싶었습니다. |
|
|
|
| 지상현 2011-05-16 PM 10:48:52 |
|
|
|
| 위에서 01234567891013가 아니라 01234567891012 입니다. 잘못 쳤네요. |
|
|
|
| 성인e 2011-05-17 AM 1:09:24 |
|
|
|
문자:긔;
되풀이(문자길이(긔)＜200)
{긔:=긔+수를교정문("00",문자길이(긔)/2);}
문자창보여(긔);
output : "00010203 ... 9899" |
|
|
|
| 지상현 2011-05-17 AM 1:36:22 |
|
|
|
저는 위 코드에 나온 아이디어를 빼고, 위와 같은 코딩 방식이 나쁜 이유에 대해서만 적어보겠습니다.
1. 확장성이 있다 하셨지만 다시 수정하신 것처럼, 조건이 바뀌면 코드를 다시 고쳐야 합니다. (확장성이 떨어집니다.)
2. 창조에선 문자 길이를 구하는 함수가 O(1)이라 얼핏 위 함수는 O(n)처럼 보이지만, 다른 환경에선 문자 길이를 구하는 함수가 O(n)일 수도 있습니다. 그런 경우 위 방법은 O(n^2)이 되고, 효율이 나빠집니다. (이식성이 떨어집니다.)
3. 작성한 본인은 당연하고 코드 자체가 길지 않아 분석하는데 큰 어려움이 없긴 하지만, 제3자가 봤을 때 어떤 역할을 하는지 코드를 분석하지 않으면 금방 와닿지 않습니다. (가독성이 떨어집니다.)
궁극적으로, 숫자 사이에 공백을 추가한다거나, 아니면 수를 0.1씩 증가시키려면 많은 부분을 고치지 않으면 안 됩니다. 데이터 길이가 자릿수에 기반하여 일정하게 증가한다는 가정을 깔고 있기 때문입니다.
오히려, 점점 자라나는 데이터를 재귀적으로 이용한다는 발상 자체는 멋지다고 생각하지만, 단순히 카운터 변수 대신 문자 변수로부터 길이를 구한 거라면 효율과 가독성이 너무 나쁘다고 생각합니다.
적다보니 너무 '이 방법은 나쁘다'는 식으로 전개됐는데, 제시하신 코드가 가지고 있을지도 모르는 어떤 문제점들을 제시했다고 생각해주시기 바랍니다.
저도 데이터를 생성하는 과정에서 생성 중인 데이터의 일부를 이용한다는 점은 유용한 방법이라 생각하니까요. |
|
|
|
| 성인e 2011-05-17 PM 10:25:07 |
|
|
|
문제점이라.. 저 문제점들은 너무 당연합니다;;
그리고 프로그래밍은 가독성보단 효율성을 중요시합니다.
아무리 가독성이 좋아도 느리면... 그닥 좋은 코딩이라고 볼 수가 없네요 저는.
다음과 같은 합을 생각해봐요.
1.
1+2+3+4+5+6+7+8+9+10+11+...+n
2.
n*(n+1)/2
물논 1번 가독성 좋아요. 헌데 2번보단 효율 떨어져요.
확장성은 좋겠죠.
1.
1^2+2^2+3^2+...+n^2
2.
n*(n+1)*(2n+1)/6
2번은 가독성 초 떨어져요. 근데 누가 1번으로 할까요.
그리고 다음과 같은건 2번으로 안돼요.
1.
1^1+2^2+3^3+...+n^n
확장성 초 떨어져요.
이 글은 확장성 따져보니 안좋다, 연산 횟수가 많아진다, 이런 평가를 쓰라고 한 것이 아닙니다.
그것들은 뉘든 쉬 아는 것입니다.
이 글은 가능한한 메모리를 조금 써서 코딩을 하는 방법을 일러줍니다. |
|
|
|
| 지상현 2011-05-17 PM 10:30:12 |
|
|
|
논점이 조금 벗어난 것 같습니다.
위에서 제시하신 1번과 2번은 문제를 푸는 해법과 알고리즘이 다른 것입니다.
가독성이 좋은 코드란 딱 보았을 때 직관적으로 무슨 말인지―컴퓨터가 아닌 사람이―이해하기 쉽게 짜는 것을 말합니다.
이후 제시하신 부분은 가독성 문제를 떠나 아예 알고리즘이 다른 거구요.
제일 처음에 올리신 코드는 카운터 변수가 문자열 길이로 숨어있을 뿐이지 카운터 변수를 뺀다고 해서 알고리즘이 바뀌는건 아닙니다.
제가 말씀드린 확장성은 가독성과도 연관이 있습니다.
코드는 글쓰기와 같습니다.
한 번 작성하고 내팽겨치는 것이 아니기 때문에, 반드시 유지 보수가 필요합니다.
그런 맥락에서 가독성은 아주 중요합니다.
가독성이 좋은 코드는 효율이 나쁘더라도 나중에 개선하기가 쉽지요.
효율이 좋다는건 컴퓨터 입장에서 효율이 좋다는 건데, 실제로 가독성을 희생하면서 효율을 강조할만큼 컴퓨터가 느리지 않습니다.
섣부른 최적화는 안 하느니만 못하다고 하지요.
제가 말씀드리고 싶었던건 이러한 점을 말씀드리고 싶었습니다.
일단 나중에 예로 제시하신건 케이스가 다른 거구요.
엄밀히 따져보면 위에서 제시하신, 카운터 변수를 쓰지 않는 방법이 메모리도 적게 먹는게 아닐 뿐더러 속도도 더 느릴 수 있습니다.
프로그래밍은 가독성보다 효율성을 중요시한다 하셨는데, 그것은 참이 아닙니다. 가독성도 중요하고 효율도 중요하기에 둘 다 살리는 것이 중요합니다. 다만 둘 중 하나를 희생해야 할 경우가 생기는데, 이 경우에도 어느 하나를 무조건 우선적으로 중요시 하는게 아니고 전체적으로 어느 것을 골라야 득이 되는지를 찾아보고 결정하는게 맞습니다.
요지는 크게 두 가지입니다.
1. 코드는 사람도 읽어야 하기 때문에 최대한 알아보기 쉽게 작성합니다. 최적화가 필요하면 일단 작성한 다음 리팩터링과 프로파일링을 통해 구조를 개선합니다.
2. 처음부터 서브루틴을 최적화나 효율을 염두에 두고 짜지 마세요. 프로그램은 '정확히' 동작하는게 가장 중요합니다. 일단 정확히 동작하는 것을 만든 다음, 마찬가지로 리팩터링과 프로파일링을 통해 효율을 개선해야 합니다.
느린 알고리즘은 빠른 알고리즘으로 교체할 수 있습니다.
가독성이 좋은 코드는 나중에 가독성이 나쁘더라도 더 빠른 코드로 개선할 수 있습니다. 원래 코드는 주석으로 남길 수도 있겠지요.
최종적으로 제가 지적하고 싶었던건, 위 코드는 "일회성 코드"라는 것입니다.
문제 하나를 풀기 위해 잠깐 만들고 버리는 코드라는 거지요.
이런 코드를 만들어내는 것은 일반적으로 좋지 않다고 합니다.
코드는 재사용 하는게 좋기 때문에요.
제가 처음부터 지적하고 싶었던건 사실 효율이니 뭐니 하는게 아니라, 위 코드가 일회성 코드라는 점이었습니다. |
|
|
|
| 성인e 2011-05-17 PM 10:42:34 |
|
|
|
음냐..
무슨 말 하시는지 모르겠네요.
일회성코드를 올린게 잘못인가요.
당연한 걸 자꾸 걸고 넘어지지 말아주세요. 귀찮네요. |
|
|
|
| 지상현 2011-05-17 PM 10:54:02 |
|
|
|
잘못했다는게 아니라, 같은 문제를 푸는 여러 방법에 대해 말씀 드린 거지요.
그 중에서 저는 성인e님께서 올리신 방법의 장점이 아닌 단점만을 말씀드린 거구요.
그리고 어디가 당연한 건지는 잘 모르겠네요.
이런 저런 문제가 있는데, 따져보지 않고 그냥 당연하게 알 수 있다는 뜻인가요? |
|
|
|
| 성인e 2011-05-17 PM 10:59:58 |
|
|
|
그냥 눈에 훤히 보이잖아요?
이런 뻔한 걸 들어내서 트집잡는 거 정말 싫어합니다 저.
지상현 님께서 말씀하신 모든 지적들은 제가 알고 있던 것들이었습니다.
상대방의 지적 수준을 너무 낮게 잡지 말아주세요. |
|
|
|
| 지상현 2011-05-17 PM 11:14:50 |
|
|
|
트집 잡는 것이 아닙니다.
지적 수준을 낮게 잡다니, 그런 적 없습니다.
특히 게시판은 모두가 보는 곳이기 때문에, 성인e님께서 빼먹은 부분을 제가 보충했다고 생각하시면 될 것입니다.
성인e님은 다 아신다고 쳐도, 이 글을 보는 다른 사람들은 모를 수도 있잖습니까?
저도 성인e님께서 다 아신다고 하기 전까진 몰랐으니까요.
다시 말씀드리지만 트집을 잡는게 아니라, 설명이 빠진 부분을 보충하는 마음으로 적은 것입니다. |
|
|
|
| 지상현 2011-05-17 PM 11:22:27 |
|
|
|
혹시 제가 말씀드린 것 중에 기분 나쁜 것이 있었다면 사과 드립니다.
저는 성인e님과 논쟁을 하거나 트집을 잡으려 한 게 아니라, 모두가 볼 수 있는 게시판에서, 창조 관련해서 이것 저것 이야기를 해서 발전적인 토론 비슷한 것을 하고 싶었을 뿐입니다.
특히 성인e님께서 올리신 글은 설명이 빠져있었기 때문에―그냥 눈에 훤히 보인다고 하시지만 저같이 그런 능력이 없는 사람도 많습니다―빠진 내용을 보충하고자 하는 의미로도 적은 것입니다.
저로선 어느 부분이 언짢으셨는지 모르겠지만, 제 의도를 이해해주시고 양해해주셨으면 합니다. |
|
 |
지우개 Expert 3.0
제작자 : 천호성 님 [LINK] |
|
|
 |
대박로또2005
제작자 : 최재일 님 [LINK] |
|
|
| 1 | 박종훈 님 | 15292 점 | |
| 2 | 지상현 님 | 8809 점 | |
| 3 | 손상진 님 | 7388 점 | |
| 4 | 권선중 님 | 6060 점 | |
| 5 | 이진백 님 | 5174 점 | |
|
|
|
| 가입일 | 닉네임 |
| 05/31 | 김동률 |
| 03/31 | 홍형기 |
| 09/01 | o00pp99oo |
| 12/27 | 이재민 |
| 11/20 | 이희철 |
|
|
|
|
