Python樹林– category –

Djangoでデータベーススキーマを設計する際、主キーやユニークな識別子（ID、コード）の定義方法は、システムの将来的な保守性に大きな影響を与えます。 その中で、「有意コード（Intelligent Code / Smart Code）」と呼ばれる設計手法を採用してしまうケ...

DjangoでWebアプリケーションを開発する際、似て非なる複数のデータを一つのモデルで管理しようとして、安易にtypeというカラムを追加してしまうことがあります。これは「種類」や「カテゴリ」を整数や文字列で区別するためのカラムで、一見すると便利に思...

Webアプリケーションを開発する際、データの「削除」は避けて通れない機能の一つです。特にDjangoのようなフレームワークを使用していると、instance.delete()メソッドで簡単にデータを削除できます。 しかし、この「削除」には、データベースからレコード...

Pythonを使ってPCのシャットダウンのようなOS操作を自動化したい、と考えたことはありませんか。さらに、そのPythonスクリプトを、ダブルクリックするだけで簡単に実行できる「バッチファイル（.bat）」から呼び出せたら便利です。 この記事では、Pythonで...

C#を用いた開発プロジェクトにおいて、Pythonが持つ豊富なライブラリ（例えば、機械学習のTensorFlowやPyTorch、データ分析のNumPyやPandasなど）を活用したい場面が出てくることがあります。その際、C#のプログラムから直接Pythonスクリプト（.pyファイル...

Pythonを使ったWebスクレイピングで非常に人気のあるライブラリ「Beautiful Soup」ですが、学習を進めるうちに「これでボタンクリックやフォーム入力はできないのか？」という疑問を持つことがあります。 結論から申し上げますと、Beautiful Soup単体では...

Webブラウザ操作を自動化するツールSeleniumは、テスト自動化や定型作業の効率化に非常に強力です。しかし、実際のWebページ、特に社内システムなどは、単純なクリックや入力だけでは操作できない複雑な構造を持っていることが少なくありません。 今回は、...

Djangoでモデルを設計する際、「タスクが完了したか（is_completed）」、「ユーザーが有効か（is_active）」といった状態を示すために、BooleanField（ブール値フラグ）を追加するのは、直感的で簡単な方法です。 しかし、この一見シンプルなアプローチは...

古いデータベース設計の慣習、あるいは将来の仕様変更への「備え」のつもりで、spare_1やextra_text_01といった、今は使わない**「予備カラム」**をDjangoのモデル定義に含めてしまっていませんか？ かつては、データベースのスキーマ変更（ALTER TABLEの...

Djangoアプリケーションが成長するにつれて、ProductやArticleのような中心的なモデルに、次々と新しいフィールドが追加されていくのはよくあることです。初めは小さなモデルだったものが、いつしか数十個のカラムを持つ「太ったモデル（Fat Model）」にな...

アプリケーションのデータが信頼できるものであるためには、データベースに「あってはならないデータ」が保存されるのを防ぐ仕組みが不可欠です。例えば、「一人のユーザーが、同じイベントに2回登録できてしまう」「同じ生徒が、同じ科目を2回履修できて...

Djangoでモデルを設計する際、null=True, blank=Trueというオプションは、「このフィールドは必須ではない」ことを示す便利な指定のように思えます。しかし、データベースレベルでNULLを許容することは、多くの場合、アプリケーションロジックを不必要に複...

ある機能追加のプルリクエスト（PR）を開いたら、ロジックの変更だけでなく、全く関係のないファイルのリファクタリングや、コードフォーマッターによる大量のスタイル修正まで含まれていて、レビューにうんざりした経験はありませんか？ このような、複数...

コードレビューは、コードの品質を担保し、チームの知識を共有するための重要なプロセスです。しかし、タイトルだけが書かれた説明不足のプルリクエスト（PR）が送られてきて、「この変更の背景は何だろう？」「どこを重点的に見ればいいんだ？」と、レビ...

機能開発に集中していると、気分が乗ってきて、つい「これもあった方が便利だろう」「将来的に必要になるはずだ」と、当初の要件にはなかった機能や、過度に汎用的な実装まで盛り込んでしまった経験はありませんか？ このような「親切心」からくる「作りす...

大規模な機能開発では、コードを書き進めてから設計上の問題に気づき、大幅な手戻りが発生することがあります。「このクラス設計、もっと良い方法があったな…」「この関数の責務が曖昧だった…」といった後悔は、多くの開発者が経験する痛みです。 もし、本...

数日、あるいは一週間かけて新機能を実装し、満を持して数百行のコード変更を含むプルリクエスト（PR）を作成したとします。しかし、レビュー担当者から返ってきたのは、「設計の根本的な部分から、アプローチを再検討していただけませんか？」というコメ...

「ユーザーが外部SNSに投稿できる機能を実装する」 このような、一見シンプルに見える機能でも、いざ着手しようとすると、OAuth認証、APIキーの管理、トークンのデータベース保存、非同期処理など、考慮すべき事項が雪崩のように押し寄せ、どこから手をつ...

新しいライブラリやフレームワークを使い始める時、私たちの多くはまずGoogleで「(ライブラリ名) 使い方」と検索し、個人ブログやQ&Aサイトの記事に飛びつきます。確かに、目の前の問題を解決する一番の近道に見えるかもしれません。 しかし、その場し...

「テストカバレッジ100%」という指標は、多くのプロジェクトで品質の一つの目標として掲げられます。すべてのコード行がテストで実行されたことを示すこの指標は、確かにテストが不足している箇所を見つけるのに役立ちます。しかし、カバレッジ100%が「バ...

「モック（Mock）」は、テストを外部APIやデータベースといった、我々がコントロールできない要素から隔離するための非常に強力なツールです。しかし、その強力さゆえに、本来モックすべきでないものまでモック化してしまう**「過剰なモック（Excessive Mo...

factory-boyのようなツールを使うと、テストデータの準備は非常に簡単になります。しかし、強力なツールを手にしたからといって、無計画にデータを作成してはなりません。テストの品質は、そのテストが**「何を検証しようとしているのか」**がどれだけ明確...

関数が返すリストの内容をテストする際、特定の要素が含まれているかを確認するアサーションを書くのは自然なことです。しかし、リストに含まれる要素の「総数」を確認するアサーションを忘れてはいないでしょうか？ この一見些細な確認を怠ると、予期せぬ...

「昨日までパスしていたテストが、今日は何もコードを変えていないのになぜか失敗する…」 このような経験は、多くの開発者にとって悪夢です。この不可解な現象の最も一般的な原因の一つが、テストケースが互いに独立しておらず、特定の実行順序に依存して...

アプリケーションのコードには、「フォロワーが1万人を超えたらボーナス」「スコアが100点を下回ったら警告」のように、特定の数値（しきい値）を条件分岐に使うロジックが頻繁に登場します。では、このようなロジックをテストする際、私たちは本当に1万1...

テストコードを書いていると、「このリスト、他のテストでも使うから共通化しよう」と考え、共有のファイルや関数にテストデータを切り出したくなることがあります。コードのDRY（Don't Repeat Yourself）原則に従っているようで、一見すると良いプラクテ...

優れたユニットテストの条件の一つに、「準備（Arrange）が簡潔であること」が挙げられます。しかし、データベースに依存するアプリケーションのテストを書いていると、テストの本体よりも、テストに必要なモデルインスタンスを準備するコードの方が長くな...

優れた自動テストとは、コードの正しさを検証するだけでなく、何度実行しても必ず同じ結果になる**「再現性」と、他のテストに一切影響を与えない「独立性」を兼ね備えています。この性質を担保するために絶対不可欠なのが、テスト中に作成したファイルや...

現代のアプリケーション開発において、外部のWeb API（例: 決済サービス、気象情報、SNS投稿）と連携する機能は不可欠です。しかし、このような外部サービスと通信するコードの自動テストを書こうとすると、多くの開発者が頭を悩ませます。「テストを実行...

「この関数のテストコード、どう書けばいいんだ…？」 開発中にそう頭を抱えた経験はありませんか？多くの場合、その原因はテストの書き方の問題ではなく、テスト対象のコードの設計そのものにあります。 「テストのしにくさ」は、コードが抱える設計上の問...