前提
新人エンジニアがもらったフィードバックやコードレビューの備忘録的記事です。※随時更新
内容
一つの処理の責任が肥大化しないようapiを叩くという機能だけ持たせたクラスを作る方がいい
apiを叩く処理は引数に条件を渡した方がより汎用的になる
global変数を使うとバグが発生した際の原因特定が難しくなるため変数のスコープは必要なければ極力狭くす
大抵同じ値が入る引数は呼び出し側がそこまで意識しなくて良いようデフォルトの値を指定しておく
引数の名前はapiの引数と同じ名前にすると対応関係がわかりやすい
コードの可読性のため変数名は意味のある名前にする。for文などでvやxなど無意味な変数を使わない。
学習後のモデルを保存する場合は ディレクトリを分けたほうが良いかもしれない
blah blah/ml_models/model.pkl
複数回使うようなコードは別クラスに分けて責任を分離でき、コードが簡潔になり運用しやすくなる
数字を変数名に入れるとマジックナンバーに見えるので具体的な単語の方が分かりやすいかも
docer fileに
- 環境変数名=$ローカルで設定してる環境変数
これで直接書きたくない秘密鍵などを設定できる
コードが長くなりすぎる場合は変数に入れる
コードで返ってくる値が分からない、意味が分かりにくい場合は変数を定義する
不要な変数定義はしない。処理から何の値が返ってくるかわかるようなものは変数に入れなくても良い