saku

組込み20年エンジニア

実務で学んだ
「壊れにくいコードの考え方」
を中心にゆるく発信しています

Python・設計・実務あるある中心
noteも更新中

[saku @saku_python]

@ntones_net めちゃくちゃしんどいやつですね…😅
どこの現場でもそういうことが起きますよね。

しかも「触ったことない」状態だと、
「そこ関係あるの…」ってことが多々あります。

[saku @saku_python]

実務あるある

障害対応中
「とにかく直さないと…！」
　↓
修正完了✨
　↓
数日後
「別の機能が動かなくなりました」
　↓
😭

焦っている時ほど
不具合箇所しか見えなくなる。
影響範囲確認って大事です。

#エンジニア

[saku @saku_python]

@RG2642403640331 本当にそうですね。

背景が理解できるだけでも
ソースコードが急に
「そういうこと！！」と
腑に落ちることがあります。

デグレは信用に関わるので、
焦らず慎重に直すことが大事ですね。

[saku @saku_python]

@palepact_dev 「3日も経てば他人のコード」まさにその通りですね😅
これホントに自分が書いたっけと思うコードもあります。
未来の自分を助けるためにも、ログやメモは残しておきたいですね

[saku @saku_python]

実務あるある

不具合修正完了✨
　↓
半年後
「前も似た障害ありませんでした？」
　↓
「ありましたよね😅」
　↓
「どうやって再現したんでしたっけ？」
　↓
😭

再現手順は
未来の自分へのメモです。

#エンジニア

[saku @saku_python]

@kagiyo_embed その基準、分かりやすくて良いですね。
参考にさせていただきます。

[saku @saku_python]

実務あるある

半年後に自分のコードを見る
mode = 3

自分
「3って何だっけ？」

コードは残る。
でも考えたことは残らない。

「なぜそうしたのか」は
未来の自分のためにコメントを残しておいた方が楽です

#Python
#プログラミング

[saku @saku_python]

@PpkunSe 本当にそうですね

若手の頃は「正常に動けばOK」となりがちですよね。
実際に私もそうでした😅
異常系を考えるのは難しいですからね。

障害対応を経験すると
「壊れた時にどうなるか」の方が大事だと感じます。
エラー時の動作や復旧手順まで考えておくと
いざという時の安心感が全然違いますね。

[saku @saku_python]

若い頃は
「正常に動けばOK」
と思っていました。

でも実務で困るのは
正常系ではなく異常系。

障害対応を何度か経験してから
コードを書く時に
「この処理、失敗したらどうなる？」
を考えることが大切

[saku @saku_python]

@Ncyv53PB8148797 ありますね😅
将来を予測するのは難しいです…

[saku @saku_python]

実務あるある

「この値は変わらないだろう」

と思って書いた

retry_count = 3

数か月後

「5回にしてください」

さらに

「環境ごとに変えたいです」

結局、設定値になりました
変更されそうな値は
最初から1か所に集めておくと楽です。

[saku @saku_python]

興味のある方はどうぞ
https://t.co/A3WQNFviTI

[saku @saku_python]

テストできないコード
・global依存
・DBアクセス
・API通信
・現在時刻
・ファイル読み込み
・何でもやる関数

一見バラバラに見えるけど

共通していたのは
👉テストしたいロジックと外部依存が混ざっている

テストは大事
でも
👉テストしやすい設計はもっと大事

内容まとめてます
↓↓↓

[saku @saku_python]

@zc1XmysAWC16893 コメントありがとうございます。

「テストケースが多すぎる」、「依存関数が増えすぎる」ような状態になっていると責任が集まりすぎているサインかもしれませんね。

テストのしやすさも設計の判断材料にしてみてください。

[saku @saku_python]

実務で重要

👉 1つの関数が全部やる

すると…

👉 テストケースが爆発する

在庫判定
割引判定
送料判定

全部1つの関数に入れると、
どの条件が悪いのか分かりにくい。

テストしやすいコードは、
👉 責任が分かれている。

[saku @saku_python]

@kagiyo_embed 「これくらいなら1つの関数でいいか」と思って、あとで後悔したことが多々あります😅

1関数1機能は大事ですよね。

[saku @saku_python]

実務で重要
👉 テストは大事

でも…
👉 テストしやすい設計はもっと大事

・DB
・API
・ファイル
・現在時刻

こういう外部依存がロジックと混ざると、
テストは一気に難しくなる。

テストしやすいコードは
👉 外部依存とロジックが分かれている
　👉 すなわち設計が良い

[saku @saku_python]

実務で重要
👉 テストしたいのは空行判定ロジック

でも…
👉 ファイルにも依存している

これ、
テストしづらいコードの典型。

本当は
・空行なし
・空行あり
・全部空行

を自由に試したい。

でもファイル直読みだと面倒。

テストしやすいコードは
👉 外部依存とロジックが分かれている。

[saku @saku_python]

@PomericanCoffee フォロバありがとうございます
こちらこそ、よろしくお願いします

[saku @saku_python]

実務で重要

👉 テストしたいのは名前取得ロジック

でも…

👉 API通信にも依存している

これ、
テストしづらいコードの典型。

本当は

・正常系
・異常系
・境界値

を自由に作りたい。

でもAPI直呼び（外部依存）だと難しい。

テストしやすいコードは、
👉 外部依存とロジックが分かれている。