5日目: 設計 is むずかしい

2日目: chrome拡張まとめ その1 - わすれっぽいきみえ でも新卒研修がーと少し書いてるけど、研修で渡された本は渡されたすぐ読んでみてもいまいちわからなかった。理解ができないというより、実感がわかないという感じ。 やっぱり技術って使ってなんぼなわけで、概念だけ話されても何のこと？となってしまう。

ただ今は業務でも「URL設計って重要だよね」「RESTって大事」とか話されるのでわからないわけにはいかない。

というわけで研修の時に渡された以下の本を必要そうなところから改めて読み返してみた。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

以下は本を読んだ感想とか実際にwebサービスの設計をしながら考えることを書く。 興味のある方だけどうぞご覧ください。

今の設計、細かい？まだ粗い？

チーム開発研修のときも本当に難しいなぁと思って、今も難しいなぁと思うのが「どこまで詰めて実装を始めるか」。

誰がどんなリソースをどうやってどういうふうになぜ利用するのか。考えるべきは5W1Hなのだけど、その5W1Hから考えられる障害・実装上クリアすべきことを考えすぎて実装が進まないのでは納期に間に合わなくなるし、かといって設計がおろそかなまま焦って実装を始めると途中がぐずぐずになって結局納期に間に合わない。
だから初めの設計はとても大事なんだけど、どこまで詰めて実装を始めるかってまだ勘所がつかめていない感じがする。

特に「RESTfulなwebサービス is 何？」みたいな状態では何を決めればいいのかもぼやっとしていて設計がすごく時間かかる。で、これでまた焦る。

この本を読んでRESTを意識しながらURLとか設計していたつもりだったけど、URLのレビューでさっそく突っ込みはいりまくってて、あぁ進まねぇwって思った。

裏側の処理（もらったデータをどんなふうに扱うか）は大事で、実装ってそっちの方がやることは多い（気がする）から設計考えるときにそっちばっかり気になるんだけど、表側の処理（どんなふうにデータを渡させるか）がちゃんと決まらないと裏側で何すればいいのかわからんようになる。でも裏側でできることにも制限があったりするから、やっぱり表だけを考えればいいわけではなくバランスが難しい。

今は新卒だけど、もう数か月で2年目だから今のうちに大量に質問して叱られておこう。ありがたいことに「これ見てくれませんか？」と訊いたことに答えてくれる先輩もいるので。

研修始まった時点で読んだときと今読み返してみたとき

本を読んだ感想は研修始まった時点では冒頭にも書いたように実感がわかなかったので、正直印象薄かった。覚えられない単語を覚えるための単語帳的な感じ。ところどころ「ここ良いなー」と思う表現が見つかるくらいだった。 でも今読み返してみると割と実践的な話が書かれてて、ただの単語帳ではなくて「こういうときはどうするとよいか」という逆引きみたいな使い方もできるのかと思った。

たとえばGET/POST/PUT/DELETEメソッドで何を意図してリクエストを送るor送らせるかということは本当に基本的なことなんだけど、実際に設計してみたら実に悩ましい問題で、
「更新系ならPUTでしょ」
「いやでもリクエスト送ってくる人はリソースの場所なんて知らないんですよ」
「じゃあ一旦POST送らせてリソースの場所返して、もっかいリクエストさせりゃいいじゃん」
「相手の手間（リクエスト数）が増えますよね？」
「…」
みたいな話、ものすごくよくあると思う。

経験値が足りなくてさばき方の手法を私が知らないというそもそもの問題があるにしても、これずっと悩むことになるんだろうな、と。そういうときに解決にはならないにしてもヒントにはできるなと思うところがいくらかあった。

ただ技術的にマッチョな先輩社員の一部に言わせれば、甘いと思われる本らしい。そこは今の私にはよくわからん。基本的すぎるのかなぁ。

読書メモ

以下はちょっとした読書メモ。全部を書き出したわけではなくて、業務上必要と思ってサッと読みかえしたところを何となく書き出してみただけ。
ほかの人だとまた全然違うところが気になるだろうけど、それはそれ。

• 第3章 REST
  • リソースを簡単に指し示せる性質「アドレス可能性」（Addressability）
  • REST = ULCODC$SS (Uniform Layered Code on Demand Client Cache Stateless Server)
    • RESTとは異なるアーキテクチャスタイルとしてPeer to Peer(P2P)が挙げられている
  • リソースをリンクで接続することで1つのアプリケーションを構成す る（Connectedness）
  • 粒度が大きいこと「粗粒度」（Coarse-Grained）
  • RESTful（RESTの制約に従っていてRESTらしいこと）
• 第4章 URIの仕様
  • URI（Uniform Resource Identifier）「統一リソース識別子」
  • URIの構文（44ページ）
    • URIスキームはIANA（Internet Assigined Numbers Authority）に公式一覧がある
  • URIの仕様はRFC3986
    • RFCとは（18ページ）
  • URIで使用できる文字にアンダーバーがない（48ページ）
    • でも実際のURIには使われてるところを私はそこそこ見る
    • %は%-Encodingで用いるのでURIに直接入れることができない
  • URIの長さ制限は仕様上存在しないが、実装上は存在（特にIEのせいで2038byteで実装することが多い）
• 第5章 URIの設計
  • Cool URIs don't change
    • プログラミング言語に依存した拡張子やパスを含めない
    • メソッド名やセッションIDを含めない
    • URIに実装依存のパス名を利用しない
    • URIはそのリソースを表現する名詞である
      • 「あるリソースを取得するのか更新するのかは、URIで指定するのではなく、URIに適応するHTTPメソッドで決定します」（56ページ）
  • どうしてもURIを変更したい時は出来る限りリダイレクトする
• 第15章 読み取り専用のWebサービスの設計
• 第16章 書き込み可能なWebサービスの設計
  • POSTかPUT
  • リソースの作成はPOSTでもPUTでもok
    • ただしどちらを選択するにしてもメリット・デメリットがある（272ページ）
  • リソースの更新は基本PUTで、バッチ更新はPOST
    • PUTだと更新対象のリソースをURIで指定しなければならないが、POSTはそれがいらない

自分で作ったchrome拡張に寝ることを強いられたので、これでおしまいにする。