Merge pull request #18 from theintrance/jayden/2024-11-06

Jayden/2024 11 06

Author: BayernMuller

astro/src/consts.ts

@@ -69,6 +69,16 @@ export const SIDEBAR: Sidebar = {
       { text: '5.4. 일관된 코딩 스타일을 고수하라', link: '/ko/chapter5/5_4_일관된_코딩_스타일을_고수하라' },
       { text: '5.5. 깊이 중첩된 코드를 피하라', link: '/ko/chapter5/5_5_깊이_중첩된_코드를_피하라' },
       { text: '5.6. 함수 호출도 가독성이 있어야 한다', link: '/ko/chapter5/5_6_함수_호출도_가독성이_있어야_한다' },
+      { text: '5.8. 익명 함수를 적절하게 사용하라', link: '/ko/chapter5/5_8_익명_함수를_적절하게_사용하라' },
+      { text: '5.9. 프로그래밍 언어의 새로운 기능을 적절하게 사용하라', link: '/ko/chapter5/5_9_프로그래밍_언어의_새로운_기능을_적절하게_사용하라' },
+    ],
+    'Chapter 6': [
+      { text: '6.1. 매직값을 반환하지 말아야 한다', link: '/ko/chapter6/6_1_매직값을_반환하지_말아야_한다' },
+      { text: '6.2. 널 객체 패턴을 적절히 사용하라', link: '/ko/chapter6/6_2_널_객체_패턴을_적절히_사용하라' },
+      { text: '6.3. 예상치 못한 사이드 이펙트를 피하라', link: '/ko/chapter6/6_3_예상치_못한_사이드_이펙트를_피하라' },
+      { text: '6.4. 입력 매개변수를 수정하는 것에 주의하라', link: '/ko/chapter6/6_4_입력_매개변수를_수정하는_것에_주의하라' },
+      { text: '6.5. 오해를 일으키는 함수는 작성하지 말라', link: '/ko/chapter6/6_5_오해를_일으키는_함수는_작성하지_말라' },
+      { text: '6.6. 미래를 대비한 열거형 처리', link: '/ko/chapter6/6_6_미래를_대비한_열거형_처리' },
     ],
   }
 }

chapter6/6_3_예상치_못한_사이드_이펙트를_피하라.mdx

@@ -0,0 +1,107 @@
+---
+title: 예상치 못한 사이드 이펙트를 피하라
+author: bayernmuller
+---
+
+* **Side Effect**는 어떤 함수의 호출히 함수 외부에 초래한 상태 변화를 의미한다.
+
+    * 예)
+        1. 사용자에게 출력 표시
+        2. 파일이나 데이터베이스에 무언가를 저장
+        3. 다른 시스템을 호출하여 네트워크 트래픽 발생
+        4. 캐시 업데이트 및 무효화
+
+* 사이드 이펙트를 피하기 위해 immutable class 를 만드는 것도 방법이며, 7장에서 다룸
+* 사이드 이펙트는 언제나 예상치 못하게 발생할 수 있으므로 최대한 방어적으로 코드를 작성해야 한다.
+
+### 6.3.1 분명하고 의도적인 사이드 이펙트는 괜찮다
+
+```java correct
+class UserDisplay {
+    private final Canvas canvas;
+    ...
+    void displayError(String message) {
+        canvas.drawText(message, Color.RED);
+    }
+}
+```
+
+* 위 코드는 의도적이고 분명하게 사이드 이펙트를 발생시키는 코드이다.
+    * 문제가 되지 않는다.
+
+### 6.3.2 예기치 않은 사이드 이펙트는 문제가 될 수 있다
+
+```java incorrect
+class UserDisplay {
+    private final Canvas canvas;
+    ...
+    Color getPixel(Int x, Int y) {
+        canvas.redraw();
+        PixelData pixelData = canvas.getPixel(x, y);
+        return new Color(
+            pixelData.red,
+            pixelData.green,
+            pixelData.blue
+        );
+    }
+}
+```
+
+* 특정 좌표의 픽셀 데이터를 구하기 위해, `canvas.redraw()` 를 호출하고 있다.
+* 이는 문제의 소지가 될 수 있다.
+
+#### 사이드 이펙트는 비용이 많이 들 수 있다
+
+* 캔버스를 업데이트 하는 것은 잠재적으로 비용이 많이 들 수 있고 flickering 현상을 일으킬 수 있다.
+* `getPixel()` 을 호출하는 쪽에서는 그정도의 작업이 필요한지 모르고 사용할 수 있다.
+
+#### 호출한 쪽의 가정을 깨트려버린다
+
+```java incorrect
+class UserDisplay {
+    ...
+    Color getPixel(Int x, Int y) { ... }
+
+    Image captureScreenshot() {
+        Image image = new Image();
+        for (int y = 0; y < canvas.height; y++) {
+            for (int x = 0; x < canvas.width; x++) {
+                image.setPixel(x, y, getPixel(x, y));
+            }
+        }
+        return image;
+    }
+}
+```
+* `getPixel()` 은 캔버스를 업데이트하고 있지만 `captureScreenshot()` 는 그것을 예측하기 쉽지 않으므로 여러번 호출하여 치명적인 버그를 만들고있다.
+* 이처럼 예기치 않은 사이드 이펙트는 호출 하는 쪽에서 예상치 못한 결과를 초래할 수 있다.
+
+#### 다중 스레드 코드의 버그
+
+|thread|1|2|comment|
+|---|---|---|---|
+|thread 1 선점|`getPixel()` -> `canvas.redraw()`||캔버스를 그리기 시작|
+|thread 2 선점||`getPixel()` -> `canvas.redraw()`|캔버스를 또 그리기 시작|
+|thread 1 재시작|`getPixel()` 마무리||예상할 수 없는 픽셀값 얻음|
+|thread 2 재시작||`getPixel()` 마무리|예상할 수 없는 픽셀값 얻음|
+
+* 이렇게 두 thread가 동시에 `getPixel()` 을 사용하면 서로 데이터를 가지고 경쟁하며 `canvas` 를 다시 그리게 되고, 결국 각각 호출한 `getPixel()` 의 결과는 예상할 수 없게 된다.
+
+### 6.3.3 해결책: 사이드 이펙트를 피하거나 그 사실을 분명하게 하라
+
+* 픽셀을 읽기 전에 `canvas.redraw()` 호출이 꼭 필요할까?
+    * 꼭 필요하지 않다면 호출하지 않아야 한다.
+* 반드시 호출 해야한다면 `getPixel()` 이라는 이름은 적절하지 않다.
+
+```java correct
+class UserDisplay {
+    ...
+    Color redrawAndGetPixel(Int x, Int y) {
+        canvas.redraw();
+        ...
+    }
+}
+```
+
+* 함수 이름을 바꾸어 호출하는 쪽에서 어떤 동작을 하는지 명확하게 알 수 있도록 한다.
+    * 또한 `redrawAndGetPixel()` 을 보고 thread-unsafe 를 의심할 수 있다.

chapter6/6_4_입력_매개변수를_수정하는_것에_주의하라.mdx

@@ -0,0 +1,81 @@
+---
+title: 입력 매개변수를 수정하는 것에 주의하라
+author: bayernmuller
+---
+
+### 6.4.1입력 파라미터를 수정하면 버그를 초래할 수 있다
+
+```cpp incorrect
+Image GetColorReversed(Image& image) {
+    for (int y = 0; y < image.height; y++) {
+        for (int x = 0; x < image.width; x++) {
+            image.setPixel(x, y, image.getPixel(x, y).reverse());
+        }
+    }   
+    return image;
+}
+
+int main() {
+    Image original_image = Image::FromFile("image.png");
+    Image reversed_image = GetColorReversed(original_image);
+
+    // Original Image 가 변경되어 있다..
+}
+```
+
+* 이 코드처럼 입력 파라미터를 변경하는 것은 예상치 못한 사이드 이펙트를 일으킬 수 있다.
+
+### 6.4.2 해결책: 변경 전 복사하라
+
+```cpp correct
+// 여전히 좋은 코드는 아님, 아래 Jayden 의 코멘트 참고
+Image GetColorReversed(Image& image) {
+    Image result(image);
+    for (int y = 0; y < result.height; y++) {
+        for (int x = 0; x < result.width; x++) {
+            result.setPixel(x, y, result.getPixel(x, y).reverse());
+        }
+    }
+    return result;
+}
+
+int main() {
+    Image original_image = Image::FromFile("image.png");
+    Image reversed_image = GetColorReversed(original_image);
+
+    // Original Image 는 변경되지 않는다.
+}
+```
+
+* 이렇게 변경 전 복사하는 것은 입력 파라미터를 수정하는 것을 방지할 수 있다.
+
+##### Jayden: C++ 에서 파라미터를 넘길 때의 테크닉
+ * 구글 스타일 C++ 에서는 `call-by-pointer` 일때, 이 파라미터가 변경될 수 있음을 뜻하고, call-by-**cosnt**-reference 일 때 변경되지 않음을 뜻한다.
+
+```cpp correct
+void sqaure(int *x)
+{
+    *x = *x * *x;
+}
+
+int a = 10;
+sqaure(&a); // a 는 square 에 의해 변경될 수 있음을 뜻한다.
+```
+
+```cpp correct
+Image GetColorReversed(const Image& image)
+{
+    ...
+}
+
+Image image = Image::FromFile("image.png");
+Image reversed_image = GetColorReversed(image); // image 는 변경되지 않는다.
+```
+
+```cpp incorrect
+Image GetColorReversed(Image& image) // cpplint error!
+{
+    ...
+}
+```
+* non-const reference 는 사용하지 않는다.

chapter6/6_5_오해를_일으키는_함수는_작성하지_말라.mdx

@@ -0,0 +1,40 @@
+---
+title: 오해를 일으키는 함수는 작성하지 말라
+author: bayernmuller
+---
+
+### 6.5.1 중요한 입력이 누락되었을 때 아무것도 하지 않으면 놀랄 수 있다
+
+```java incorrect
+class UserDisplay {
+    private final LocalizedMessages messages;
+    ...
+    void displayLegalDisclaimer(String? legalText) {
+        if (legalText == null) {
+            return;
+        }
+        ...
+        displayOverlay(
+            title: messages.getLegalDisclaimerTitle(),
+            message: legalText,
+            textColor: Color.RED
+        );
+    }
+}
+```
+* 위 `displayLegalDisclaimer()` 함수는 `legalText` 가 `null` 일 때 아무것도 하지 않는다.
+* 호출하는 쪽에서 `legalText` 가 `null` 일 때 아무것도 하지 않는다는 것을 알 수 없으며, 항상 잘 작동하고 있다고 착각할 수 있다.
+
+### 6.5.2 해결책: 중요한 입력은 필수 항목으로 만들라
+
+* 중요한 파라미터는 nullable 하지 않도록 하라.
+
+```java correct
+class UserDisplay {
+    private final LocalizedMessages messages;
+    ...
+    void displayLegalDisclaimer(String legalText) {
+        // legalText CANNOT be null!
+    }
+}
+```

chapter6/6_6_미래를_대비한_열거형_처리.mdx

@@ -0,0 +1,113 @@
+---
+title: 미래를 대비한 열거형 처리
+author: bayernmuller
+---
+
+* 지금까지 6장에서는 코드를 사용하는 쪽에서 코드가 수행하는 일이나 반환값이 예상을 벗어나지 않도록 하는데에 초점을 맞추었다.
+* 하지만 반대로, 우리가 의존하는 코드에 대해서 부실한 가정을 할 경우에도 버그가 생길 수 있다.
+
+### 6.6.1 미래에 추가될 수 있는 enum 값을 암묵적으로 처리하는 것은 문제가 될 수 있다
+
+```java 
+enum PredictedOutcome {
+    BAYERN_MUNICH_WILL_WIN,
+    BAYERN_MUNICH_WILL_LOSE,
+}
+
+Boolean isOutcomeSafe(PredictedOutcome prediction) {
+    if (prediction == PredictedOutcome.BAYERN_MUNICH_WILL_LOSE) {
+        return false;
+    }
+    return true;
+}
+```
+
+* 위 코드는 Enum 의 요소가 2개일 때는 잘 작동한다.
+* 하지만 Enum 의 요소가 추가될 때 문제가 생긴다.
+
+```java incorrect
+enum PredictedOutcome {
+    BAYERN_MUNICH_WILL_WIN,
+    BAYERN_MUNICH_WILL_LOSE,
+    REAL_MADRID_WILL_WIN_THE_CHAMPIONS_LEAGUE, // 새로운 요소가 추가됨
+}
+
+Boolean isOutcomeSafe(PredictedOutcome prediction) {
+    if (prediction == PredictedOutcome.BAYN_MUNICH_WILL_LOSE) {
+        return false;
+    }
+    return true;
+}
+```
+
+* 3번쨰 enum 값이 추가되었는데, `isOutcomeSafe()` 에서는 `REAL_MADRID_WILL_WIN_THE_CHAMPIONS_LEAGUE` 를 safe 하다고 판단할 것이다. 절대 안된다.
+* 이렇게 Enum 을 추가할 떄 Enum 을 참조하는 코드에 문제가 생길 수 있다.
+
+### 6.6.2 해결책: 모든 경우를 처리하는 스위치 문을 사용하라
+
+* 이 문제를 해결하기 위해 모든 열거값을 명시적으로 처리하도록 강제할 수 있다.
+
+```java
+Boolean isOutcomeSafe(PredictedOutcome prediction) {
+    switch (prediction) {
+        case BAYERN_MUNICH_WILL_WIN:
+            return true;
+        case BAYERN_MUNICH_WILL_LOSE:
+            return false;
+    }
+    throw new UncheckedException("Unknown prediction: " + prediction);
+}
+```
+
+* 만약 `switch` 문에서 모든 경우를 처리하지 않는다면 `UncheckedException` 이 발생할 것이다.
+    * 즉 새로운 열거값을 추가했을 때, 이것을 사용하는 코드의 수정을 강제할 수 있다.
+    * Unit Test 를 작성하여 모든 Enum 값을 처리하는지 확인할 수 있다.
+
+```java correct
+testIsOutcomeSafe_allPredictedOutcomeValues() {
+    for (PredictedOutcome prediction : PredictedOutcome.values()) {
+        isOutcomeSafe(prediction);
+    }
+}
+```
+
+```java correct
+Boolean isOutcomeSafe(PredictedOutcome prediction) {
+    switch (prediction) {
+        case BAYERN_MUNICH_WILL_WIN:
+            return true;
+        case BAYERN_MUNICH_WILL_LOSE:
+            return false;
+        case REAL_MADRID_WILL_WIN_THE_CHAMPIONS_LEAGUE:
+            return false;
+    }
+    throw new UncheckedException("Unknown prediction: " + prediction);
+}
+```
+* 단위 테스트를 통해 모든 열거값을 처리하는지 확인할 수 있었고, 코드를 수정할 수 있었다.
+
+### 6.6.3 switch: default-case 를 주의하라
+
+```java incorrect
+Boolean isOutcomeSafe(PredictedOutcome prediction) {
+    switch (prediction) {
+        case BAYERN_MUNICH_WILL_WIN:
+            return true;
+        case BAYERN_MUNICH_WILL_LOSE:
+            return false;
+        default:
+            return false;
+    }
+}
+```
+
+* 새로운 열거값이 추가되었을 때, `default` 케이스로 수행되어 `false` 를 반환하게 된다.
+* 이는 버그가 있음에도 예외도 발생시키지 않고 무시된다.
+* C++ 과 몇몇 언어는 switch 문에서 모든 열거형이 처리되고 있는지 컴파일러가 확인하고 경고를 줄 수 있다.
+* 따라서 명시적으로 예외를 발생시켜 버그를 방지하자
+* **Java 에서는 switch 문에서 `default` 케이스를 사용하면 새 열거형이 추가되더라도 컴파일러가 이를 체크하지 않을 수 있다!**
+
+### 6.6.4 주의 사항: 다른 프로젝트의 열거형에 의존
+
+* 다른 프로젝트에서 열거형을 가지고 와서 사용할 수 있다.
+* 다른 프로젝트를 참조할 때, 그 프로젝트의 열거형이 변경될 수 있음을 기억하고 코드를 작성해야한다.