너무삐딱한 개발방법론 인가요..^^

혼자 작업합니까?
꼭 실력없는 사람들이 실력있는 행세를 할려고 가끔 저런 발언을 하는 것을 봤는데
저런 사람들 남기고 간 소스 보면 완전 개판 일분전이더군요
유지보수는 둘째치고 버그도 많고 정리도 안되고
과거는 과거일뿐 소프트웨어 개발방법은 여러 시행착오를 거치면서 발전하고있는것입니다.

적절한 주석은 필요 합니다..

주석 하나도 없는( 1번과 같은 생각을 하신 PM께서 친히 달린 주석을 깨끗이 정리 하신다능..)
프로젝트 소스를 볼일이 있었는데

한참 걸리더군요..

2. 이게 무슨 뜻인가...한참 헤멘적도 많습니다. 적절한 길이는 필요한듯 하네요

3. 한참 고민해서 짜놓은거...문서화 안해놓으니..나중에 내가짠건데도 이해가 안될때가 있더군요.

뭐 나머진 어느정도 동감 되는군요.

"더구나 다른사람이 본다면 주석만보고 아는체하기쉽상이다."

이건 개발자가 다른 개발자를 믿지 못한다는 얘긴데 서로 못믿는 상태에서 개발해서 성공하면 그게 이상하죠. 주석을 달고 안달고로 해결될 문제가 아닌 것 같은데요.

몇 번 인수 받아서 유지보수 하시면 조금 생각이 달라지실듯 하네요.

개발자들이 모두 존카멕이 아니죠. 똑똑한 사람도 있고 멍청한 사람도 있고...

언제나 멍청한 사람도 보았을 때 이해 할 수 있는 코드를 만들어줘야 합니다.

안 그러면 언제나 처음 만들 개발자 보다 같거나 똑똑한 사람만을 뽑아야하는데
그건 너무 희망적인 생각이 아닐까 합니다.

세상은 언제나 소수의 뛰어난 사람과 그 보다 조금 더 많은 그럭저럭 쓸만한 사람
그리고 좀 갑갑한 다수로 이루어져 있습니다.

PS> 반어법이지 않을까 싶은 글인데, 일단은 반어법이 아니라고 생각하고 썼습니다.
--

B/o/o/k/w/o/r/m/

방법론이라 보기에는 무리가 있네요.
그냥 자기중심적인 한 개발자의 의식의 흐름(?) 정도로 보입니다만...

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

남이 짠 코드는 오죽할까요;;

맘대로 짠 코드들이 쌓여서 결국에는 스파게티 모듈이 되어
일정시간후 처음부터 다시 짜는 삽질들을 곁에서 목격하면서
개발에서 제일 중요한건 가독성과 도큐먼트라는 생각을 갖게 되었습니다.
아무리 비효율적이어도 코드를 통채로 버리는 것보다는 나으니까요..

--
This is for you new people. I have just one rule :
Everyone fights, no one quits. If you don't do your job, I'll shoot you myself. Do you get me?

문서화를 정규화 할수로 다른사람들과 공유되어 개발 됩니다.
현장에서 오래 개발해봐다면.. 당연히 아는사실인데 .. 단지 그게 귀찮고 그러니 다들 꺼려하는거지만.
코드만 달랑보는거보다 흐름을 빨리 파악할수 있는데..

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

1. 웬만하면 주석을 달지마라.
> 코딩량이 길어질뿐아니라 코딩할때도 거추장스럽다.
주석은 코드가 아닙니다. 특히나 여럿이서 한 프로젝트에 일할때는 documentation과 서로간의 소통이 가장 중요하다고 봅니다.
본인이 주석을 달 때 거추장스러울지 몰라도 주석이 아예 없는 코드를 읽고 이해해야 하는게 몇 배로 거추장스러우며 비효율적입니다.

> 더구나 다른사람이 본다면 주석만보고 아는체하기쉽상이다.
편견에 사로잡힌 듯한 말씀이군요. 또한, 예를 들자면 모든 application developer가 framework 내부의 구동 원리를 알아야 해야 할까요?
어떤 부분이 안 된다면 이게 왜 안 되는지 찾기 위해 framework 코드를 읽으며 탐구하는 것만큼 쓸데없는 시간이 없을 겁니다.

> 실제코드자체를 분석하지 않고 얻은정보는 쉽게 내뱉어지며 논란의 대상이된다.
encapsulation의 원리를 정면으로 반박하는 말이군요.

> 이내 개발자의 입지를 약화시키며 원치않은방향으로 개발이 진행된다.
아닙니다. 기획자에게 코드를 들이대며 하나하나 설명할 정도로 시간이 많지 않습니다.
최소한 소통하는 개발자라면 기획자에게 어떤 기획이 왜 불가능한지 직접 설명할 수 있으리라 봅니다.

> 2. 네이밍을 너무길게하는것또한 웃긴일이 아닌가.. 차라리 당신의 2세의 이름이나 길게지으라..
> "김대한민국어디서몇년도에태어난김아무개몇대손앞으로무슨일을하길바란다"
> 집에서도 항상 성과함께 이름을 불러라. 그것이 효과적이라고 생각한다면..네이밍을 길게해도 좋다.

이런 개발론 때문에 특히 자바스크립트 코딩이 싫어집니다.
function do(obj)
특히 이런 거 좀...

> 웬만하면 길게하는것보다는 짧게하는방향으로 생각하라.
간결함과 짧은 것의 차이가 있습니다.

> 3. 프로그램자체에대한 알고리즘수준의 상세한 문서화를 하지마라.
> 알고리즘등을 작성하지마라. 문서는 업무흐름수준정도이상 작성하지 않는것이좋다.
첫번째 요점에 관련되기에 생략합니다.

> 코딩전에 하는것은 잘못된방향임을 알고도 코딩 해야하게될가능성을만들고 이후에하는것은
> 개선을 어렵게한다.
문제가 있으면 문서를 고치는 게 올바른게 아닐까요.

> 4. 코딩은 간결하고 효율적으로하되 어려운코딩을 지양하지마라.
> 쉬운코딩이랍시고 풀어쓰는것은 결국 프로그램을 더욱어렵게한다.
> 풀어쓰기시작하면 예외케이스가 늘어나고 분량이늘어나며
> 곧 더욱난해함을 불러낸다.
> 효율적이고 합리적이라면 그것은 코딩이 어려워진것이 아니라 쉬워진것을 의미한다.

동의합니다.

> 5. 표준이라는 명목으로 코딩방법이나 개발시스템을 강요하지마라.
> 공산주의나다름없다. 강하면강할수록 더욱빨리 시스템은 지저분해지고
> 수년내 폐기시켜야할지경으로 갈것이다.
> 세월이 흐름이따라 모든기술이나 방법들이 발전해가듯이.
> 당장그것이 최고라고 자부하지마라. 불과 수년내에 구닥다리가된다.
> 규제나 제한보다 더나은시스템을 토론하고 교육하라.
> 일부 똑똑한 개발자에의해 매우 효과적으로 변해갈것이다.

일부분 동의합니다.

> 6. 개발과 설계를 재대로 구분할줄알라.
> 보통의 설계자들은 개발에 관여하고싶어한다. 변수명을 어떻게하라는등, 무엇을 사용하여 작성하라는등.
> 자신이 원하는데로 개발하길원한다.. 그러나 설계나 제대로하라.
> 무엇이 필요한지에대한 요구사항이나 제대로 작성하여야한다. 개발은 개발자에게 맏기라.
> 그렇지 않다면 몇배의 비용을 지불해야할것이며 그러고도 오류투성이가 될것이다.

개발론이라기보다는 설계론에 가까운 말이군요.

> 7. 위의 모든 방법을 반대로 해야하는곳이라면 어쨋거나 따라주라...
> 그것은 결국 개발자의 생명을 더더욱연장시켜줄것이다.
> 하지만 재미는 없고 조만간 지치게되므로 미리 준비하는것이 좋을것이다.
잘 이해를 못 했습니다.

...And all in war with Time for love of you,
As he takes from you, I engraft you new.

-Sonnet XV

애자일, XP .. 기타등등 모두 마케팅적인 목적에서 나온 것들입니다.
그걸로 밥먹고 사는 사람들이 있다는 것만해도 왜 그것들이 자꾸 사람들의 입에 회자되는지 알수가 있지요.
실제로 현업에서는 그런 방법론이란 무의미합니다. 예를 들어, 아무리 빨리 프로토타입을 만들어봐야 클라이언트가 원하지 않으면 무의미합니다.
다양한 클라이언트와 그보다 더 다양한 개발환경과 그보다 더 다양한 개발자들에게 어느 한가지 방법론을 맞춘다는건.
마치, 혈액형별로 사람들 성격을 4가지 정도로 꿰찬다고 말하는 사람들과 같은 맥락이지요.
그 혈액형얘기는 일본에서 한때 잘팔린책의 출처일뿐더러, 그 책의 원저작자조차 100%는 확신할수 없다. 며 고백한 내용을 우리나라는 벌써 20년 가까이 A,B,AB, O 형을 들먹이며 성격을 짜맞추는 내용으로 인터넷을 도배하지요.
지금도 개발방법론은 이제 무의미하다는게 밝혀진 마당에 아직도 무슨 새로운 유행과 최신기술인양 떠벌리고 다니는 사람들을 보면 정말 공개적으로 반박하며 사기꾼 이라고 하고도 싶을 정도입니다.
하지만, 그런 개발방법론이 먹힐 분야가 1%라도 존재하기도 하니 100% 사기라고 단정할수 없어서 그러지 못하는것뿐이지요.
결론은, 무슨 방법론이 진리인양 떠드는 사람들 말은 안믿는 것이 좋습니다.
세상엔 사기꾼들이 자주 쓰는 단어, 숙어가 몇개 있지요.
"진리, 획기적, 100%, 새로운, 혁신, 혁명, 누가 쓰더라, 누가 하더라"