일단 직관적으로 짜세요. 그리고 성능이 안나오면 프로파일러를 이용하여 성능이 낮은곳을
찾고 그곳을 최적화 하면 됩니다. 직관적이지 못한 코드가 성능까지 낮다면 나중에 그걸
최적화 할려고 할때 무슨 코드인지 몰라서 최적화도 못하게 됩니다.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
혼자 작성하는 프로그램이라도 나중에 자신이 작성한 코드를 다시 보면 어떤 부분인지 모호해지는 경우가 있습니다. 예전에 프로세서의 성능이 낮을 때는 코드의 복잡도나 코드의 길이에 속도문제가 있었습니다만 컴파일러의 발달과 10년전과 비교했을 때 프로세서의 성능이 획기적으로 개선되면서 짧은 코드는 작성하지 않는 것이 좋은 것 같습니다.
물론 Embedded 업계에서는 여전히 함축된 코드 혹은 어셈블리어를 사용하는 경우는 있습니다만 이런 부분은 소수의 경우라 생각됩니다.
Embedded 시스템의 경우에도 프로세서 성능이 점차 개선되고 있는 상황입니다.
팀단위 개발에서는 모두가 가독할 수 있는 코드가 제일 중요한 것 같습니다.
그래야, 개인시간이 그나마 줄어드는 것을 막을 수 있지 않겠어요?
여기서 김창준님이 말씀하하시는 것처럼 처음에 쉬워보이는 코드가 나중에 점점 복잡성을 키워나갈 수도 있을테고...
또 팀의 사람에 따라서 달라질 수도 있다고 생각합니다.
매우 간단한 예로,
return sum > 0 ? OK : ERROR;
뭐 이런식의 단순해보이는 문장도, 만약 이게 학부 1학년 1학기 학생에게 주어지는 예제코드라면
복잡하고 어려워보일 수도 있을겁니다.
그리고, XPE에서 본건지 TDD 책에서 본건지 기억이 가물가물하지만, 간단한 파서를 만들어야 할 경우
팀이 파서생성기의 개념을 이해하고 있다면, 그것이 가장 쉬운 선택이고, 그렇지 않을경우에는
재귀적 하향 파서가 가장 쉬운(좋은??) 선택이다...라는 뭐 대충 그런얘기도 있었지 싶습니다.
완벽히 동일한 기능을 동일한 알고리즘으로 수행하는 코드를 괜히 어렵고 복잡하게 만들 필요는
없겠습니다만, 코드가 직관적이냐 아니냐는 팀의 구성원이 어떠한가에 따라 많이 달라질거 같습니다.
=================================================
Do the python !
=================================================
=================================================
Do the python !
=================================================
직관적인 코드.
직관적인 코드.
상황에 따라..
보통 팀프로젝트에선 가독성을 더 중요시 합니다.
그리고 짧은 코드라고 해서 가독성이 떨어지는 것은 아닙니다. sytax sugar(http://en.wikipedia.org/wiki/Syntactic_sugar)와 같은 표현은 쓰임도 쉽고 단순하며 가독성(직관적인..)또한 좋습니다.
혼자 만드는거라면 나만 알아보게 짜면 됩니다.
일단 직관적으로
일단 직관적으로 짜세요. 그리고 성능이 안나오면 프로파일러를 이용하여 성능이 낮은곳을
찾고 그곳을 최적화 하면 됩니다. 직관적이지 못한 코드가 성능까지 낮다면 나중에 그걸
최적화 할려고 할때 무슨 코드인지 몰라서 최적화도 못하게 됩니다.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
따지고 보면
따지고 보면 "직관적", "가독성"이라는 말이 상당히 어려운 말이라는 걸 느낍니다.
세상에 이런 사람도 있고 저런 사람도 있기 마련이기 때문에 직관적, 가독성을 바라보는 눈이 각자 나름대로 다릅니다.
각자의 직관적, 가독성으로 따지면 짧은 이름, 긴 이름으로도 말다툼이 일어나더군요.
두리뭉실한 "직관적"이나 "가독성"이라는 말보다는 abstraction을 잘 쓴 코드가 조금 더 명확하지 않을까 싶습니다.
좀 더 쉽게 중복되는 부분이 없는 코드라고 하는게 좋을지도 모르겠군요.
그게 아마도 누구나 만족할 "직관적"이고 "가독성"있는 코드가 아닐까요?
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
결국은
실제로 어떻게 짜든 성능 차이는 별로 안나는 것 같고..
전 항상 가독성 때문에 고민합니다..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
직관적인 코드에 한 표.
혼자 작성하는 프로그램이라도 나중에 자신이 작성한 코드를 다시 보면 어떤 부분인지 모호해지는 경우가 있습니다. 예전에 프로세서의 성능이 낮을 때는 코드의 복잡도나 코드의 길이에 속도문제가 있었습니다만 컴파일러의 발달과 10년전과 비교했을 때 프로세서의 성능이 획기적으로 개선되면서 짧은 코드는 작성하지 않는 것이 좋은 것 같습니다.
물론 Embedded 업계에서는 여전히 함축된 코드 혹은 어셈블리어를 사용하는 경우는 있습니다만 이런 부분은 소수의 경우라 생각됩니다.
Embedded 시스템의 경우에도 프로세서 성능이 점차 개선되고 있는 상황입니다.
팀단위 개발에서는 모두가 가독할 수 있는 코드가 제일 중요한 것 같습니다.
그래야, 개인시간이 그나마 줄어드는 것을 막을 수 있지 않겠어요?
상황에 따라...
상황에 따라... 그리고 앞으로의 방향에 따라 달라질 수도 있다고 생각합니다.
http://agile.egloos.com/5026291
여기서 김창준님이 말씀하하시는 것처럼 처음에 쉬워보이는 코드가 나중에 점점 복잡성을 키워나갈 수도 있을테고...
또 팀의 사람에 따라서 달라질 수도 있다고 생각합니다.
매우 간단한 예로,
return sum > 0 ? OK : ERROR;
뭐 이런식의 단순해보이는 문장도, 만약 이게 학부 1학년 1학기 학생에게 주어지는 예제코드라면
복잡하고 어려워보일 수도 있을겁니다.
그리고, XPE에서 본건지 TDD 책에서 본건지 기억이 가물가물하지만, 간단한 파서를 만들어야 할 경우
팀이 파서생성기의 개념을 이해하고 있다면, 그것이 가장 쉬운 선택이고, 그렇지 않을경우에는
재귀적 하향 파서가 가장 쉬운(좋은??) 선택이다...라는 뭐 대충 그런얘기도 있었지 싶습니다.
완벽히 동일한 기능을 동일한 알고리즘으로 수행하는 코드를 괜히 어렵고 복잡하게 만들 필요는
없겠습니다만, 코드가 직관적이냐 아니냐는 팀의 구성원이 어떠한가에 따라 많이 달라질거 같습니다.
=================================================
Do the python !
=================================================
=================================================
Do the python !
=================================================
감사합니다
많은 도움이 되었네요~^^
감사합니다~^^
댓글 달기