'2007/10'에 해당되는 글 5건
- 2007/10/10 :: Linux HDD 추가방법
- 2007/10/07 :: Create A Data Set Tutorial
- 2007/10/07 :: Open Source Charting & Reporting Tools in Java
- 2007/10/01 :: 어느 피노키오의 후회
- 2007/10/01 :: 팀원들에게 보내는 잔소리
# 지금 개발할때 따로 vmware에 설치한 리눅스를 사용하고 있습니다. 설치할때 하드디스크의 용량을 10G를 줬었는데 프로그램 설치한것도 별로 없이 벌써 용량이 모자라서 5G의 하드디스크의 용량을 추가하였습니다.
# Fdisk로 파티션을 나누고 mkfs로 파일시스템을 주고 난 다음 /etc/fstab 에 부팅시 자동 오토마운트 되도록 등록하였습니다. 그리고 다시 재부팅을 했는데 마운트할때 에러 발생!! 정말 난감했습니다. 원인을 알아보니 fstab에 디바이스명을 잘못 줘서 부팅시 에러가 발생한걸 알았습니다. 그럼 fstab을 수정하면 문제 해결이지만 에러가 발생하니 "/"가 read 로만 마운트되었습니다. (부팅시 에러발생하니 / 만 마운트 되어있더군요.)
결국 여기저기서 찾아보니 재마운트하는 방법으로 해결하라고 나오더군요. 이것도 안되면 cd로 부팅후 복구해야 한다고 합니다. 그래서 마운트를 다시 하니 fstab 수정가능 ..O.O (mount -o remount,rw /) 그리고 정상 작동했습니다.
# 하드디스크 추가할때 당연히 fstab을 수정해서 오토마운트 시키는데 fstab을 수정할때는 정말정말~ 주의해야합니다.
이올린에 북마크하기
Trackback : http://reme.tistory.com/trackback/276
< # Create A Data Set Tutorial >
Trackback : http://reme.tistory.com/trackback/275
2007/10/07 15:29
:: Open Source Charting & Reporting Tools in Java
2007/10/07 15:29 in programming/database
Open Source Charting & Reporting Tools in Java
JFreeChart
| JFreeChart is a free Java class library for generating charts, including: * pie charts (2D and 3D) * bar charts (regular and stacked, with an optional 3D effect) * line and area charts * scatter plots and bubble charts * time series, high/low/open/close charts and candle stick charts * combination charts * Pareto charts * Gantt charts * wind plots, meter charts and symbol charts * wafer map charts |
JasperReports
| JasperReports is a powerful open source Java reporting tool that has the ability to deliver rich content onto the screen, to the printer or into PDF, HTML, XLS, CSV and XML files. |
jCharts
| jCharts is a 100% Java based charting utility that outputs a variety of charts. This package has been designed from the ground up by volunteers for displaying charts via Servlets, JSP's, and Swing apps. |
Cewolf
| Cewolf can be used inside a Servlet/JSP based web application to embed complex graphical charts of all kinds (e.g. line, pie, bar chart, plots, etc.) into a web page. Therefore it provides a full featured tag library to define all properties of the chart (colors, strokes, legend, etc.). Thus the JSP which embedds the chart is not polluted with any java code. Everything is described with XML conform tags. |
JCCKit
| The Java Chart Constuction Kit (JCCKit) is a small (< 100Kb) Java library and a very flexible framework for creating scientific charts and plots. |
JOpenChart
| OpenChart is an open source Java library and toolkit for creating different kinds of charts and embedding them into web applications or Swing applications. |
Chart2D
| Chart2D is a library written in Java for adding 2D charts to Java programs |
JFreeReport
| JFreeReport is a free Java report library. It has the following features: * full on-screen print preview * data obtained via Swing's TableModel interface (making it easy to print data directly from your application) * XML-based report definitions * output to the screen, printer or various export formats (PDF, HTML, CSV, Excel, plain text) * support for servlets (uses the JFreeReport extensions) |
Datavision
| DataVision is an Open Source reporting tool similar to Crystal Reports. Reports can be designed using a drag-and-drop GUI. They may be run, viewed, and printed from the application or exported as HTML, XML, PDF, LaTeX2e, DocBook, or tab- or comma-delimited text files. The output files produced by LaTeX2e and DocBook can in turn be used to produce PDF, text, HTML, PostScript, and more. |
iReport
| iReport is a visual reporting tool based on JasperReports written in 100% pure java. You can manage charts, images, subreports,... Data can be retrived using JDBC, TableModels, JavaBeans, XML,...It supports output in PDF,XML,XLS,CSV,HTML,Java2D,... |
ART
| ART is a lightweight, multiplatform web based query tool and reporting environment. Easy customizable, support graphs, export resultset in various formats via plug-ins. |
JChart2d
| A Java swing widget (JComponent) for precise runtime-dynamic display of tupels in form of a stripe chart. Intended for engineering task where precision is more important than a huge variety of different beautiful presentations. Key features are a minimal configuration effort, automatic scaling and labeling, thread-safeness, a clean and extendible API and extensive documentation. |
Open Reports
| OpenReports is a flexible open source web reporting solution that allows users to generate dynamic reports in a browser. OpenReports uses JasperReports, an excellent full featured open source reporting engine, and was developed using leading open source components including WebWork, Velocity, Quartz, and Hibernate. |
BIRT
| BIRT is an open source, Eclipse-based reporting system that can integrates with an application to produce compelling reports for both web and PDF. |
Pentaho - Business Intelligence
| Enterprise-class Business Intelligence (BI) - including reporting, analysis, dashboards, data mining and workflow. Inlcudes Eclipse BIRT, JasperReports, Mondrian, JPivot, scheduling, web services, busienss rules. Released under the Pentaho Public License |
Go To Pentaho - Business Intelligence
See also Open Source PDF Libraries in Java
이올린에 추천하기Trackback : http://reme.tistory.com/trackback/273
Trackback : http://reme.tistory.com/trackback/272
김도형|(주)알티캐스트 책임연구원
포항공대 컴퓨터 공학과를 졸업하고 KAIST 전산학과에서 석사 학위를 취득했다. 마소에는 96년부터 주로 자바, XML, 인터넷 관련 기고를 해 왔다. 알티캐스트 창립 멤버로 대화형 TV를 위한 저작도구를 개발했고, 현재는 수신기에 탑재되는 미들웨어의 JVM과 그래픽 엔진 쪽의 개발과 개선을 담당하고 있다.
석사를 갓 마치고 신생 회사에 들어온 탓에 사실상 팀장으로 회사 생활을 시작한 필자는 말단이 될 수 있는 호사(?)를 한번도 누리지 못한 채 만 4년 동안 적게는 4명, 많게는 12명 정도 규모의 개발팀을 이끌어 왔다. 개발팀을 구성하고 이끄는 모델을 제시해 줄 그 누군가가 없는 상황에서 필자는 항상 독학, 초보 관리자였고 겪은 시행착오도 이루 말할 수 없다. 물론 작은 회사의 개발 팀장들이 그렇듯 바람직하다고 할 수는 없지만 아직도 상당 부분의 코드를 직접 쓰고 리뷰한다. 이 글에서는 한 사람의 개발자로서, 또 개발 팀장으로 필자가 팀원들에게 늘 하던 말이나 하고 싶었던 잔소리들을 추려 보았다.
표현의 기술을 익혀라
여럿이 함께 일하는 그 자체만으로도 난관은 무척 많다. 전산학을 전공한 사람이라면 학생 시절부터 다수의 사람이 함께 일하는 방법에 대해 많은 고민들을 해 보았을 것이다. 특히 협업을 지원하기 위한 도구와 방법론에 관심을 가지게 되고 실제 적용하려는 시도도 해 보게 된다. 하지만 현업에서 부딪히는 가장 큰 문제점은 그런 고차원적인 것에 있지 않다. 개발자간에 대화 자체가 쉽지 않다는 아주 근원적인 문제에 봉착하게 된다.
글이 어렵기로 정평이 난 필자가 이런 이야기를 하는 것 자체가 어색한 일이지만 글 잘 쓰고 말을 조리 있게 하는 개발자를 만나기는 의외로 쉽지 않다. 필자가 타인과 어떤 정보를 주고 받아야 하는지, 또 어떻게 하면 효과적으로 내 의사를 전달할 수 있는지에 대한 기본적인 고민이 우리에게는 많이 부족한 것 같다. 특히 영어를 사용해야 하는 경우 상황은 더 나빠진다. 문서나 주석을 영어로 작성하는 경우 표현력과 어휘력의 한계로 정작 적어야 하는 내용은 조용히 건너뛰는 경우가 대부분이다.
자신의 생각을 정리하고 표현하는 기술을 향상시키자. 생각을 그저 코드만으로 표현할 수 있다고 주장하는 개발자와는 일하기 힘들다. 또 그 코드는 믿을 수 없는 경우가 많다. 자신이 설계한 도구의 기본 개념을 일목요연하게 설명할 수 없는 개발자의 코드에 요구 사항들이 제대로 반영되었다고 어떻게 믿을 수 있겠는가. 또 멀티쓰레드 프로그래밍을 하면서 내 코드의 동기화(synchronization) 구조를 명확히 표현하고 데드락(deadlock)의 유무를 설명할 수 없는 프로그래머의 코드를 어떻게 믿을 수 있겠는가.
또한 많은 개발자에게 있어 J2EE니 닷넷이니 하는 브랜드가 붙은 기술적인 것들 외의 책을 접하는 경우가 많이 부족한 듯 싶다. 하지만 사실 중요한 것은 브랜드를 넘어서는 지식의 깊이다. 꼭 교과서적인 책을 읽으라는 말은 아니다. 그 외에도 실용적이면서 읽어둘 만한 책들은 얼마든지 있다. 또한 아예 현안과 다른 분야의 자료를 읽어두는 여유를 가져라. 멀티쓰레드 프로그래밍을 하고 있다면 자바 관련으로 나오는 해당 서적 한 권쯤은 읽어보자. 이미 관리자의 길에 들어선 개발자라면(굳이 말하지 않아도 그렇게 하고 있겠지만), 소프트웨어 프로젝트 관리에 대한 책이나 마소에 소개된 적이 있고 많은 분들이 인용하는 『The Mythical Man-Month』 같은 책 정도는 읽어 두자.
그저 부딪히는 것 외에 멀티쓰레드 프로그래밍이나 소프트웨어 프로젝트 관리에 뭐 왕도가 있겠냐고 생각할 수 있겠지만, 그러한 책들이 자신의 역량에 주는 도움은 상상 이상이다. 개발자로서 소프트웨어 프로젝트의 관리에 대해서 조금이라도 고민해 본 적이 있는 사람이라면 1975년도에 초판이 나온 『The Mythical Man-Month』가 오늘날 내가 처한 상황을 꿰뚫는 통찰력에 무척 놀라게 될 것이다. 변화가 빠른 IT도 결국 근원적이고 본질적인 문제들을 뒤엎는 혁신의 연속은 아니다. 올해 읽은 것들이 내년이면 쓸모 없어질 것이라는 근거 없는 조바심을 버리자.
코드가 곧 문서
개발 초기 빡빡한 개발 스케쥴에 빈번히 코드가 다시 쓰여지는 상황에서 단순히 문서 작성의 중요성을 강조해 봐야 그건 공허한 메아리일 뿐이다. 강요에 의해 나오는 문서는 아무도 다시 읽지 않는다. 필자의 경우 최초 개발을 주로 자바로 진행했으므로 팀원들에게 썬의 자바 코딩 규약을 약간 수정해서 따를 것과 Javadoc이 문서를 생성할 수 있는 문서 주석(doc comment)을 꼼꼼히 작성할 것을 요구했다. 그 결과 그간 팀을 거쳐 간 개발자들은 어느 정도 꼼꼼히 문서 주석을 작성하는 습관이 들어 있다. 최근에는 C 코드의 경우도 Javadoc과 유사한 Doxygen(Javadoc과 유사한 도구) 형식에 맞춰 문서 주석을 작성하도록 하고 있다.
이 방법의 좋은 점은 우선 소스 코드의 일부로 문서가 관리되므로 비교적 적은 노력으로 소스 코드의 변경을 반영하는 문서를 얻어낼 수 있다는 점을 들 수 있다. 당연하지만 이를 위해서는 문서 주석이 코드의 일부라는 인식을 가지는 것이 중요하다.
또 한 가지 중요하면서도 자주 간과되는 장점은 클래스 혹은 함수들의 골격을 작성하고 그 코드가 어떤 일을 하고 어떤 가정을 하는지를 미리 꼼꼼히 정리하다 보면 기본적인 설계의 문제점을 조기에 파악할 수 있고 코딩상 오류를 줄일 수 있다는 점이다. 즉 주석은 남을 위한 만큼 나를 위한 것이다. 이를 위해서는 코드를 다 작성한 뒤에 주석을 적어 가는 게 아니라 코드의 골격만을 잡은 상태에서 주석을 적어 놓고 코드를 채워 나가는 습관이 필요하다.
아울러 개발 과정에서 서로 아이디어를 공유하고 리뷰하기 위해서는 단순히 칠판 앞에서 아무 준비 없이 토론을 하는 것보다는 뭔가 회의 전에 미리 볼 수 있고 기록으로도 남는 문서로 정리하는 편이 유용한 경우가 많다. 하지만 많은 개발자들에게 문서의 작성은 그저 귀중한 시간을 갉아먹는 귀찮은 일일뿐이다. 이 문제에 대한 해결책으로 같이 일을 했던 후배가 소개해 준 방법이 있다. 잘 아는 학교 선배에게 배웠다는 해결책은 의외로 간단하다. 파워포인트 같은 프리젠테이션 툴을 이용해서 발표자료를 만들 듯이 문서를 만드는 것이다. 실제 적용해 본 결과는 꽤 만족스러웠다. 아마도 이미 정해진 문서의 틀이 있고 발표자료의 경우는 뭔가 요점을 표현해야 한다는 인식을 가지고 있는 점이 효과를 발휘하는 것 같다.
코드 리뷰의 놀라운 효과
소프트웨어 프로젝트 관리에 대한 책을 읽으면 코드 리뷰의 중요성에 대해서는 꼭 언급이 된다. 회사의 미국 법인 내의 개발자를 포함해서 필자가 만나 본 상당수의 외국 개발자들은 3시간의 코드 리뷰가 3주 이상의 시간을 절약할 수 있다는 점에 아무도 이의를 제기하지 않았다. 하지만 코드 리뷰를 제대로 하고 있는 국내 소프트웨어 회사가 몇 군데나 될지 상당히 의문이다.
누가 리뷰를 하느냐, 언제 리뷰를 하느냐 등의 절차적인 이슈를 제외하고 리뷰의 실효성에 대해서는 실제 해 보면 쉽게 알 수 있다. 많은 개발자들이 코딩이 끝난 뒤 코드의 검증이 테스트를 통해서 이루어진다는 안이한 인식에 머물러 있는 것을 보게 된다. 웬만큼 자신의 코드를 꼼꼼히 테스트하는 사람도 사실 자신의 테스트 케이스가 코드를 테스트하기에는 그 범위(coverage)가 사실상 턱없이 부족하다는 것을 모르는 경우가 허다하다.
관리자는 코드 리뷰와 같은 작업에 시간을 투자할 수 있도록 언제나 시간을 비워 둬라. 그것이야말로 긴 테스트와 디버깅 사이클 동안 웃을 수 있는 비결이다. 또한 시간을 두고 한 번씩만 자신의 코드를 다시 살펴보자. 필자가 아는 한 개발자는 항상 꼼꼼히 테스트 케이스를 디자인하고 자신의 코드를 적어도 한번 이상은 리뷰해 본다. 당연하지만 그 개발자의 코드는 상당히 질이 높다. 많은 프로그래머가 설익은 생각을 코드에 쏟아놓고 그저 아무 일 없기를 기도한다. 내가 저지른 일과 정면으로 맞닥뜨려라.
여러 세대에 걸쳐 지어지는 성당처럼
마지막으로 팀을 이끄는 관리자 입장에서 독자들에게 당부하고 싶은 이야기다. 흔히 엔지니어들은 고집이 세다고 말한다. 그러다 보면 흔히 개발팀 내의 많은 사항들을 결정하는데 있어 잦은 충돌이 있기 마련이다. 객관적으로 어떤 결정이 우월한 경우는 별 문제가 아니지만 애매한 경우가 많다. 이런 경우 애매한 절충안을 택하는 경우가 많은데 원래 선택보다 못한 경우가 대부분이다.
앞서 소개한 『The Mythical Man-Month』에서 보듯 유럽의 성당은 여러 세대를 거쳐 다른 건축가에 의해 완성되어 가지만 그 전체의 완결성과 통일성은 유지된다는 사실을 명심해 주기 바란다. 필자의 경험으로는 대부분 개발자 각각의 만족보다는 항상 전체적인 설계의 완결성이 절대적으로 중요하다. 이 글을 읽는 모든 개발자들이 잔소리를 늘어놓는 필자와 같은 팀장을 이해해 주기를 바라면서 내일의 팀장을 꿈꾸는 모든 개발팀원들에게 이 글을 바친다.
포항공대 컴퓨터 공학과를 졸업하고 KAIST 전산학과에서 석사 학위를 취득했다. 마소에는 96년부터 주로 자바, XML, 인터넷 관련 기고를 해 왔다. 알티캐스트 창립 멤버로 대화형 TV를 위한 저작도구를 개발했고, 현재는 수신기에 탑재되는 미들웨어의 JVM과 그래픽 엔진 쪽의 개발과 개선을 담당하고 있다.
석사를 갓 마치고 신생 회사에 들어온 탓에 사실상 팀장으로 회사 생활을 시작한 필자는 말단이 될 수 있는 호사(?)를 한번도 누리지 못한 채 만 4년 동안 적게는 4명, 많게는 12명 정도 규모의 개발팀을 이끌어 왔다. 개발팀을 구성하고 이끄는 모델을 제시해 줄 그 누군가가 없는 상황에서 필자는 항상 독학, 초보 관리자였고 겪은 시행착오도 이루 말할 수 없다. 물론 작은 회사의 개발 팀장들이 그렇듯 바람직하다고 할 수는 없지만 아직도 상당 부분의 코드를 직접 쓰고 리뷰한다. 이 글에서는 한 사람의 개발자로서, 또 개발 팀장으로 필자가 팀원들에게 늘 하던 말이나 하고 싶었던 잔소리들을 추려 보았다.
표현의 기술을 익혀라
여럿이 함께 일하는 그 자체만으로도 난관은 무척 많다. 전산학을 전공한 사람이라면 학생 시절부터 다수의 사람이 함께 일하는 방법에 대해 많은 고민들을 해 보았을 것이다. 특히 협업을 지원하기 위한 도구와 방법론에 관심을 가지게 되고 실제 적용하려는 시도도 해 보게 된다. 하지만 현업에서 부딪히는 가장 큰 문제점은 그런 고차원적인 것에 있지 않다. 개발자간에 대화 자체가 쉽지 않다는 아주 근원적인 문제에 봉착하게 된다.
글이 어렵기로 정평이 난 필자가 이런 이야기를 하는 것 자체가 어색한 일이지만 글 잘 쓰고 말을 조리 있게 하는 개발자를 만나기는 의외로 쉽지 않다. 필자가 타인과 어떤 정보를 주고 받아야 하는지, 또 어떻게 하면 효과적으로 내 의사를 전달할 수 있는지에 대한 기본적인 고민이 우리에게는 많이 부족한 것 같다. 특히 영어를 사용해야 하는 경우 상황은 더 나빠진다. 문서나 주석을 영어로 작성하는 경우 표현력과 어휘력의 한계로 정작 적어야 하는 내용은 조용히 건너뛰는 경우가 대부분이다.
자신의 생각을 정리하고 표현하는 기술을 향상시키자. 생각을 그저 코드만으로 표현할 수 있다고 주장하는 개발자와는 일하기 힘들다. 또 그 코드는 믿을 수 없는 경우가 많다. 자신이 설계한 도구의 기본 개념을 일목요연하게 설명할 수 없는 개발자의 코드에 요구 사항들이 제대로 반영되었다고 어떻게 믿을 수 있겠는가. 또 멀티쓰레드 프로그래밍을 하면서 내 코드의 동기화(synchronization) 구조를 명확히 표현하고 데드락(deadlock)의 유무를 설명할 수 없는 프로그래머의 코드를 어떻게 믿을 수 있겠는가.
또한 많은 개발자에게 있어 J2EE니 닷넷이니 하는 브랜드가 붙은 기술적인 것들 외의 책을 접하는 경우가 많이 부족한 듯 싶다. 하지만 사실 중요한 것은 브랜드를 넘어서는 지식의 깊이다. 꼭 교과서적인 책을 읽으라는 말은 아니다. 그 외에도 실용적이면서 읽어둘 만한 책들은 얼마든지 있다. 또한 아예 현안과 다른 분야의 자료를 읽어두는 여유를 가져라. 멀티쓰레드 프로그래밍을 하고 있다면 자바 관련으로 나오는 해당 서적 한 권쯤은 읽어보자. 이미 관리자의 길에 들어선 개발자라면(굳이 말하지 않아도 그렇게 하고 있겠지만), 소프트웨어 프로젝트 관리에 대한 책이나 마소에 소개된 적이 있고 많은 분들이 인용하는 『The Mythical Man-Month』 같은 책 정도는 읽어 두자.
그저 부딪히는 것 외에 멀티쓰레드 프로그래밍이나 소프트웨어 프로젝트 관리에 뭐 왕도가 있겠냐고 생각할 수 있겠지만, 그러한 책들이 자신의 역량에 주는 도움은 상상 이상이다. 개발자로서 소프트웨어 프로젝트의 관리에 대해서 조금이라도 고민해 본 적이 있는 사람이라면 1975년도에 초판이 나온 『The Mythical Man-Month』가 오늘날 내가 처한 상황을 꿰뚫는 통찰력에 무척 놀라게 될 것이다. 변화가 빠른 IT도 결국 근원적이고 본질적인 문제들을 뒤엎는 혁신의 연속은 아니다. 올해 읽은 것들이 내년이면 쓸모 없어질 것이라는 근거 없는 조바심을 버리자.
코드가 곧 문서
개발 초기 빡빡한 개발 스케쥴에 빈번히 코드가 다시 쓰여지는 상황에서 단순히 문서 작성의 중요성을 강조해 봐야 그건 공허한 메아리일 뿐이다. 강요에 의해 나오는 문서는 아무도 다시 읽지 않는다. 필자의 경우 최초 개발을 주로 자바로 진행했으므로 팀원들에게 썬의 자바 코딩 규약을 약간 수정해서 따를 것과 Javadoc이 문서를 생성할 수 있는 문서 주석(doc comment)을 꼼꼼히 작성할 것을 요구했다. 그 결과 그간 팀을 거쳐 간 개발자들은 어느 정도 꼼꼼히 문서 주석을 작성하는 습관이 들어 있다. 최근에는 C 코드의 경우도 Javadoc과 유사한 Doxygen(Javadoc과 유사한 도구) 형식에 맞춰 문서 주석을 작성하도록 하고 있다.
이 방법의 좋은 점은 우선 소스 코드의 일부로 문서가 관리되므로 비교적 적은 노력으로 소스 코드의 변경을 반영하는 문서를 얻어낼 수 있다는 점을 들 수 있다. 당연하지만 이를 위해서는 문서 주석이 코드의 일부라는 인식을 가지는 것이 중요하다.
또 한 가지 중요하면서도 자주 간과되는 장점은 클래스 혹은 함수들의 골격을 작성하고 그 코드가 어떤 일을 하고 어떤 가정을 하는지를 미리 꼼꼼히 정리하다 보면 기본적인 설계의 문제점을 조기에 파악할 수 있고 코딩상 오류를 줄일 수 있다는 점이다. 즉 주석은 남을 위한 만큼 나를 위한 것이다. 이를 위해서는 코드를 다 작성한 뒤에 주석을 적어 가는 게 아니라 코드의 골격만을 잡은 상태에서 주석을 적어 놓고 코드를 채워 나가는 습관이 필요하다.
아울러 개발 과정에서 서로 아이디어를 공유하고 리뷰하기 위해서는 단순히 칠판 앞에서 아무 준비 없이 토론을 하는 것보다는 뭔가 회의 전에 미리 볼 수 있고 기록으로도 남는 문서로 정리하는 편이 유용한 경우가 많다. 하지만 많은 개발자들에게 문서의 작성은 그저 귀중한 시간을 갉아먹는 귀찮은 일일뿐이다. 이 문제에 대한 해결책으로 같이 일을 했던 후배가 소개해 준 방법이 있다. 잘 아는 학교 선배에게 배웠다는 해결책은 의외로 간단하다. 파워포인트 같은 프리젠테이션 툴을 이용해서 발표자료를 만들 듯이 문서를 만드는 것이다. 실제 적용해 본 결과는 꽤 만족스러웠다. 아마도 이미 정해진 문서의 틀이 있고 발표자료의 경우는 뭔가 요점을 표현해야 한다는 인식을 가지고 있는 점이 효과를 발휘하는 것 같다.
코드 리뷰의 놀라운 효과
소프트웨어 프로젝트 관리에 대한 책을 읽으면 코드 리뷰의 중요성에 대해서는 꼭 언급이 된다. 회사의 미국 법인 내의 개발자를 포함해서 필자가 만나 본 상당수의 외국 개발자들은 3시간의 코드 리뷰가 3주 이상의 시간을 절약할 수 있다는 점에 아무도 이의를 제기하지 않았다. 하지만 코드 리뷰를 제대로 하고 있는 국내 소프트웨어 회사가 몇 군데나 될지 상당히 의문이다.
누가 리뷰를 하느냐, 언제 리뷰를 하느냐 등의 절차적인 이슈를 제외하고 리뷰의 실효성에 대해서는 실제 해 보면 쉽게 알 수 있다. 많은 개발자들이 코딩이 끝난 뒤 코드의 검증이 테스트를 통해서 이루어진다는 안이한 인식에 머물러 있는 것을 보게 된다. 웬만큼 자신의 코드를 꼼꼼히 테스트하는 사람도 사실 자신의 테스트 케이스가 코드를 테스트하기에는 그 범위(coverage)가 사실상 턱없이 부족하다는 것을 모르는 경우가 허다하다.
관리자는 코드 리뷰와 같은 작업에 시간을 투자할 수 있도록 언제나 시간을 비워 둬라. 그것이야말로 긴 테스트와 디버깅 사이클 동안 웃을 수 있는 비결이다. 또한 시간을 두고 한 번씩만 자신의 코드를 다시 살펴보자. 필자가 아는 한 개발자는 항상 꼼꼼히 테스트 케이스를 디자인하고 자신의 코드를 적어도 한번 이상은 리뷰해 본다. 당연하지만 그 개발자의 코드는 상당히 질이 높다. 많은 프로그래머가 설익은 생각을 코드에 쏟아놓고 그저 아무 일 없기를 기도한다. 내가 저지른 일과 정면으로 맞닥뜨려라.
여러 세대에 걸쳐 지어지는 성당처럼
마지막으로 팀을 이끄는 관리자 입장에서 독자들에게 당부하고 싶은 이야기다. 흔히 엔지니어들은 고집이 세다고 말한다. 그러다 보면 흔히 개발팀 내의 많은 사항들을 결정하는데 있어 잦은 충돌이 있기 마련이다. 객관적으로 어떤 결정이 우월한 경우는 별 문제가 아니지만 애매한 경우가 많다. 이런 경우 애매한 절충안을 택하는 경우가 많은데 원래 선택보다 못한 경우가 대부분이다.
앞서 소개한 『The Mythical Man-Month』에서 보듯 유럽의 성당은 여러 세대를 거쳐 다른 건축가에 의해 완성되어 가지만 그 전체의 완결성과 통일성은 유지된다는 사실을 명심해 주기 바란다. 필자의 경험으로는 대부분 개발자 각각의 만족보다는 항상 전체적인 설계의 완결성이 절대적으로 중요하다. 이 글을 읽는 모든 개발자들이 잔소리를 늘어놓는 필자와 같은 팀장을 이해해 주기를 바라면서 내일의 팀장을 꿈꾸는 모든 개발팀원들에게 이 글을 바친다.
Prev
Rss Feed