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

select99의 이미지

개발방법론
1. 웬만하면 주석을 달지마라.
코딩량이 길어질뿐아니라 코딩할때도 거추장스럽다.
더구나 다른사람이 본다면 주석만보고 아는체하기쉽상이다.
실제코드자체를 분석하지 않고 얻은정보는 쉽게 내뱉어지며 논란의 대상이된다.
이내 개발자의 입지를 약화시키며 원치않은방향으로 개발이 진행된다.
2. 네이밍을 너무길게하는것또한 웃긴일이 아닌가.. 차라리 당신의 2세의 이름이나 길게지으라..
"김대한민국어디서몇년도에태어난김아무개몇대손앞으로무슨일을하길바란다"
집에서도 항상 성과함께 이름을 불러라. 그것이 효과적이라고 생각한다면..네이밍을 길게해도 좋다.
웬만하면 길게하는것보다는 짧게하는방향으로 생각하라.
3. 프로그램자체에대한 알고리즘수준의 상세한 문서화를 하지마라.
알고리즘등을 작성하지마라. 문서는 업무흐름수준정도이상 작성하지 않는것이좋다.
코딩전에 하는것은 잘못된방향임을 알고도 코딩 해야하게될가능성을만들고 이후에하는것은
개선을 어렵게한다.
4. 코딩은 간결하고 효율적으로하되 어려운코딩을 지양하지마라.
쉬운코딩이랍시고 풀어쓰는것은 결국 프로그램을 더욱어렵게한다.
풀어쓰기시작하면 예외케이스가 늘어나고 분량이늘어나며
곧 더욱난해함을 불러낸다.
효율적이고 합리적이라면 그것은 코딩이 어려워진것이 아니라 쉬워진것을 의미한다.
5. 표준이라는 명목으로 코딩방법이나 개발시스템을 강요하지마라.
공산주의나다름없다. 강하면강할수록 더욱빨리 시스템은 지저분해지고
수년내 폐기시켜야할지경으로 갈것이다.
세월이 흐름이따라 모든기술이나 방법들이 발전해가듯이.
당장그것이 최고라고 자부하지마라. 불과 수년내에 구닥다리가된다.
규제나 제한보다 더나은시스템을 토론하고 교육하라.
일부 똑똑한 개발자에의해 매우 효과적으로 변해갈것이다.
6. 개발과 설계를 재대로 구분할줄알라.
보통의 설계자들은 개발에 관여하고싶어한다. 변수명을 어떻게하라는등, 무엇을 사용하여 작성하라는등.
자신이 원하는데로 개발하길원한다.. 그러나 설계나 제대로하라.
무엇이 필요한지에대한 요구사항이나 제대로 작성하여야한다. 개발은 개발자에게 맏기라.
그렇지 않다면 몇배의 비용을 지불해야할것이며 그러고도 오류투성이가 될것이다.
7. 위의 모든 방법을 반대로 해야하는곳이라면 어쨋거나 따라주라...
그것은 결국 개발자의 생명을 더더욱연장시켜줄것이다.
하지만 재미는 없고 조만간 지치게되므로 미리 준비하는것이 좋을것이다.

다즐링의 이미지

말만 삐딱하게 쓰신거 같은데요 -.-;;;

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

system77의 이미지

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

select99의 이미지

과거에 얽메이지말고.. 발전하라는뜻인데요...

pokev25의 이미지

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

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

한참 걸리더군요..

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

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

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

system77의 이미지

혼자 메모장 프로그램 만들으면서 그런식으로 개발하세요.

아무도 상관안할듯

jick의 이미지

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

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

ymir의 이미지

7번을 쓰신 걸로 봐서, 그냥 농담으로 적으신 것 같은데...흠...

추가로 http://mindprod.com/jgloss/unmain.html 의 내용을 모두 마스터 한다면...
회사에서 독보적인(?) 존재가 될 수 있을 겁니다..
좋은 쪽으로든 나쁜 쪽으로든... ㅎㅎ

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

bookworm의 이미지

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

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

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

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

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

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

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

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

codebank의 이미지

멍청한 사람은 아무리 잘 정리된 소스를 보더라도 그게 잘된건지도 모를 수 있습니다.
(아~~~ 찔린다...)

사실 개발은 똑똑한 사람만이 하는게 맞습니다. 단, 똑똑하지 않은 사람이 필요한
경우는 명수를 채우기 위해서...(음~~~ 이것도 찔린다... :-))
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

bookworm의 이미지

경력 20년의 천재적인 능력의 개발자가 간단한 입력툴을 개발하고 있다고 생각 해보세요.
입력툴 정도는 대학 방금 졸업한 사람도 충분히 만들 수 있습니다. 천재 개발자의 시간이 아까운
일입니다. 그러나 없으면 개발이 안 되죠.

개발이란 것이 이렇듯이 천재적인 사람 한둘로는 품질을 올릴 수 있을지언정 양을 늘릴 수는
없습니다. 사람인 이상 키보드 입력하는 속도의 한계가 있으니까요. ㅎㅎ.

그래서 개발은 소수의 훌륭한 개발자와 다수의 적당히 쓸만한 개발자를 묶어놓는게 최선이라고
봅니다.

부가적으로 훌륭한 개발자들 덕에 적당히 쓸만한 개발자들도 실력이 꽤 오르죠.

--

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

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

codebank의 이미지

제가 글을 올린 이유는 저와같은 '멍청한'개발자의 존재여부입니다.
'쓸만한'개발자를 말하는게 아니죠. '쓸만한'개발자라면 그들도 '훌륭한'개발자에
속하지는 않지만 나름대로의 역할을 다하고 있다고 생각합니다.
제가 말하고자하는 '멍청한'개발자는 사실 IT쪽에서 별로 쓸모가 없는 다른 일을
찾아봐야하는 사람들을 뜻합니다.
잘 동작하고 있는 코드를 뜯어고쳐서 엉뚱하게 동작하게 만들거나 원래대로 복원시켜야하는데
백업관리 잘못해서 그것도 못하게 되었거나, 고객은 부산을 가길 원하는데 삼천포로
빠지거나 등등의 그 뜻을 헤아리지 못하는 사람들을 뜻한 겁니다.

학교나 학원에서 'Hello, world'의 출력을 배웠다고 이제부터 나도 프로그래머를
외치며 다니는 사람은 없겠지만 (배움이 적은 제가 가끔 듣기에도 민망한 초보적인
프로그램이야기를 아무렇지 않게 전철에서 그것도 틀린점만 강조해서 떠드는 몇몇
사람들을 볼 때면 그런 사람들도 꽤있는것 같지만...) 어쨌든 그러한 사람들이
'훌륭한'개발자가 만들어놓은 프로그램을 망쳐놓지는 않을지 걱정이 되어서 써놓은
글입니다.

아주 극단적으로 말하면 사람들이 모두 대학교를 나와서 생산직엔 사람이 모자라고
대학교를 졸업한 사람들은 눈높이가 맞지 않아 취직하지 못하고 있는 지금이 어이없어서
쓴 말이기도 합니다. -.-; (저부터 다른 자리를 알아 봐야하는데 말이죠...)
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

semmal의 이미지

별로 멀지 않은 과거에, 모 회사에서 C++프로젝트에 VB프로그래머를 투입했는데, 다형성을 이해못하는 그 분(?)께서 친절히 모든 클래스를 슈퍼클래스로 바꿔주시는 바람에 어느 날 갑자기 프로그램이 동작하지 않게 되었지요. 저는 cvs를 쓰고 있으니 정상적인 상태였던(?) 시절로 되돌리자고 주장했지만, 그 분의 기준으로는 꽤나 오랬동안 작업했던(당연히도...) 터라, 훌륭하게도 긴 시간을 투자해서 전부 슈퍼클래스로 동작할 수 있도록 잘 바꿔주시더군요. 덕분에 아무 일도 못하게 스턴걸린 채로 정신공격 크리를 먹고 스트레스 500% 상승한 적이 있습니다. 당연히 시간이 갈 수록 예전에 없던 버그가 하나 둘 발견되고, 당연히 모른척(아마도 진짜 몰라서겠지만...)하는 그 분 덕에 저만 힘들었습니다.
거기에 버그나면 지래짐작으로 코드 이곳 저곳을 마구 바꾸어대는 방법론(?)을 쓰시는 분에게, 조금이라도 확신을 가진 다음에 그 부분을 고치자라고 주장했지만 비슷한 수준의 분들에게 협공을 받고 침몰한 적도 있구요. 그래도 그 분들이 속한 곳이 IT쪽에서는 알아주는 대기업이랍니다. 을의 슬픔이랄까... 아마 다들 10년은 더 이 분야에 계실 것 같은 분위기인데... 속으로는 빨리 다른 분야로 가시는게 우리나라 IT를 돕는 것이라 생각중입니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

kkb110의 이미지

전 아무리 봐도 농담조이신거같은데 -_-;

M.W.Park의 이미지

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

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

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

itlognext의 이미지

5번에 feel 이 꽃히는 저는 외톨이 인가요?

왜 어디서나 언제나 오로지 표준을 강조하는 것은 결코 좋은 것은 아니다라고 생각하고 있습니다.

ldgood의 이미지

프로젝트내에서 사용되는 정형화된 규칙이라면 저도 완벽하게 지키기 보다는 효율을 중시해서 일부 변형하는 것이 좋다고 생각합니다.

그런 의미로 쓰신내용은 아니겠지만,

그러나 XACML, SAML이나 SOAP등 스펙이 정해진 표준을 구현에 맞춰 수정해서 임시방편으로 사용하는 것은(일부 커스텀 태그를 추가한다던가) 옳지 않다고 생각합니다. 특히 1번을 중요하게 생각하는 개발자라면 말이죠.

표준을 지키지 않으면 그것은 어떠한 방법이 라고 불릴 수 없습니다. 단지 보잘것 없는 마이너리티 리포트에 불과하게 되죠.(just an opinion) 표준은 근거입니다.

'왜 어디서나 언제나 오로지' 라는 추상적 표현은 역으로 생각하면, 사람에 따라 굉장한 개념적 생각의 틈을 만들 수 있습니다.

모든것은 모든것에 잇닿아 있다.


------------------------------
모든것은 모든것에 잇닿아 있다.

익명_사용자의 이미지

제가 표준을 신경쓰지 않는 사람들에게 묻는 말이 있습니다.

"왜 이 표준이 생겼는지 아나요?"

대부분 대답은...(대부분 질문에 대한 대답은 하지 않습니다.)
"표준이고 나발이고 이거 돌아 가잖아...돌아가는데 왜 자꾸 GR이야?"

표준이 왜 생겼고, 과연 표준이 말하자고는 바가 뭔지 아는것은 정말 중요합니다.
표준은 그냥 아무렇게 생긴게 아닙니다.
세계의 전문가들의 많은 기간동안 고민하고. 심사숙고, 검토하고 해서 정말 어렵게 통과합니다.

표준을 지키지 않는 부분이 있다면, ****왜**** 표준이 부합하는 코드를 짰는지 이유를 주석으로
달아놓고, 여러 가정들을 상세하게 써 놔야합니다.( 가령, 이건 윈도 intel x86에서만 돌아가는 프로그램이다. 절대 어느 플랫폼, CPU에서도 절~~~~대 돌리지 마라. 난 아무것도 책임질수 없다 )

혹시, 제가 말하는 표준의 정의를 말하자면...
ISO에 등록되고, IETF에의해 관리되며, RFC문서가 존재하는것들을 표준이라고 합니다.

행여,,닷넷 표준
윈32 표준 그런 표현을 쓰는 분들이 더럿있어서..

여기부터는 서명입니다.
"저는 인터넷에서 숨어서 정확한 의견을 피력하는 자들과 말을 섞습니다."

mirheekl의 이미지

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

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

--
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?

--

winner의 이미지

꼭 틀린 말은 아니라고 생각합니다.

huss5210의 이미지

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

winner의 이미지

문서는 위에서 시키면 구색으로 쓰고요.
문서는 그냥 내가 했다라는 기록일 뿐임. 이해는 합니다. 위에서 문서쓰기를 권장하고, 때로는 요구하고, 때로는 윽박지르지만 작성된 문서가 읽히지 않는다면 의미가 없죠. 그리고 정말 가치있는 문서를 작성하는 것은 구현작업만큼 시간을 요구하지만 위에서는 그걸 용납하지는 않으니, 원하는 만큼의 품질을 만족시켜주는 거겠죠. 그냥 분량채우고 구색맞추기.

요구사항을 명확히 정의하기 싫어하는 기획자도 있습니다.
개짜증남.

협업의 의미를 아는 건지 어떤건지.
이승철이었던가? 아이돌들에게 음악제작 전체과정에 참여해봐야 한다고 말했던 것으로 아는데 programming도 마찬가지라고 생각합니다.

제가 작성한 문서가 보기 좋은 것은 아니지만 어제 들었던 소리가 DB 헝가리안에 대한 것이었습니다. DB 설계는 제가 했는데 TB, VW 접두사가 없는 것을 문제삼더군요. 저는 향후 DB가 변경되면서 호환성을 위한 추가 table, view를 고려할 때 접두사가 없느니만 못하다고 생각했습니다. 뭐 덜렁 만들어두기만 했다면 제가 잘못한 거겠죠. 하지만 문서에 무엇이 table이고, 무엇이 view이며 view를 위한 기반 table은 무엇임을 명시하고, table 관계를 명시해두었으니 접두사가 없는 것이 문제는 아니라고 말하니 제가 유지보수 다 할거냐는 대답이 오더군요. Source를 보고 수정하지, 누가 문서보고 수정하냐라는 말씀을...

물론 제 생각이 팀 전체의 기존 생각을 바꿀 수는 없지요. 제 생각이 옳은 것인지도 알 수 없지만 기존 관습도 존중되어야 해야 할 겁니다.

그래도 그분은 저랑 같이 작업을 해서인지 최소한 제가 갖다 바치는 문서에 대해서 의미가 있다고 보시는 것 같습니다. 문서 작성하고, e-mail로 interface 변경필요성을 세밀하게 이야기하면 그대로 따라주시더군요. 그런데 이번에 같이 작업하는 기획은 할 말이 없더군요. 자기가 요청한 것에 대해서 설계과정도중 요구사항 우선순위와 불명확하거나 해소될 수 없는 부분이 있기 때문에 논의를 하면 그걸 왜 자기한테 묻냐고... 자신이 요구사항을 내면 해결과정은 알아서 고민하라고... -_-.

아, 젠장. 이거 반은 제가 제안해서 작업하는건데(반은 기획자이자 사용자인 그 분) 괜히 하자고 말했다는 생각마저 들더군요.

madman93의 이미지

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

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

sisuc의 이미지


"말은 코드로 해라"

이런느낌이네요

어느정도 공감갑니다.

위대한 한글

위대한 한글

niuzeta의 이미지

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

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

-Sonnet XV
전산계획설계사 지망 영문학과생

shei77의 이미지


규모가 크다면 원칙을 지키는게 유지보수하는 것에 도움이 되지만,

제대로 개발 하고 손이 많이 가지 않는다면, 최대한 짧고 간결하게,

구현하는 것이 효과적이라고 생각합니다.

----------------------------------------------------------
It's feasible to make an inspiration on your own.

----------------------------------------------------------
It's feasible to make an inspiration on your own.

익명 사용자의 이미지

개발 방법론은 좀 다른 개념이구요.
보통 개발은 천재 몇명이서 개발을 하는게 아닙니다.
일반적인서로의 코드를 보면서 협업하는 경우가 많고
처음에 스팩이 딱 정해진 소프트웨어를 개발하는 경우가 아닌이상
요구사항이 수시로 변경이 되면 그에 따른 코드 변경도 수시로 일어납니다.
코드 수정은 다른 작업자가 할 경우도 있지만 대게 본인이 할때가 많습니다만,
작업한 기간이 오래되면 자기코드를 분석해야되는 경우도 있지요.
한두달만에 끝나는 프로젝트가 아닌이상 프로젝트 시작시점에 정한
코딩룰( 네이밍룰, 인덴션규칙 등등 )을 따라야 전체적인 코드이해도 쉽고
신입 프로그래머가 왔을때 현 코드적응도 쉽습니다.
그것들은 모두 개발 기간 단축이라는 결과를 낳지요.
2명이서 한두달 만드는 프로젝트라면 위의 내용이 맞을수 있겠네요.
1년이상 6-7명이 진행하는 프로젝트에서 위 방식대로하면
프로젝트 말미에 아비규환 상태를 맞을수도 있습니다.
이렇게 이야기 하고 싶네요.
본인이 될수도 있는 '뒷사람'을 위한 배려라구요.

snowall의 이미지

혼자서 기획, 설계, 개발, 테스트, 디버깅, 사용, 피드백까지 하는 개발자로서, 저 개발방법론대로 뭔가를 개발중입니다.
(업무상 개발하는 프로그램이네요. 일을 던져주신 분은 "이거 하는 프로그램을 만들어 봐"라고 잘 추상화된 기획을 구두로 전해주셨죠.)

저에게는 잘 작동하는 개발방법론입니다.

문서화는 참 복잡한 문제인데, "문서화를 잘 해둬야 후임자가 쉽다" vs "문서화 해봐야 읽지도 않는데 뭐하러 잘 해두나" 두 의견이 충돌하죠.

개발자는 문서화를 잘 해두고, 후임자와 관리자는 문서를 열심히 읽는게 원칙인데 둘 다 자기 귀찮은건 안하려고 해요.

물론 저는 제가 개발자이고 후임자이며 관리자이므로... 문서화를 어떻게 할까(=할까 말까) 고민중입니다.

피할 수 있을때 즐겨라! http://melotopia.net/b

semmal의 이미지

제 생각에는 문서화나 TDD같은 방법론은 윗사람(또는 프로젝트 관리자, 진행자)들이 써야하는 것이라 생각합니다.

왜냐하면, 자신의 말을 정확히 아랫사람에게 전달해야하고,

문서나 테스트케이스만큼 자신이 말 하고자하는 것을 정확히 전달하는 방법은 드물기 때문입니다.

하지만 현실은, 아랫사람보고 문서 만들라고하고, 아랫사람보고 테스트케이스 만들라고하죠.

윗사람은 뭘 시키는지 모르고, 아랫사람은 열심히 만들면서, 무엇을 만들고 있는지 윗사람에게 설명까지 해야합니다.

아랫사람이 들어오면 윗사람이 아랫사람을 교육시켜야 하는데, 아랫사람이 아랫사람을 교육시키니 일은 가중되기만 합니다.

개발자들이 주석을 붙이기 싫어하고, 문서화 싫어하고, 테스트케이스 작성하기 싫어하는 이유는 다 있는 법입니다.

------------------------------
How many legs does a dog have?

RurM8Q9g의 이미지

5번말인데요
공산주의에 대해 알지도 못하면
공산주의란말 함부로 안썼으면 좋겠네요 :(
그리고 요즘 웹개발을 하고있는 저로서는
웹표준 지키지 말라는뜻으로 들리네요

semmal의 이미지

표준을 지키지 말라고 하는게 아니라,

표준이라는 핑계로 코딩 방법을 강요를 하지 말라고 하는 말인듯한데요?

즉 코딩 방법은 표준이 될 수 없다고 말하는 것 같습니다만??

------------------------------
How many legs does a dog have?

RurM8Q9g의 이미지

그 코딩 방법이란게 코딩스타일을 말하는건가요?

bangjunyoung의 이미지

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

익명 사용자의 이미지

너무 흑백논리 인것 같습니다.
Agile 방법론은 기존에 UP같이 덩치 커다란 방법론들이 비효율적이여서 나온 방법론 입니다.
물론 100% 정답이라고 할 수는 없겠죠. 하지만 코드가 가장 중요한 문서이고 주석을 중요시 여기는 이야기는
기본에 해당되는 아주 중요한 이야기 입니다.
요즘 느낌은 방법론들이 현업의 목소리를 듣기 시작하는 것 같습니다.

ez2luv의 이미지

글쓴이는 혼자서 일을 하셔야 맞는거 같네요.
어느정도의 프로젝트를 수행하고 계셨는지는 모르겠지만, 3~5명 안밖일꺼 같군요.
결과물을 낸 뒤 생각은 없으신거 같네요.
그 회사에서 일을 그만둔 다음의 결과물에 대한 책임감은 제로군요.
제발 자영업으로 혼자 일하세요 여러사람 피곤하게 하지 말고요