fix: github name changed issue

hyunwook13 · hyunwook13 · commit a53377902395 · 2024-11-29T14:29:29.000+09:00
diff --git a/README.md b/README.md
@@ -18,7 +18,7 @@
     <a href="https://github.com/bayernmuller">@bayernmuller</a>
 </p>
 <p align="center">
-    <img src="https://github.com/hyunwok.png" width="100" height="100">
+    <img src="https://github.com/hyunwook13.png" width="100" height="100">
     <br>
-    <a href="https://github.com/hyunwok">@hyunwok</a>
+    <a href="https://github.com/hyunwook13">@hyunwook13</a>
 </p>
diff --git a/chapter1/1_3_코드_품질의_핵심_요소.mdx b/chapter1/1_3_코드_품질의_핵심_요소.mdx
@@ -1,6 +1,6 @@
 ---
 title: '코드는 어떻게 소프트웨어가 되는가'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 코딩 업무에 대해서가 아닌 근본적 성취에 대해서 이야기 했기에, 지금부터는 코딩 업무에 대한 조언을 제공한다.
diff --git a/chapter1/1_4_고품질_코드_작성은_일정을_지연시키는가.mdx b/chapter1/1_4_고품질_코드_작성은_일정을_지연시키는가.mdx
@@ -1,6 +1,6 @@
 ---
 title: '고품질 코드 작성은 일정을 지연시키는가'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 높은 품질의 코드를 작성하는 것은 보통 우리 머릿속에 떠오르는 것을 바로 코딩하는 것보다 조금 더 많은 생각과 노력이 필요하다.
diff --git a/chapter10/10_4_테스트_더블.mdx b/chapter10/10_4_테스트_더블.mdx
@@ -1,6 +1,6 @@
 ---
 title: '테스트 더블'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 코드의 모든 동작을 완벽하게 테스트하기 위해 종종 입력을 설정하고 Side Effect를 검증해야 하지만, 테스트에서 의존성을 실제로 사용하는 것이 항상 가능하거나 바람직한 것만은 아니다.
diff --git a/chapter10/10_5_테스트_철학으로부터_신중하게_선택하라.mdx b/chapter10/10_5_테스트_철학으로부터_신중하게_선택하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '테스트 철학으로부터 신중하게 선택하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - **테스트 주도 개발** : TDD는 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하는 것을 지지한다.
diff --git a/chapter11/11_1_기능뿐만_아니라_동작을_시험하라.mdx b/chapter11/11_1_기능뿐만_아니라_동작을_시험하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '기능뿐만 아니라 동작을 시험하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 ### 11.1.1 함수당 하나의 테스트 케이스만 있으면 적절하지 않을 때가 많다
diff --git a/chapter11/11_5_적절한_어서션_확인자를_사용하라.mdx b/chapter11/11_5_적절한_어서션_확인자를_사용하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '적절한 어서션 확인자를 사용하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 어서션 확인자는 보통 테스트 통과 여부를 최종적으로 결정하기 위한 테스트 케이스 내의 코드이다.
diff --git a/chapter11/11_6_테스트_용이성을_위해_의존성_주입을_사용하라.mdx b/chapter11/11_6_테스트_용이성을_위해_의존성_주입을_사용하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '테스트 용이성을 위해 의존성 주입을 사용하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 ### 11.6.1 하드 코딩된 의존성은 테스트를 불가능하게 할 수 있다
diff --git a/chapter11/11_7_테스트에_대한_몇_가지_결론.mdx b/chapter11/11_7_테스트에_대한_몇_가지_결론.mdx
@@ -1,6 +1,6 @@
 ---
 title: '테스트에 대한 몇 가지 결론'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 개발자로서 접하고 사용할 가능성이 큰 다른 두 가지 테스트 수준
diff --git a/chapter2/2_1_널값_및_의사코드_규약.mdx b/chapter2/2_1_널값_및_의사코드_규약.mdx
@@ -1,6 +1,6 @@
 ---
 title: '널값 및 의사코드 규약'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 많은 프로그래밍 언어에는 값이 없다는 개념을 표현하기 위해 null 값을 사용한다.
diff --git a/chapter2/2_2_왜_추상화_계층을_만드는가.mdx b/chapter2/2_2_왜_추상화_계층을_만드는가.mdx
@@ -1,6 +1,6 @@
 ---
 title: '왜 추상화 계층을 만드는가?'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 코드 작성은 복잡한 문제를 계속해서 더 작은 하위 문제로 세분화하는 작업이다.
diff --git a/chapter3/3_4_체크_및_어서션.mdx b/chapter3/3_4_체크_및_어서션.mdx
@@ -1,6 +1,6 @@
 ---
 title: '체크 및 어서션'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 컴파일러를 사용해 코드 계약을 확인하는 것에 대한 대안으로 런타임 검사를 사용할 수 있다.
diff --git a/chapter4/4_5_호출하는_쪽에서_복구하기를_원할_수도_있는_오류의_전달.mdx b/chapter4/4_5_호출하는_쪽에서_복구하기를_원할_수도_있는_오류의_전달.mdx
@@ -1,6 +1,6 @@
 ---
 title: '호출하는 쪽에서 복구하기를 원할 수도 있는 오류의 전달'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 여러가지 논쟁이 있는 흥미로운 주제에 대한 각각의 주장과 반론을 요약해보겠다.
diff --git a/chapter4/4_6_컴파일러_경고를_무시하지_말라.mdx b/chapter4/4_6_컴파일러_경고를_무시하지_말라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '컴파일러 경고를 무시하지 말라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 컴파일러 경고는 어떤 식으로든 코드가 의심스러우면 표시를 하는데, 이에 주의를 기울이면 코드베이스에 병합되기 훨씬 전에 오류를 발견하고 제거할 수 있다.
diff --git a/chapter5/5_1_서술형_명칭_사용.mdx b/chapter5/5_1_서술형_명칭_사용.mdx
@@ -1,6 +1,6 @@
 ---
 title: '서술형 명칭 사용'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 토스터를 보고 무언가를 굽는 기계라고 알 수 있는 것처럼, 코드 작성 시 이름이 클래스, 함수, 변수 등에도 동일하게 적용된다.
diff --git a/chapter5/5_2_주석문의_적절한_사용.mdx b/chapter5/5_2_주석문의_적절한_사용.mdx
@@ -1,6 +1,6 @@
 ---
 title: '서술형 명칭 사용'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 서술적인 이름으로 잘 작성된 코드는 그 자체로 설명이 잘 되지만, 그렇지 않은 경우 코드가 하는 일에 대해 이유나 배경을 설명하는 주석문은 유용하다.
diff --git a/chapter5/5_8_익명_함수를_적절하게_사용하라.mdx b/chapter5/5_8_익명_함수를_적절하게_사용하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '익명 함수를 적절하게 사용하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 익명 함수는 이름이 없는 함수이며, 일반적으로 코드 내의 필요한 지점에서 안라인으로 정의된다.
diff --git a/chapter5/5_9_프로그래밍_언어의_새로운_기능을_적절하게_사용하라.mdx b/chapter5/5_9_프로그래밍_언어의_새로운_기능을_적절하게_사용하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '프로그래밍 언어의 새로운 기능을 적절하게 사용하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 새로운 기능에 대해 써보고 싶을 때, 그 기능이 정말로 그 일에 가장 적합한 도구인지 솔직하게 생각해봐야 한다.
diff --git a/chapter6/6_1_매직값을_반환하지_말아야_한다.mdx b/chapter6/6_1_매직값을_반환하지_말아야_한다.mdx
@@ -1,6 +1,6 @@
 ---
 title: '매직값을 반환하지 말아야 한다'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 매직값의 일반적인 예는 값이 없거나 오류가 발생했음을 나타내기 위해 -1을 반환하는 것이다.
diff --git a/chapter6/6_2_널_객체_패턴을_적절히_사용하라.mdx b/chapter6/6_2_널_객체_패턴을_적절히_사용하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '널 객체 패턴을 적절히 사용하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 널 객체 패턴을 사용하는 이유는 널값을 반환하는 대신 유효한 값이 반환되어 그 이후에 실행되는 로직에서 널값을 인해 시스템에 의해 피해가 가지 않도록 하기 위함이다.
diff --git a/chapter6/6_7_이_모든_것을_테스트로_해결할_수는_없는가.mdx b/chapter6/6_7_이_모든_것을_테스트로_해결할_수는_없는가.mdx
@@ -1,6 +1,6 @@
 ---
 title: '이 모든 것을 테스트로 해결할 수는 없는가?'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 테스트가 모든 문제를 잡아낼 것이기 떄문에 코드 품질 향상 노력은 시간 낭비라는 주장을 하는 개발자들이 가끔 있다.
diff --git a/chapter7/7_1_불변_객체로_만드는_것을_고려하라.mdx b/chapter7/7_1_불변_객체로_만드는_것을_고려하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '불변 객체로 만드는 것을 고려하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 객체가 생성된 후에 상태를 바꿀 수 없다면 이 객체는 불변(불가변)이고, 그 반대는 가변이다.
diff --git a/chapter7/7_2_객체를_깊은_수준까지_불변적으로_만드는_것을_고려하라.mdx b/chapter7/7_2_객체를_깊은_수준까지_불변적으로_만드는_것을_고려하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '객체를 깊은 수준까지 불변적으로 만드는 것을 고려하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 클래스가 실수로 가변적으로 될 수 있는 일반적인 경우는 깊은 가변성 때문이다
diff --git a/chapter7/7_3_지나치게_일반적인_데이터_유형을_피하라.mdx b/chapter7/7_3_지나치게_일반적인_데이터_유형을_피하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '지나치게 일반적인 데이터 유형을 피하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 정수나 리스트와 같은 유형으로 표현이 '가능'하다고 해서 그것이 반드시 '좋은' 방법은 아니다.
diff --git a/chapter8/8_2_인터페이스에_의존하라.mdx b/chapter8/8_2_인터페이스에_의존하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '인터페이스에 의존하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 클래스 행동을 인터페이스로 만들고, 이에 의존한다면 어떤 구현 클래스라도 사용할 수 있으므로 코드가 훨씬 더 모듈화되고 적응성이 높아진다.
diff --git a/chapter8/8_3_클래스_상속을_주의하라.mdx b/chapter8/8_3_클래스_상속을_주의하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '클래스 상속을 주의하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 클래스 게층이 형성되는 예시
diff --git a/chapter8/8_4_클래스는_자신의_기능에만_집중해야_한다.mdx b/chapter8/8_4_클래스는_자신의_기능에만_집중해야_한다.mdx
@@ -1,6 +1,6 @@
 ---
 title: '클래스는 자신의 기능에만 집중해야 한다'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 모듈화의 핵심 목표 중 하나는 변경된 요구사항과 직접 관련된 코드만 수정하는 것
diff --git a/chapter8/8_5_관련_있는_데이터는_함께_캡슐화하라.mdx b/chapter8/8_5_관련_있는_데이터는_함께_캡슐화하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '관련 있는 데이터는 함께 캡슐화하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 클래스를 통해 여러 가지를 함께 묶을 수 있는데, 너무 많은 것들이 한 클래스 안에 있을 때 야기될 수 있는 문제점을 조심해야 한다는 것을 살펴봤지만, 합리적인 상황일 때는 이점을 놓치면 안 된다. 
diff --git a/chapter8/8_6_반환_유형에_구현_세부_정보가_유출되지_않도록_주의하라.mdx b/chapter8/8_6_반환_유형에_구현_세부_정보가_유출되지_않도록_주의하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '반환 유형에 구현 세부 정보가 유출되지 않도록 주의하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 간결한 추상화 계층을 가지려면 각 계층의 구현 세부 정보가 유출되지 않아야 하는데, 유출된다면 향후 수정이나 재설정이 매우 어려워질 수 있다.
diff --git a/chapter8/8_7_예외_처리_시_구현_세부_사항이_유출되지_않도록_주의하라.mdx b/chapter8/8_7_예외_처리_시_구현_세부_사항이_유출되지_않도록_주의하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '예외 처리 시 구현 세부 사항이 유출되지 않도록 주의하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 구현 세부 정보가 유출될 수 있는 일반적인 경우는 예외가 발생할 때이다.
diff --git a/chapter9/9_1_가정을_주의하라.mdx b/chapter9/9_1_가정을_주의하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '가정을 주의하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 - 코드 작성 시 가정을 하면 코드가 더 단순해지거나, 더 효율적으로 되거나, 둘 다 일수도 있다.
diff --git a/chapter9/9_2_전역_상태를_주의하라.mdx b/chapter9/9_2_전역_상태를_주의하라.mdx
@@ -1,6 +1,6 @@
 ---
 title: '전역 상태를 주의하라'
-author: 'hyunwok'
+author: 'hyunwook13'
 ---
 
 ### 9.2.1 전역 상태를 갖는 코드는 재사용하기에 안전하지 않을 수 있다
