티스토리 뷰
1. 프로그래밍 실전
[ 조엘 테스트: 더 나은 코드를 위한 12단계 ]
다음과 같은 소프트웨어 팀 평가 테스트를 진행하여, 10점 이하라면 심각한 문제가 있는 것이다. 사실 대다수의 회사는 2~3점 수준이다.
- 소스코드 관리 시스템을 사용하고 있습니까?
- 한방에 빌드를 만들어낼 수 있습니까?
- 일일 빌드를 하고 있습니까?
- 버그 추적시스템을 운영하고 있습니까?
- 코드를 새로 작성하기 전에 버그를 수정합니까?
- 일정을 업데이트하고 있습니까?
- 명세서를 작성하고 있습니까?
- 조용한 작업 환경에서 일하고 있습니까?
- 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
- 테스터를 별도로 두고 있습니까?
- 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
- 무작위 사용편의성 테스트(방금 막 작성한 코드를 다른 사람에게 사용해보도록 하는 기법)를 추가하고 있습니까?
[ 개발자가 꼭 알아둬야 할 유니코드와 문자 집합에 대한 고찰 ]
1. 유니코드의 등장
C언어가 나왔을 쯤에는 32에서 127사이의 숫자로 모든 영문자를 표현할 수 있는 ASCII 코드가 유행하고 있었다. ASCII 문자는 7비트를 사용하고도 한 비트의 여유분이 있었기 때문에, 각각의 PC마다 용도에 맞게 128글자를 정의하였다. 여분의 글자들은 각각의 PC마다 다르게 설정되었기 때문에, 서로 다른 PC가 이를 주고받으면 서로 다르게 해석이 된다.
그리고 이러한 문제는 ANSI 표준 위원회에서 ANSI 표준을 처계적으로 정리함에 따라 모든 사람이 128 미만의 문자를 어떻게 다룰지 동의하면서 끝났다. 하지만 여전히 지역에 따라 128이상의 문자를 다루는 여러 방법이 존재한다. 이를 코드페이지라고 하는데, 영어는 코드페이지 437을 한국어는 코드페이지 949를 사용한다. 하지만 그렇다 하여도 한국어와 영어를 하나의 컴퓨터에서 동시에 사용하는 것은 불가능했으며, 아시아에서는 문자집합이 결코 8비트에 들어갈 수 없기 때문에 2바이트를 사용하는 DBCS(Double Bytes Character Set)을 해결해야 했다. 그리고 인터넷 세상이 열리며, 서로 다른 나라의 사람들이 통신을 하게 되면서 이러한 문제는 더욱 대두되었다. 그리고 이를 해결하기 위해 유니코드가 등장하게 되었다.
유니코드는 지구상에 존재하는 모든 언어를 포함하는 단일 문자 집합을 만들기 위한 노력 끝에 탄생하게 되었다. 유니코드 컨소시엄은 각 단어에 존재하는 관념적인 철자마다 고유 번호를 붙여놓았고, U+0041과 같이 표현한다. U+는 유니코드를 의미하며, 16진수로 표현되는 숫자 0041은 영어 글자 A를 상징한다. 숫자는 확장가능하기에 유니코드로 정의가능한 글자 개수에는 제한이 없으며, Hello를 유니코드로 표현할 경우 다음과 같다.
U+0048, U+0065, U+006C, U+006C, U+006F
그리고 이러한 유니코드를 어떻게 이메일 메세지에서 표현하거나 메모리에 올리는지를 알아야 한다.
2. 인코딩
Hello를 표현하기 위해 두 바이트씩 저장하도록 하였는데, 구현 초기에는 특정 CPU에 맞춰서 빨리 동작가능하도록 리틀엔디안 방식과 빅엔디안 방식을 모두 지원하여 다음과 같이 표현될 수 있다.
00 48 00 64 00 6c 00 6c 00 6f
48 00 65 00 6c 00 6c 00 6f 00
하지만 위와 같이 표현하면 유니코드의 시작을 알 수 없었기에, 유니코드의 시작에 FF를 붙이는 희한한 관례가 생기게 되었다. 하지만 이러한 방식은 영문 텍스트를 사람들로부터 불필요한 공간이 00에 의해 차지된다는 불만이 나오게 하였고, 이에 맞춰 UTF-8이라는 개념이 등장하였다.
UTF-8은 유니코드 코드 포인트를 따르는 문자열을 저장하기 위한 또 다른 시스템으로, 8비트 바이트를 사용해서 매직 U+넘버를 기억 공간에 저장한다. UTF-8에서는 0에서 127 사이에 존재하는 모든 코드 포인트를 단일 바이트로 저장한다. 그리고 128 이상인 코드 포인트만 2, 3바이트에서 시작해서 최대 한계인 6바이트까지 확장해서 저장한다. 즉, Hello은 48 65 6c 6c 6F로 저장된다.
이렇게 함으로써 영어 텍스트는 ASCII, ANSI 등과 같이 동일하게 사용되며 00과 같은 단순한 문자열 처리 코드가 포함되지 않는다.
3. 인코딩에 대해 가장 중요한 사실 한가지
그렇기 때문에 문자열의 인코딩 방식을 반드시 알아야 한다. 메모리나 파일이나 이메일 메세지 내부에 문자열이 있으면, 인코딩이 무엇인지 알아야 해석할 수 있다. 웹사이트가 깨져 보이거나, 작성한 문자들이 다른 사람에게 보이지 않는다면 이는 대부분 인코딩 문제일 것이다.
그렇기 때문에 문자열 인코딩 방식에 대한 정보가 필요한데, 웹 페이지인 경우 웹 서버가 Content-Type과 같은 Http 헤더를 웹 페이지 자체와 함께 반환하는 방식이 처음에 제안되었다. 그래서 Content-Type: text/plain; charset="UTF-8"과 같은 헤더가 추가되기 시작하였다. 당연히 이것은 HTML 페이지에 앞서 나오는 별도의 응답 헤더일 것이다.
하지만 이러한 방식은 다양한 사이트를 지원하는 대형 웹서버의 경우에 문제가 발생한다. 수 많은 언어로 작성된 웹 페이지를 렌더링해주어야 하는 경우, 웹 서버는 각각의 파일이 어떤 인코딩을 따르는지 모르기에 일괄적으로 시스템 전체에 할당한 Content-Type을 보내는 것이 불가능했다. 그래서 HTML 파일 자체에 특별한 태그를 사용하여 Content-Type을 넣어야 하게 되었고, 모든 인코딩은 32부터 127까지를 숫자와 알파벳으로 사용하기 때문에 다음과 같이 HTML에 인코딩 정보를 활용하게 되었다.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
</html>이러한 메타 태그는 <head>의 가장 처음에 등장해야 하는데, 그래야 웹 브라우저가 이 태그를 보자 마자 페이지 파싱을 중단하고 지정한 인코딩을 사용해 전체 페이지를 재해석하기 때문이다.
만약 http 헤더나 html 메타 태그 어느 쪽에도 Content-Type이 존재하지 않는다면, 웹 브라우저는 어떻게 할까? 그러면 웹 브라우저는 특정 언어와 인코딩을 조합해 나타나는 바이트 빈도를 토대로 문서에 사용된 언어와 인코딩 방식을 추측한다. 하지만 추측을 잘못할 수 있으므로 반드시 인코딩 정보를 포함해야 한다.
[ 손쉬운 기능명세 작성법 - 명세서 작업이 귀찮습니까? ]
앞선 12가지의 조엘 테스트에서 사람들이 가장 민감하게 반응했던 것은 명세서 작업이였다. 모두가 명세서 작업을 해야 한다고 생각하지만, 아무도 이를 하지는 않았다. 하지만 명세서 작업을 하지 않는 것은 가장 크고 불필요한 위험 요인을 내포하며, 오히려 개발 생산성을 낮춘다. 왜냐하면 명세서 작업의 가장 중요한 결실은 설계인데, 스스로 명세서 작업을 하다보면 자연스럽게 프로그램을 설계하게 되기 때문이다. 또한 명세서의 작성은 의사소통 시간을 절약하게 해준다. 명세서를 통해 다른 개발 팀, 품질검증 팀, 마케팅 팀, 사업 검증 팀 등은 불필요한 커뮤니케이션 없이 각자 자신의 업무를 수행할 수 있습니다. 또한 세부 명세서 없이는 일정을 계획하는 것이 불가능하다. 일정을 잡아야 해당 사업을 계속 진행할지 또는 언제까지 진행할지 결정할 수 있다. 하지만 명세서가 없다면, 일정을 산정하는 것이 불가능하여 이러한 결정을 내릴 수 없다.
즉, 우리는 다음과 같은 이유로 명세서를 작성해야 한다.
- 개발의 생산성을 높일 수 있다.
- 의사소통 시간을 절약할 수 있다.
- 일정을 계획할 수 있다.
[ 손쉬운 기능명세 작성법 - 명세가 뭡니까? ]
사람들은 기능 명세와 기술 명세를 혼용하곤 한다. 하지만 이는 명확히 다르며 각각 다음과 같다.
- 기능 명세(functional specification): 완전히 사용자 관점에서 제품이 어떻게 동작하는지를 기술한다. 어떠헥 구현했는지는 신경쓰지 않는다. 기능에 대해 이야기하고, 화면, 메뉴, 대화 상자와 같은 사용자 인터페이스 부품을 명세한다.
- 기술 명세(technical specification): 프로그램의 내부 구현을 기술한다. 자료 구조와 관계형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 명세한다.
제품을 설계할 때 중요한 것은 화면이 어떠한지, 어떻게 동작하는지, 무엇을 하는지를 정의하는 것이며, 어떻게 구현할지는 나중에 걱정해도 된다. 제품이 어떻게 동작할지 결정하기도 전에 어떤 프로그래밍 언어를 사용할지는 걱정할 필요가 없다. 그렇기 때문에 다음과 같은 내용을 포함하여 명세서를 작성해야 한다.
- 면책 조항
- 저자
- 시나리오
- 회피 목표
- 개요
- 세부 사항들
- 미해결 문제
- 방주(side note)
- 지속적인 개정
자세한 내용은 책의 p70을 참고하도록 하자.
[ 손쉬운 기능명세 작성법 - 하지만 어떻게? ]
1. 누가 명세를 작성합니까?
프로그램 관리자(Program Manager)는 요구사항을 수집하고, 코드의 예상 동작을 이해해서 명세서를 작성한다. 그리고 프로그램 관리자마자 5명씩 프로그래머를 붙인다. 프로그래머는 프로그램 관리자가 명세 형식으로 구현한 프로그램을 코드로 구현하는 책임을 맡는다. 프로그램 관리자는 마케팅, 문서, 테스트, 지역화를 비롯해 자신의 하급 직원인 프로그래머가 시간을 낭비하지 않도록 귀찮은 세부 사항을 모두 챙겨야 한다.
2. 프로그램 관리자를 어떻게 뽑는가?
- 코드 개발자를 프로그램 관리자로 승급시키지 마라
명쾌한 언어 구사 능력, 시장을 고려한 외교적 수완, 사용자 공감, 훌륭한 UI 설계 등은 훌륭한 프로그래머가 갖추기 어렵다. - 마케팅 부서 사람을 프로그램 관리자로 승급시키지 마라
아무리 유능한 마케팅 직원이라도 제품을 설계하는데 필요한 기술 사항까지 이해하는 것은 힘들다. - 프로그래머가 프로그램 관리자에게
기본적으로 프로그램 관리자는 독립적인 진로이다. 모든 프로그램 관리자는 기술적인 감각이 뛰어나면 좋지만, 코드를 잘 작성할 필요는 없다. 프로그램 관리자는 사용자 인터페이스를 연구하고, 고객을 만나고, 명세서를 쓰는 것이 주된 업무이다.
[ 손쉬운 기능명세 작성법 - 팁 ]
명세를 쓰는 팀원의 가장 큰 불평은 아무도 명세를 읽지 않는다는 것이다. 그렇기 때문에 명세는 다른 사람이 읽도록 유도할 필요가 있다. 즉, 읽고 싶어지는 명세를 만들기 위해 글을 잘 써야하는데, 아래의 5가지 규칙을 지키면 이를 달성하기 쉽다.
- 재미있게 쓰자
- 대상층을 고려하여 이해하기 쉽도록 쓰자
- 최대한 단순하고 보기좋게 작성하라
- 여러 차례에 걸쳐 검토하고 다시 읽어라
- 표준양식은 해롭다고 간주하라
[ 손쉬운 소프트웨어 일정 관리법 ]
일정을 짜지 않는 이유는 크게 두 가지이다.
- 일정을 짜는 작업은 고통이다.
- 일정을 짜는 것이 의미가 없다고 생각한다.
일정을 짜봤자 잘 지켜지지 못하기 때문에 다들 일정을 짜는 것이 의미없다고 생각한다. 또한 이는 상당히 번거롭다. 그렇기 때문에 일정을 손쉽게 짜는 장법을 소개하고자 한다.
- 엑셀을 사용하라
- 단순하게 만들어라
- 각 기능연 여러 개의 과업을 포함해야 한다
- 담당 프로그래머만이 제대로 일정을 짤 수 있다.
- 과업을 세부적으로 나눠라
- 초기 예측과 현재 예측을 동시에 유지하라
- 경과열은 매일 갱신하라
- 일정에 휴가나 휴일 같은 항목을 넣어라
- 일정에 디버깅 시간을 넣어라
- 일정에 통합 시간을 넣어라
- 일정에 여유 기간을 둬라
- 프로그래머에게 일정을 단축하도록 강요하지 마라
- 일정은 한정적이고, 우선순위와 중요도 순으로 선택해야 한다.
[ 고리타분한 버그 수정 ]
버그 수정은 수정한 버그 가치가 그 수정 비용을 넘어설 때에만 의미가 있다. 그렇기 때문에 어떤 버그를 수정할지를 결정해야 하는데, 다음과 같은 아이디어를 소개하고자 한다.
- 찾아낸 버그를 모두 수집 및 확인하라
- 경제적인 피드백을 확인하라
- 버그 수정 작업이 어떤 값어치가 있는지 계산하라
[ 5가지 세계 ]
소프트웨어는 크게 5가지로 구분될 수 있다.
- 상품 소프트웨어
상품이란 대규모 사용자가 자기 의지에 따라 선택해 사용할 수 있는 소프트웨어이다. 상품 소프트웨어의 핵김은 설치한 상품을 수 백만명 이상이 사용한다는 것이다. 상품 소프트웨어에는 크게 3가지 주요 변종이 있다.
- 오픈소스
- 웹 기반
- 컨설팅 웨어
그리고 이러한 상품 소프트웨어의 주된 요점은 크게 다음 2가지이다.
- 엄청나게 많은 사용자가 이용하지만 대안도 있다. 그렇기 때문에 사용자 인터페이스를 평균 이상으로 쓰기 쉽게 해야한다.
- 소프트웨어는 수 많은 컴퓨터에서 동작하므로, 다양한 시스템 환경에서 대응할 수 있어야 한다.
- 사내용 소프트웨어
사내용 소프트웨어는 작동 환경에 수많은 가정을 할 수 있고, 특정 회사가 직면만 문제점만 해결하면 되어 훨씬 대응이 쉽다. 또한 제한된 사람들이 이용하며, 다른 대안이 뚜렷하지 않기 때문에 사용편이성의 우선순위가 낮다. 또한 합당한 ROI(Return of Investment)를 위해 빠르개 개발하며, 품질을 상당히 희생한다.
- 임베디드 소프트웨어
임베디드 소프트웨어는 거의 대부분 업데이트가 불가능하며, 하드웨어 일부로 취급된다. 그렇기 때문에 품질 기준이 매우 높으며, 데스크탑보다 느리기 때문에 최적화와 수작업을 통한 튜닝에 많은 시간을 보내기도 한다. 또한 빠른 코드가 중요하며, 사용하게 될 입출력 장치는 제한이 많이 있을 수 있다.
- 게임 소프트웨어
게임 소프트웨어는 2가지 이유로 독특하다.
- 게임 개발의 경제성은 흥행에 의존하며 많은 게임이 실패한다
- 버전이 하나뿐이다.
- 일회성 소프트웨어
일회성 소프트웨어는 특정한 목적만을 위해 임시로 만들어지며, 원하는 바를 이루고나면 폐기 처분된다.
소프트웨어 개발 과정에서는 진행하는 프로젝트가 무엇이든 간에 거의 비슷한 상황이 발생한다. 예를 들어 누군가 방법론에 대해 이야기하면 우리는 그것이 우리에게 잘 적용될 수 있는지 검토해야 한다. 즉, 각각의 소프트웨어 분야를 고려하여 얘기가 되어야 한다.
[ 더불어 살기 ]
윈도우와 유닉스는 기능적인 차이점보다는 유사점이 더 많다. 파일 시스템에서 시작해서 메모리, 소켓, 프로세스, 쓰레드에 이르기까지 거의 동일한 시스템 자원을 조직화하고 있다. 윈도우와 유닉스의 차이는 결국 대상의 차이이다. 유닉스는 프로그래머를 위한 프로그래밍을 하는 반면 윈도우는 일반 사용자를 위한 프로그래밍을 한다는 것이다.
[ 자동으로 충돌 보고서 수집 ]
베타테스트를 아무리 잘 했다고 하더라도, 고객 누군가가 보유한 온갖 PC 환경을 재현하는 것은 쉽지 않다. 분명 누군가에게는 문제가 발생할텐데, 고객이 충돌을 보고하리라는 보장이 없다. 누군가는 기술적 지식이 부족할 수도 있고, 해당 작업에 시간을 뺏기고 싶지 않을 수도 있다. 그렇기 때문에 이러한 충돌 보고서를 자동으로 수집하도록 하는 것은 상당히 의미있다.
2. 개발자 다루기
[ 인터뷰를 위한 게릴라 가이드 ]
1. 첫 인사
첫 인사 단계는 지원자를 편하게 해주려는 목적이다. 정답을 듣기 보다는 지원자가 어떻게 문제를 해결하는지에 관심이 있다는 사실을 늘 강조한다.
2. 최근 프로젝트 경력에 대한 질문
개방형 질문을 던져 주고는 느긋하게 앉아서 기다려라. 때로 말이 끊긴다 싶으면 부연 설명을 통해 이야기를 유도한다. 그리고 이 때에는 다음과 같은 자질을 살펴보아야 한다.
- 열정이 보이는가?
똑똑한 사람은 자신이 수행한 프로젝트에 대해 열정적이며, 상당히 흥분한다. 말이 빨라지고 손짓이 따라온다. 지원자가 이야기를 하는 동안 자신이 인터뷰 중이라는 사실을 잊는다면, 열정적이라는 증거이다. 긴장하는 것은 당연한 것이기 때문에 이러한 면은 중요하지 않다. 반면에 인터뷰 내내 무덤덤하고 열정이 없는 지원자는 좋지 않다.
- 훌륭한 지원자는 상대 수준에 맞춰 설명할 수 있다.
룰륭한 지원자는 보통 사람이 알아들을 수 있는 용어로 설명할 수 있어야 한다. 이렇기 못하는 사람은 다른 사람에게 자신을 납득시키기 위해 어떤 태도를 취해야 할지 모를정도로 똑똑하지 못하기 때문이다.
- 팀 프로젝트였다면 리더십일 발휘했을 것 같은가?
똑똑한 지성과 성실한 업무 완수 두 가지를 기억해야 한다. 업무수행 경력은 지원자가 업무를 제대로 완수할 수 있을지 판단하는 유일한 근거가 된다. 리더십을 가지고 완수한 프로젝트 예를 들라고 직접 물어봐도 좋다.
3. 답변 불가능한 질문
답변 불가능한 질문을 하고 어떻게 반응하는지 살펴보자. 똑똑한 지원자는 단편적인 지식을 묻는 질문이 아님을 바로 알아채고, 어림 계산을 하며 열정적으로 반응할 것이다. 때로는 창의력으로 면접관을 놀래킬수도 있다. 하지만 똑똑하지 못한 지원자는 당황하거나 화를 낼 것이다. 이러한 사람은 문제를 해결할 능력이 없으므로 고용하면 안된다.
4. 프로그래밍 문제
지원자에게 종이를 나누어주고, 간단한 함수(10줄 이내)를 하나 짜보도록 해보자. 여기서 좋은 프로그래머는 간단한 규칙이라도 변수 명명법을 사용하거나 구현 전에 계획을 짜는 등의 신호를 보낸다.
5. 만족합니까?
틀림없이 작성한 함수에는 버그가 있을 것이다. 그리고 코드에 만족하냐고 질문을 하였을 때, 버그를 찾아낼 수 있어야 한다. 버그가 없어도 이러한 질문을 통해, 그가 얼마나 능수능란하게 대응하는지를 관찰할 수 있다.
6. 질문 있습니까?
우수한 지원자는 여기가 일할 만한 곳인지 총명한 질문을 통해 파악할 것이다. 면접관은 별볼일 없는 지원자였다고 해도, 회사에 대해 좋은 인상을 품고 떠나게 해야 한다.
[ 테스터를 두지 않는 잘못된 이유 5가지 ]
QA 부서는 독립적이며, 권한이 있어야 한다. 개발팀에 속해서는 안된다. 그리고 QA 팀장은 품질 테스트를 통과하지 못한 소프트웨어의 출시를 막을 권한이 있어야 한다. 테스터를 고용하지 않는 가장 흔한 이유는 다음과 같다.
- 버그는 프로그래머가 게을러서 생긴다.
버그란 프로그래머가 게을러서 생기근 것이 아니고, 이를 발견하지 못했기 때문에 나오는 것이다. 버그는 오히려 다른 사람이 더 쉽게 찾을 수 있다. - 웹으로 배포하는 소프트웨어는 쉽게 고칠 수 있다.
웹으로 배포하는 소프트웨어는 버그 수정판도 다른 소프트웨어들보다 빨리 배포할 수 있다. 하지만 출시 뒤에 발생한 버그를 수정하는 것은 어렵다. - 고객이 소프트웨어를 테스트 해준다.
사람들은 버그로 가득찬 소프트웨어를 사용하게 되고, 회사의 이미지는 떨어진다. 또한 모든 사용자에게 발생한 버그를 받았다 하더라도, 이를 수정하는 것은 불가능하다. - 우수한 테스터는 테스터로 일하려고 하지 않는다.
우수한 테스터를 고용하는 것은 매우 힘들다. 우수한 테스터는 다른 테스터들보다 훨씬 더 많은 버그를 찾아낸다. 그렇기 때문에 높은 직급과 복지 등으로 그들을 고용할 수 있어야 한다. - 테스터를 고용할 비용이 없다.
테스터는 프로그래머보다 훨씬 비용이 저렴하다. 테스터에게 드는 돈을 아끼려는 행태는 수지타산이 전혀 맞지 않는 행동이다.
[ 허술한 추상화의 법칙 ]
어떤 새로운 효율적인 도구가 등장하였다고 하자. 그 도구는 우리가 기대하는 것과 다르게 동작할수도 있고, 버그가 있을 수도 있다. 우리는 그 도구를 완전히 이해하기 위해 결국 내부를 봐야 한다.
즉, 프로그래밍 작업을 더 쉽게 만들어주는 도구가 등장하더라도, 위대한 프로그래머가 되기 위해 알아야만 하는 지식은 계속 늘어난다.
[ 프로그래밍 세계의 파머스톤 경 ]
소프트웨어 제작 과정에서 의존할 언어 클래스, API, 플랫폼 등에 대해 몇년 간의 경험이 있는 아키텍트를 한 명이라도 확보하지 못했다면, 새로운 프로젝트를 시작하지 않는 것이 좋다. 플랫폼 선택이 가능하다면, 가장 자신있는 플랫폼을 선택하라. 해당 기술이 최신 유행을 따르지 못하거나, 생산성이 최고로 높지 않더라도 상관없다.
3. 조엘 따라하기: 두서없는 생각, 하지만 놓쳐서는 안될 이야기
[ 직접 경헙해보기 ]
자신이 만든 소프트웨어를 직접 이용해보는 것은 상당히 의미가 있다. 불편한 부분들을 파악할 수 있고, 더 개선할 부분을 파악할 수 있기 때문이다.
[ 말단이면서도 해내기 ]
- 혼자라도 개선하라
다른 사람이 일일 빌드를 하지 않거나 뭔가를 하지 않는다면 혼자라도 진행하자. - 입소문의 힘을 이용하라
팀원들이 버그 추적 시스템이나 VCS를 사용하지 않다면, 이를 이용하고 다른 팀원들에게 알려라. 언젠가는 유용성을 깨닫고 사용할 것이다. - 우수한 인재를 모아라
우수한 인재를 팀으로 끌어들이기 위해 채용과 인터뷰 업무 등에 참여하라 - 고문관은 봉쇄하라
말단 프로그래머 입장에서는 피해를 최소화하도록 작성한 코드를 버그 리포팅하고, 수정하도록 하라 - 방해 받지 않는 곳으로
업무 환경이 좋지 않으면 뛰어난 인재를 모으기 어렵고, 생산성이 격감한다. - 꼭 필요한 인물이 되어라
위에서 제안한 내용들은 조직에 긍정적으로 공헌하는 사람이어야 좋게 받아들여진다.
[ 방법론을 조심하라 ]
방법론은 결과물을 일정한 수준으로 유지하기 위해 규칙과 절차를 만든 것일 뿐이다. 방법론은 그저 그런 성능을 내는 데는 괜찮은 방법이 될 수 있지만, 동시에 아주 좋은 결과물을 내지 못하도록 인재들을 방해할 수 있고, 그들을 쫓아낼 수도 있다.
[ 구현에 앞서 설계를 해야 한다 ]
구현에 앞서 설계를 해야 좋은 소프트웨어를 만들 수 있다. 하지만 설계를 필요 이상으로 하는 것은 좋지 못하다. 대신 점진적인 설계와 구현을 통해 발전하도록 하자.
[ 핵심 비지니스 기능은 직접 구현하라 ]
우수한 팀에서 뛰어난 프로그래머와 일한다면, 다른 사람의 코드는 버그 투성이에 문제가 많을 것이다. 그렇기 때문에 핵심 비지니스 기능은 다른 프로젝트와 연관성을 끊고 직접 개발 또는 작업하는 것이 좋다. 물론 핵심이 아닌 기능은 아웃소싱을 하거나 다른 프로젝트를 사용하여도 문제가 없을 것이다.
[ 플랫폼 비지니스 사업 ]
플랫폼을 만드는 비즈니스에 종사한다면, 분명 닭이 먼저냐 달걀이 먼저냐는 문제를 안고 있을 것이다. 플랫폼용 소프트웨어가 많지 않으면 아무도 플랫폼을 사지 않고, 플랫폼 사용자가 많지 않으면 아무도 소프트웨어를 만들지 않기 때문이다. 하지만 결국 중요한 것은 이전 버전과의 호환성이며, 이것을 제공해야 한다.
[ 80/20 법칙의 미신 ]
많은 소프트웨어 개발자가 80/20 법칙을 맹신한다. 이는 '사용자 중 80%는 기능 중 20%만을 사용한다'는 법칙으로 꽤나 일리가 있어 보인다. 그래서 전체 기능 중 20%만을 구현하여도 80%의 판매고를 올릴 수 있다고 믿는다. 하지만 여기서 주목해야 하는 것은 20%가 항상 동일한 집합이 아니라는 것이다. 그렇기 때문에 우리는 이러한 미신에 빠져서는 안되고, 모든 사용자의 20%에 해당하는 기능을 제공하도록 노력해야 한다.
[ 오픈소스 경제학 ]
많은 회사들이 오픈소스 소프트웨어 개발에 큰 돈을 투자하는 이유는 자기네 비즈니스 전략에 도움이 되기 때문이지, 자유에 열광하기 때문이 아니다. 모든 제품에는 대체재와 보완재가 있다. 대체재는 한 제품이 너무 비쌀 때 대체할 다른 상품이고, 보완재는 한 상품을 구매할 때 같이 사는 제품들이다. 또한 모든 조건이 동일하다면, 보완재 가격이 하락할 때 제품의 수요는 증가한다. 그렇기 때문에 똑똑한 회사라면 자사 제품의 보완재를 일반 재화로 만들려고 노력해야 한다.
'나의 공부방' 카테고리의 다른 글
| [개발서적] Professional 소프트웨어 개발 핵심 요약 및 정리 (4) | 2021.03.27 |
|---|---|
| [IntelliJ] 자주 사용되는 인텔리제이 단축키 모음(맥북, Mac OS) (16) | 2021.03.26 |
| [개발서적] 클린 아키텍처(Clean Architecture) 내용 정리 (0) | 2021.03.15 |
| [개발서적] 이펙티브 자바(Effective Java) 핵심 요약 및 정리 (20) | 2021.03.05 |
| [개발서적] 클린 코드(Clean Code) 핵심 요약 및 정리 (10) | 2021.03.05 |
