成果物
GitHub.Upload.ByPython.Add.Database.Create.refactoring.Response.201703270700
開発環境
- Linux Mint 17.3 MATE 32bit
- SQLite 3.8.2
- Python 3.4.3
前回まで
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レスポンス
以下の場所にあるHTTP応答に関する部分を共通化した。
./database/src/license/insert/...
./database/src/license/insert/...
./database/src/license/insert/...
./uploader/command/repository/...
問題
各アプリ機能classでResponse.pyのインスタンスを生成しているため、無駄なメモリを消費している。と思う。
インスタンスごとによる差などないから1つでいい。どのように解決するか。
- classでなくmoduleにする
- 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でリビジョン管理を学ぶ余裕も出てくるだろう。
所感
いろいろと複雑になってきた。小さく一歩ずつ確実に整理しながらいかないと、一瞬で崩壊しそうな予感。まともにテストもしてこなかったし。