gon｜エンジニア／テクノスタンダード代表

d.get('a', load()) と書くと、キー 'a' があっても load() が毎回呼ばれました。 手元の検証(Python 3.13.18)で、キーがある辞書に対して3回 get を呼ぶと、load() も3回実行されました。get の第2引数は呼ぶ前に評価されるためです。重い処理や外部アクセスを書くと、使わない値のために毎回走ります。 捨てた案は「第2引数に関数呼び出しを置いて様子を見る」で、辞書にキーがあるときも無駄に実行されるのでやめました。採用は、d['a'] if 'a' in d else load() です。呼び出しは0回でした。 #Python #辞書 #バグ予防

for x in xs: で偶数を xs.remove(x) したら、偶数が1つ残りました。 手元の検証(Python 3.13.18)で、[1,2,2,3,4] を走査しながら偶数を remove すると結果は [1,2,3] でした。remove で後ろの要素が前に詰まり、走査が次の2をひとつ飛ばしたためです。 捨てた案は「走査中に remove して様子を見る」で、結果が入力の並びで変わるのが怖くてやめました。 採用は、[y for y in ys if y % 2] で新しいリストを作る形です。元のリストを壊さないのが理由です。 #Python #リスト #バックエンド

defaultdict(list) で存在確認のつもりで d['x'] を読んだだけなのに、キーが増えました。 手元の検証(Python 3.13)では、空の defaultdict に d['x'] を1回読むと len(d) が0から1になり、'x' in d も False から True に変わりました。 d.get('x') なら len は0のままで None が返りました。読むだけの場所には get を使う案にします。参照のたびにキーが増えると、件数の集計や存在確認の結果がずれるためです。 #Python #バグ予防 #バックエンド

2つのリストを zip でまとめたら、片方が1件短いだけで最後のIDが黙って消えました。手元の検証(Python 3.13)では、3件のIDと2件の名前を zip すると結果は2件で、エラーも警告も出ませんでした。zip(ids, names, strict=True) にすると ValueError: zip() argument 2 is shorter than argument 1 で止まりました。strict は Python 3.10 からの引数で、古い環境では使えないため、その場合は長さを先に比べる案になります。件数のズレを黙って通すより、止まってくれるほうが原因を追いやすいと感じました。 #Python #バグ予防 #コードレビュー

datetime.now() と datetime.now(timezone.utc) を比べると、TypeError: can't compare offset-naive and offset-aware datetimes で止まりました。 手元の検証(Python 3.13)では、tzinfo のない値と付いた値は、比較も引き算も同じ TypeError でした。どちらも timezone.utc を付けた値にそろえると比較できました。 tzinfo のない値は、どのタイムゾーンの時刻か読み取れないので、黙って比べてしまう案は採りません。 #Python #datetime #バグ予防

[[0]*3]*3 で 3x3 の表を作って g[0][0] = 1 とすると、1行目だけでなく3行すべての先頭が 1 になりました。 手元の検証(Python 3.13)では、3つの行は同じリストオブジェクトを指していて、id を調べると種類は1つだけでした。 [[0]*3 for _ in range(3)] に変えると、書き換わるのは1行目だけでした。入れ子のリストに * を使う案は、行が共有される理由が読み取りにくいので採りません。 #Python #バグ予防 #コードレビュー

'happy.py'.rstrip('.py') が 'happy' ではなく 'ha' を返しました。 手元の検証(Python 3.13)では、rstrip の引数は接尾辞ではなく文字の集合として扱われ、'.' 'p' 'y' のどれかが末尾に続く限り削られました。 拡張子を外したいときは、3.9以降なら removesuffix('.py') を使うと、'happy.py' から 'happy' が得られました。 #Python #バグ予防 #バックエンド

def add(x, acc=[]) を3回呼ぶと、毎回新しいリストが返りそうに見えて、3回とも同じリストでした。 手元の検証(Python 3.13)では、デフォルト値は関数定義時に1度だけ作られ、呼び出し後の add.__defaults__ は ([1, 2, 3],) に書き換わっていました。 acc=None にして関数内で [] を作る形に変えると、結果は [1] [2] [3] になりました。空リストをデフォルト値のまま使う案は、共有される理由が読み取りにくいので採りません。 #Python #バックエンド #コードレビュー

json.dumps のデフォルトだと、ログの日本語が \u6771\u4eac のようにエスケープされて出力され、grep で探せません。 手元の検証(Python 3.13)では、ensure_ascii=False にすると、このサンプル(日本語の短い辞書)は138バイトから81バイトになりました。loads した結果は両方とも同一でした。 ただし、ログ基盤が UTF-8 前提でない場合は True のほうが安全なので、基盤の文字コードを確認してから切り替えます。 #Python #ログ設計 #バックエンド

Pythonで round(2.5) が 3 ではなく 2 になりました。 手元の検証(Python 3.13)では、round(0.5)、round(1.5)、round(2.5)、round(3.5) は 0, 2, 2, 4 を返し、組み込みの round は偶数丸め(銀行丸め)でした。 round(2.675, 2) も、浮動小数点の表現誤差で 2.68 ではなく 2.67 です。 金額計算で四捨五入が必要なら、Decimal と ROUND_HALF_UP を使うと 2.68 が返りました。 #Python #プログラミング #バグ

SQLiteで WHERE id NOT IN (SELECT a_id FROM b) が0件になりました。 手元の検証(SQLite 3.53.1)では、サブクエリ側の a_id に NULL が1行混ざっているだけで、NOT IN は条件が真にならず、本来残るはずの行も全て消えます。 NOT EXISTS に書き換えるか、サブクエリに WHERE a_id IS NOT NULL を足すと、期待どおり2件が返りました。 NULLを許す列に対する NOT IN は、結果が変わっても気づきにくいので注意しています。 #SQLite #SQL #データベース

障害の振り返りでは、原因の説明より先に「発生から気づくまでにかかった時間」を書くようにしています。 原因が分かっても、気づくのが遅ければ被害は広がります。検知までの時間を先に見ると、直すべきなのが修正なのか監視なのかが分かれやすくなります。 #システム開発 #障害対応 #振り返り

機能の検討では、採用した案だけでなく「やらないと決めたこと」も理由と一緒に残すようにしています。 数か月後に同じ提案が出たとき、経緯を調べ直す時間が省けます。判断の記録は、決めた内容より外した内容のほうが後で役に立つことが多いです。 #システム開発 #設計 #ドキュメント

見積もりを出すときに、作業時間とは別に「確認待ちの時間」も書くようにしました。 開発自体は予定どおり進んでも、仕様確認の返事待ちで日程がずれることが多いためです。待ち時間を先に見せておくと、相手との認識合わせもしやすくなります。 #システム開発 #見積もり #プロジェクト管理

仕様書のレビューでは、書かれていることより「書かれていないこと」を探すようにしています。 例外時の挙動や上限値など、抜けている項目は実装中に見つかるほど修正が高くつきます。着手前に空白を探す時間を取るだけで、手戻りが減ります。 #仕様レビュー #システム開発 #要件定義

コードレビューのコメントに、指摘の理由を一文添えるようにしました。 「ここを直してください」だけだと意図が伝わらず、修正の往復が増えがちです。理由が書いてあれば相手が自分で判断でき、レビューが短く済みます。 #コードレビュー #システム開発 #チーム開発

障害対応のあとの振り返りに、原因だけでなく「なぜ気づくのが遅れたか」も書き残すようにしました。 再発防止は原因の修正で終わりがちですが、検知の遅れを直すほうが次の被害を小さくできます。項目を1つ足すだけで始められます。 #障害対応 #システム開発 #運用改善

受け入れ条件を、実装に入る前に文章で書いてもらうようにしてから、手戻りが減りました。 「何ができたら完了か」を先に揃えると、開発側と依頼側で完成の認識がずれにくいです。書く量は少なくて構わず、3行でも効果がありました。 #受け入れ条件 #システム開発 #開発

管理ツールを使う人にヒアリングしたとき、最初に聞いた要望と、本当に困っていることが違っていたことがありました。 言われた機能をそのまま作るより、作業を横で見せてもらうほうが、小さな改修で効く場所が見つかった気がします。 #要件定義 #エンジニア #開発

今度の日曜、両国の屋上でエンジニア交流会（BBQ）を開きます。 技術の話もキャリアの話も、テーマは自由。おいしいものを食べながら、気軽に話せる場にしたいと思っています。 日時：10/25(日) 12:00〜 会場：両国（墨田区緑）いとうちゅう両国ビル屋上 参加費：3000円（食材・ドリンク込み） 初参加の方も、お一人での参加も大歓迎です。 peatix.com/event/5162428 #交流会 #エンジニア #BBQ