SolarGrace
502
2019-10-10 17:47:49
26
2805

아래 주석관련하여 .. 논쟁을 읽으며...


저도 이회사 처음 왔을 때 쯤이지요....

업무관련해서 돌아가는 프로그램은 엄청나게 많은데 문제는 메뉴얼이 하나도 없었어요 ㅎㅎ

서로 어떻게 관계되어 있는지 일일이 하나하나 인풋 아웃풋 확인해가며 프로세스를 파악해야했죠..

그나마 소스가 남아있는 프로그램은 소스해석을 했다지만, 실행파일만 남겨두고 소스코드는 날아가 버린 것도 많아 정말 난감했었습니다..

심지어 에러나 버그가 발견될 경우 또는 그냥.. 프로세스 변경 필요에 의해..

프로그램을 뜯어고쳐야하는데도 말이죠..... 



전임자 욕을 입에 달고 살았던거 같아요 미친새끼 미친놈이라고...


그러나 시간이 지나 어느정도 반이상 파악을 하고 나서.. 생각해보니..

누굴 욕할 문제는 아니라고 느끼는 바입니다..

혹시나 그것이 일부러 본인의 가치상승을 위해 또는 회사를 엿?먹이기위해 일부러 한 일이라 하더라도요..


뭐든지.. 기존시스템이나 사람을 욕하기보다, 그때는 상황이 그랬었나보다고.. 그만큼도 최선이었을 수 있다 생각하렵니다..

8
1
  • 댓글 26

  • pooq
    3k
    2019-10-10 18:14:00

    알바나 프리가 급하게 만든것도 아니고, 정직원이 몇개월 이상 소요해서 만든거라면 욕 먹는게 맞는거죠.

    저도 개발하면서 주석을 많이 달진 않지만, 유별난 변수나 메소드, 기능이 애매한 부분에는 무조건 주석을 달아둡니다. 남을 위해서가 아니라 나중에 제가 봤을때 삽질하지 않기 위해서죠. 

    주석이 하나도 없다는건 그냥 회사or후임자 엿먹으라고 일부러 다 지운거라고 밖에 생각이 안드네요.

    4
  • 유리세계
    2k
    2019-10-10 18:30:53

    주석이 없는 코드를 물려받아 고생했다고 나 역시 그래야하나?


    우리 학교의 전통이다

    선배가 후배를 교육이라는 명목하에 폭행하던게 떠오르네요


    남이 시간없어 어쩔 수 없었다

    너도 엿먹어라


    주석을 달지 않는것

    그게 옳은 개발자인가요?

    4
  • 동대
    992
    2019-10-10 18:39:46

    "혹시나 그것이 일부러 본인의 가치상승을 위해 또는 회사를 엿?먹이기위해 일부러 한 일이라 하더라도요.."

    이 부분을 옹호하시는 분들도 있겠지만 저는 여기에 대해서 비판적입니다... 사람마다 가치관이 다르기 때문에 제 생각이 옳다라는건 아니지만 성향이 성향이다보니 아래책을 보다가 열 받아서 포기했었네요. ㅎㅎ

    유지보수 하기 어렵게 코딩하는 방법
    http://www.hanbit.co.kr/store/books/look.php?p_code=E2375873090

    1
  • baltasar
    5k
    2019-10-10 18:39:58 작성 2019-10-10 18:46:17 수정됨

    주석이 없는 프로그램은 분석기간을 길게 가져가면 무난합니다.

    사장이 신규 인력 관리하기 귀찮아하고 일정 촉박하게 가져가는 관리체계 태만을 전임개발자가 책임져야 할 이유가 없습니다.

    소스 분석이 어려우면 전임개발자 물고 늘어지지 말고 시스템 주인인 사장에게 얘기해서 기간을 더 달라고 하세요.


    시스템은 사장 소유이고, 관리권도 사장이 가지고 있고, 시스템이 벌어들인 돈도 사장 혼자 버는데, 

    그 시스템의 주석을 전임 개발자가 져야 할 이유가 없습니다.

    본인 소유의 시스템 책임은 본인이 지는 것이 원칙입니다.


    전임 개발자에게 시스템의 책임을 지우는 궁극의 방법은 딱 한가지.

    전임개발자에게 지분을 주고 CTO로 앉혀놓은 다음, 시스템으로 벌어들인 돈을 배당금으로 할당해 지급하면 사장이 전임개발자더러 하지 말라고 협박을 해도 전임개발자가 주석 정리하고 기능도 알아서 확장합니다.

    1
  • defult
    2k
    2019-10-10 18:41:38

    주석이 하나도 없이 소스코드만으로 이해되야  좋은 코드다라는 개발방식도 많이 퍼지고있는데

    이런 상황에서 업무 프로세스 규정도 없는 회사는 x되봐라 말고도 주석이 0인 이유가 점점 늘기에 후임자는 주석보기 더 힘들어질수도 있을겁니다.

    2
  • zamils
    66
    2019-10-10 18:51:30
    10여년 전에는 자기가짠 procedure에 암호걸고 나간 개발자도 있었답니다
    4
  • baltasar
    5k
    2019-10-10 19:21:05 작성 2019-10-10 20:57:22 수정됨

    프로시저에 암호 거는 건 위법입니다. 사장(대표이사)가 아닌 법인을 상대로 하는 영업방해에 해당하죠.

    그러니 그런 건 하면 안 됩니다.

    합법적인 범위 내에서 자기 가치 상승을 추구하세요. 중국인들도, 미국인들도, 심지어 러시아인들도 조직 내에서 일하다가 연봉이 적다고 느끼면 바로 연봉 올려달라고 하고, 착취당한다고 느끼면 사장에게 바로 거부권을 행사하고 협상을 요구합니다. 협상이 결렬되면 자기 머릿속 업무노하우가 식어버리기 전에 다른 회사로 이직해버립니다.

    한국인들만 아직도 1970년대식 근대화 노예근성이 있어서 사장을 주술사, 신녀, 판사 급으로 우러러보니까 조직을 거역하지 못하는 거죠.

    법인이라는 조직체는 누구를 일방적으로 부리고 사장 혼자 다 가져가는 조직이 아니라, 대리, 과장, 사장(대표이사), 부장이 전부 모여서 노획한 전리품을 갖가지 방법을 동원하여 서로 경쟁해서 재주껏 가져가고, 남은 이익을 주주들에게 일정액 나눠주는 수익 조직입니다. 사장(대표이사)은 주주의 이익을 지키기 위하여 최대한 대리, 과장, 부장, 차장 등과의 협상에서 적게 지급하도록 고민해야 합니다.

    만약 사장(대표이사)의 지분이 너무 적다면, 주주들은 화가 나서 사장(대표이사)를 해고해 버리는 거지요.


    그러므로 주석 안 남기는 것 가지고, 근거도 없고 실체도 없는 도덕 운운하지 말고, 근거와 실체부터 명확하게 증명한 후에 도덕 운운하세요.

    세상물정도 모르고 소양도 부족한 모니터 안에 갇혀서 일하는 프로그래머들이 자의적 기준으로 도덕을 판별하고 요구하는 것은 소가 사람을 상대로 자기가 만든 경을 읽는 것이나 다름 없습니다.

    2
  • 스텁
    1k
    2019-10-10 20:55:35

    개인적으로는 주석은 최소화를 선호합니다. 주석없으면 이해 안되는 코드가 주석이 있으면 이해가 된다는 점도 조금  와닿진 않네요.

    뭐...개떡같이 짜놓은 코드라서 //이부분은 필요없음 // 이부분은 사용되지 않음 이런 주석을 말하는거라면 몰라도요.

    그정도면 주석의 문제가 아닌듯...

    아 글쓴분한테 쓴 댓글은 아니에요 

    7
  • mer
    85
    2019-10-10 21:20:41 작성 2019-10-10 21:37:35 수정됨

    제가 항상 느끼는건 주석이 필요 없을 정도로 코드를 깔끔하게 짜는게 베스트고(필요없다는거 아님)

    남의 코드 건드릴때 실질적으로 도움되는건 대부분 주석 보다는 적절한 단위로 나눠진 테스트라는 겁니다

    주석으로 인풋이 뭐고 아웃풋이 뭐다 보다는 그거에 대한 테스트가 있는게 더 믿음직했습니다 주석은 관리가 안됐을지도 모르기 때문에 어딘가 불안합니다


    주석이야 있으면 좋긴한데 추출해서 문서로 만들지 않는 이상 크게 의미가 있는지는 모르겠습니다

    잘짠 코드는 휠 내리면서 주석 거르고 휙휙 봐도 동작이 이해되고

    못짠 코드는 주석을 보고 해석할 시간에 그냥 문서보고 새로 짜는게 정신건강에 이롭습니다

    코드를 남기는 입장에서는 주석을 관리하는 비용도 무시할 수 없구요


    실제로 문제가 터지면 일단 문서를 보고 테스트를 보고 최종적으로 코드 수준에서 분석할때 보는게 주석인데

    시간 많이 잡아먹는건 어디서 터지는지랑 그 이유를 찾는거고 이건 주석보다는 테스트로 거르는게 빠르고 정확합니다


    그래서 저는 주석보다는 테스트를 신뢰하고

    문서로 추출할 수 있는 수준의 주석이 가장 의미있는 주석이라 생각합니다

    2
  • setoka
    505
    2019-10-10 22:05:11

    회사 스타일일수도 있는데, 저희 회사에서는 개발자 두명이 빡세게 '완성시킬 수는 있는거'를

    일정, 업무 관리직으로 한명 더 붙이고, 테스트 만들고 실행하느라 한명 더 붙이고, 문서 관리 하는 사람이 한명 더 있습니다

    물론 전담이라기보단 상호보완해가면서 하는거죠


    아무튼 2명분 월급으로 끝낼 일을, 5명분 월급으로 처리합니다

    누가 보면 돈낭비죠

    근데 덕분에 테스트 제대로 안해서 빡칠 일도 없고, 문서 부족해서 빡칠 일도 없고, 주석 없어서 빡칠 일도 없어요


    그리고 만드는 입장에서도 고객 입장에서도 원래 그게 다 필요비용이라고 인식하고요

    전 능력자 개발자가 알아서 주석도 쓰고 개발도 하고 다 하는것보다 이쪽이 더 마음에 드네요

    2
  • 마르세유1
    860
    2019-10-11 05:30:30

    댓글에도 다른분이 언급하셨는데 테스트를 잘 만들어놓는것이 유지보수를 위한 최선인것 같습니다.


    요즘 주석은 가독성과 유지보수에 해가 된다는 의견이 많죠.


    "주석, 문서를 코드가 바뀔때마다 수정하면 되잖아" 라고 생각하신다면... 그렇게 하시면 될것같습니다...

    2
  • ercnam
    2k
    2019-10-11 08:49:25

    코드 짤때부터 주석없이 읽게 하는것

    그리고 엥간하면 남에 코드 읽을줄 아는것 두개가 다 되야죠.


    주석에만 의존하는것은 마치 장부를 관리하는 장부를 관리하는 장부를 계속 만드는 행위랑 같다고 봅니다.

    타이핑은 최소화해야죠.

    3
  • 재현아빠
    1k
    2019-10-11 10:02:21

    라운드2 인가요 ?

    2
  • 초보.
    2k
    2019-10-11 10:04:46

    zamils 대박이네요 ㅎㅎㅎ


    주석이 없다면 없다고 불만... ㅎㅎㅎ

    주석이 있다면 안맞다고 불만... ㅎㅎㅎ


    주석은 주관적일수 밖에 없어 보는 사람에 따라 의미 해석도 달라질수  있습니다.

    소스코드는 보는 사람에 따라 의미 해석이 결과가 달라지나요??


    자 과연 어느쪽이 더 좋다고 보이싶니까???


    결론 소스코드만으로 분석할수 있는 가독성 좋은 소스코드를 남겨보아요 ^^;;;;;;



    1
  • 나다
    3k
    2019-10-11 10:59:14

    관리 안된 주석은 없는것 보다 못하지요..

    유지보수 할때. 저는 제가 쓴 주석 외에는 대충 거릅니다..

    뭐 제가 쓴 주석도 나중에 내가 헷갈릴까봐 하는거죠.

    다른 사람이 쓴 주석도 명필급 아니면 이해하기 모호한 주석들도 많고요..

    고로 주석은 남을 위해 쓰는게 아니라 자신을 위해 적는겁니다.

    물론 공통기능은 주석을 남겨 팀내 다른사람도 편하게 쓰게끔 하는건 당연하지만요.

    1
  • onimusha
    7k
    2019-10-11 14:30:08

    svn 쓰면 커밋 코멘트나 잘 남겨둡시다!!

    (라고 아랫 것들 가이드 전달했더니 전부 "0월 0일 지이름" 이러고 남기고 있었네;;)

    3
  • ISA
    768
    2019-10-11 21:26:57

    주석도 룰이 있는데 진짜 간단한 코드까지 주석다는건 그거 주석봐야 그나마 이해할 비 개발자를 위한 일 정도 되겠네요. 주석도 남발하면 쓰레기라고 생각합니다. 각자 환경에 맞는 개발방식이 있을거라 생각해요 (참고로 주석 하나 안다는 것도 주석으로 일일히 친절히 설명하는 것도 다 해봤어요 ㅋㅋㅋ) 그 환경에 맞는 개발방식을 선택해야하지 않을까요 마치 제이쿼리가 레거시에 가깝다고 다 날려버리면 미친놈이듯이 ㅎㅎ

    1
  • 우루부루구루
    673
    2019-10-12 10:25:18

    주석, 문서화는 저를 위해서도, 그리고 남을 유지보수 인력을 위해서도 만듭니다.

    개발 문화는 계속 변화해 갈 것이고,

    현재는 주석이 필요없을 정도로 이해 가능한 좋은 코드를 짜는게 추세라고 하지만,

    같이 일하는 사람들을 생각하고,

    본인의 수준을 생각하면서 코딩을 하면 저는 주석을 안 달 수가 없더군요.

    주석은 주석 달았다는 게 중요한 것도 아닌 것 같습니다.

    기능에 맞는 주석이 달려야 하고

    그 주석이 정확한 설명이 되야 그제야 주석을 달았다고 말할 수 있는 것 같습니다.

    그렇지 않을 경우엔 주석을 차라리 안 다는게 낫더군요.

    문서화도 그렇구요.

    잘못된 문서를 만들 것이면 그냥 안 만드는 게 낫습니다.

    간략하게라도 맞는 문서를 만들 거라면 문서가 있는 게  없는 것보다

    훨씬 좋더군요.

    1
  • Frudy
    3k
    2019-10-13 11:47:46 작성 2019-10-13 14:44:23 수정됨

    저는 주석을 최대한 적게다는 편입니다.

    소스가 업데이트되면 주석도 같이 업데이트해야하는 공수가 생기기 때문에,

    주석업데이트를 안하면 주석따로 코드따로되서 오히려 민폐가 됩니다.


    그래서 기능을 설명하는 주석은 굳이 달지않습니다.

    개발자라면 남의 코드읽어서 이해할 수 있으니까요.


    대신 왜 이렇게 구현을 했는지에 대해 주석을 달 뿐입니다.

    실력부족으로 좀 모호하게 구현을 했거나,

    좀 신기한 방법으로 구현을 했을 때 주로 달고있습니다.

    2
  • 아플라
    589
    2019-10-13 13:25:26

    주석없이 이해되는 간결한 코드가 가장 이상적이긴 하지만, 실무에서 이런 개념이 적용되고 그 효과를 느끼려면 거의 대부분의 개발자가 공통된 가치관을 가지고 작업에 임할 때 실현 가능한 부분이라고 생각됩니다.

    만약 실제로 위에 제가 말한 환경에서 근무하는 분이 계신다면 정말 부러울 따름이네요...


    1
  • 퓨리오사
    2k
    2019-10-14 01:38:01

    주석은 그 기능에 대해서 서술하고 추후 업데이트에 따라 변화될수 있는 내용이 있다면 

    안다는 편.

    예를 들어 MVC 모델로 작성된 소스가 있다면 해당 기능이 어떤 모듈(예. 공지사항) 인지에 대해서만

    주석달고 세부내용이나 변경될수 있는 내용은 주석달지 않음.

    나머지 세부내용이나 변화 되는 내용은 별도의 문서 작성하여 버전관리하는게 맞음.

    하지만 대부분의 회사에서는 이러한 문서 산출물은 초기에만 작성되거나 제대로 버전관리가

    되지 않음. 그러므로 그냥 소스보고 판단하는게 더 빠르고 정확함.

    0
  • 삼식이
    1k
    2019-10-14 09:55:08

    주석 달 시간 없음

    0
  • Dive_Drink_Develope
    3k
    2019-10-14 12:52:19

    정책이 아니면 주석볼시간에 소스보면 끝나는걸.

    0
  • cat11
    372
    2019-10-15 07:56:16

    클린코드라는 책에서도 주석의 위험성에 대해 설명합니다

    일단 소스코드가 아니므로, 주석의 버전관리가 잘 되고 있다라고 신뢰하기 어렵고

    주석이 내용의 이해를 도울수는 있다고 생각하지만 방해할수도 있다고 생각합니다

    0
  • AbsoluteZero
    2
    2019-10-15 11:59:22

    개인적으로 관리되지 않는 주석은 그냥 없는거보다 더 위험하다고 생각합니다. 그냥 코드 함수명이랑 변수명을 용도에 맞도록 정의하고 그거로 주석을 대체하는걸 선호합니다

    0
  • 코노
    49
    2019-10-16 02:59:16

    주석이 없다면 문서화라도 있어야 한다고 생각합니다... 물론 문서화가 주석보다 더 시간투자를 많이 해야하죠..

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.