"과연 언제 깔끔한.." 이라는글에 댓글로 쓸려다가 새로씁니다.

익명 사용자의 이미지

댓글달려던글인데.. 너무길고..또... 글쓰다가 하고싶은 말의 의도가 좀바뀌어서.. 새주제글을 열었습니다..

-----------------------------------------------------------------------------------------------------------

저는 코드를 지저분하게 늘릴려고 노력하고 있습니다. ㅡㅡ;;

사실 제 성격이 장황하고.. 길게 쓰는걸 매우 싫어하고.. 제가 긴것을 기억하거나 쉽게 보지 못하는 성격이거든요...

또.. 타이핑하는걸 매우 싫어하기때문에... 특히나...

그래서 보통보면.. 남들 2000라인으로 작성하는 프로그램을 500라인이하로 작성하는 식입니다.

또한 느린것을 매우 싫어합니다. 그래서 이리돌려보고 저리 돌려보고 처음부터 튜닝도 하죠..

그런데요.. 이게 회사에서 이렇게 일하는게 매우 안좋더군요...

일단 위와같이 하려면 오류가 있으면 안됩니다. 오류가 있으면 지저분해지거나.. 처음부터 설계가 잘못되었다면 바꾸기 매우힘들거든요..

또한 보통 코딩이 간편한만큼 사소한오류는 매우크게 잘못된결과를 내게됩니다.

이게 왜 안좋으냐구요??

일단 다른사람이 보면.. 매우간단해보이니.. 일을 적게한다고 생각하더군요.. 또한 한번에 쉽게돌고.. 오류도 안나니..

더구나 아주 작고 쉬운일을 오랜시간을 들여 했다고 평가해버립니다. 제 3자는 그업무의 상세한 내용이나 이슈를 알려고도 하지 않죠..

또한 아시파시피 이렇게 일하려면 철저한 일정조절 필요합니다. 만약에 잘못되면 완전히 개발을 하나도 못한것이 되버리기 때문이죠..

막코딩은 막한만큼의 결과는 나오죠.. 하지만.. 이런류의 코딩은.. 어느 한부분만 안되어도.. 결과물을 전혀볼수 없습니다. 혹시 이부분은 이해하시죠?
(왜냐하면..자동차공장의 분업화된 하나의 부분이 안돌면 자동차는 단한대도 나오지 않고.. 가네수공업식의 자동차생산은 한사람잘못되도 나머지 자동차들은 생산되죠)

머어쨋든.. 그래서 보통 남아서 일하는 타입이 아니죠.. 애초의 일정대로 잘돌아간다면..(꼭그래야됨 아니면 애초 이렇게 시도조차하는게 잘못된것)

당연히 남아서 하지 않는게 정상이겠죠...(남아서 하는사태가 발생하면 그건이미 좀곤란한상황이죠)

그러다보니 특히나 제3자가보면... 할일이 없어 혼자 집에 일찍가튼것처럼보이죠.. 어쨋거나 항상 이사람은 일이적게 할당된다고 보더군요...

그래서 회사에서 그다지 좋은소리 못듣습니다.

한번은 이런일도 있었죠..

새업무 난이도는 기존의약 3배이상 복잡한 업무로 확대되었는데..기존프로그램의 코딩량보다 약 1/10 로 코딩을 축소 시켰습니다.

성능은 약 100배이상 빨리 나오더군요.. 기존것이 거의 10시간걸렸는데 이건 5분?? 정도에 나왔던걸로 기억합니다....

또한 프로그램도 매우깔끔?( 개인적인 판단일수도 있습니다만) 했죠...

워낙 깔끔한나머지.. 이후 업무인계자가... 왜? 기존로직들이 없느냐 이게 과연 기존로직을 수용하며 결과를 낼수있냐고 따져물을지경이었습니다.

어쨋건 애초 할당된 업무에서 제가 가장먼저끝냈고.. 검증요구까지 했으며.. 이로써 가장먼제 해당프로젝트에서 제거되게 되었습니다. ㅡㅡ;;

다른사람들은 모두 연장프로젝트를 하게되었고 제업무는 그중한명에거 넘기게되었죠.. 추가변경사항이 별로없거나 있어도 간단히 할수있을것이다고 본거죠..
(프로그램이 워낙 간단해보이니까..)

인계자는 설명조차 필요없다고 생각했는지 제 설명조차 듣지를 않으려고 하더군요.. 혼자 할수 있다나 뭐다나...

전 같은사무실에서 다른업무에 투입되었고 그후 해당프로젝트가 막바지에 이르러.. 부랴부랴 인계담당자가 난리가 났습니다.

화를 버럭내며.. 왜, 개발을 안했냐고 하더군요.. 무슨소리냐 했죠.. 제프로그램에 로직이 없다는겁니다.

전 금새 그사람말을 이해했습니다.. 웃으며 말했죠.. 로직이 없는게 아니라.. 그게 기존업무 모두를 수용할수 있다고했죠..

말도 안된다는것 이었습니다. 자꾸화만내는 인계자가 어이없어 한마디했죠... 그럼 돌려보고 결과가 무엇이 잘못되었는지 정확히 말하라고 했죠.

그랬더니 알았다며.. 가더니.. 안오는것이었습니다. 제가가서 안나오더냐 물어보니.. 힘이한풀꺽인 목소리로 결과는 잘 나오더라는 겁니다.

왜 돌려보지도 않고 그러냐.. 이해를 못하는거같아 다시 시간을 내서 설명을 해줬죠.. 이해를 못하더군요..

한는수가 없어 추가 변경개발이 무엇인지 물었습니다. 제가 해주겠다고 했죠.. 추가사항이 일반적으론 매우 어렵게 고쳐야하나..

매우 간단히 수정할수 있더군요.. 추가요구사항을 반영하는데 5분도 안걸렸습니다..

또한가지가 더있는데 그것도 매우간단히된다고 설명하니..그건자기도 할수있겠다는겁니다.. 이제 어느정도 이해 한듯 보이더군요...

그래서 그냥 공부 해보란 셈치고 하라고 놔뒀죠..

그런데.. 몇일후 깜짝놀랐습니다.

그냥 단몇줄이면 끝날일을 무려 제가 인계한코딩의 3배가량 늘렸을뿐만아니라.. 그와중에 엄청나게 비효율적이며 (실제시간도 많이늘어남 그래도 30분이내 )

제가볼때 좀 어이없는코딩을 해두었더군요...

한숨이 나왔습니다..

문제는 이게 다가 아니었습니다.. 이인계자가.. 다음 운영자에게 넘길때.. 자신은 초기개발자가 이렇게 해놔서 어쩔수없이 이렇게 되었다고

또한 코딩을 반도 안한것을 나머지자기가 해서 겨우했다고...ㅡㅡ;;(코딩량이 반도 안되긴했죠..지가 중복복사해서 비슷한코딩을 3배로 늘렸습니다.)

그래서 저는 비공식적 도의적으로 매우 나쁜인간이 되어버렸습니다.. 저에게 직접와서 따지는 사람은 없었지만. 공공연히 돌아 들리는소리를 들었기때문이죠..

저의 해명은 그업무를 자세히 보지않는이상 알기힘들며 자세한 내용을 알려고 할필요도없으며 코딩을 보여주며 직접검증하지 않는동안에는 제3자입장에서는 누구말이 맞는지조차 알수없겠죠...

더구나 운영자는 마지막 인계자의 말만들었지 저에게와서 3자대면을 하지 않은상황이죠..그러니 저보다는 그사람말을 믿는건 당연하겠죠..

더구나 3자대면따위의 자리를 만들 어떤 여지가 없었죠.. 아무도 이것으루 문제제기를 하지 않았으니까요..

오직 제가 "당신왜 엉뚱한소문을 퍼트렸냐" 찾아가서 멱쌀잡고 싸울수는 있겠죠.. 하지만 그러고싶진않았습니다.

그러기에 앞서 제가 다시 혹여 제프로그램이 정말잘못되었거나 추가요구사항을 반영하기에 최초설계가 잘못되었는지를 검토부터 하고 싶었습니다..

그래서 최종프로그램과 제가 넘긴 프로그램을 비교검토했죠...

결론은 참으로 어이없게 망쳐놨다는것입니다. 결과적으로 제가넘긴프로그램에서 단 3~4줄의 코딩만 더추가되면 끝나는 사항이었습니다.

그런데 왜 이사람은 이렇게 망쳐놨나를 생각해봤죠... 일단 스타일인것 같았습니다.(이사람이 짠 다른프로그램도 봄) 또한 추가코딩후 추가코딩한부분의 오류때문에 매우 난감했을것으로 보이며

이것때문에.. 임기응변와중에 프로그램을 망쳤을것으로보임 (아마도 데이터 중복발생으로 프로그램중단 : 이건 간단하고 도 중요한문제인데 원 데이터의 무결성처리부터하면 해결되는데..아쉽..알려줄껄..)

이후 그냥 이사람의 인간성에 실망했습니다.. 그리고 다시 부딧치고 싶지 않더군요...

cleansugar의 이미지

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

snowall의 이미지

liame의 이미지

"코드를 지저분하게 늘릴려고 노력"한다니 정말 놀라운 사실이네요.

한편으로는 그런 동료들과 그런 회사에서 근무를 한다는 것 자체가 안타깝네요.

또, 요즘에는 조금만 둘러보면 개발능력을 인정해 줄만한 좋은 회사를 찾을 수 있을거라 생각하는데 왜 그렇게 하지 않는지 모르겠네요.

익명 사용자의 이미지

그런가요..

추천좀해주세요..^^

liame의 이미지

우리 회사요 -_-;

일단 공식적으로 출퇴근 자유구요.( 단 팀 정책을 따라야 함. 전 10시 이후 출근 6시 전 퇴근을 추천합니다. )

능력있으시면 30대 중반 전에 개발 직군으로 연봉 1억찍는 것도 가능합니다.( 두분 있는데 능력도 능력이지만 너무 빡세게 사는거 같아서 전 포기 )

능력 좋은 사람들이 많아서 좋은 개발자를 보는 눈도 있구요.

같이 일하면 배우는 것도 많고요.

혹시 java쪽이고 30대 미만이시라면 마침 채용 기회가 될거 같네요.

관심있으신지요?

익명 사용자의 이미지

오우~ 좋은 회사군요..

자바쪽은 아니지만 회사 이름이라도 알려주세요.. 참고라도 좀하게요..

맨발의 이미지

그럼 어느쪽이세요?! ^^;
C# 하시면 저희 회사도 사람 뽑아요~

윗분 회사 만큼은 아닌 것 같지만 야근 없고, 공부하는 분위기..

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

맨발의 이미지

SI바닥에 몇 년 만 있어 보시면 그닥 놀랍게 느껴지지 않으실 꺼예요 ;;;

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

익명 사용자의 이미지

이렇게 쓸데없고 아무한테도 도움안되는 글을 왜 쓰나요?

정상인의 이미지

이렇게 쓸데없고 아무한테도 도움안되는 댓글은 또 왜 쓰시나요?

익명 사용자의 이미지

도꼬다이를 하거나 혼자 개발하는
앱개발자로 나서세요. 능력을 떠나서 님은
팀플에는 서로에게 도움 안되는 일을 하고 있습니다.

나그네나그네의 이미지

능력이 되지 않는 사람들이 팀으로 있으니 간결하고 좋은 로직을 써도 그들의 머리로는 이해조차 되지 않겠죠ㅎㅎ

더 넓은 물에 풀어놓아야 할 사람인 듯 합니다

한국에는 아직 그런 물이 잘 없는 듯 하더군요..

ironpapa의 이미지

잘하는 사람 밟는게 팀플인가요?
순간 욱했네..;;;

철이 아빠 입니다. :D

익명 사용자의 이미지

가능한 상황이고 이해될 법한 상황입니다.
단순한 예를 들어보자면, 어떤 사람이 세달동안 못한 일을 제가 몇시간 안에 끝낸적이 있습니다.
어떻게 했냐고 물어봐도.. 사실 딱히 해줄 말이 없더군요. 그냥 내가 했던 방식대로 했을 뿐;;
어떤 경우는 쉬쉬 하고 넘어가다가 그 사람이 스스로 잘못을 인정하는데에 6개월이 넘어 걸린 적도 있습니다.
원래 코딩은 쉽습니다. 사람들하고 부딫히는게 몇배 어렵지...

snowall의 이미지

일단 일을 다 해놓고

일을 하는 척 합니다

마감이 되면 싸워서 마감을 며칠 늦춥니다

결과물을 넘겨줍니다

고생해서 간단하게 만들었다고...

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

neocoin의 이미지

이런 똑똑함 부럽습니다.

익명 사용자의 이미지

저런 분들 이해시키는 것도 능력이지 않을까요?

snowall의 이미지

그렇게 평가한다면 우리나라의 엄청나게 많은 개발자들이 무능력한 개발자가 될텐데요...

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

익명 사용자의 이미지

네 한국에선 큰 능력이겠지요.
하지만 사실 프로그래밍 하는 사람들은 보통 정직하기때문에 가감없이 말하다보면 피보는 경우가 많습니다.
다 알려주려 하지 말고 조금씩 보여줘야 우습게 보지 않죠.

이 경우에도 짧고 단순한 알고리즘의 코드와 더불에 모든게 아무 이상없다는 결과보고서를 따로 작성해서 만방에 알리셔야 합니다.
그게 귀찮겠지만 필요합니다. 그래서 다른 분이 찍소리 하지 못하게 해야 합니다.
그리고 코딩 잘하시는 분들이 가끔 실수하는 것은... 문서를 너무 남기지 않는다는 것입니다. 다 남기려고 하지 말고 적당히 남겨두세요.
그래야 후임이 엉뚱한 일을 하지 않으니까요

bacon의 이미지

일반적인 관점에서 하는 말이니 민감하게 받아들이지 않기 바랍니다.

>>>> 남들 2000라인으로 작성하는 프로그램을 500라인이하로 작성하는 식입니다.
>>>> (아마도 데이터 중복발생으로 프로그램중단 : 이건 간단하고 도 중요한문제인데 원 데이터의 무결성처리부터하면 해결되는데..아쉽..알려줄껄..)

한번 쓰고 버릴프로그램이면 몰라도 그렇지 않다고 하면, robust한 프로그램이라면 에러나 예외처리에 필요한 코드량이 상당히 많은것 같습니다. 로직을 단순화하여 라인수를 줄이는 것은 상관이 없지만, 해야할 처리를 하지 않고서 라인수를 줄이는 것이라면 문제가 되겠죠. 예를 들어, 데이터 중복이 발생했을때, 어떻게 할지를 선택할수 옵션이 있으면 더 좋을것이고(중복무시, 중단, 등등), 만일 중단해야 한다면 데이터의 어느 부분에 어떤 중복이 발생해서 중단한다는것을 구체적으로 알려 주었다면, 넘겨 받은 분이 보다 쉽게 처리했을수도 있을듯 합니다. 이렇게 에러 처리를 user-friendly하게 하려면 코드량이 또 늘어나게 되죠.

경험상 개발자들 실력차가 많이 나도 힘들고, 그렇지 않아도 힘들고... 그런걸 잘 조율할 수 있는 관리자의 부재도 문제인듯 합니다.

익명 사용자의 이미지

아네.. 제3자의 입장에서는 아마 그런생각이 드실것으로 봅니다..

아무튼... 예외발생 케이스별 대응처리는 모든케이스를 고려하지 않으면 누락이생기죠..

하지만 모든 케이스를 수용할수있다면 얘기는 달라지겠죠..
(이부분을 이해하지 못한듯합니다... 아무튼 업무에따라 그럴수도 있는경우가 간혹있죠)

있어야할 부분이 없다면 반드시 문제가 생기며.. 그랬다면.. 결과물을보고 잘못되었음을 합리적으로 지적될수 있었겠죠..

아무튼 그런 필요한부분을 없애거나 해서 코딩량을 줄이진 않습니다.^^

또한 설명은물론이요.. 기꺼이 제업무를 제쳐두고 대신개발까지 해줄수있는 의사및 실제해주기도 했으니 이점에선 섭섭하지 않았을꺼 같네요.

문서또한 제출할 형식의 문서들도 모두 제출되었죠..

s019923의 이미지

마케팅/홍보가 중요하고 또 어려운 이유중에 하나죠...
"잘 하는 것 - A / 잘했다고 알리는 것 - B"
라면, 제 개인적으로는, 경력과 시간이 지날수록 A의 비중 보다는 B의 비중이 높아질 필요가 있다고 느끼고 있습니다.
요즘은 거의 50:50 정도까지도 보고 있죠... -_-;
물론 전부 제 개인적인 의견입니다.^^

익명 사용자의 이미지

그런 경우 해당 기능에 대한 interface(function or class) 정의가 필요하지 않을까 싶네요.

여기서의 interface의 역할은 설계자가 생각한 디자인(설계)을 강제(강압?)로 따를것을 요구하겠죠.

뭐, 처음에는 불평 불만이 많더라도 나중에 나오는 여러 요구 사항을 일정한 규칙으로 추가할수 있게 학습이 되면

그냥 잘 씁니다.