Skip to content

Commit

Permalink
docs: translate for japanese
Browse files Browse the repository at this point in the history
  • Loading branch information
@kaehehehe
kaehehehe committed Jan 17, 2025
1 parent cc371c5 commit 0563619
Show file tree
Hide file tree
Showing 20 changed files with 297 additions and 278 deletions.
42 changes: 21 additions & 21 deletions .vitepress/ja.mts
View file
Original file line number Diff line number Diff line change
Expand Up @@ -71,15 +71,15 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "はじめる",
link: "/code/start"
link: "/ja/code/start"
},
{
text: "変更しやすいコード",
link: "/code"
link: "/ja/code/"
},
{
text: "貢献する",
link: "/code/contributing"
link: "/ja/code/contributing"
}
]
},
Expand All @@ -94,15 +94,15 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "A. 一緒に実行されないコードを分離する",
link: "/code/examples/submit-button"
link: "/ja/code/examples/submit-button"
},
{
text: "B. 実装の詳細を抽象化する",
link: "/code/examples/login-start-page"
link: "/ja/code/examples/login-start-page"
},
{
text: "C. ロジックの種類に応じて一体化している関数を分ける",
link: "/code/examples/use-page-state-readability"
link: "/ja/code/examples/use-page-state-readability"
}
],
collapsed: true
Expand All @@ -112,11 +112,11 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "A. 複雑な条件に名前を付ける",
link: "/code/examples/condition-name"
link: "/ja/code/examples/condition-name"
},
{
text: "B. マジックナンバーに名前を付ける",
link: "/code/examples/magic-number-readability"
link: "/ja/code/examples/magic-number-readability"
}
],
collapsed: true
Expand All @@ -126,11 +126,11 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "A. 視点の移動を減らす",
link: "/code/examples/user-policy"
link: "/ja/code/examples/user-policy"
},
{
text: "B. 三項演算子をシンプルにする",
link: "/code/examples/ternary-operator"
link: "/ja/code/examples/ternary-operator"
}
],
collapsed: true
Expand All @@ -143,32 +143,32 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "A. 名前が被らないように管理する",
link: "/code/examples/http"
link: "/ja/code/examples/http"
},
{
text: "B. 同じ種類の関数は返り値の型を統一する",
link: "/code/examples/use-user"
link: "/ja/code/examples/use-user"
},
{
text: "C. 隠れたロジックを露呈させる",
link: "/code/examples/hidden-logic"
link: "/ja/code/examples/hidden-logic"
}
]
},
{
text: "3. 結合度",
text: "3. 凝集度",
items: [
{
text: "A. 緒に修正されるファイルは同じディレクトリに置く",
link: "/code/examples/code-directory"
link: "/ja/code/examples/code-directory"
},
{
text: "B. マジックナンバーを排除する",
link: "/code/examples/magic-number-cohesion"
link: "/ja/code/examples/magic-number-cohesion"
},
{
text: "C. フォームの結合度について考える",
link: "/code/examples/form-fields"
text: "C. フォームの凝集度について考える",
link: "/ja/code/examples/form-fields"
}
]
},
Expand All @@ -177,15 +177,15 @@ function sidebar(): DefaultTheme.Sidebar {
items: [
{
text: "A. 責任を一つずつ管理する",
link: "/code/examples/use-page-state-coupling"
link: "/ja/code/examples/use-page-state-coupling"
},
{
text: "B. 重複コードを許容する",
link: "/code/examples/use-bottom-sheet"
link: "/ja/code/examples/use-bottom-sheet"
},
{
text: "C. Props Drilling を解消する",
link: "/code/examples/item-edit-modal"
link: "/ja/code/examples/item-edit-modal"
}
]
}
Expand Down
3 changes: 1 addition & 2 deletions ja/code/examples/code-directory.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# 一緒に修正されるファイルは同じディレクトリに置く

<div style="margin-top: 16px">
<Badge type="info" text="응집도" />
<Badge type="info" text="凝集度" />
</div>

プロジェクトでコードを作成していると、Hook、コンポーネント、ユーティリティ関数などを複数のファイルに分けて管理することになります。こうしたファイルを簡単に作成、検索、削除できるように、適切なディレクトリ構造を確立することが重要です。
Expand Down Expand Up @@ -35,7 +35,6 @@

## ✏️ リファクタリングしてみる

다음은 함께 수정되는 코드 파일끼리 하나의 디렉토리를 이루도록 구조를 개선한 예시예요.
次のコードは、関連して修正されるコードファイルを一つのディレクトリにまとめるように構造を改善した例です。

```text
Expand Down
4 changes: 2 additions & 2 deletions ja/code/examples/condition-name.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# 複雑な条件に名前を付ける

<div style="margin-top: 16px">
<Badge type="info" text="가독성" />
<Badge type="info" text="可読性" />
</div>

複雑な条件式が何の名前もなく使用されると、その条件が意味することを一目で把握するのが難しくなります。
Expand Down Expand Up @@ -30,7 +30,7 @@ const result = products.filter((product) =>

[^1]: [プログラマー脳](https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E8%84%B3-%EF%BD%9E%E5%84%AA%E3%82%8C%E3%81%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%AA%8D%E7%9F%A5%E7%A7%91%E5%AD%A6%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC%E3%83%81-Felienne-Hermans/dp/4798068535)によると、人間の脳が一度に保存できる情報の数は 6 個だそうです。

## ✏️ リファクタリングしてみる
### ✏️ リファクタリングしてみる

次のコードのように条件に明示的な名前を付けると、コードを読む人が一度に考慮しなければならないコンテキストを減らすことができます。

Expand Down
74 changes: 36 additions & 38 deletions ja/code/examples/form-fields.md
View file
Original file line number Diff line number Diff line change
@@ -1,17 +1,16 @@
# 폼의 응집도 생각하기

# フォームの凝集度について考える
<div style="margin-top: 16px">
<Badge type="info" text="응집도" />
<Badge type="info" text="凝集度" />
</div>

프론트엔드 개발을 하다 보면 Form으로 사용자에게 값을 입력받아야 하는 경우가 많아요.
Form을 관리할 때는 2가지의 방법으로 응집도를 관리해서, 함께 수정되어야 할 코드가 함께 수정되도록 할 수 있어요.
フロントエンド開発をしていると、ユーザーから値を入力してもらうためにフォームを使用することがよくあります。
フォームを管理する際には、2つの方法で凝集度を保ち、一緒に修正すべきコードが同時に修正されるようにすることができます。

## 필드 단위 응집도
## フィールド単位の凝集度

필드 단위 응집은 개별 입력 요소를 독립적으로 관리하는 방식이에요.
각 필드가 고유의 검증 로직을 가지므로 변경이 필요한 범위가 줄어들어 특정 필드의 유지보수가 쉬워져요.
필드 단위의 응집도를 고려하여 설계하면, 각 필드의 검증 로직이 독립적이어서 다른 필드에 영향을 주지 않아요.
フィールド単位の凝集度は、個別の入力要素を独立して管理する方法です。
各フィールドが独自の検証ロジックを持つため、変更が必要な範囲が縮小され、特定のフィールドのメンテナンスが容易になります。
フィールド単位の凝集度を考慮して設計すると、各フィールドの検証ロジックが独立しているため、他のフィールドに影響を与えることがありません。

```tsx
import { useForm } from "react-hook-form";
Expand All @@ -29,7 +28,7 @@ export function Form() {
});

const onSubmit = handleSubmit((formData) => {
// 폼 데이터 제출 로직
// フォームデータを送信するロジック
console.log("Form submitted:", formData);
});

Expand All @@ -39,9 +38,9 @@ export function Form() {
<input
{...register("name", {
validate: (value) =>
isEmptyStringOrNil(value) ? "이름을 입력해주세요." : ""
isEmptyStringOrNil(value) ? "名前を入力してください。" : ""
})}
placeholder="이름"
placeholder="名前"
/>
{errors.name && <p>{errors.name.message}</p>}
</div>
Expand All @@ -51,22 +50,22 @@ export function Form() {
{...register("email", {
validate: (value) => {
if (isEmptyStringOrNil(value)) {
return "이메일을 입력해주세요.";
return "メールアドレスを入力してください。";
}

if (!/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$/i.test(value)) {
return "유효한 이메일 주소를 입력해주세요.";
return "正しいメールアドレスを入力してください。";
}

return "";
}
})}
placeholder="이메일"
placeholder="メールアドレス"
/>
{errors.email && <p>{errors.email.message}</p>}
</div>

<button type="submit">제출</button>
<button type="submit">送信</button>
</form>
);
}
Expand All @@ -82,23 +81,23 @@ function isEmptyStringOrNil(value: NullableString): boolean {
}
```

## 폼 전체 단위 응집도
## フォーム全体の凝集度

폼 전체 응집은 모든 필드의 검증 로직이 폼에 종속되는 방식이에요. 폼 전체에서의 흐름을 고려하여 설계되며, 변경 단위가 폼 단위로 발생할 때 고려해요.
フォーム全体の凝集度とは、すべてのフィールドの検証ロジックがフォームに依存する設計のことです。この設計は、フォーム全体の流れを考慮して行われ、変更がフォーム単位で発生する場合に特に重要です。

폼 전체 응집도를 높이면, 폼 전체의 검증이 한 곳에서 관리되어 로직이 간결해지고, 상태가 중앙 집중식으로 관리되므로 폼 전체 흐름을 이해하기 쉬워져요. 필드 간의 결합도가 높아지므로 폼의 재사용성은 떨어질 수 있어요.
フォーム全体の凝集度を高めると、検証が一箇所で管理されるため、ロジックがシンプルになり、状態も中央で管理できるようになります。これにより、フォーム全体の流れを把握しやすくなります。しかし、フィールド間の結合度が高まるため、フォームの再利用性が下がる可能性もあります。

```tsx
import * as z from "zod";
import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";

const schema = z.object({
name: z.string().min(1, "이름을 입력해주세요."),
name: z.string().min(1, "名前を入力してください。"),
email: z
.string()
.min(1, "이메일을 입력해주세요.")
.email("유효한 이메일 주소를 입력해주세요")
.min(1, "メールアドレスを入力してください。")
.email("正しいメールアドレスを入力してください。")
});

export function Form() {
Expand All @@ -115,42 +114,41 @@ export function Form() {
});

const onSubmit = handleSubmit((formData) => {
// 폼 데이터 제출 로직
// フォームデータを送信するロジック
console.log("Form submitted:", formData);
});

return (
<form onSubmit={onSubmit}>
<div>
<input {...register("name")} placeholder="이름" />
<input {...register("name")} placeholder="名前" />
{errors.name && <p>{errors.name.message}</p>}
</div>

<div>
<input {...register("email")} placeholder="이메일" />
<input {...register("email")} placeholder="メールアドレス" />
{errors.email && <p>{errors.email.message}</p>}
</div>

<button type="submit">제출</button>
<button type="submit">送信</button>
</form>
);
}
```

## 필드 단위 vs. 폼 전체 단위 응집도

응집도를 높이려면 필드 단위와 폼 전체 단위 중 상황에 적합한 방식을 선택해야 해요.
필드 단위로 나누면 재사용성과 독립성이 높아지지만, 폼 전체 단위로 관리하면 일관된 흐름을 유지할 수 있어요.
## フィールド単位 vs. フォーム全体の凝集度

변경의 단위가 필드 단위인지 폼 전체 단위인지에 따라 설계를 조정해야 해요.
凝集度を高めるためには、フィールド単位とフォーム全体単位のどちらが状況に適しているかを選ぶことが大切です。
フィールド単位で分けると再利用性と独立性が高まりますが、フォーム全体単位で管理することで一貫した流れを保つことができます。

### 필드 단위 응집도를 선택하면 좋을 때
変更単位がフィールド単位かフォーム全体単位かによって、設計を調整する必要があります。

- **독립적인 검증이 필요할 때**: 필드별로 복잡한 검증 로직이 필요하거나 비동기 검증이 필요한 경우예요. 이메일 형식 검사, 전화번호 유효성 검증, 아이디 중복 확인, 추천 코드 유효성 확인처럼 각 필드가 독립적이고 고유한 검증이 필요할 때 유용해요.
- **재사용이 필요할 때**: 필드와 검증 로직이 다른 폼에서도 동일하게 사용될 수 있는 경우예요. 공통 입력 필드들을 독립적으로 관리하고 재사용하고 싶을 때 좋아요.
### フィールド単位の凝集度を選ぶべき時

### 폼 전체 단위 응집도를 선택하면 좋을 때
- **独立した検証が必要な場合**: フィールドごとに複雑な検証ロジックや非同期検証が必要な場合に適しています。メールアドレスの形式チェックや電話番号の有効性確認、IDの重複チェック、推薦コードの有効性確認など、各フィールドが独立してそれぞれの検証を行う必要があるときに便利です。
- **再利用が必要な場合**: フィールドと検証ロジックが他のフォームでも同様に使用できる場合です。共通の入力フィールドを独立して管理し、再利用したいときに便利です。
### フォーム全体単位の凝集度を選ぶべき時

- **단일 기능을 나타낼 때**: 모든 필드가 밀접하게 관련되어 하나의 완결된 기능을 구성하는 경우예요. 결제 정보나 배송 정보처럼 모든 필드가 하나의 비즈니스 로직을 이룰 때 유용해요.
- **단계별 입력이 필요할 때**: Wizard Form과 같이 스텝별로 동작하는 복잡한 폼의 경우예요. 회원가입이나 설문조사처럼 이전 단계의 입력값이 다음 단계에 영향을 주는 경우에 적합해요.
- **필드 간 의존성이 있을 때**: 여러 필드가 서로를 참조하거나 영향을 주는 경우예요. 비밀번호 확인이나 총액 계산처럼 필드 간 상호작용이 필요할 때 좋아요.
- **単一機能を示す場合**: すべてのフィールドが密接に関連して、ひとつの完結した機能を構成する時に有用です。決済情報や配送情報のように、すべてのフィールドが一つのビジネスロジックを形成する場合に適しています。
- **段階的な入力が必要な場合**: ウィザードフォームのように、ステップごとに動作する複雑なフォームに適しています。会員登録やアンケートのように、前のステップの入力が次のステップに影響を与える場合に適しています。
- **フィールド間の依存性がある場合**: 複数のフィールドが互いに参照したり影響を与えたりする場合に適しています。パスワード確認や合計計算のように、フィールド間の相互作用が必要な場合に便利です。
26 changes: 13 additions & 13 deletions ja/code/examples/hidden-logic.md
View file
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
# 숨은 로직 드러내기
# 隠れたロジックを露呈させる

<div style="margin-top: 16px">
<Badge type="info" text="예측 가능성" />
<Badge type="info" text="予測可能性" />
</div>

함수나 컴포넌트의 이름, 파라미터, 반환 값에 드러나지 않는 숨은 로직이 있다면, 함께 협업하는 동료들이 동작을 예측하는 데에 어려움을 겪을 수 있어요.
関数やコンポーネントの名前、パラメータ、返り値に明示されていない隠れたロジックがある場合、一緒に開発をしているチームメンバーがその挙動を予測するのが困難になる可能性があります。

## 📝 코드 예시
## 📝 コード例

다음 코드는 사용자의 계좌 잔액을 조회할 때 사용할 수 있는 `fetchBalance` 함수예요. 함수를 호출할 때마다 암시적으로 `balance_fetched`라는 로깅이 이루어지고 있어요.
次のコードは、ユーザーの口座残高を照会する際に使用できる`fetchBalance`関数です。この関数を呼び出すたびに、暗黙的に `balance_fetched`というロギングが行われています。

```typescript 4
async function fetchBalance(): Promise<number> {
Expand All @@ -20,17 +20,17 @@ async function fetchBalance(): Promise<number> {
}
```

## 👃 코드 냄새 맡아보기
## 👃 コードの不吉な臭いを嗅いでみる

### 예측 가능성
### 予測可能性

`fetchBalance` 함수의 이름과 반환 타입만을 가지고는 `balance_fetched` 라는 로깅이 이루어지는지 알 수 없어요. 그래서 로깅을 원하지 않는 곳에서도 로깅이 이루어질 수 있어요.
`fetchBalance`関数の名前と返り値の型だけでは、`balance_fetched`というロギングが行われるかどうか分かりません。そのため、ロギングを望まない場所でもロギングが行われてしまう可能性があります。

또, 로깅 로직에 오류가 발생했을 때 갑자기 계좌 잔액을 가져오는 로직이 망가질 수도 있죠.
また、ロギングのロジックにエラーが発生した場合、突然口座残高を取得するロジックが壊れてしまう可能性もあるでしょう。

## ✏️ 개선해보기
## ✏️ リファクタリングしてみる

함수의 이름과 파라미터, 반환 타입으로 예측할 수 있는 로직만 구현 부분에 남기세요.
関数の名前、パラメータ、返り値の型から予測できるロジックだけを実装部分に残してください。

```typescript
async function fetchBalance(): Promise<number> {
Expand All @@ -40,7 +40,7 @@ async function fetchBalance(): Promise<number> {
}
```

로깅을 하는 코드는 별도로 분리하세요.
そして、ロギングを行うコードは別に分離してください。

```tsx
<Button
Expand All @@ -51,6 +51,6 @@ async function fetchBalance(): Promise<number> {
await syncBalance(balance);
}}
>
계좌 잔액 갱신하기
口座残高を更新する
</Button>
```
Loading

0 comments on commit 0563619

Please sign in to comment.