개발자를 위한 소프트웨어 엔지니어링 팁 모음

개발 프로세스에 대해

1. 코드는 단순히 실행을 위한 것이 아닙니다. 코드는 팀 간 소통의 수단이며, 문제 해결 방법을 다른 사람에게 설명하는 방법이기도 합니다. 읽기 쉬운 코드는 선택이 아닌 필수입니다. 이를 위해 코드를 명확하게 구조화하고, 직관적인 변수명을 사용하며, 암시적인 부분을 설명하는 주석을 달아야 합니다.
2. 코드 리뷰가 승진을 위한 것이 아니라, 사용자와 커뮤니티를 위한 것임을 항상 염두에 두세요. “눈에 띄는 기여”는 피해야 합니다. 제품의 목적에 명확히 도움이 되지 않는 기능은 추가하지 마세요.
3. 코드에도 취향이 중요합니다. 취향은 단순함을 향한 욕구에 의해 정해진 제약을 만족시키는 과정입니다. 단순함을 유지하려는 경향을 가지세요.
4. 요청된 기능을 반드시 구현해야 하는 것은 아닙니다. 모든 기능은 초기 구현 비용 외에도 유지보수 비용, 문서화 비용, 사용자에게 가해지는 인지적 부담이 있습니다. 항상 “정말로 이걸 해야 할까?”를 자문하세요. 대답은 종종 “아니오”일 것입니다.
5. 새로운 Use Case를 지원하기로 결정할 때, 사용자가 요청한 것을 그대로 추가하는 것이 최선이 아닐 수 있습니다. 사용자는 자신의 필요에 집중하지만, 우리는 프로젝트 전체를 고려한 원칙적인 비전을 제시해야 합니다. 종종 올바른 답은 기존 기능을 확장하는 것입니다.
6. 지속적인 통합에 투자하고, 전체 단위 테스트 커버리지를 목표로 하세요. 자신 있게 코딩할 수 있는 환경을 조성하세요. 그렇지 않다면 먼저 적절한 인프라를 구축하는 데 집중하세요.
7. 모든 것을 미리 계획하지 않아도 괜찮습니다. 시도해보고 결과를 확인하세요. 잘못된 선택은 초기에 되돌리세요. 그런 환경을 만드는 것이 중요합니다.
8. 좋은 소프트웨어는 어려운 문제를 쉽게 해결합니다. 처음에 문제가 어렵다고 해서 해결책이 복잡하거나 사용하기 어려울 필요는 없습니다. 엔지니어들은 종종 불필요한 복잡성을 도입하는 반사적인 해결책을 선택합니다(예: “ML을 사용하자!”, “앱을 만들자!”, “블록체인을 추가하자!”). 코드를 작성하기 전에, 선택한 해결책이 더 단순화될 수 있는지 확인하세요. 모든 문제를 근본 원리에서 접근하세요.
9. 암시적인 규칙을 피하세요. 암시적으로 생긴 규칙은 항상 명확하게 공유되거나 자동화되어야 합니다. 반복적이고 준 알고리즘적인 작업이 있다면, 이를 문서화된 프로세스로 공식화하여 팀원들이 그 경험을 공유할 수 있도록 하세요. 또한, 그러한 작업의 일부를 자동화할 수 있다면 소프트웨어로 자동화하세요(예: 정확성 검사).
10. 디자인 과정에서는 자신이 집중하고 싶은 부분(예: 수익이나 성장)뿐만 아니라 선택의 총체적인 영향을 고려해야 합니다. 모니터링 중인 지표 외에도 소프트웨어가 사용자와 세상에 미치는 총체적인 영향은 무엇인가요? 가치 제안보다 더 큰 부작용이 있나요? 소프트웨어의 유용성을 유지하면서 이를 해결할 수 있는 방법은 무엇인가요?

윤리를 고려하여 설계하세요. 당신의 가치를 창작물에 녹여내세요.

API 디자인에 대하여

1. API에는 사용자가 존재하며, 이는 사용자 경험을 고려해야 함을 의미합니다. 모든 결정에서 항상 사용자를 염두에 두고, 초보자든 숙련된 개발자든 사용자에 대한 공감을 가지세요.
2. API 사용 시 사용자에게 가해지는 인지적 부담을 최소화해야 합니다. 자동화할 수 있는 부분은 자동화하고, 사용자가 수행해야 할 행동과 선택을 최소화하며, 중요하지 않은 옵션은 숨기세요. 단순하고 일관된 작업 흐름을 설계하여 단순하고 일관된 멘탈 모델을 반영하세요.
3. 단순한 작업은 쉽게, 복잡한 작업은 가능하도록 설계하세요. 틈새 Use Case를 위해 일반적인 Use Case의 인지적 부담을 증가시키지 마세요.
4. 작업 흐름의 인지적 부담이 충분히 낮다면, 사용자가 한두 번의 경험으로 튜토리얼이나 문서를 찾아보지 않고도 기억을 더듬어 작업을 수행할 수 있어야 합니다.
5. 도메인 전문가와 실무자의 멘탈 모델에 맞는 API를 지향하세요. 도메인 경험은 있지만 API 경험이 없는 사람이 최소한의 문서만으로 직관적으로 API를 이해할 수 있어야 합니다. 몇 가지 코드 예제와 객체의 시그니처를 보는 것만으로 말이죠.
6. 인자의 의미는 구현에 대한 맥락 없이도 이해할 수 있어야 합니다. 사용자가 지정해야 하는 인자는 문제에 대한 사용자의 멘탈 모델과 관련되어야 하며, 코드의 구현 세부 사항과 관련되어서는 안 됩니다. API는 해결하는 문제에 관한 것이지, 소프트웨어의 작동 방식에 관한 것이 아닙니다.
7. 가장 강력한 멘탈 모델은 모듈화되고 계층적입니다. 높은 수준에서는 단순하지만, 세부 사항으로 들어갈수록 정밀해집니다. 마찬가지로 좋은 API도 모듈화되고 계층적입니다. 접근하기 쉽지만 표현력이 뛰어납니다. 적은 객체에 복잡한 시그니처를 갖거나, 더 많은 객체에 단순한 시그니처를 갖는 것 사이에서 균형을 맞춰야 합니다. 좋은 API는 합리적인 수의 객체와 단순한 시그니처를 가집니다.
8. API는 필연적으로 구현 선택, 특히 데이터 구조 선택을 반영합니다. 직관적인 API를 위해서는 도메인에 자연스럽게 맞는 데이터 구조를 선택해야 합니다. 이는 도메인 전문가의 멘탈 모델과 일치합니다.
9. 엔드 투 엔드 작업 흐름을 고의적으로 설계하세요. 단일 기능 세트를 설계하지 마세요. 대부분의 개발자는 API 디자인 접근 방식을 “어떤 기능을 제공해야 하는가? 설정 옵션을 추가하자”라고 생각합니다. 대신 “이 도구의 Use Case는 무엇인가? 각 Use Case에 대한 최적의 사용자 행동 순서는 무엇인가? 이 작업 흐름을 지원할 수 있는 가장 쉬운 API는 무엇인가?”라고 질문하세요. API의 단일 옵션은 높은 수준의 작업 흐름에서 발생하는 명확한 요구를 해결해야 하며, “누군가 필요할 수도 있으니까”라는 이유로 추가되지 않아야 합니다.
10. 오류 메시지와 API와 상호작용하는 과정에서 제공되는 모든 피드백은 API의 일부입니다. 상호작용성과 피드백은 사용자 경험의 필수 요소입니다. API의 오류 메시지를 신중하게 설계하세요.
11. 코드는 의사소통이기 때문에 이름 짓는 것이 중요합니다. 프로젝트나 변수를 명명할 때, 문제를 어떻게 생각하는지를 반영합니다. 지나치게 일반적인 이름(x, variable, parameter), 과도하게 길고 구체적인 이름 패턴, 불필요한 마찰을 일으킬 수 있는 용어(master, slave)를 피하고, 명명 선택에서 일관성을 유지하세요. 명명 일관성은 내부 일관성(다른 곳에서 “axis”라고 부르는 것을 “dim”이라고 부르지 않기)과 문제 도메인에 대한 기존 관례와의 일관성을 의미합니다. 이름을 결정하기 전에 도메인 전문가나 다른 API에서 사용되는 기존 이름을 꼭 확인하세요.
12. 문서는 API의 사용자 경험에서 중심적인 역할을 합니다. 추가적인 요소가 아닙니다. 고품질 문서에 투자하면 기능 추가보다 더 높은 수익을 얻을 수 있습니다.
13. 보여주고 설명하지 마세요: 문서는 소프트웨어 작동 방식을 설명하지 않고 사용하는 방법을 보여줘야 합니다. 엔드 투 엔드 작업 흐름에 대한 코드 예제, 일반적인 Use Case와 API의 주요 기능에 대한 코드 예제를 보여주세요.

생산성은 빠른 의사 결정과 실행 중심의 태도로 귀결됩니다.

소프트웨어 커리어에 대하여

1. 커리어 발전은 관리하는 사람의 수가 아니라, 당신의 작업이 세상에 미치는 영향력의 차이로 측정됩니다. 즉, 당신의 작업이 있는 세상과 없는 세상의 차이입니다.
2. 소프트웨어 개발은 팀워크입니다. 기술적인 능력만큼이나 인간 관계도 중요합니다. 좋은 팀원이 되세요. 앞으로 나아가면서도 사람들과 계속 연락을 유지하세요.
3. 기술은 결코 중립적이지 않습니다. 만약 당신의 작업이 세상에 어떤 영향을 미친다면, 그 영향에는 도덕적 방향이 있습니다. 우리가 소프트웨어 제품에서 내리는 겉보기에 무해한 기술적 선택조차 기술 접근 조건, 사용 동기, 혜택을 받는 사람과 고통받는 사람을 결정짓습니다. 기술적 선택은 윤리적 선택이기도 합니다. 따라서 항상 당신이 지지하고자 하는 가치를 신중하고 명확하게 선택하세요. 윤리를 염두에 두고 설계하세요. 당신의 가치를 창작물에 녹여내세요. ‘나는 단지 기능을 만들고 있을 뿐이야, 그 자체로는 중립적이야’라고 생각하지 마세요. 당신이 어떻게 만들었느냐가 그 사용 방식을 결정하기 때문입니다.
4. 자율성, 즉 당신의 작업과 환경에 대한 주도권은 삶의 만족의 열쇠입니다. 주변 사람들에게 충분한 자율성을 부여하고, 당신의 커리어 선택이 당신에게 더 큰 주도권을 부여하도록 하세요.
5. 세상이 필요로 하는 것을 만드세요. 단지 당신이 필요로 하는 것만 만들지 마세요. 너무 자주, 기술자들은 자신만의 필요에 맞춘 제품에 집중합니다. 삶의 경험을 넓힐 기회를 찾아보세요. 이는 세상이 무엇을 필요로 하는지 더 잘 알게 해줄 것입니다.
6. 장기적인 영향을 미칠 선택을 할 때는, 단기적인 자기 이익이나 일시적인 감정 — 예를 들어 탐욕이나 두려움 — 보다 당신의 가치를 우선시하세요. 당신의 가치가 무엇인지 알고, 그것이 당신을 이끌게 하세요.
7. 갈등에 처했을 때는, 우리의 공유된 가치와 목표를 인정하고, 우리가 거의 확실히 같은 편에 있다는 것을 상기하는 것이 좋습니다.
8. 생산성은 높은 속도의 의사결정과 행동 편향으로 요약됩니다. 이는 a) 부분적인 정보로 일반적으로 올바른 결정을 내릴 수 있는 경험에서 나오는 좋은 직관과 b) 잘못된 결정의 비용이 지연의 비용보다 클 때 더 신중하게 움직이고 정보를 기다려야 하는 시기를 아는 예리한 인식이 필요합니다. 최적의 속도/품질 의사결정 균형은 다양한 환경에서 크게 다를 수 있습니다.
9. 빠른 결정을 내리는 것은 당신이 커리어 동안 더 많은 결정을 내리게 하며, 이는 가용한 옵션의 올바름에 대한 더 강한 직관을 제공합니다. 경험은 생산성의 열쇠이며, 더 높은 생산성은 당신에게 더 많은 경험을 제공할 것입니다. 이는 선순환입니다.
10. 직관이 부족하다는 것을 인식한 상황에서는, 추상적인 원칙을 따르세요. 커리어 동안 검증된 원칙 목록을 만들어가세요. 원칙은 유사한 상황에 대한 직접적이고 광범위한 경험을 요구하는 패턴 인식보다 더 넓은 범위의 상황에 일반화될 수 있는 공식화된 직관입니다.