엘키의 주절 주절

사실 프로젝트를 진행해오면서 표준이 필요하다는 생각이 많이 들었습니다. XP에서도 주장하는 것은 죽은 문서를 만들지 말자는 것이지, 문서를 만들지 말자는 것이 아니듯이, 필요한 문서라면, 자주 참고해야 되는 내용이라면 당연히 문서화 하는 것이 맞습니다. 프로젝트가 오래 진행될 수록 네이밍, 클래스 상관도, 기본 설계 방침과 같은 것들에 대한 필요성이 절실했습니다. 아키텍처가 없을 때 같은 일을 하는 메소드가 중복 되고, 어떤 클래스는 크고 어떤 클래스는 작고, 어설픈 패턴적용으로 클래스 간의 관계가 모호하거나 복잡하고, 기능별 처리 주체 불분명해지는 등의 많은 문제를 안게 됩니다. 이런 문제를 책임지고 해결해줄 사람이 바로 아키텍트였습니다. 이 책에서는 아키텍트를 책임 설계자라고도 칭했는데, 아키텍처와 ..

사실 소프트웨어 개발에서 자바를 사용할 것인가, C++을 사용할 것인가, 윈도우를 사용할 것인가, 리눅스를 사용할 것인가, DBMS는 어떤 것을 사용할 것인가와 같은 기술적인 이슈는 빠질 수 없는 요소입니다. 그렇지만 기술적인 요소들에 대한 이해도가 높고, 능숙한 기술들로 소프트웨어를 개발한다고 했을 때에도 여전히 소프트웨어 개발은 쉽지 않습니다. 제가 천재가 아니라 확실하진 않지만, 천재도 실수를 하더군요. 당연한 것 아니겠습니까? 사람은 불완전한 존재니까요. 그렇다보니 익스트림 프로그래밍(eXtream Programming, 이하 XP)에서는 그런 실수를 줄이기 위해 테스트를 먼저 작성하고 프로그램에 포함 시키는 테스트 우선 프로그래밍(Test First Programming)을 하자고 주장하고 있습..

사실 이 책의 목차를 봤을 때만해도 흥미진진했던게 사실이다. 과연 베테랑 프로그래머들이 꼽는 Beautiful Code는 무엇일까? 내가 꼽을 Beatiful Code의 기준이 무엇이 될지도 흥미진진했던게 사실이다. 그런데 책을 읽으면 읽을수록 내가 기대하는 Beautiful보다는 Resolving에 가깝다는 느낌이 들었다. 어떤 문제를 해결 하기 위한(혹은 목표에 도달하기 위한) 과정을 코드로써 설명하고 있다는 느낌이 강하게 들었다. 다양한 분야의 개발자들의 코드를 묶은 것이다보니 내가 잘 모르는 언어로 표현된 것들이 있었지만, 대부분 어떤 의미를 내포하고 왜 그런 변화를 주었는지에 대해서 어느정도 이해가 되었기에 계속 읽어 나갈 수 있었다. 나처럼 정말 아름다운 코드가 무엇일까 라는 해답을 얻고자 한..

혼자 개발을 하던 시대는 지나갔다. 게임 업계에서도 1인 개발자는 별바람님을 제외하곤 사라진지 오래다. 그만큼 팀 작업의 중요성은 더 크게 다가 오고 있다. 한 프로젝트를 위해 마케팅, 서비스, 시스템, 개발이라는 각기 다른 업무를 맡고 있는 사람들이 협동해야하며, 한 팀 내에서도 웹, 서버, 클라이언트, 애니메이터, 배경, 원화가, 모델러, 기획자 등의 다양한 사람들이 함께 일하곤 한다. 우리는 하루에 반 이상을 회사에서 보낸다. 회사에서 즐겁지 못하다면, 우리의 인생도 즐겁지 않을 것이다. 어떻게 해야 우리 모두 만족하는 개발 과정을 만들 수 있을까? 사실 나는 알게 모르게 유비무환이라는 사자성어를 교훈삼아, 늘 넘치도록 준비하려 노력했다. 그게 미덕인줄 알았다. 이런 내게 있어 낭비를 제거하라는 충..

프로그래머는 자주 개발자라는 이름으로 불리고, 구현이 가장 중요한 듯 생각되기도 한다. 하지만, 개발 과정에서나, 유지보수 과정에서나 문제는 발생하기 마련이다. 능력이 아무리 뛰어나고, 머리 좋은 사람들이라 해도 문제를 만들기 마련이며, 오죽했으면 문제가 없다는 것은 아무 일도 일어나지 않고 있다는 증거다라는 말이 있겠는가? 문제가 발생하는 것을 당연하게 여기게 되었다면 우리가 할 수 있는 것은 크게 두 가지가 있다. 첫번째. 문제가 발생할 여지를 줄이는 것이다. 문제가 발생할 여지를 줄이는 좋은 방법으로는 좋은 습관을 들이는 것인데, 개발 프로세스를 늘 개선함으로써 단점을 보완해나가는 것이다. 반복 작업이 있다면 그 횟수를 줄일 순 없을까? 한번으로 끝낼 순 없을까? 고민하고 보완해나가고, 피드백이 부..

프로그램을 작성하다보면 예기치 못한 문제에 봉착할 때가 많습니다. 그런 문제를 덜 겪기 위해 다양한 개발 방법론을 접해보았고, 시도해 보았습니다. 그 중에서도 조엘의 이야기는 특별했습니다. 능률을 높이기 위한 복잡한 절차대신, 마인드와 작은 행동으로 그것들을 대신했습니다. 방법론을 쉽사리 적용시키기 힘든 초보 프로그래머인 저에게도 조엘의 이야기는 쉽게 받아들이고, 쉽게 적용시킬수 있는 것들이었기에 더더욱 좋지 않았나 생각합니다. 무엇보다 조엘 테스트(http://elky.tistory.com/149)는 꼭 체크해보시기 바랍니다. 조엘 테스트 점수 높은 팀 치고 안좋은 팀이 없습니다. 또 일정 예측이란, 예측 자체에 부담을 가질 것이 아니라, 예측과 실제 소요시간과의 오차를 줄여가는 과정이라는 얘기도 아주..

내가 처음본 API서적은 국내에서 가장 유명(아닐지도 모르지만)한 김상형씨의 API 정복이었다. 물론 나역시도 만족했고, 현재도 WIN32 API 레퍼런스로 사용하고 있다. API란 Application Programming Interface라는것, 그리고 기본적인 프로그래밍에 필요한 함수 집합이라는것은 알고 있었지만, 다들 배워야 한다기에, 다들 알아야한다기에 접했을뿐 별다른 감흥은 없었고, 더 알고 싶지도 않았다. 컴퓨터 공학을 공부하다보니 운영체제란 과목이 있었지만, 설명이 부족해선지, 아니면 교재가 좋지 않아선지 별 흥미를 느끼지 못했고, 다른 과목보다 관심도가 낮았다. 프로그래밍을 하는데, 왜 운영체제가 필요한지는 의문이었었고, 윈도우 프로그래밍에 필요한 내용을 어느정도 선(멀티 태스크, 멀티 ..

웃기는 이야기일지 모르지만, 사실 나는 게임이 좋아서 프로그래밍을 시작했다. 게임을 만들고 싶은데, 그래픽(간단한 그림도 많이 못그리는 편이다)에는 너무 소질이 없었고, 기획이란 분야는 너무 막막한 상황이었기에, 선택한것이 프로그래밍이었다. 그러나 그 시작과는 달리, 갈수록 프로그래밍의 매력에 빠져들었고, 프로그램을 만든다는 그 자체를 즐기게 되었다. 나에게 주어진 문제를 해결했을때 오는 짜릿함? 내가 만든것이 컴퓨터안의 가상 세계(이 표현은 틀렸을지도 모른다. 왜냐면 컴퓨터안의 세계는 저자의 말대로 bit로 이루어진 현실에 존재하는 세계이기도 하니까)에서 나의 발상을 코드화해서 그것을 구동하였을때의 즐거움? 이런건 무엇과도 바꿀수없는것이었다. 그러나 그 즐거움을 잊을때가 많았다. 어떠한 프로젝트를 위해..