여러 팀을 구성하고 팀원들의 loc를 관리해본 제 경험(!)으로는
6개월 이상 프로젝트에서 매일 100줄 이상을 짤 수 있다면 상당한 수준입니다.
Windows 기반, VC, Delphi, VB, .NET 등등 잡다한 개발환경에,
멀티미디어, C/S, CBD 기반, TDD, 머 할만한건 다해 봤는데,
최상급이라 할 만한 경우가 130줄 정도였네요...
매일 의무적으로 commit하고 주요 작업 완료시 추가로 commit하는 경우입니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
모두 다 포함합니다. 회사 업무라는 것이 그렇습니다.
함께 계획하고 리뷰하고, 지켜 보는 눈이 많기 때문에
의외로 쓸데 없는 코드 변경은 거의 없다고 보시변 됩니다.
제가 예를 든 경우는 일반적인 SI업무를 위해 초,중,고급 개발자들이
팀작업에 할당된 경우를 말씀드리는 겁니다.
전문 분야에 특화된 기술을 가진 개발자가 투입된다면 loc가 다소 높아질 수는
있겠지만, 이 경우도 갑이 따로 있어서 변경 요구가 빈번하게 생긴다면
많이 높아지기는 힘들겁니다.
자체적으로 개발 계획을 가지고 사양을 스스로 정해가며 집중적으로 개발할 수
있는 팀이 설계된 대로 잘 따르는 경우에 일일 130 loc 이상 가능하지 않을까
생각합니다만, 뭐 그런 경우도 100 loc/일 정도면 나쁘지 않습니다.
매일 팀원당 100 loc 이상을 작업할 수 있다면 어디 내놔도 손색없는,
아니 오히려 대단한 실적을 내는 팀이 되곤 했습니다.
그 이상을 위해서는 개발팀이 노력하기 보다는 계약 관리나 변경 관리에
집중하는 것이 훨씬 좋을 거라고 생각합니다.
갑의 요구에 회사나 PM이 잘 대처해서 개발팀의 로드맵을 지켜주려는 노력이
필요하다는 것이 제 소견입니다.
추가: 6인이 6개월간 100 loc 로작업하면 10만라인 정도의 코드가 생성됩니다.
4GL까지 포함하는 환경에서 그 정도면,,,,음...
워드 프로세서 하나를 1년안에 만들수 있는 정도라고 생각하시면 될 듯 합니다.
자꾸 고치게 되네요....^^;
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
라인 수 계산은 SCM 도구의 리포트 결과를 따랐습니다.
loc 계산을 위해 별도의 전략을 수립할 필요는 없는 것 같습니다.
다만 코드의 추가, 수정, 삭제 모두 다 중요한 정보이고,
결국 작업의 결과이므로 모두 포함하는 것이 맞다고 생각합니다.
어쨌든 중요한 것은 팀의 생산성을 파악해서,
향후 계획 수립과 프로젝트 진행의 지표로 삼겠다는 것입니다.
세부 절차에 얽매일 필요 없이 metric을 위한 기본적인 환경을 꾸며놓고
관리를 해 보면 loc 자체가 큰 의미가 있지는 않습니다.
중요한 것은 코딩이나 라인 수가 아니라 계획과 절차를 수립하고,
이를 지켜나가자는 것입니다.
문제가 있으면 계획과 절차를 수정해서 바로잡아 가면 됩니다.
다만 하나의 지표로서 우리가 잘 해 나가고 있는지를 알려 준다는 것 뿐이지요.
사실 뭐 100보다 120이 훨씬 좋다 그런 의미는 아니라고 봅니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
또 하나 의문인 것은 학교 다닐 때 학기과제를 하는 것들을 보면 3학년 되면 1000줄이 넘어가는 source를 만드는 사람들이 있더군요. 저는 그걸 보고 정말 놀라움을 금할 수가 없었습니다. 그런데 그런 과제가 2개까지 하기도 하죠.
견습인 사람들이 그것도 그것만 전문으로 하는 사람들이 아닌 사람들이 어떻게 그렇게 한 것인지...
컴퓨터학과의 어려움은 장난이 아닌 듯... -_-
예전에 교수님이 만줄, 10만줄 짜리 source를 작성해야봐야 아키텍처를 이해하고, 만들 수 있는 수준이 된다라는 말을 한 적이 있는데... -_-. 당시 그 말 들을 때는 도저히 믿기지가 않았었죠...
전 회사내에서 거의 저 혼자 기획하고 시스템 구축하고 플밍하고 테스트하고 디자인 입히고 ㅡ.ㅡ;;;;;;;
협업을 해본 경험이 거의 없어 그러는데... 실제 협업을 할때는 어떤 식으로 진행이 되나요 ?
대개 스펙(or 클래스 or 함수 or 기능) 을 정해주면 그 안에서 내구부조는 마음대로 하고 input, output 만 지키면 되는거 아닌가요 ?
2만라인이면
2만라인이면 상당한거 아닌가요 ?
저는 작년기준으로 1년에 5천라인 될까말까 하는거 같습니다 ㅡㅡ;
-----------------------------
in the real-time scheduler !
-----------------------------
in the real-time scheduler !
위의 계산은 전문적으로 coding 했을 때 이야기입니다. ^_^
물론 휴일, 휴가와 몇가지 등등은 뺀 겁니다만...
회사에서는 대게 전화때문에 작업을 못하죠. ^_^
게다가 사실 매달려서 작업할 일도 없는 경우도 많을테니 이런 저런 거 빼면 비슷할 겁니다.
좀 더 줄여야 겠군요.
여전히 저 수치는 낙관적인 것 같습니다.
반만 하죠. 3만에 1만. ^_^.
대신 목표는 100%...
목표를 위하여 뭔가 인생의 관리와 정리가 중요할 것 같군요. ^_^
LOC 보다는...
LOM 이 점점 더 중요해져가는 현실...
LOM == Lines of Mail
--
B/o/o/k/w/o/r/m/
--
Minimalist Programmer
.
Line of Mail
Line of Word
Line of Excel
ㅠ.ㅜ;;
코딩이 훨씬 재미있어요 ㅠ.
공감합니다.
동의는 못합니다만... ^_^
6만줄?
6만줄이면 1년 52주 260일이라고 할 때 하루에 230줄씩인데 전혀 자신 없습니다. 물론 썼다 지웠다 하는 양을 더하면 그 이상 나오겠지만 결과적으로 볼 때 하루에 100-150줄의 "남는" 코드를 짜면 저에게는 보람찬 하루였던 것 같아요.
작성 가능한 LOC는 프로그래밍 언어에 따라 크게 변하지 않는다고 하는데, 그러면 결국 한 줄로 많은 일을 할 수 있는 고급 언어를 쓰는 게 답이라는 생각도 듭니다.
정답이네요...
문득 노보리 다이유가 떠올라서요.. http://tisphie.net/typo/articles/2007/07/20/throw-away-logical-thinking
그런데 고급언어를 쓰면 간단한 것은 확실히 차이가 나는데 복잡한 것은 좀더 저급언어를 써도 함수를 만들게 되니 크게 차는 안 나더군요.
2배에서 3배까지는 나는 것 같습니다만... 그 이상 나는 것은 못 봤습니다.
위에 썼듯 주석과 test code를 빼면 2만으로 줄인 거고요. 이것도 그것에 나름 집중하고 있을 때입니다.
위의 계산대로라면 1/3 이니 230줄의 1/3이면 100줄도 안 되지요.
말씀하신 남는 code라면 순수 model code가 아닌지요?
밑에서 다시 줄인 3만에 만 조차도 전 다시 줄여야 하는 것이 아닌가 좀 생각해봅니다.
하지만 model code 1만줄은 사실 한달에 천 줄도 안되지요. 저도 노보리 다이유가 말한 일반사람이구나 했습니다.
130 loc/일 정도면 수준급인데요...?
여러 팀을 구성하고 팀원들의 loc를 관리해본 제 경험(!)으로는
6개월 이상 프로젝트에서 매일 100줄 이상을 짤 수 있다면 상당한 수준입니다.
Windows 기반, VC, Delphi, VB, .NET 등등 잡다한 개발환경에,
멀티미디어, C/S, CBD 기반, TDD, 머 할만한건 다해 봤는데,
최상급이라 할 만한 경우가 130줄 정도였네요...
매일 의무적으로 commit하고 주요 작업 완료시 추가로 commit하는 경우입니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
어떻게 산출되죠?
수정이나 제거는 어떻게 계산되나요? 최종 남는 code만 계산되는 건가요?
TDD라면 test code 포함인가요?
주석은?
모두 다 포함합니다만
모두 다 포함합니다. 회사 업무라는 것이 그렇습니다.
함께 계획하고 리뷰하고, 지켜 보는 눈이 많기 때문에
의외로 쓸데 없는 코드 변경은 거의 없다고 보시변 됩니다.
제가 예를 든 경우는 일반적인 SI업무를 위해 초,중,고급 개발자들이
팀작업에 할당된 경우를 말씀드리는 겁니다.
전문 분야에 특화된 기술을 가진 개발자가 투입된다면 loc가 다소 높아질 수는
있겠지만, 이 경우도 갑이 따로 있어서 변경 요구가 빈번하게 생긴다면
많이 높아지기는 힘들겁니다.
자체적으로 개발 계획을 가지고 사양을 스스로 정해가며 집중적으로 개발할 수
있는 팀이 설계된 대로 잘 따르는 경우에 일일 130 loc 이상 가능하지 않을까
생각합니다만, 뭐 그런 경우도 100 loc/일 정도면 나쁘지 않습니다.
매일 팀원당 100 loc 이상을 작업할 수 있다면 어디 내놔도 손색없는,
아니 오히려 대단한 실적을 내는 팀이 되곤 했습니다.
그 이상을 위해서는 개발팀이 노력하기 보다는 계약 관리나 변경 관리에
집중하는 것이 훨씬 좋을 거라고 생각합니다.
갑의 요구에 회사나 PM이 잘 대처해서 개발팀의 로드맵을 지켜주려는 노력이
필요하다는 것이 제 소견입니다.
추가: 6인이 6개월간 100 loc 로작업하면 10만라인 정도의 코드가 생성됩니다.
4GL까지 포함하는 환경에서 그 정도면,,,,음...
워드 프로세서 하나를 1년안에 만들수 있는 정도라고 생각하시면 될 듯 합니다.
자꾸 고치게 되네요....^^;
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
귀찮게 해서 죄송합니다만...
그렇다면 100줄 작성하고 commit
50줄 지우고 20줄을 추가하고 commit 했다고 한다면
최종적으로 산출되는 loc는 70줄(최종 남는 loc)인가요?
아니면 170줄(지우고 덧붙인 것을 모두 합산)? 아니면 150줄(50줄 추가는 변경으로 봄)?
죄송합니다만 여기에 대해서 대답해주신다면 팀운영 평가에 대해서 참고가 많이 될 거 같습니다.
SCM 리포트 결과를 보십시오.
라인 수 계산은 SCM 도구의 리포트 결과를 따랐습니다.
loc 계산을 위해 별도의 전략을 수립할 필요는 없는 것 같습니다.
다만 코드의 추가, 수정, 삭제 모두 다 중요한 정보이고,
결국 작업의 결과이므로 모두 포함하는 것이 맞다고 생각합니다.
어쨌든 중요한 것은 팀의 생산성을 파악해서,
향후 계획 수립과 프로젝트 진행의 지표로 삼겠다는 것입니다.
세부 절차에 얽매일 필요 없이 metric을 위한 기본적인 환경을 꾸며놓고
관리를 해 보면 loc 자체가 큰 의미가 있지는 않습니다.
중요한 것은 코딩이나 라인 수가 아니라 계획과 절차를 수립하고,
이를 지켜나가자는 것입니다.
문제가 있으면 계획과 절차를 수정해서 바로잡아 가면 됩니다.
다만 하나의 지표로서 우리가 잘 해 나가고 있는지를 알려 준다는 것 뿐이지요.
사실 뭐 100보다 120이 훨씬 좋다 그런 의미는 아니라고 봅니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
.
이번주에 800라인 짰습니다.
현재까지 주당 짜본 라인중에 제일 많이 짠듯 -_-;; with python =3
------------------------------------------------------------------------------------------------
Life is in 다즐링
------------------------------------------------------------------------------------------------
Life is in 다즐링
제가 뭔가 착각을 하는 것 같군요.
예전 알티베이스의 글이 있습니다. http://kldp.org/node/68261#comment-325262
알티베이스의 직원들은 당시 엄청난 수준의 사람들만 있었던 건가요?
또 하나 의문인 것은 학교 다닐 때 학기과제를 하는 것들을 보면 3학년 되면 1000줄이 넘어가는 source를 만드는 사람들이 있더군요. 저는 그걸 보고 정말 놀라움을 금할 수가 없었습니다. 그런데 그런 과제가 2개까지 하기도 하죠.
견습인 사람들이 그것도 그것만 전문으로 하는 사람들이 아닌 사람들이 어떻게 그렇게 한 것인지...
컴퓨터학과의 어려움은 장난이 아닌 듯... -_-
예전에 교수님이 만줄, 10만줄 짜리 source를 작성해야봐야 아키텍처를 이해하고, 만들 수 있는 수준이 된다라는 말을 한 적이 있는데... -_-. 당시 그 말 들을 때는 도저히 믿기지가 않았었죠...
그런 코드를 짤 수
그런 코드를 짤 수 있는 이유는 일단 스펙은 정해져 있지만 내부 구조는 자기 혼자 마음대로 정할 수 있기 때문이 아닐까요. 프로그래밍이 진짜로 어려워지는 때는 여러 사람이서 개발을 협업해야 할 때가 아닌가 싶습니다.
전 회사내에서 거의
전 회사내에서 거의 저 혼자 기획하고 시스템 구축하고 플밍하고 테스트하고 디자인 입히고 ㅡ.ㅡ;;;;;;;
협업을 해본 경험이 거의 없어 그러는데... 실제 협업을 할때는 어떤 식으로 진행이 되나요 ?
대개 스펙(or 클래스 or 함수 or 기능) 을 정해주면 그 안에서 내구부조는 마음대로 하고 input, output 만 지키면 되는거 아닌가요 ?
답변 주신 분들 감사합니다.
제 예측이 완전히 틀리지는 않은 것 같기도 합니다만 또한 답변 주신 분들 덕택에 많은 보충이 되었습니다.