検索結果

🧭 はじめに このページでは、Python の Zen Refuse the temptation to guess に反するアンチパターン、 「推測に頼るコード」 を扱います。 Python は柔軟で表現力が高い言語ですが、その反面 「それっぽく書けてしまう」 ことが設計ミスを隠します。 本記事では、その曖昧さがどのように事故につながるかを整理します。 🎯 ねらい Python の truthy / falsy 文化が設計と衝突する瞬間を可視化する 「短い条件式」と「正しい仕様」は別物であることを示す ❓...

🧭 はじめに このページでは、「将来の拡張」を理由に今のコードを不必要に複雑化してしまうアンチパターンを整理する。Python の Zen がいう Simple is better than complex は、「雑に書け」という意味ではない。必要十分な構造に留めよという設計原則である。 🎯 ねらい まだ存在しない要件のために抽象レイヤを作ることのコストを可視化する 「拡張しやすさ」と「読みやすさ」の混同を解消する ❓ 問題の定義 将来起きるか分からない変更に備えて、抽象・DI・Factory・Strat...

🧭 はじめに このページでは、「同じことをするコードが、複数の流儀で書かれている」状態が、チーム開発において最も高コストになるという事実を整理する。 Python の Zen が言う There should be one— and preferably only one —obvious way to do it は、言語仕様の話ではない。設計と運用の話である。 🎯 ねらい 「自由に書けること」と「統一されていること」の違いを明確にする “個人最適” が “チーム最悪” になる構造を可視化する ❓ 問題の...

🧭 はじめに このページでは、import * に代表される名前空間の破壊を、単なるスタイル違反ではなく設計不良として整理する。 Python の Zen にある Namespaces are one honking great idea は、「衝突を避けよう」という小さな話ではない。意図をコードに刻めという強いメッセージである。 🎯 ねらい 「どこから来た名前か分からない」状態の危険性を言語化する import 設計を可読性・変更容易性の問題として捉え直す ❓ 問題の定義 名前の出所が曖昧で、コードを追...

🧭 はじめに このページでは、「短い・凝っている・トリッキー」なコードが必ずしも良いコードではないことを整理する。 Python の Zen が繰り返し強調する Readability counts と Beautiful is better than ugly は、好みの話ではない。保守性と生産性の話である。 🎯 ねらい “一行で書ける＝優秀” という誤解を正す 「読む速さ」を最適化するという設計視点を取り戻す ❓ 問題の定義 表現を詰め込みすぎて、理解に時間がかかる 書いた本人しか説明できないコードに...

🧭 はじめに（What） このページでは、Python におけるシングルトンの定石を整理する。 結論は明確で、Python ではシングルトンを「クラス」で作らない。 代わりに、モジュールそのものをシングルトンとして使うのが最も自然で、読みやすく、テストしやすい。 🎯 ねらい GoF 的な Singleton パターンを Python に持ち込む誤りを正す Python が本来備えている 「唯一性」の表現方法を理解する 過剰設計を避け、意図が一目で伝わる設計を身につける 🧱 問題の背景 Python でシング...

NIP

NIP

NIP

NIP

NIP

NIP

NIP

NIP

🧭 はじめに（What） このページでは、 functools.lru_cache(maxsize=1) を使って logging の「セットアップだけ」を一度に制御する設計パターン を解説する。 重要なのは、 logger を Singleton 化することではない。 副作用を伴う logging セットアップを「必要になった瞬間に、一度だけ」実行することが目的である。 🎯 ねらい logging 設定で起こりがちな 実行順序依存バグを防ぐ import と副作用を分離する logger 名（__name__...