tag:blogger.com,1999:blog-6060875800282210631.post8210159617894486306..comments2023-11-08T05:29:09.590+09:00Comments on All of Software: 문서화 딜레마전규현http://www.blogger.com/profile/02706025917864233238noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-6060875800282210631.post-84193494990337569272010-11-11T17:42:29.000+09:002010-11-11T17:42:29.000+09:00문서화 정말 어렵더라구요. 4년차만에 처음으로 개발하기 전에 설계하면서 문서부터 만들고 있...문서화 정말 어렵더라구요. 4년차만에 처음으로 개발하기 전에 설계하면서 문서부터 만들고 있는 중인데, 이 정도밖에 안됐나 하는 자괴감이 들더라구요. 갑자기 또 속상해지네. 크크크. 10년차 되서 스펙때문에 또 좌절하면 어쩌죠. 스펙까지 익숙해지려면 보통 몇년 걸리나요? 빌 조이같은 천재들 말고요.김재호http://www.petabytes.orgnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-2042788531624892752010-11-12T00:14:35.000+09:002010-11-12T00:14:35.000+09:00안녕하세요. 김재호님스펙은 가장 작성하기 어려운 문서입니다.요구사항 분석 능력이 있어야 하...안녕하세요. 김재호님<br>스펙은 가장 작성하기 어려운 문서입니다.<br>요구사항 분석 능력이 있어야 하고, Domain도 잘 알아야 하고, 문서도 잘 작성해야 합니다.<br>제대로 적는데는 기본적으로 3~4년은 걸리고 10년이 지나고 20년이 지나도 꾸준히 실력이 증가하는 소프트웨어를 개발하는데 있어서 가장 어려운 분야입니다.<br>빌조이 같은 천재라고 해도 결코 처음부터 스펙을 잘 적을 수는 없습니다.<br>문제는 스펙을 적는 방법을 배우기가 어려운 거죠.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-56367948096618206812010-11-11T17:53:29.000+09:002010-11-11T17:53:29.000+09:00이에 관련된 책들의 도움을 받아야 한다고 하셨는데 혹시 좋은 책을 추천해 주시는 것은 가능...이에 관련된 책들의 도움을 받아야 한다고 하셨는데 혹시 좋은 책을 추천해 주시는 것은 가능하신지요?godwaynoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-84996441439928820212010-11-12T00:16:25.000+09:002010-11-12T00:16:25.000+09:00안녕하세요. godway님우리나라 책중에서는 제가 쓴 "소프트웨어 개발의 모든 것...안녕하세요. godway님<br>우리나라 책중에서는 제가 쓴 "소프트웨어 개발의 모든 것"을 추천합니다. 그리고 외국책 중에서는 Requirement Engineering으로 검색을 해보시는 것이 좋겠습니다. <br>책을 보는 것은 도움이 되기는 하지만 책만 보고 제대로 작성하는데는 매우 오랜 시간이 걸립니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-89554411396804525282010-11-11T21:03:21.000+09:002010-11-11T21:03:21.000+09:00소프트웨어 개발의 모든 것, CodeCraft, 조엘온 소프트웨어 등등을 읽으면서,&quo...소프트웨어 개발의 모든 것, CodeCraft, 조엘온 소프트웨어 등등을 읽으면서,<br><br>"스펙 문서 만드세요."<br><br>라는 말을 볼 때마다, 그렇지요 옳은 말씀이지요 하면서 읽었습니다. <br><br>실제로 실천하려 하니 참으로 어렵다는 생각을 많이 해 봤습니다. <br><br><br><br>문서를 여러개를 짧게 만들어야 하는지, 길게 하나로 만들어야 하는지...<br><br>여기에는 이것이 들어가도 되지만, 저기에는 이것이 들어가면 안되는지...<br><br>이것들 고민하는 것이 일이고 실력이라는 생각 역시 들었습니다. <br><br><br>하지만 전에 한 번 분석 설계 구현의 순서로 만들기를 실험해 봤을 때,<br><br>시간이 확실히 줄어들었던 기억이 있어서 <br><br>이젠 꼭 지키려고 노력합니다. <br><br><br>정말<br><br>"건강하게 살려면, 나쁜 것들 드시지 마시고, 운동 열심히 하세요"만큼이나 어려운 일이 문서화인듯 합니다.주의사신http://sainthkh.codex.krnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-27098418177344837622010-11-12T00:18:43.000+09:002010-11-12T00:18:43.000+09:00안녕하세요. 주의사신님문서는 쪼개나 합치나 같은 겁니다.관리가 편하려면 하나의 문서로 만드...안녕하세요. 주의사신님<br>문서는 쪼개나 합치나 같은 겁니다.<br>관리가 편하려면 하나의 문서로 만드는 것이 좋지만, 한 섹션이 너무 크면 문서를 나눠도 좋습니다.<br>단 문서를 나눌 경우에는 문서에 Link를 걸어야 하는데 Link된 문서는 바로 열어 볼 수 있도록 회사의 문서관리시스템이나 소스코드관리시스템에 등록해서 그 Link를 추가해야 합니다.<br>좋은 경험을 가지고 계시네요.<br>꾸준히 계속 적어나가면 매번 실력이 늘어가는 것을 느낄 수 있을 겁니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-14389813273348924982010-11-12T01:33:13.000+09:002010-11-12T01:33:13.000+09:00안녕하세요, 전규현님 오랜만입니다.문서를 만들겠다고 달려드는 데서 부터 문서화 작업이 힘들...안녕하세요, 전규현님 오랜만입니다.<br>문서를 만들겠다고 달려드는 데서 부터 문서화 작업이 힘들어 지는 것이 아닌가 생각합니다. 요즘 인기있는 지속적 통합이나 지속적 배포같은 부분에서 말하듯이 문서화도 짧게 지속적으로 문서를 만들어 나가야 하지 않을까 생각합니다. 시스템 만들어 놓고 테스트 시작하거나, 통합을 시작하거나 하면 큰 문제가 생기니 짧게 짧게 작은 양에 대한 작업을 하자는 것처럼 문서화도 그 때 그 때 노트 형식으로 적어 놓으면서 발전 시켜 나가는 방법도 나쁘지 않은것 같습니다.Jakenoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-11052725299726687812010-11-14T11:09:17.000+09:002010-11-14T11:09:17.000+09:00안녕하세요. Jake님과유불급이라고 생각합니다.그래도 여전히 문서 만들기를 지극히 싫어 합...안녕하세요. Jake님<br>과유불급이라고 생각합니다.<br>그래도 여전히 문서 만들기를 지극히 싫어 합니다.<br>그래서 최근에 Agile에서는 문서를 안만들어 되는 것으로 착각하고 혹 하기는 합니다.<br>문서를 만드는 방법이 다를 뿐이죠.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-43862792697517436292010-11-12T09:01:16.000+09:002010-11-12T09:01:16.000+09:00문서는 만드는것보다도 계속 업데이트하는게 중요한것 같더군요..실제로 버전이 올라가다 보면 ...문서는 만드는것보다도 계속 업데이트하는게 중요한것 같더군요..<br>실제로 버전이 올라가다 보면 문서와 소스내용이 틀려 낭패보는 경우도 가끔 있구요..<br>저술하신 "소프트웨어 개발의 모든것"을 봤지만 제가 말씀드린 경우의 해결책은 못 본것 같은데요..(기억을 못하는지도..)<br><br>문서의 버전업을 어떤 형식으로 진행할 수 있는지 방안이 있으시면 조언 부탁드립니다.<br>또 문서없이 wiki만 사용하는 경우 문제점이 있을까요? (요즘 문서의 버전문제때문에 wiki를 검토중이라서요..)<br><br>언제나 좋은 글 감사합니다..무혹http://digitcom.krnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-51906309821410027382010-11-14T11:14:20.000+09:002010-11-14T11:14:20.000+09:00안녕하세요. 무혹님그래서 문서는 최대한 적게 만들어야 합니다.제 책에서도 문서의 업데이트에...안녕하세요. 무혹님<br>그래서 문서는 최대한 적게 만들어야 합니다.<br>제 책에서도 문서의 업데이트에 대한 내용이 있습니다.<br>책의 내용을 보면 이와 관련된 내용이 몇가지 있습니다.<br>문서는 업데이트가 어렵기 때문에 꼭 필요한 문서만 만들고 SRS는 꼭 업데이트 하라고 하고 있습니다.<br>또한 설계문서는 완벽하게 업데이트하기 어렵다고 설명하고 있습니다.<br>설계문서는 구현을 하기 위해 필요한 것이기 때문에 나중에 변경되는 것은 모두 업데이트 하기 어렵습니다.<br>그래서 Doxygen이나 JavaDoc을 잘 이용할 것을 설명하고 있습니다.<br><br>설계에서는 그렇기 때문에 인터페이스를 최대한으로 깔끔하고 간단하게 만드는 것이 좋습니다. 너무 얽히섥히 섞인 인터페이스는 나중에 바뀌더라도 관리가 잘 안됩니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-454844072841015492010-11-12T09:53:39.000+09:002010-11-12T09:53:39.000+09:00약간 다른 이야기 이기는 합니다만..대체로 글 잘 쓰시는 분들이 코딩 역시 잘 하시더군요후...약간 다른 이야기 이기는 합니다만..<br>대체로 글 잘 쓰시는 분들이 코딩 역시 잘 하시더군요<br><br>후배들 코딩 스타일을 글 쓰는 유형에 비교하면 다음 3가지로 간추려 지는데..<br> -시인 타입: 이해하기 힘들다. 잘 돌아간다.<br> -이면지 제작자: 이해하기 힘들다. 잘 안 돌아간다.<br> -기자 타입: 이해하기 쉽다. 잘 돌아간다.<br><br>요새는 코딩하기 전 과제 계획서 또는 일정표 등 문서 부터 써 보라고 합니다.<br>글을 쓰는 모습을 보면 이 사람이 코딩을 어떻게 하겠다 대충 알 것 같더군요<br>더불어 우리가 수학 논문을 많이 쓰기 때문에 증명 숙제 한거나, 쓴 논문을 보면 이 녀석이 위 중 어느 타입이구나 감이 오더군요.csjnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-39724714499484230962010-11-14T11:15:25.000+09:002010-11-14T11:15:25.000+09:00csj님 안녕하세요.전적으로 동감합니다. Coding도 하나의 언어잖아요. ^^csj님 안녕하세요.<br>전적으로 동감합니다. Coding도 하나의 언어잖아요. ^^Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-10642690191408407912010-11-12T16:51:05.000+09:002010-11-12T16:51:05.000+09:00안녕하세요 ~ 좋은 글 잘 봤습니다저는 컴퓨터와는 전혀 관련이 없지만 말씀하신 내용은 학생...안녕하세요 ~ 좋은 글 잘 봤습니다<br>저는 컴퓨터와는 전혀 관련이 없지만 말씀하신 내용은 학생부터 나이든 할아버지 할머니까지 도움이 되는 거 같아요<br><br>뭐 개인적으로는 연구노트를 꾸준히 제 때에 쓰고, 제 때에 다시 살펴보는 게 얼마나 어려운 지 느끼고 있네욤 ㅡ _ㅡ;;Playinghttp://playing.thoth.krnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-91630417519616946222010-11-14T11:16:18.000+09:002010-11-14T11:16:18.000+09:00안녕하세요. Playing님세상만사 다 비슷한가 봅니다.안녕하세요. Playing님<br>세상만사 다 비슷한가 봅니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-28107391758560186782010-11-14T11:39:42.000+09:002010-11-14T11:39:42.000+09:00한번 작성이 아니라 계속 업데이트 해야 하고그걸 여러 사람과 공유/동기화 하는게 가장 힘든...한번 작성이 아니라 계속 업데이트 해야 하고<br>그걸 여러 사람과 공유/동기화 하는게 가장 힘든걸 보면<br>Trac 등에서 위키로 문서화 하는 추세가 바람직 할수 밖에 없는것 같아요.구차니http://minimonk.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-15632636556412657822010-11-14T17:16:25.000+09:002010-11-14T17:16:25.000+09:00안녕하세요. 구차니님Word로 작성을 하던 Wiki를 이용하든지 큰 상관은 없을 것 같습니...안녕하세요. 구차니님<br>Word로 작성을 하던 Wiki를 이용하든지 큰 상관은 없을 것 같습니다. 중요한 것은 문서를 작성하는 것이고 그 내용이 더 중요하다고 생각합니다. 어디에 적느냐는 서로 장단점이 있는 것 같습니다.<br><br>내용이 중요하다는 의미는 설계문서를 작성할 때 UML을 이용하느냐 Doc로 작성하느냐 노트에 연필로 작성하느냐보다는 "설계"자체를 잘 하냐가 더 중요하듯이 어차피 내용을 잘 모르면 어떠한 툴을 가져와도 의미 없는 문서가 됩니다.<br><br>그래서 선배들이 작성한 문서를 리뷰에 참석해서 꾸준히 배워나가는 것이 문서에 무엇을 적어야 하는지 배우고 또 어떻게 적어야 하는지 어떻게 리뷰를 해야 하는지 익힐 수 있습니다.<br><br>또, 무엇은 적을 필요가 없는지도 자연스럽게 배우게 됩니다.<br><br>현재 그런 환경이 아니라면 누군가가 먼저 시작을 해야겠죠. 항상 선구자는 힘든 법입니다. ^^Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-24199308747828601332010-11-14T19:40:06.000+09:002010-11-14T19:40:06.000+09:00선구자는 힘들다는 말, 무척 공감이 갑니다."내가 무엇을 해 보겠다" 할...선구자는 힘들다는 말, 무척 공감이 갑니다.<br><br>"내가 무엇을 해 보겠다" 할 때 대부분 반응은 "왜 귀찮게 그런 걸 하냐"가 대다수 더군요<br><br>가끔은 왜 이걸 해야 하는지 설득하는게 더 힘들 때도 있습니다.<br><br>여하튼 최근에 작은 프로젝트 팀장이 되어 이것 저것 해 보려고 하다보니 고민이 많네요.csjnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-87015545534238838552010-11-15T10:03:26.000+09:002010-11-15T10:03:26.000+09:00그런 경우는 무엇을 하고 무엇은 지금은 무리인지를 판단하는게 중요합니다.사실 이런 판단이 ...그런 경우는 무엇을 하고 무엇은 지금은 무리인지를 판단하는게 중요합니다.<br>사실 이런 판단이 가장 어려운 판단 중에서 하나입니다.<br>그럴때 주변의 선배나 전문가에게 물어보는 것이 가장 좋습니다.<br>본인 스스로 판단하는 능력이 생기려면 이러한 경험을 모두 해 본 후 일겁니다.<br>참 힘들죠~Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-84353853493662782382010-11-15T22:53:09.000+09:002010-11-15T22:53:09.000+09:00현재 3명이 작은 프로젝트를 진행 하고 있습니다. 문서화.. 참 힘들네요.. ㅠ현재 3명이 작은 프로젝트를 진행 하고 있습니다. <br><br>문서화.. 참 힘들네요.. ㅠ철이noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-44971915464060188222010-11-16T09:10:35.000+09:002010-11-16T09:10:35.000+09:00안녕하세요. 철이님혹시 문서화를 왜 하려고 하시나요?문서를 작성하면 프로젝트의 기간이 줄어...안녕하세요. 철이님<br>혹시 문서화를 왜 하려고 하시나요?<br>문서를 작성하면 프로젝트의 기간이 줄어든다는 것을 믿고 계시나요?<br>이것을 경험을 통해서 알고 있지 않으면 문서를 만들기 정말 어렵습니다.<br>대부분은 몇번 문서를 만들다가 프로젝트 시간만 더 걸리고 문서가 사장되기 일쑤입니다.<br>이런 경우는 필요없는 문서를 만들거나 문서를 잘못 만들기 때문인 경우가 많습니다.<br>그래서 제 책에서는 설계 문서보다더 스펙(SRS)문서를 만들라고 권하고 있습니다. 또한 뒤늦게 만드는 문서는 필요없고 프로젝트를 더 지연시키므로 만들지 말라고 하고 있습니다.<br>또 중요한 것은 문서는 가능하면 적게 만드는 것이 가장 좋습니다.Ray.전규현http://allofsoftware.netnoreply@blogger.com