検索結果

🧭 はじめに このページでは、「動くけれど説明できないコード」 が生まれる最大要因である 暗黙の前提（implicit assumptions） に焦点を当てます。 Python の Zen における Explicit is better than implicit は、可読性の話ではなく、 設計上の責任の所在をコードに刻めているかという問いです。 🎯 ねらい 「なぜこのコードは壊れやすいのか」を、暗黙知という観点で言語化する 「察しの共有」に依存しない、契約が読めるコードの基準を示す ❓ 問題の定義 暗黙...

🧭 はじめに このページでは、Python の Zen Flat is better than nested に反する代表的アンチパターン 「ネスト地獄」 を扱います。 ネスト地獄は単なる「見た目の悪さ」ではありません。 処理の主筋が視覚的に失われ、理解・修正・検証のコストが指数関数的に増える という、構造的な欠陥です。 🎯 ねらい ネストが深くなるほど、認知負荷が爆発する理由を説明する 「平坦化」は好みではなく、設計上の安全策であることを示す ❓ 問題の定義 ネスト地獄とは、 if / for / tr...

🧭 はじめに このページでは、Python の Zen Errors should never pass silently に真正面から反するアンチパターン、 「例外の黙殺」 を扱います。 例外の黙殺は「とりあえず落ちないようにする」ための小細工に見えますが、 実際には バグを不可逆に埋め込み、後工程で爆発させる設計ミスです。 🎯 ねらい except: pass がなぜ危険なのかを構造的に説明する 「無視する例外」と「握りつぶしているだけの例外」を区別する ❓ 問題の定義 例外の黙殺とは、 例外が発生し...

🧭 はじめに このページでは、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