개발자 관행과 윤리¶

토픽: Programming 레슨: 16 of 16 선수 지식: 소프트웨어 개발 경험, 버전 관리, 소프트웨어 라이프사이클의 기본 이해 목표: 기술 부채 관리, 문서화 전략, 오픈 소스 기여, 소프트웨어 윤리, 경력 성장 원칙을 포함한 전문 개발 관행 학습

소개¶

코드 작성은 전문 개발자가 되는 것의 일부일 뿐입니다. 이 레슨은 훌륭한 개발자를 단순히 유능한 개발자와 구별하는 관행, 원칙, 윤리를 다룹니다:

기술 부채 관리: 속도와 품질의 균형
문서화: 작업을 이해하기 쉽고 유지보수 가능하게 만들기
오픈 소스: 공개 소프트웨어에 기여하고 만들기
윤리: 책임감 있게 소프트웨어 구축
경력 성장: 지속 가능하고 만족스러운 경력 개발

이러한 관행은 여러분이 일하고, 협업하고, 더 넓은 소프트웨어 커뮤니티에 기여하는 방식을 형성합니다.

기술 부채¶

기술 부채(Technical debt)는 더 오래 걸릴 더 나은 접근 방식 대신 오늘 빠른 솔루션을 선택함으로써 발생하는 미래 재작업의 암묵적 비용입니다.

정의¶

기술 부채는 은유입니다: - 재정 부채처럼 전략적일 수 있음(지금 빌리고, 나중에 갚기) - 이자가 발생함: 기다릴수록 수정하기 어려워짐 - 너무 많은 부채는 파산으로 이어짐: 코드베이스가 유지보수 불가능

# 빠른 솔루션(기술 부채 생성)
def process_data(data):
    # TODO: 엣지 케이스 처리, 유효성 검증 추가
    return data.split(',')[0]  # 취약, 형식 가정

# 더 나은 솔루션(앞서 더 많은 시간 소요)
def process_data(data):
    if not isinstance(data, str):
        raise TypeError("Data must be a string")
    if not data:
        raise ValueError("Data cannot be empty")

    parts = data.split(',')
    if len(parts) == 0:
        raise ValueError("Invalid format")

    return parts[0].strip()

기술 부채의 유형¶

의도적 vs 우발적:

의도적	우발적
"이게 임시방편인 걸 알지만 배포해야 해"	"더 나은 방법을 몰랐어"
의식적 결정	지식/기술 부족
계획 가능	나중에 발견

신중한 vs 무모한(Martin Fowler의 사분면):

              의도적
                 |
    신중한       |     무모한
   "지금 배포,   |    "설계할
    나중 리팩토링"|     시간 없어"
-----------------+------------------
   "계층화가     |     "코드를
   뭐야?"       |    복제하게 될 줄
                 |      몰랐어"
              우발적

예제:

// 의도적 + 신중한: 지금 하드코딩, 나중에 설정 가능하게
const API_URL = 'https://api.example.com';  // TODO: 설정으로 이동

// 의도적 + 무모한: 생각 없이 복사-붙여넣기
function calculateDiscount1(price) { return price * 0.1; }
function calculateDiscount2(price) { return price * 0.1; }
function calculateDiscount3(price) { return price * 0.1; }

// 우발적 + 신중한: 더 나은 패턴 배움, 리팩토링 필요
// 오래된 코드: 전역 변수(더 나은 방법을 몰랐음)
let userId = 123;
// 새 코드: 의존성 주입(패턴 배움)
class UserService {
    constructor(userId) { this.userId = userId; }
}

// 우발적 + 무모한: 문제를 이해하지 못해 더 나빠지게 함
// 관심사 혼재를 인식하지 못함
function saveUser(user) {
    db.save(user);
    sendEmail(user.email);  // 부작용!
    logAnalytics(user.id);  // 부작용!
}

기술 부채 관리¶

1. 추적: 코드나 이슈 트래커에 부채 문서화

// TODO-TECH-DEBT: N+1 쿼리 사용. 주문 배치 가져오기.
public List<Order> getUserOrders(int userId) {
    User user = userRepository.findById(userId);
    List<Order> orders = new ArrayList<>();
    for (int orderId : user.getOrderIds()) {
        orders.add(orderRepository.findById(orderId));  // N개의 쿼리
    }
    return orders;
}

2. 우선순위: 모든 부채가 동등하지 않음 - 높은 우선순위: 보안 취약점, 성능 병목 - 중간 우선순위: 코드 중복, 나쁜 네이밍 - 낮은 우선순위: 누락된 주석, 사소한 스타일 문제

3. 갚기: 리팩토링 시간 할당

# 스프린트 계획
사용자 스토리: 용량의 60%
기술 부채:    용량의 20%
버그:         용량의 20%

4. 방지: 코드 리뷰, 자동화 테스트, 아키텍처 가이드라인

기술 부채가 허용되는 경우¶

✅ 좋은 이유로 부채 발생: - 출시 시간: MVP를 배포하여 제품 가설 검증 - 학습: 문제를 더 잘 이해하기 위한 프로토타입 구축 - 실험: 전체 구현 전에 A/B 테스트

# 허용 가능: 기능 채택 테스트를 위한 빠른 프로토타입
# 사용자가 좋아하면 제대로 다시 작성
@app.route('/experimental-search')
def search():
    # 프로토타입: 성공하면 적절한 검색 엔진으로 교체
    results = [item for item in items if query in item['name']]
    return jsonify(results)

❌ 나쁜 이유: - "나중에 고칠게"(계획 없이) - "작동해, 배포해!"(품질 무시) - 게으름으로 알려진 모범 사례 무시

기술적 파산¶

부채가 견딜 수 없을 때, 코드베이스는 유지보수 불가능: - 모든 변경이 무언가를 깨뜨림 - 개발자가 코드 건드리기 두려워함 - 새 개발자 온보딩에 몇 달 소요

해결책: 1. 점진적 재작성: 교살 패턴(조각별로 교체) 2. 대규모 재작성: 위험하고, 종종 실패(Netscape 재작성 재해 참조) 3. 적극적 리팩토링: 정리에 스프린트 전념

문서화¶

좋은 문서는 소프트웨어를 이해 가능, 사용 가능, 유지보수 가능하게 만듭니다.

문서화 유형¶

1. 코드 주석: 왜를 설명, 무엇이 아니라

// 나쁨: 명백한 무엇
int x = y + 5;  // y에 5 더하기

// 좋음: 왜 설명
int maxRetries = baseRetries + 5;  // 불안정한 네트워크를 위한 5개 버퍼 재시도 추가

// 좋음: 명확하지 않은 논리 설명
// 배열이 정렬되어 있으므로 O(n) 대신 O(log n)을 위해 이진 검색 사용
int index = binarySearch(sortedArray, target);

2. API 문서: 참조 + 가이드 + 튜토리얼

def calculate_discount(price, customer_tier):
    """
    고객 등급에 따라 할인 계산.

    Args:
        price (float): USD 원래 가격
        customer_tier (str): 'bronze', 'silver', 'gold', 'platinum' 중 하나

    Returns:
        float: 할인된 가격

    Raises:
        ValueError: customer_tier가 유효하지 않은 경우

    Examples:
        >>> calculate_discount(100, 'gold')
        85.0
        >>> calculate_discount(100, 'platinum')
        75.0
    """
    tiers = {'bronze': 0, 'silver': 0.05, 'gold': 0.15, 'platinum': 0.25}
    if customer_tier not in tiers:
        raise ValueError(f"Invalid tier: {customer_tier}")
    return price * (1 - tiers[customer_tier])

3. 아키텍처 문서: 고수준 설계 결정

# 아키텍처: C4 모델

## 컨텍스트 다이어그램
시스템이 세계에 어떻게 맞는지 보여줌(사용자, 외부 시스템).

## 컨테이너 다이어그램
고수준 기술 선택을 보여줌(웹 앱, API, 데이터베이스).

## 구성 요소 다이어그램
각 컨테이너 내의 구성 요소를 보여줌.

## 코드 다이어그램
클래스/모듈을 보여줌(보통 코드에서 자동 생성).

4. README: 프로젝트의 현관

# 프로젝트 이름

이 프로젝트가 무엇을 하는지에 대한 간단한 설명.

## 기능
- 기능 1
- 기능 2

## 설치
```bash
pip install myproject

빠른 시작¶

from myproject import main
main()

문서¶

전체 문서는 https://docs.example.com

기여¶

CONTRIBUTING.md 참조

라이선스¶

MIT License

### 문서를 작성할 때

**문서 작성 시기**:
- 공개 API: 사용자가 사용 방법을 이해해야 함
- 복잡한 알고리즘: 미래의 당신이 왜 작동하는지 잊을 것
- 온보딩: 새 팀원이 시작해야 함
- 아키텍처 결정: 왜 선택했는지 기록

**문서를 작성하지 않을 때**:
- 코드가 자명함(좋은 네이밍, 명확한 구조)
- 문서가 단지 코드를 반복

### 코드로서의 문서

문서를 코드와 함께 **버전 관리**에 저장:

project/ ├── src/ ├── docs/ │ ├── architecture.md │ ├── api-reference.md │ └── deployment.md ├── README.md └── CONTRIBUTING.md

**장점**:
- 풀 리퀘스트에서 리뷰됨
- 코드와 버전 관리됨(문서가 코드 버전과 일치)
- 업데이트하기 쉬움

**도구**: Sphinx, MkDocs, Docusaurus, JSDoc

### 아키텍처 문서화를 위한 C4 모델

**C4**는 Context, Containers, Components, Code를 의미합니다.

레벨 1: 시스템 컨텍스트 ┌──────────────────────────────────────┐ │ 사용자 → [시스템] → [데이터베이스]│ └──────────────────────────────────────┘

레벨 2: 컨테이너 ┌──────────────────────────────────────┐ │ 사용자 → [웹 앱] → [API] → DB │ └──────────────────────────────────────┘

레벨 3: 구성 요소(API 컨테이너 내) ┌──────────────────────────────────────┐ │ [컨트롤러] → [서비스] → [저장소] │ └──────────────────────────────────────┘

레벨 4: 코드(클래스, 함수)

다이어그램을 아껴 사용—빠르게 구식이 됨. 레벨 1-2에 집중.

## 오픈 소스

**오픈 소스 소프트웨어**는 누구나 소스 코드를 검사, 수정, 배포할 수 있는 소프트웨어입니다.

### 오픈 소스 작동 방식

**라이선스**: 소프트웨어 사용, 수정, 배포를 위한 법적 조건
**기여**: 풀 리퀘스트를 통해 버그 수정, 기능 제출
**커뮤니티**: 유지관리자, 기여자, 사용자가 협업

### 오픈 소스에 기여하기

**왜 기여하는가**:
- **학습**: 실제 코드베이스 연구
- **포트폴리오 구축**: 고용주에게 작업 보여주기
- **보답**: 사용하는 도구 개선
- **네트워킹**: 전 세계 개발자 만나기

**시작 방법**:
1. **프로젝트 찾기**: `good-first-issue` 레이블이 있는 저장소 찾기
2. **CONTRIBUTING.md 읽기**: 프로젝트 워크플로우 이해
3. **작게 시작**: 오타 수정, 문서 개선, 테스트 추가
4. **소통**: 질문하기, 존중하기

**예제: 첫 기여**:
```bash
# 1. GitHub에서 저장소 포크
# 2. 포크 클론
git clone https://github.com/yourname/projectname.git
cd projectname

# 3. 브랜치 생성
git checkout -b fix-typo-readme

# 4. 변경
# README.md 편집

# 5. 커밋
git commit -m "docs: fix typo in installation instructions"

# 6. Push
git push origin fix-typo-readme

# 7. GitHub에서 풀 리퀘스트 열기

에티켓: - 존중하기: 유지관리자는 자원봉사자 - 가이드라인 따르기: CONTRIBUTING.md, 코드 스타일 - 인내심: 리뷰에 시간 소요 - 피드백 받아들이기: 코드 변경은 좋은 이유로 요청됨

오픈 소스 프로젝트 만들기¶

언제 오픈 소스화할까: - 도구가 회사를 넘어 유용 - 커뮤니티 기여를 원함 - 포트폴리오를 구축 중

단계: 1. 라이선스 선택(다음 섹션 참조) 2. README 작성: 무엇을 하는지, 설치 방법, 사용 방법 3. CONTRIBUTING.md 추가: 기여 방법 4. CODE_OF_CONDUCT.md 추가: 커뮤니티 행동 기대 5. 게시: GitHub, GitLab 등에 푸시

예제 README:

# AwesomeTool

배포 자동화를 위한 CLI 도구.

## 설치
```bash
npm install -g awesome-tool

사용법¶

awesome-tool deploy --env production

기여¶

CONTRIBUTING.md 참조

라이선스¶

MIT License

### 인기 있는 오픈 소스 라이선스

**관대한 라이선스**: 최소 제한

| 라이선스 | 설명 |
|---------|-------------|
| **MIT** | 매우 관대함. 자유롭게 사용, 수정, 배포. |
| **Apache 2.0** | MIT와 유사하나 특허 부여 포함. |
| **BSD** | MIT와 유사, 약간의 변형(2-clause, 3-clause). |

**카피레프트 라이선스**: 파생물도 오픈 소스여야 함

| 라이선스 | 설명 |
|---------|-------------|
| **GPL v3** | 강한 카피레프트. 모든 파생물은 GPL이어야 함. |
| **LGPL v3** | 약한 카피레프트. 라이브러리 링크 허용. |
| **AGPL v3** | GPL과 유사하나 네트워크 사용도 포함(SaaS). |

**언제 사용**:
- **MIT**: 대부분의 프로젝트(간단, 널리 이해됨)
- **Apache 2.0**: 특허가 우려되는 경우
- **GPL v3**: 파생물이 오픈으로 유지되기를 원하는 경우
- **AGPL v3**: SaaS가 오픈으로 유지되기를 원하는 경우

**예제: 라이선스 추가**:
```bash
# 선택한 라이선스 텍스트로 LICENSE 파일 추가
# package.json 또는 setup.py에 추가
"license": "MIT"

라이선스 호환성¶

일부 라이선스는 호환되지 않음:

✅ OK: Apache 프로젝트의 MIT 라이브러리(관대 → 관대)
✅ OK: GPL 프로젝트의 MIT 라이브러리(관대 → 카피레프트)
❌ 불가: MIT 프로젝트의 GPL 라이브러리(카피레프트 → 관대)

경험 법칙: 관대한 라이선스는 모든 것과 호환. 카피레프트 라이선스는 관대한 것과 호환되지 않음.

이중 라이선스¶

일부 프로젝트는 두 개의 라이선스 제공: - 오픈 소스 라이선스(GPL): 오픈 소스 프로젝트에 무료 - 상업 라이선스: 독점 프로젝트에 유료

예제: MySQL(GPL 또는 상업 라이선스)

소프트웨어 개발 윤리¶

소프트웨어는 실제 영향이 있습니다. 개발자는 윤리적 책임이 있습니다.

프라이버시와 데이터 보호¶

원칙: - 수집 최소화: 필요한 데이터만 수집 - 목적 제한: 명시된 목적으로만 데이터 사용 - 사용자 제어: 사용자가 자신의 데이터에 접근, 삭제 가능 - 보안: 침해로부터 데이터 보호

규정: - GDPR(EU): 엄격한 데이터 보호, 사용자 권리(접근, 삭제, 이동) - CCPA(캘리포니아): 캘리포니아 거주자를 위한 GDPR과 유사

예제: 프라이버시 친화적 설계:

# 나쁨: 모든 것 수집
user = {
    'name': name,
    'email': email,
    'birthday': birthday,
    'location': location,
    'browsing_history': history,  # 이게 필요한가?
}

# 좋음: 필요한 것만 수집
user = {
    'email': email,  # 로그인용
}

알고리즘 편향과 공정성¶

알고리즘의 편향은 차별을 영속화할 수 있습니다.

편향의 출처: 1. 학습 데이터 편향: 데이터가 역사적 불평등 반영 2. 특징 선택 편향: 보호 속성과 상관있는 특징 선택 3. 레이블 편향: 레이블이 인간 편향 반영

예제: 채용 알고리즘:

# 편향됨: 학습 데이터에 남성 엔지니어가 더 많음
model.fit(historical_resumes, historical_hires)
# 모델 학습: 남성 → 더 높은 점수

# 완화: 성별 관련 특징 제거, 균형 잡힌 학습 데이터

원칙: - 공정성: 유사한 개인을 유사하게 대우 - 투명성: 결정이 어떻게 내려지는지 설명 - 책임성: 결과에 대해 누가 책임지는가?

접근성¶

접근성은 장애인을 포함한 모든 사람이 소프트웨어를 사용할 수 있도록 보장합니다.

웹 접근성(WCAG): - 인식 가능: 이미지의 텍스트 대체, 비디오의 자막 - 작동 가능: 키보드 내비게이션, 깜빡이는 콘텐츠 없음(발작) - 이해 가능: 명확한 언어, 일관된 내비게이션 - 견고함: 보조 기술과 호환(스크린 리더)

예제: 접근 가능한 HTML:

<!-- 나쁨: alt 텍스트 없는 이미지 -->
<img src="chart.png">

<!-- 좋음: 설명적 alt 텍스트 -->
<img src="chart.png" alt="2020년부터 2024년까지 매출 성장을 보여주는 막대 차트">

<!-- 나쁨: 레이블 없는 버튼 -->
<button><span class="icon-close"></span></button>

<!-- 좋음: 접근 가능한 레이블이 있는 버튼 -->
<button aria-label="대화 상자 닫기">
  <span class="icon-close" aria-hidden="true"></span>
</button>

장애를 넘어선 이점: - 자막은 시끄러운 환경에서 도움 - 키보드 내비게이션은 파워 유저에게 도움 - 명확한 언어는 비원어민에게 도움

보안 책임¶

개발자는 책임이 있습니다 사용자 데이터 보호에.

원칙: - 심층 방어: 여러 보안 계층 - 최소 권한: 최소 권한 부여 - 안전하게 실패: 오류가 데이터를 노출하지 않아야 함 - 비밀 유지: 비밀번호, API 키를 하드코딩하지 말 것

예제: 안전한 비밀번호 저장:

// 나쁨: 평문 비밀번호
db.save({ username, password });

// 나쁨: 역변환 가능한 암호화
db.save({ username, password: encrypt(password) });

// 좋음: 솔트로 해시
const bcrypt = require('bcrypt');
const hashedPassword = await bcrypt.hash(password, 10);
db.save({ username, password: hashedPassword });

예제: SQL 인젝션 방지:

# 나쁨: 문자열 연결(SQL 인젝션 위험)
query = f"SELECT * FROM users WHERE email = '{email}'"
db.execute(query)

# 좋음: 매개변수화된 쿼리
query = "SELECT * FROM users WHERE email = ?"
db.execute(query, (email,))

다크 패턴¶

다크 패턴은 사용자를 속이는 조작적 UI/UX 설계입니다.

예제: - 강제 계속성: 구독 취소하기 어려움 - 숨겨진 비용: 결제 시 공개되는 수수료 - 미끼와 교환: 버튼은 한 가지를 말하지만 다른 것을 함 - 확인수치심: "아니요, 감사합니다. 돈을 절약하고 싶지 않아요"

윤리적 입장: 다크 패턴을 만들지 마세요. 사용자 자율성을 존중하세요.

AI 윤리¶

AI가 널리 퍼짐에 따라 개발자는 다음을 고려해야 합니다:

투명성: 사용자가 AI 결정이 어떻게 내려지는지 이해할 수 있는가?

# 블랙박스: 신경망 결정
prediction = model.predict(features)

# 투명: 사용된 특징 설명
prediction = model.predict(features)
explanation = explainer.explain_instance(features)
# "결정 근거: 신용 점수(0.6), 소득(0.3), ..."

책임성: AI가 실수할 때 누가 책임지는가? - 자율 주행차 사고: 운전자? 제조사? 개발자?

편향: AI가 인구통계학적 그룹 간에 공정한가? - 얼굴 인식이 어두운 피부톤에서 더 나쁘게 작동(학습 데이터 편향)

프라이버시: 학습 데이터는 어떻게 수집되는가? 모델이 학습 데이터를 누출할 수 있는가?

개발자 웰빙¶

소프트웨어 개발은 마라톤이지, 스프린트가 아닙니다. 지속 가능한 경력은 웰빙을 필요로 합니다.

지속 가능한 페이스¶

번아웃 방지: - 일과 생활의 균형: 정기적으로 밤/주말에 일하지 말 것 - 휴식: 화면에서 벗어나기, 산책하기 - 휴가: 완전히 연결 해제(Slack 확인하지 말 것)

크런치 타임은 해롭습니다: - 주당 40-50시간 후 생산성 감소 - 피로로 버그 증가 - 번아웃이 이직으로 이어짐

적신호: - "우리는 가족이에요"(과로의 암호) - 지속적인 소방(나쁜 계획) - 영웅 문화(과로 보상)

지속적 학습¶

기술은 빠르게 변합니다. 지속적 학습이 필수입니다.

전략: - 코드 읽기: 오픈 소스 프로젝트 연구 - 사이드 프로젝트: 재미로 도구 구축 - 강좌: 온라인 강좌, 책, 컨퍼런스 - 가르치기: 글쓰기, 멘토링이 지식 고화

피하기: - 과대광고 주도 개발: 모든 새 프레임워크를 쫓지 말 것 - 튜토리얼 지옥: 학습과 구축의 균형 - 비교: 모두가 다른 속도로 발전

사기꾼 증후군¶

사기꾼 증후군: 능력의 증거에도 불구하고 사기꾼처럼 느껴짐.

정상입니다: - 경험 많은 개발자도 느낌 - 산업이 빠르게 변함(모두가 학습 중)

전략: - 승리 문서화: "자랑 문서" 유지 - 이야기하기: 다른 사람도 같은 느낌을 가진다는 것을 알게 됨 - 관점: 모든 것을 알 필요 없음

경력 성장¶

소프트웨어 경력은 두 가지 주요 트랙을 제공합니다.

IC 트랙 vs 관리 트랙¶

개별 기여자(IC) 트랙: - 초점: 기술 깊이 - 진행: 주니어 → 미드 → 시니어 → 스태프 → 프린시펄 - 책임: 코드 작성, 시스템 설계, 멘토링

관리 트랙: - 초점: 사람, 프로세스, 전략 - 진행: 팀 리드 → 매니저 → 디렉터 → VP - 책임: 채용, 성과 검토, 로드맵 계획

둘 다 나은 것 없음: 당신에게 활력을 주는 것에 따라 선택.

T자형 스킬¶

T자형 개발자: - 세로 막대: 한 영역의 깊은 전문성(예: 백엔드 시스템) - 가로 막대: 영역 간 광범위한 지식(프론트엔드, 데이터베이스, DevOps)

   프론트엔드  백엔드  DevOps  ML  모바일
      |       |||      |     |     |
      |       |||      |     |     |
      |       |||      |     |     |
             (백엔드에 깊고, 다른 곳에 넓음)

구축 방법: - 깊이: 한 도메인 마스터(3-5년) - 넓이: 사이드 프로젝트, 교차 기능 작업

학습 습관 구축¶

기법: - 일일 독서: 블로그, 문서에 30분 - 주간 실험: 새 도구/언어 시도 - 월간 프로젝트: 종단 간 무언가 구축 - 분기별 깊이 탐구: 책 읽기, 강좌 수강

리소스: - 블로그: Martin Fowler, Joel Spolsky, 엔지니어링 블로그(Uber, Netflix) - 책: "Clean Code", "Designing Data-Intensive Applications" - 팟캐스트: Software Engineering Daily, Changelog - 컨퍼런스: 로컬 모임, 온라인 컨퍼런스

실용주의 프로그래머 마인드셋¶

Andrew Hunt와 David Thomas의 책 The Pragmatic Programmer에서:

1. 당신의 기술에 관심을 가지세요 - 작업에 자부심 가지기 - 깨진 창문 용인하지 않기(나쁜 코드)

2. 작업에 대해 생각하세요 - 자동 조종으로 코딩하지 말 것 - 결정에 질문: "왜 이렇게 하는가?"

3. 변화의 촉매제가 되세요 - 허가를 기다리지 말고 개선하세요 - 말하지 말고 보여주세요(프로토타입 구축, 그런 다음 설득)

4. 큰 그림 기억하세요 - 세부사항에 빠지지 말 것 - 비즈니스 컨텍스트 이해

5. DRY: 자신을 반복하지 마세요 - 중복은 낭비(코드, 지식, 문서화)

6. 재사용하기 쉽게 만드세요 - 모듈화되고 분리된 코드 작성

7. 배우기 위해 프로토타입 - 아이디어 탐색을 위한 버릴 코드 구축

8. 놀람을 피하기 위해 추정 - 시간 추정 배우기(연습, 개선)

9. 일찍, 자주 리팩토링 - 코드가 썩음—깨끗하게 유지

10. 소프트웨어 테스트, 그렇지 않으면 사용자가 테스트 - 자동화 테스트가 회귀 포착

연습 문제¶

연습 문제 1: 기술 부채 식별¶

프로젝트 중 하나를 검토하고 식별하세요: 1. 의도적, 신중한 기술 부채의 한 예 2. 우발적 기술 부채의 한 예 3. 우선순위: 먼저 어느 것을 해결해야 하는가? 왜?

연습 문제 2: README 작성¶

가상 프로젝트를 위한 README 작성: TODO 목록 관리용 명령줄 도구. 포함: - 프로젝트 설명 - 설치 지침 - 사용 예제 - 기여 가이드라인 - 라이선스

연습 문제 3: 라이선스 선택¶

머신러닝을 위한 오픈 소스 라이브러리를 릴리스하고 있습니다. 원하는 것: - 누구나 자유롭게 사용 - 파생물도 오픈 소스 - 특허 소송으로부터 보호

어떤 라이선스를 선택하시겠습니까? 답을 정당화하세요.

연습 문제 4: 윤리적 시나리오 분석¶

이 시나리오를 분석하세요:

회사가 신용 점수 알고리즘을 구축하고 있습니다. 모델은 우편번호를 특징으로 사용합니다. 우편번호가 인종과 높은 상관관계가 있고, 모델이 주로 흑인 지역에 낮은 점수를 준다는 것을 알아챕니다.

질문: 1. 윤리적 문제는 무엇입니까? 2. 잠재적 피해는 무엇입니까? 3. 당신은 무엇을 하시겠습니까?

연습 문제 5: 경력 성찰¶

자신의 경력에 대해 성찰하세요: 1. IC 트랙과 관리 트랙 중 어느 것에 더 관심이 있습니까? 왜? 2. "세로 막대"(깊은 전문성 영역)는 무엇입니까? 3. 개발하고 싶은 "가로 막대"(광범위한 지식)는 무엇입니까? 4. 앞으로 3개월 동안의 학습 목표는 무엇입니까?

요약¶

전문 소프트웨어 개발은 코드 작성을 훨씬 넘어섭니다:

기술 부채: 속도와 품질의 균형; 의도적으로 부채 관리
문서화: 코드 주석, API 문서, 아키텍처 다이어그램, README를 통해 소프트웨어를 이해 가능하게 만들기
오픈 소스: 오픈 소스 프로젝트에 기여하고 만들기; 라이선스 이해(MIT, Apache, GPL)
윤리: 프라이버시, 공정성, 접근성, 보안, 투명성 우선순위
웰빙: 지속 가능한 페이스, 지속적 학습, 사기꾼 증후군 관리 유지
경력 성장: IC 또는 관리 트랙 선택, T자형 스킬 개발, 학습 습관 구축
실용주의 마인드셋: 기술에 관심 가지기, 비판적으로 생각하기, 지속적으로 리팩토링, 철저히 테스트

훌륭한 개발자는 기술 스킬과 전문성, 윤리, 지속적 성장을 결합합니다. 오늘 작성하는 코드는 내일 남기는 유산이 됩니다—가치 있게 만드세요.

내비게이션¶

← 이전: 소프트웨어 아키텍처

Programming 토픽 끝

16개 레슨을 모두 완료했습니다. 관련 토픽을 계속 탐색하세요: - Algorithm: 자료구조와 알고리즘 심화 - System_Design: 확장 가능한 분산 시스템 - Security: 애플리케이션 보안과 암호학 - 언어별 토픽: Python, C_Programming, CPP