리뷰/실용주의 프로그래머

[개발자의 서재] "실용주의 프로그래머" 4. 적당히 괜찮은 소프트웨어, 10. 예광탄

적당히 괜찮은 소프트웨어 모든 기능이 완벽하게 구현되어 있고, 확장성과 유지보수성이 높은 아키텍처를 가지고 있는 완벽한 소프트웨어를 출시하는 것은 모든 개발자들이 꿈꾸는 이상적인 상황일 것이다. 하지만 애석하게도 하늘은 이상(理想)을 허락하지 않고, 이상(異常)만을 허락하셨다. 일정, 기술, 구조 등의 이유로 완벽한 소프트웨어를 출시하는 것을 방해한다. 그렇다고 개발자들이 절망적인 상황에 놓여있는 것은 아니다. 적당히 괜찮은(마음의 평화를 유지하면서 사용자, 협업하고 있는 개발자들이 사용할 수 있는 정도의) 소프트웨어를 만들도록 노력할 수 있다. 같이 보면 좋은 영상 개발자에게 레거시?! 오히려 좋아 레거시에 관한 영상인데 맥락이 이어지는 것 같아서 첨부했습니다. 사용자의 피드백 그렇다고 지저분하고 아무..

[개발자의 서재] "실용주의 프로그래머" 3. 돌멩이 수프와 삶은 개구리

소프트웨어 개발을 가로막는 장애물 어떤 소프트웨어를 살펴보더라도 필요한 개선 사항이 없는 소프트웨어는 없다. 기능, UI, UX, 운영 등 다양한 측면에서 살펴보면 부족한 부분에서 개선이 필요하다. 그런데 어째서 개선되지 않는 것일까? 예산, 인력 충원의 어려움, 기술력 등 이유를 찾아보자면 끊임없이 나올 것이다. 여기서는 "시작 피로"에 대해서 다뤄보려고 한다. 시작 피로(start-up fatigue) 새로운 기능, 버그 수정 등 필수적으로 진행해야 되는 작업들은 이미 우리 곁에 존재하고 있다. 그런 상황에서 추가적인 업무 요청이 들어오면 어떨까? 작업 공수 계산, 일정 조율, 인력 배정 등 사전 작업에 대한 두려움 때문에 아주 방어적으로 맞서게 된다. 이런 두려움들을 시작 피로라고 한다. 시작 피로..

[개발자의 서재] "실용주의 프로그래머" 44. 결국은 모두 글쓰기

문서는 필요악? 코드 ≒ 문서 많은 수의 개발자들이 문서 작성을 불필요한 작업이라고 생각한다. 고작해야 필요악 정도로 인식하는 경우가 많다. 프로젝트가 끝날 무렵에나 어쩔 수 없이 문서를 작성하기 시작한다. 하지만 실용주의 프로그래머들은 문서화를 필수 불가결한 요소라고 생각한다. 다른 점은 노력을 중복하거나 시간을 낭비하지 않고, 문서를 늘 코드와 가깝게 두면서 항상 문서를 촉촉하게 유지한다. 이런 방법들이 완전히 새로운 것은 아니고 JavaDoc, pydoc 등 다양한 부분에서 이미 이뤄지고 있다. 이제부터 소프트웨어의 내부, 외부 문서들을 어떻게 관리해야 하는지 다뤄보겠다. 문서화의 필요성은 알고 있지만 실천하지 못했다. 최근에 와서는 그 필요성을 뼈저리게 느끼고 있다. 나중으로 미루지 말고, 처음부..

[개발자의 서재] "실용주의 프로그래머" 31. 우연에 맡기는 프로그래밍

우연에 맡기는 프로그래밍 혹시 전쟁, 어드벤처, 공포 영화에서 주인공의 부주의한 행동으로 주인공 스스로 혹은 동료의 목숨을 잃는 것을 본 적이 있는가? 그들도 처음부터 그렇게 부주의하지는 않았다. 몇 번의 실험을 통해서 자신들은 죽지 않는다는 가설을 입증했고 그에 따라서 행동했을 뿐이다. 무엇이 문제였을까? 아마 순전히 운에 따른 실험 결과로 잘못된 가설을 증명했다고 착각한 것이 가장 큰 문제라고 생각한다. 개발자인 우리들 역시 매일매일 이러한 시험대에 오르고 있다. "여기서 굳이 확장성을 고려해야 하나?", "아직 성능 고려해서 최적화를 준비해야 할 시기는 아니지" 등 다양한 가정과 가설을 우리 멋대로 사실인양 코드에 작성하고는 한다. 우리는 어쩌다 가설이 참일 때만 성공적으로 동작하는 프로그램을 작성..

[개발자의 서재] "실용주의 프로그래머" 8. 직교성

1. 직교성이란 직교란 직각으로 교차한다는 뜻으로 물리학적인 관점으로 보면 두 물체의 기존 운동과 가장 영향을 적게 주는 방향으로 충돌하는 것이다. 소프트웨어에서 말하는 직교성도 유사하다. 두 모듈, 컴퍼넌트, 시스템이 직교적이라는 말은 서로의 변경이 서로에게 영향을 주지 않는다는 뜻이다. 객체 지향 설계 원칙인 단일 책임 원칙(SRP), 개방 폐쇄 원칙(OCP)의 맥락과 동일하다고 생각한다. 2. 직교성의 장점 사실 직교성의 장점은 명확하고 모두가 이해하고 있다. 소프트웨어 특정 부분의 변경이 시스템 전체로 전달되는 것을 막아주기 때문에 생산성, 안정성을 높여준다. 문제는 개발 중에 소프트웨어가 직교성을 잃어가는 것이라고 생각한다. 직교성을 적용할 수 있는 범위와 방법을 익히자. 3. 팀 + 직교성 팀..

[개발자의 서재] "실용주의 프로그래머" 7. 중복의 해악

1. 소프트웨어 개발에서 중복이란 소프트웨어 개발은 문제에 대한 지식(조건, 해결책 등)을 코드로 풀어나가는 행위라고 할 수 있습니다. 따라서 개발 과정에서 일어나는 중복은 결국 지식의 중복이라고 할 수 있습니다. 이런 관점에서 중복들을 다음 4가지로 1) 강요된 중복, 2) 부주의한 중복, 3) 참을성 없는 중복, 4) 개발자 간의 중복 분류할 수 있었습니다. 2. 강요된 중복 강요된 중복의 예시로는 로직이 중복되는 API, 추상 클래스와 구상 클래스에 중복으로 작성되는 주석, 테스트 케이스 문서들이 있습니다. 이런 상황에서 개발자들은 중복을 피할 수 없다고 생각합니다. 하지만 코드 생성기를 통한 인터페이스 자동 생성, 주석에서 고차원적인 내용과 저차원적인 내용 분리, 문서 - 코드 연동 시스템 구축을..