やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

GitHubアップローダのHTTPレスポンス定形部を共通化した

GitHubアップローダリファクタリングシリーズ。

成果物

GitHubGitHub.Upload.ByPython.Add.Database.Create.refactoring.Response.201703270700

開発環境

前回まで

http://ytyaru.hatenablog.com/entry/2017/10/05/000000
http://ytyaru.hatenablog.com/entry/2017/09/29/000000
http://ytyaru.hatenablog.com/entry/2017/09/26/000000

今回

  • HTTPレスポンス
    • 定形処理
      • 標準出力(ファイル出力はしない)
      • time.sleep(2)
      • HTTP_Code, raise Exception
      • 型(r.text, r.content, json.loads(r.text))
        • r.json()で簡単に取得できる。もしや不要?でもtextは変数なのにjson()は関数とか紛らわしいし…

以下の場所にあるHTTP応答に関する部分を共通化した。

  • ./database/src/license/insert/...
  • ./database/src/license/insert/...
  • ./database/src/license/insert/...
  • ./uploader/command/repository/...

問題

各アプリ機能classでResponse.pyのインスタンスを生成しているため、無駄なメモリを消費している。と思う。

インスタンスごとによる差などないから1つでいい。どのように解決するか。

  1. classでなくmoduleにする
  2. classのまま。1箇所で1回だけ生成して各アプリ機能classに渡して使い回す

これまではbの解決方法でやってきた。moduleの場合、ディレクトリ構造が変動するとメソッドを呼び出す箇所すべて変更せねばならなくなりそうで面倒そう。classならimportと生成箇所だけで済む。

課題

  • HTTPレスポンス
    • 定形処理
      • GitHubAPIごとに異なる差を吸収したい(Url, HttpMethod, HttpCode, 型)
    • Pagenation
      • くりかえすリクエストのHttpMethodはGETで固定としてしまっていいのか
      • 引数の扱いはどうするか
        • r.links[rel]['url']で取得できるURLはパラメータがURL文字列である
        • でも初回リクエストはrequests.get(params={param: 'value'})のようにdict変数で渡す
  • HTTPリクエスト
    • アプリ機能とGitHubリクエスト処理を別ファイルに実装したい

Pagenationはリクエストも含んでいる。先にリクエストを考える必要があるかもしれない。

リクエストの共通化は具体的に考えていない。どこまでやるか、どうやるか、requestsライブラリ以上に共通化する箇所があるのか。

リポジトリ

リビジョン管理すべきときがきた?

規模が大きくなってきた。もう新規リポジトリでなく固定リポジトリで追加、修正するようにすべきかもしれない。

  • 一部しか修正していないのに何度も丸ごとUPするので変更なしの部分が重複する

だったら一気に大量に修正すればいいと思うが、それは危険。

  • 一気に変更して壊れたら大惨事。ちょっとずつ修正したい

べつに容量を圧迫してもいいと考えればそうなのだが、リビジョン管理ツールを使いこなしてスマートにキメたい。

しかし、固定リポジトリにして修正するスタイルにするのは難しい。以下の懸念があるせいで。

  • Gitの使い方を勉強せねばならない
    • ブランチ使いこなせない
    • 以前の状態に戻すための学習
      • どこまでなら可能なのか
      • そのために必要な操作は何か
      • ディレクトリ構造などの設計すらないのに毎回それやるの大変すぎ
  • Gitでも以前の状態に戻せなくなりそう
    • ディレクトリ構造が激しく変化している(設計がない。作りながらその場その場で変更している)
    • 共通化によりファイル名が変更されたり、削除されたりしている

たぶんわけがわからなくなって崩壊する。以下のような厳しい状況になるから。

  • 規模の大きなコード内容を把握するだけで大変
  • なのに、それに加えてGitHubの詳細な使い方まで同時に学習せねばならない

これまで

そもそもこのGitHubアップローダ、最初は「GitHubコマンドを覚えずとも簡単にアップロードできる」ことを目的としていた。今までは規模が小さかったし、1リポジトリ1回アップロードするだけで終わっていた。

いよいよリビジョン管理したくなるような規模のコードが書けるようになってきた、ということかもしれない。

これから

まずはこの規模のコードを書くことだけに専念しよう。それに慣れてくればGitHubでリビジョン管理を学ぶ余裕も出てくるだろう。

所感

いろいろと複雑になってきた。小さく一歩ずつ確実に整理しながらいかないと、一瞬で崩壊しそうな予感。まともにテストもしてこなかったし。