タスクのためだけでなく、スケール、読みやすさ、チームワークを念頭に置いてコードを書くときは、すでにミドルレベルに近づいています。この記事では、初心者のコードと成熟したプロジェクトのアプローチを区別する 5 つの重要な原則を分析します。
🛠 1. プロジェクトの構造：意味を分割する
悪いプロジェクト これは、コンポーネント、ユーティリティ、スタイル、テストなど、すべてが1つのフォルダにある場合です。
ミドルアプローチ — これは考え抜かれたアーキテクチャです。
src/components— 再利用可能なコンポーネントsrc/pages— ページsrc/utils— ヘルパー関数src/styles— グローバルスタイルsrc/services— API の操作
💬 2. コード内のドキュメント
良いコードは自らを説明しますが、コメントが不要であることを意味するものではありません。それらは必要です。 しかし、明白ではない、説明：
❌ // カウンターを増やす
✅ // UIに新しいユーザーアクションを反映させるためにカウンターを更新します
また、以下の点についても説明する必要があります。
非標準的なソリューションの動作
関数の入力/出力パラメータ
特にTSなしでJSを使用する場合のタイプ
📚 Midleは、少なくともベースに対してREADME.mdを作成することがよくあります。起動方法、構築方法、構成の場所など。
🧪 3. テストを追加する（簡単なものでも可）
テストなしでコードを書くことは、ブレーキなしで自転車に乗るようなものです。TDDから始める必要はありませんが、ミドルウェアの特徴は次のとおりです。
ビジネスロジックのユニットテスト
エッジケースのテスト
テスト可能性への意識的なアプローチ
// utils/calc.js
export function sum(a, b) {
return a + b;
}
// utils/calc.test.js
import { sum } from './calc';
test('Adds two numbers', () => {
expect(sum(2, 3)).toBe(5);
});
🧼 4. コードの明瞭さと統一されたスタイル
ミドルは、 効果のあるもの、しかし、 どのように見えるか.
📎 使用するもの：
リント（ESLint、Flake8、Pylint）
フォーマッター（Prettier、Black）
git pre-commit フック
命名規則
💡 KISSとDRYに従ってください。コードの一部を3回繰り返す場合は、それを取り出す時です。
🔁 5. ビジネスロジックとUIの分離
Middleは、ロジックとプレゼンテーションの区別を理解しています。簡単な例を挙げます。
// useTodoList.js
export const useTodoList = () => {
const [todos, setTodos] = useState([]);
useEffect(() => {
fetchTodos().then(setTodos);
}, []);
return todos;
};
// TodoList.jsx
const TodoList = ({ todos }) => (
<ul>{todos.map(todo => <li key={todo.id}>{todo.text}</li>)}</ul>
);
🚀 これらはすべて「ルール」ではなく、優れた開発者の習慣です
原則 | なぜ必要なのか |
|---|---|
明確な構造 | ナビゲーションとチームワークを簡素化 |
コメントとREADME | 何が起こっているのかをあなたや他の人が理解するのを助ける |
ユニットテスト | 変化に自信を持たせる |
リフターとフォーマッター | スタイルと読みやすさを維持する |
ロジックとUIの分離 | 再利用性とモジュール性を向上 |
このような習慣を実践したい場合は、アプリをご覧ください コディック. ここでは、実際のプロジェクト、自動チェックの課題、JavaScript、Python、TypeScriptのモジュール、さらにはアーキテクチャの実践まで見つけることができます。これらすべては、ステップバイステップの説明と Telegramのコミュニティサポート.
あなたは自分のプロジェクトにこれらの原則を適用していますか？それとも、フロントエンドのアーキテクチャやフォルダ構造についての記事が必要ですか？
コメントでお知らせください。一緒に解決しましょう💬