「強いチームはオフィスを捨てる」を読んだ

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

リモートワークいいぞという内容だが、むやみやたらとリモートワークを導入しろと言っているわけではない。

ちょうど リモートワークへの努力とは何なのか - axross.io という記事が話題になっており、この本と同じようなことを言っている。

リモートワークをするためには情報がオープンでなければならない、これは必須である。しかし、これはリモートワークに限った話ではないと思う。

働き方に関わらず情報はオープンであるべきだと思う。オフィスにいたとしても裏でこそこそ動いている案件があるべきではないし、チームが違うからといって情報にアクセスできないなんてのは良くない。口頭で会話したけど議事録も何もないというのはオフィスで働いていたって起こる。

大切なのは、必要な資料や情報を、いつでもみんなの手の届くところに置いておくことだ。

これらを普段からやっていない会社がリモートワークをやるとリモートワークがうまく機能しないのは当然で、そもそもこれができてないとオフィスで働いててもストレスが溜まると思う。

弱いチームはオフィスを捨てられないのである。

「小さなチーム、大きな仕事」を読んだ

小さなチーム、大きな仕事 働き方の新しいスタンダード (ハヤカワ文庫NF)

小さなチーム、大きな仕事 働き方の新しいスタンダード (ハヤカワ文庫NF)

書籍の名前は聞いたことあったけど読んだことはなかったので読んでみた。 題名の通り少ない人数(例えば一人)であっても大きな仕事が可能だからやろうぜ、現に俺たちは少ない人数で大きな仕事をやっているよ、という内容。1つの章が3ページくらいになっててサクサク読めて良い。

無駄なことはせず、小さく始め、顧客のために良いプロダクトを作ろう、という話が中心となっていて、当然のことを当然のようにやることが大切であると言っているように感じた。最近いろいろな本を読んでるけど他の書籍でも同じことを言っていて、やっぱりこういうことをするべきなんだなという感じ。

また、個人アプリ開発者なので身にしみることがたくさんあった。弱小デベロッパは広告会社なんて使えないから Twitter で拡散したり口コミなど草の根でやっていくしかない。そういうやり方でいいからやっていこうぜと書かれていて勇気付けられる。

いくつか心に残る点があったのでメモ:

失敗は成功の源ではない

失敗しないならその方が良いし、成功する人は成功する。
おっしゃる通りだ…。

量より質

中途半端な完成品より、機能を半分にした良い製品が良い。

おっしゃる通りだ。

今すぐ世に出すべき

商品が最低限の要件を満たしているなら、いますぐ世に出すべきだ。

MVPだ、リーンスタートアップだ。

見積もりを間違ったタスク

最初に2時間で見積もったタスクが全然終わらず、16時間かかると判明したとする。 もともとは2時間予定だったそのタスク、16時間かかるとわかったらやるだろうか?途中でやめる方が有益か考えた方が良い。

ひとりきりモード

コミュニケーション依存症からの依存。インスタントメッセージ、電話、メール、会議を断念しよう。

最近読んだどの本にも書かれている。

競合相手

競合相手は製品はパクれるかもしれないが、製品の中にあるあなたまではコピーできない。だからあなたが信じていることで戦おう。

これは口で言うのは簡単だが実際にやるのはかなりの勇気がいると思う、けどその勇気を出してサービスを作っていきたい。

文化

文化は作るものでなく自然と発達するもの。

弊社、文化を作ろう?みたいな働きがあってだいぶエモい気持ちになる。

ビジネスで絶対に使ってはいけない四文字言葉

need(必要), must(しなければ), can’t(できない), just(ただ), only(だけ), fast(早く・速く)。

弊社オンパレードだって思った。

「Web API: The Good Parts」を読んだ

Web API: The Good Parts

Web API: The Good Parts

仕事で API は書いてないけど API は使うのでベストプラクティスを知りたい、と思って手に取った。(「えっ!?アプリエンジニアが読んだのにサーバサイドエンジニアが読んでいないだって!? 」という煽りができるのも良い。)
電子書籍版もある ので、そっちを買って mobi を Kindle に送って読んだ。

美しい APIAPI に必要な HTTP メソッドや Status Code の考え方、エンドポイント名、フォーマット、エラー、キャッシュ、HTTPヘッダ、セキュリティなど網羅的に書かれていて、Twitter や FB などで現実に動いている API などが参考にあがってて大変良かった。
と言いつつも本を読む前からすでに理解していたことが多く、どちらかというと自分の考え方は間違っていなかったと自信がついたのが一番良かった。

HATEOAS

以前、会社のパイセンと HATEOAS どうすかね?という話をしたので自分の考えを述べておく。HATEOAS とは詳細は省くが、下記のように json のレスポンスに関連する URL をのせるものである。

   "user": {
    ....
   "links": [{
        "rel": "roles",
        "href": "http://awesomeapi.com/users/1/roles"
      }]
  }

HATEOAS の利点として、「クライアント側が取得したいデータに対しエンドポイントを知らなくて良い」「サーバ側でエンドポイント名を変更できる」があるのかなと思っている。(違ってたらツッコミ入れて欲しい)

  1. クライアント側が取得したいデータに対し URL を知らなくて良い
    • URL は知らないけどレスポンスマッピングはするから、エンドポイントの名称( roles )を元にクライアント側で API を実行する必要がある
    • サーバ側でエンドポイント名を変更されると、クライアント側のソースコードと整合性が取れずに気持ち悪い(クラス名をエンドポイントと同じにしていた場合などズレが生じる)
  2. サーバ側でエンドポイント名を変更できる
    • エンドポイント名を変えるというのはそもそもが破壊的な変更
    • 変えたいなら古いエンドポイントを生かしつつ新しいエンドポイントを作成するべきでは

エンドポイントを知らないで良いというメリットがあまりしっくりこず、私は HATEOAS 否定派である。正直に言うと、HATEOAS を使いこなせずクライアントのコードが煩雑になってしまう気がしている。

オーケストレーション

これはめっちゃ良い。クライアントのエンジニアが、複数の API などを 1 つにまとめたりレスポンス量を調節したりできるようにする仕組み。サーバは細かい API を提供して、クライアントエンジニアがそれを束ねた API を開発できるようにするような感じ。

BFF と近いものを感じていて、細かい調整などをサーバの人にお願いするのもだるいのでこう言うのあるとすごく良い。しかし、これを用意するのは結構な労力がかかるのでコスパは悪そう。
Netflix でやってるらしい。

書いて欲しかったこと

残念なことが2つあって、 JSON Scheme への言及がないことと、クライアントサイドで扱いやすい JSON 形式という視点がなかったこと。

JSON Scheme で仕様を表現するのは賛否あると思うが、そういう方法があるのは述べてて欲しかった。

また、アプリエンジニアからサーバサイドエンジニアへの JSON オブジェクトに関するお願い - Qiita という記事を前に書いたが、レスポンスオブジェクトの形式には気を配って欲しい。


以下、 wikihub 日報 の雑メモ。


読み始めた、1/3 読んだ。 これを読むことで「えっ!?サーバサイド API 実装するのに読んでないんですか?クライアントサイドの人が読んでるのに!?」という煽りができる。

今のところ知ってることが中心、 Rails 書いてたり他のサービスの API 使ってると染み付くようなことが言語化されてる感じ。

  • そのサービスのコアの価値のある部分を全て API として公開し提供しよう。
  • 設計の美しい Web API は使いやすい、変更しやすい、頑強である、恥ずかしくない
  • 仕様が決まっているものは仕様に従い、そうでないものはデファクトスタンダードに従う
    • 他の API 真似たりとかする
  • 美しい URI 設計
    • 短く入力しやすい、人間が読んで理解できる、大文字小文字が混在してない、改造しやすい、サーバ側と切り離されている、ルールが統一
  • POST は新しい情報を登録し、完全に上がいて修正は PUT, 一部修正は PATCH
  • アンダーバーかハイフンで迷ったらとりあえずハイフン

2/3 まできた。明日読み終える。 いい本なんだけど、知っていることばかりという感じ。いままでで API 開発の基礎は身についていたということだろう。

  • Chatty API (おしゃべりなAPI)
    • 1つの作業を完結するために複数回アクセスしないといけない API
  • エンベロープ
  • JSON レスポンスで直下に配列があると JavaScript としても解釈できてしまうので、オブジェクトを返した方が良い
  • JSON はアンダーバーなどではなくキャメルケースが良い
    • レールズがアンダーバーにしちゃうからアンダーバー派だわ…
  • 配列は複数形、それ以外は単数形
  • エラーが配列で変えるのは合理的、複数エラーにも対応できる
    • アプリの場合、配列でエラー返ってきても割と困るんだよなあ
  • メンテナンスは Retry-After でいつ終わるのか示そう
    • 知らなかった
  • Vary ヘッダ
  • Content-Type はちゃんと実装してテストもちゃんとしよう

読み終わった。だいたい知っている内容だったけど、 API 開発マンは絶対に読んでおいた方が良いと思う。 JSON ハイジャックやセキリュティなども述べられていて大変良い、そこらへんおろそかにしがちなので気をつけないと…。

  • 同一性生元ポリシー(Same Origin Policy)
    • 違うhostの API を実行できないやつ、むかしこれでハマった、懐かしい…。
  • クロスオリジンリソース共有(CORS: Cross-Origin ResourceSharing)
    • 異なるhostでアクセスする
  • オーケストレーション
  • HttpOnly 属性は JavaScript などを使ってもアクセスできない
    • WKWebView で Cookie 取得できないのはコレか?

iOS Simulator で壁紙を設定する

実機 iPhone だと 設定 > 壁紙 から壁紙を変更できるが、シミュレータだと壁紙や Wallpaper の変更画面が表示されない。

しかし、写真アプリからなら壁紙設定画面にたどり着ける。
手順としては以下。

  1. Photos(写真) アプリを開く
  2. 壁紙にしたい画像を選ぶ
  3. Action ボタンをタップ
  4. 画面下に選択肢が出てくるので、 Use as Wallpaper を選択
  5. 壁紙を Set !

f:id:star__hoshi:20170507133409g:plain

「コード・シンプリシティ」を読んだ

www.oreilly.co.jp

会社の先輩に「短くて読みやすくて良い」と勧められたので読んで見た。本当に短くて、1.5時間くらいで読み終わった。

内容は、複雑なソフトウェアは良くないのでシンプルにしよう、そのためにはこのようなルール、事実、定義、法則があるので、その法則にのっとり開発していこう、という内容だった。

感想としては、リーダブルコードと同じようなことが書いてあっただけで、あまり目新しい内容はなかった気がする。

いまと未来

ソフトウェアデザインにとって第一に考えるべくは未来、と言っているのに、未来のことは未来に考えようと言っていてちょっと混乱した。

インクリメンタルな開発として、現状見えている範囲だけを確実に実装し、将来新しい要件が増えたらそれに合わせて実装を拡張していけば良い、とのことで、私は YAGNI 好きなので理解できる。

でもこれは誤って捉えられてしまうと「クソコードでも動けばいい」となってしまうので、これをちゃんと実践するには技術力が必要になると思う。オブジェクト指向の本に「変更可用性の高いコードを書こう」とあるので、つまりそういうコードを書く必要があるということだ。

クソコードを書くのではなく変更可用性の高いコードを書くべき、というのは肝に命じておきたい。

以下雑メモ:

  • 良い開発者は能力の及ぶ限りコードを簡潔に書き、他の開発者が使いやすくしなければならない
  • コードデザインの決断は、集団の多数決などではなく個人が行うべき
  • 誰か人を助けるためにソフトウェアは存在する、人間以外を助けるために存在するソフトウェアは存在しない
  • 人を助けること以外を念頭に置くと、劣悪なソフトウェアを書いてしまう。
  • 現在の価値より将来の価値と管理にかかる作業量が大事
  • 実装にかかる作業量よりも管理にかかる作業量を減らす方が重要
  • ソフトウェアデザインにとって第一に考えるべくは未来
  • インクリメンタルな開発
    • 現状必要になる部分のみの最適化をして、新しい要件は未来に対応しよう
    • YAGNI
  • コードの実行速度が遅くても、実際にユーザにとってパフォーマンスの影響が出ていなければ問題ないので触るな

迷走

友人と slack で話してて、「エンジニアとして生きていくためにはどうするべきか」という題の結論として離島に橋を掛けたい、といういい話をした。

2017年1月27日の深夜の会話。

star__hoshi [00:25]  
:thinking_face: これガチで動いたらすごいけどどうなんだろ

sjnya [00:29] 
htmlをjavaとかswiftに変換する感じなんかな

star__hoshi [00:30] 
なのかなあ、クソアプリが増えるのだけはやめてほしいな

sjnya [00:31] 
逆に考えるとネイティブエンジニアはちゃんとネイティブ要素考えないとって気になってくるな
ネイティブ要素だけで生き残れるのか…

star__hoshi [00:31] 
確かに

sjnya [00:32] 
webエンジニア極めたほうがニーズある気が

star__hoshi [00:32] 
まあ5年たったらスマホもオワコンな気がするんで、アプリに縛られない基礎的な知識とかサービスの概念とかそこらへん押さえとけって感じですかね

sjnya [00:33] 
あー分かる、そういうこと考えたことある

star__hoshi [00:33] 
web の方が明らかにニーズありますよね、 react-native キテるし、webフロントエンドに投資するのが一番コスパは良さそう

iOS やってて、iOSで最適に動かすためにはどうするかってのよく考えるんですが、それって iOS がなくなったら死ぬ知識なんでもっと根本的に OS がどうとか言語がどうとか設計とか知らないと死ぬなあという気持ちです

sjnya [00:35] 
そうだねー

コード書くのが楽しいから、目先の楽しさ追っちゃいがちになるけど、そういう先のこと考えないとだめだよなー

star__hoshi [00:40] 
といっても雇用は創出されるし、低レベルと言ってはあれですがもっとダメなエンジニアもたくさんいると思うので死ぬことはないですが、がむしゃらにコード書いてても成長しないなあと最近実感します

sjnya [00:44] 
スキルどうこうじゃなくてコード書くのが好きなんだからいいんだよ、的な言い訳してる感あるし、その言い訳のためにコード書くの好きだと思い込んでるだけかもしれないって思うことがある

冷静になるとコード書くよりも、パン焼いてるほうが楽しい的なw

star__hoshi [00:45] 
わかる

sjnya [00:45] 
本当にやりたいのかって思うと分かんなくなる

star__hoshi [00:45] 
というかおれにはコードを書いていく以外の人生が見えていないのでひたすらそれで高みを目指さねばならない、という強迫観念が強くて辛いところがある

もっと広い視野とか持てば人生楽になるのだろうな〜とか思う...

sjnya [00:46] 
あぁそれねー
無理にアイデンティティー化しようとしてる感

star__hoshi [00:48] 
そばとか1回も打ったことないけど、そば打ってみたらそれが天職かもしれないし、狭い IT 業界で色々考えるのもな〜という感じ

sjnya [00:48] 
ww

[00:49]  
hoge さんにこのはなしするとき、そば打ち題材にしてたわw

自分が本当になりたいものに自信がないのが原因だから、同じことばっかしないで人生経験つんで何か見つけなさいって結論だった

star__hoshi [00:50] 
そば打つか

sjnya [00:51] 
飲食のバイトとか楽しかったしなぁ

star__hoshi [00:52] 
コンビニバイトは何も身につかないし何も楽しくなかった

sjnya [00:52] 
コンビニバイト以外の何かだな

star__hoshi [00:52] 
早朝の新聞配達とかやってみたいな

sjnya [00:53] 
案外生き生きしてるかもね

shinyaozawa [00:53] 
土方おもしろいよ

star__hoshi [00:53] 
ITドカタ

物理でもの作りたい

sjnya [00:54] 
まじでやってみないと分かんないよなぁ

star__hoshi [00:56] 
不労所得で生きいけるようにして3年くらい色々やりたいけどそれただの自分探しの旅だわ

[00:56]  
アメリカ横断する意識の高い大学生みたいだな

shinyaozawa [00:57] 
橋作ろうぜ

star__hoshi [00:57] 
橋良い

shinyaozawa [00:57] 
離島にかける橋

star__hoshi [00:57] 
カッケェ

sjnya [00:57] 
あぁーいい

star__hoshi [00:57] 
本土と Dash 島つなごう

shinyaozawa [00:58] 
Dash 島って福島じゃねーの?w

sjnya [00:58] 
近いw

star__hoshi [00:58] 
それ dash 村では

[00:58]  
http://xn--50-hi4azc9fsf5155c.com/wp-content/uploads/2014/10/e.png (254KB)

sjnya [00:59] 
ばれてんのか

star__hoshi [00:59] 
荒らしに行くか

[00:59]  
海賊だ

sjnya [01:00] 
僕はもくもく会からはじめて世界広げてくよ

[01:01]  
今年は迷走してみよう!

star__hoshi [01:01] 
いいな

[01:01]  
スローガン: 迷走

sjnya [01:02] 
嫌いな人としゃべるとかもして、世界広げてく

star__hoshi [01:02] 
意識高い

sjnya [01:02] 
圧倒的成長

star__hoshi [01:03] 
やっていくぞ

「エッセンシャル思考」を読んだ

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

誰かの DeepWork の書評に「これならエッセンシャル思考を読んだ方が良い」などと書いてあったので読んでみた。

エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方で、本書の中で繰り返し述べられてたのは2点だと感じた。

  1. 本質的なことのみ行い、より大きな成果を出そう
  2. 本当に重要なことにのみイエスと良い、その他全てのことにノーと言おう

とにかく本当に大事なことにだけイエスをして、それ以外はノーと言うので、結果としてより大きな成果が出る、と言う感じ。わかる、しょーもない仕事はしない方が良い。

と言ってもなかなかノーと言うのは難しい。この前も悩んだ末に社員旅行と言うイベントにイエスと言ってしまった。行きたくないが、まあ断るのもアレだしと思ってイエスにしてしまった。

イエスと言ってしまうことはあるかもしれないが、ノーと言える基準はしっかり持っていきたい。

私はなぜソフトウェアエンジニアをしているのか?

話は変わるが、サンクスコストと言うのがある。一度やり始めたから後戻りができなくなって無駄にズルズル続けてしまうのは良くないので、早々に辞めろと言うやつだ。本書でも言及されている。

なぜいまソフトウェアエンジニアをしているのかと言うと、その職しか知らないから、と思っている。もちろんコードを書くのは楽しいし、ユーザに価値を提供できる仕事だし、合理的な会社が多い、などの理由もある。

そもそもコードを書こうと思ったのは、大学の周りの人がプログラミングをしててかっこいいと思ったからが5割で、暇だったからが5割。

そのコードを書き始めたのも大学の中盤からで早いとは言えず、最初の頃は勉強するのが辛くて仕方がなかった。中学高校から息を吐くようにプログラムを書いている人とは違う。数学も苦手で、高校1年の初めてのテストが赤点でそれからずっと苦手で、受験も日本史で入学した。仕事でコード書いててもつらい気持ちになることが多いし、毎日勉強しないといけないという焦燥感があるし、5年コード書いているのにオブジェクト指向も良くわからないし、デザインパターンも5個くらいしか知らないし、劣等感ばかりつのる。

つまり私はソフトウェアエンジニアに向いていないのではないか、という話である。

向いていないのであれば、それはサンクスコストなので早々に辞め別のことをした方が良い。
「ソフトウェアエンジニアに向いていないかもしれない」と思いながら「自分の仕事の本質」などを考えるのはおかしいのでは?と思ってしまっている。

しかしコードを書くのが楽しい時もあるし、適当にコード書いてる人よりかはまともなコードかける自信が付いてきたし、正直それ以外の職でどうやって働くのか全くイメージが湧かない。
結局ソフトウェアエンジニアとして顧客に価値を届けることに従事していきたい、という結論に達した。

IT と全く関係ない他の職も経験してみたい、パン屋さんになりたい、蕎麦打ってみたいし、ろくろも回してみたい。しかし他の職を体験したら絶対に「こんな非効率的な職業ありえない」と言うと思うし、ソフトウェアエンジニアに向いているのかもしれない。いや染まっただけか。


以下 wikihub 日報 のまとめ

読み始めた、半分近くまで来たので明日読み終わりそう。
Deep Work みたいな内容で、何かを選択することは何かを捨てることである、自分が何を選択すべきなのか考えよう、みたいな内容。
いわゆる自己啓発本ってやつっすね。

  • エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方
  • 今自分は正しいことに力を注いでいるか?を絶えず問い続ける
  • 優先順位を決められない人は他人のいいなりになる
  • 重要なことにイエスというために、その他すべてのことにノーという
  • 何かを得ることは何かを失うことであり、何が最優先か明確にしておかなければならない
    • 以前弊社で「結局ユーザって誰なんですか?」って聞いたら「全員です」って言われてキレそうになったの思い出した
  • トレードオフから目を背けても、トレードオフから逃れられない
  • 集中は歩いてこない、だから自分から集中できる環境に飛び込む
    • Deep Work で読んだやつだ
  • 遊びは大事、遊びはどこまでも本質的である
  • 絶対にイエスだと言い切れないならそれはノーだ

読み終わった。
いい本だったが、自分の考えとだいぶ近く「ウンウンわかる」という内容だったので読む意味はあまりなかったかもしれない。

  • 目的が明確でないと人を動かすことはできない、目的がわからないとやる気が出ない
  • 具体的で魅力的、意味があって覚えたい本質目標を立てよ
  • 絶対にやるべきこと以外の全てに対しノーということが大事
  • サンクスコストにとらわれずダメな行動をすっぱりきる
  • 授かり効果
    • 一度所有すると、それに価値があると思ってしまう
    • これは買う価値があるか?を考えそうでなければ捨てる
  • 人助けもいいが、問題を肩代わるのは逆効果
  • しくみ化
    • 無意識にできるようにすると良い
  • 確実に言えるのは、世の中に確実なことはない、ということだけ
  • 見積もりは1.5倍で考える
  • 仕事を減らしより多くを生み出す
  • 小さいことからはじめ、成功体験を通し、大きい目標を達成しよう
  • 習慣を作れればあとは勝手にうまくいく
  • 大切なのは「選ぶ」こと
  • 「本当に重要なのは何か?」それ以外のことは全部捨てていい

「オブジェクト指向設計実践ガイド」を読んだ

先日 「オブジェクト指向でなぜつくるのか」を読んだ が、内容が薄かったのでもっと濃いオブジェクト指向についての本が読みたかったので、先輩に勧められたこともあり読んでみた。
内容は濃くて良かった、こういう本が読みたかった。

特に良かったのが「オブジェクトがあるからメッセージを送るのではなく、メッセージを送るためにオブジェクトがある」とのところ。
自分はそんな真面目に考えたことはなく、軽い気持ちでクラスを定義しメソッドを作成してしまうので、そうではなく相互関係をちゃんと検討した上で実装すべきなんだなと思った。
そういうメッセージベースの考え方ができるようになると一段上に上がれるとのことなので、意識していきたい。

また、クラス内で具象化してしまうと依存度が高くなってしまい良くないので、 DI して依存度を外から設定できるようにしよう、というのが繰り返し述べられていた気がする。
ここはテスト書くときにほぼ必須なので最近気をつけている。

1つ疑問だったのが、この著者は静的型付を「コンパイル時間がかかる割にメリットが少なすぎる」と言って動的型付を持ち上げているところ。
別にそれはいいのだが、静的型付だったら何も意識しないで済むところを動的型付はテストを書くことでカバーしていて、静的型付にもメリットがあるところをちゃんと書くべきでは、と思った。

全体的な内容は良かったのだが結構難しく、正直あまり理解できない部分が多い… 3ヶ月後くらいにまた読み直そうと思っている。

以下 wikihub 日報 に雑に書いてた感想まとめ。


読み始めた。 Rubyオブジェクト指向についてガチで学ぶ感じになりそう、うわべだけのオブジェクト指向 ではなく真髄に迫る感じがして良い。

  • オブジェクト指向設計とは、「依存関係を管理すること」
  • 設計がないと管理されてない依存関係が大混乱を起こし、1つ変更すると他のが壊れてやばくなる
  • 設計は芸術と言えます、コード構成の芸術なのです。
  • SOLID
  • 前もって詳細設計を作るのは全く意味がない
  • アジャイルが成功するかはシンプル、適応性、柔軟性のあるコード
  • アジャイルは「どれだけの期間で完成するかわからない」を肯定するものであり、オブジェクト指向だってそう、完成時期はわからない

25%まできた。
ためになる!(いつもためになるって言ってる気がする)

Gear と言うクラスを愚直に作った後に徐々に綺麗にしていく流れ。
自分はメンバ変数をいろんなところで叩いてしまうのだが、この本によるとアンチパターンっぽい…。

  • 単一責任のクラスを設計しよう
  • シンプルであれ
  • 設計とはアプリケーションの可変性を保つために技巧を凝らすことであり、完璧を目指す行為ではない
  • TRUE
    • 見通しが良い(Transparent)
    • 合理的(Reasonable)
    • 利用性が高い(Usable)
    • 模範的(exemplary)
  • TRUE なコードを書くために、それぞれのクラスが、明確に定義された単一の責任を持つ ように徹底すること
  • 2 つ以上の責任をもってはいけない
  • クラスが実際に何をしているか、1文で表現できるか?
    • それと、またはみたいな言葉が出たら2つ以上の責任を負っている証拠
  • 設計を決める時、何もしないことで将来的なコストが変わらないなら何もしないで良い
  • 今と未来の可能性のトレードオフを理解しコストが最小になる決断をする
  • 変数はそれらを定義しているクラスからでさえ隠蔽しましょう
    • ruby の attr_reader を使う
    • ジャバで言うと getter, setter かな?
  • メソッドもクラスのように単一の責任を持つべき
  • 1つのこのに専念するクラスは、その1つのことをアプリケーションの他の部位から「隔離」する
  • クラスが知るべきことは自身の責任を果たすために必要十分なことのみ
  • dependency injection で依存をクラスの外にだす
    • Ruby は Interface ないから DI できないと思ってたけどそもそも動的型付だから Interface とかいらないんだった…
  • 場合によっては依存を隠すのではなく、逆に依存部分を強調することでわかりやすくする
  • 初期化の引数にハッシュやデフォルト値を使うとわかりやすい
  • 初期化の引数を変えられない場合(3rd party ライブラリとか)はファクトリーでラップすると良い

オブジェクト思考はクラスがどうこうではなくメッセージをどう送り合うか、と言うことらしい。
正直あまり理解ができてない点が多く、自分は全く理解できてないだなと言うのを理解できて良い。

  • 自身より変更されないものに依存しなさい
    • 具象クラスは抽象クラスよりも変わる可能性が高い
    • 多くのところから依存されたクラスを変更すると広範囲に影響する
  • 変更が多くかつ依存するものが大量にあるとやばい
  • 依存関係の管理で鍵になるのはその方向を制御すること、また自身より変更の少ないクラスに依存するべき
    • Clean Architecture の思想は依存を一方方向にするしそう言うことなんかな
  • オブジェクト指向アプリケーションは「クラスから成り立つ」がメッセージによって「定義される」
  • クラスが何を「する」かではなく、何を「明らかにするか」
  • クラスに基づく設計ではなくメッセージに基づく設計ができるようになるとキャリアの天気になる
    • このクラスがどうするでなく、このメッセージを送る必要があるがどうするかみたいに考えられるようになれ
    • オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
  • public, private などは明確に意図を持ってやれ
    • rails は private method の先頭に _ をつける (知らなかった…
  • デルメルの法則
    • オブジェクトを疎結合にするための規則
    • 異なる二つ目のオブジェクトを介すことを禁じる (ドットで2つ以上繋ぐな、 music.song.artist とかはドットが2つ繋がれている)
    • 遠く離れたものに依存しているのは影響に気がつきにくくよくない
    • この法則に違反している場合インターフェースがよくないことが多い
  • オブジェクト指向オブジェクト指向間で交換されるメッセージによって定義される、そのメッセージは public interface にそって行われる

真ん中まで読んだ。
ためになる!のだが、静的型付と動的型付を比較し、最終的に「いいから動的型付は最高なんだよ」みたいに押し付けっぽい感じになっててかなり萎えた。
それぞれ良さはあるし、「私は動的型付けの方が良いと思っています」と主張を述べるだけのが良いのでは、この本の内容全部押し付けなのかなと思ってしまう。

  • ダックタイピング
    • DI みたいなもんっぽい、ダックタイピングの概念がしっくりこないまま読み進んでしまっているので結局なんだっけと言う感じになっている
    • 具象クラスに依存しないで抽象クラスに依存しよう
  • 動的型付けに慣れればその方がよくやすく、描きやすく、理解しやすいと思うでしょう
    • お前んなかではな?
  • 静的型付によて安全になると言う考えは幻想です
    • お前んなかではな?
  • 動的型付けはコンパイル時の型検査と言うコストが高い割にわずかな価値しか得られないが、動的型付けは莫大な効率性がある
    • まあビルド時間長いのはつらいな
  • 継承
    • 根本的には「メッセージの自動委譲」の仕組み

65%まできた。 Module と Class の違いが述べられていたがあまりよくわからなかった、つらい。

  • 抽象のルール
    • モデル化しているオブジェクトが一般-特殊の関係をしっかりと持っていること
    • 正しいコーディングテクニックを使っていること
  • Ruby は抽象クラスが存在しないので具象化できてしまうが、みんな良識があるから問題がない
    • いやいや、それで問題があるから静的型付によって強制力を効かせるんじゃないの
  • 抽象クラスを作るときには、具象クラスのメソッドを抽象クラスに移動させた方がいい
    • 抽象クラスから具象クラスに移動させるのはやめた方がいい
  • テンプレートメソッドで継承うまくやろう
  • モジュール
    • 様々なクラスのオブジェクトが、一箇所に定義されたコードを使って共通のロールを担うための完璧な方法
  • is-a
    • class
  • behaves-like-a
    • module

75%。コンポジションとかの話、正直よくわからなくて、もう一度この本を読み直した方が良さそう :cry:

  • 一部のサブクラスだけ使うようなメソッドをスーパークラスに置いちゃメッ!
  • スーパークラスとサブクラスは置換可能でなければならない
  • 継承する側で super を呼び出すのはやめて、フックメッセージを使おう
  • コンポジション
    • 組み合わされた全体が、異なる備品の就業以上となる方に、個別の部品を複雑な全体へと組み合わせる(コンポーズする)行為
    • 自転車にはパーツがある、 has-a の関係であると言うことらしい
    • 包含される側のオブジェクトは、包含する側のオブジェクトがなければ存在し得ないもの
      • 学部と言うのは大学がなくなれば存在しなくなるので、コンポジションと言える

87%まできた。明日読み終わる。
静的型付だったら問題にならないようなことをつらつら書いていて、なんでこの人静的型付ディスってたんだろうって感じがある。

  • 継承かコンポジションか迷ったらコンポジションにした方が良い
    • 継承よりも依存が少なくなるから
  • 継承の懸念2つ
    • 継承が適さない問題に対して、謝って継承を選択してしまう
    • 他のプログラマが予期せぬ目的で使うかもしれない
  • コンポジションをちゃんと使えれば、単純で抜き差し可能で、拡張性のたかく変更にも寛容なのができる
  • 継承は特殊化、 is-a関係に継承を使う
  • behaves-like-a関係にダックタイプを使う
  • has-a関係にコンポジション
  • テストダブルはロールの担い手を洋式化したインスタンスで、テストで飲み使われるもの
  • モックはダブルではない
    • モック、スタブ、テストダブルらへんが何をさすのかよくわからないのでちゃんと学びたい

読み終わった、良い本だった。

  • プライベートメソッドはなるべく書くな、書いたとしてもテストは書くな
  • 副作用のないメッセージはクエリメッセージ
  • テストを書く前にリファクタリングをしてより良い設計にしていこう
  • リスコフの原則に従っているか証明する簡単な方法は、契約を共有したテストを書き、全てのオブジェクトにそのテストをインクルードすること
  • スタブを用意するためにサブクラスを作るのは、リスコフの置換原則を破らない限り使える
    • サブクラスを作るときは、そのサブクラスが古くならないようにテストを書こう

iTunes Connect の売り上げとトレンドにある「デスクトップ」は何者なのか

iOS 向けにしかアプリをリリースしていないのに、 デスクトップ というデバイスでのダウンロードがある。

f:id:star__hoshi:20170427101820p:plain

デスクトップとは

stackoverflow.com

どうやら、 PC の iTunes からダウンロードした時はデスクトップとしてカウントされるらしい。どこ経由でダウンロードされたのかが計測対象になっていると思われる。
デスクトップとしてカウントされると、 iPhoneiPad どちらで使われるかは不明。

おそらくだが、 MDM とかで機械的にインストールする場合もデスクトップとしてカウントされる気がする。
(確信はないが、会社でリリースしているアプリが異常にデスクトップ率が高い)

「モバイルアプリ開発エキスパート養成読本」を読んだ

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパートになりたいので読んでみた。
初っ端からいきなり Kotlin の話があり攻めてて良い。

iOS エンジニアなので iOS 関連のところの心に残ったことだけ、さらにこれは書評ではなくメモに近いので、本の内容がどうこうよりもそれを読んで感じたことを書いておく。

3-1 Swift 3.0 入門

Swift 3 の命名規則についての記事を読むたびに、英語力が足りないと Swifty なコードをかけないと感じる…。

Protocol の命名、 HogeProtocol とか書いてるのみたりするけどそれは思考停止で Swifty じゃないのだろうな。
メソッドの定義はなんとなく動詞で書きたくなってしまうのだが、これは Swift 関係なく改めないとマズそう。

3-2 Xcode 8 入門

Memory Graph Debug の使い方などが書かれている。
Xcode Extension については、私は XVim のために署名を外して使ってしまっている、誰か XVim-Extension を作ってくれと言う気持ちしかない。

4-1 リアクティブプログラミングと Rx, 4-3 RxSwift 入門

Rx なんとなく理解してきたタイミングで読んだが、やっぱり概念はわかるけどモヤモヤが晴れないと言う感じ。難しい。

Subject や Value は積極的に使うべきではないと書かれていて、でも MVVM やるなら PublishSubject とか使うわけじゃないですか、これもアンチパターンなのだろうか。
宣言的にかけるのは確かに良い。のだが、素人が Rx してしまうとわけがわからない複雑な Stream ができてしまう気がする。と言うか私の書いている個人開発の MVVM がだいぶ辛くなっている。
自分一人でやっていると間違いに気がつきにくいので、複数人でレビューし合いながらやるのは良いと思う、自分の理解力や実装力が足りないと言われてしまえばそれまでだが。

UITextField の初期化時に空文字列が bind されてしまうのに困っていたのだが、 skip(1) で初期化時の空文字列は無視しよう書かれていて、一つ疑問が晴れてよかった。

5-2 タイプセーフでモダンな iOS アプリの設計

storyboard, TableViewCell の初期化やキャストを Swifty に書いていこうという内容。
会社でやっているのは segue で画面遷移しているので、 segue は早く引き剥がしたい。
TableViewCell のもこのやり方に変えるぞ!

6-3 iOS アプリのテスト

めちゃくちゃためになる。
UITest は書いたことないし、パフォーマンスがテストできるのも恥ずかしながら知らなかった。
今後 UITest を書くかと言われると微妙、でも書いてある通りログイン画面などの非常に重要なところはあったほうがいいかなと思った。

全体として

読むのにそんなに時間はかからないし、ポイントがわかりやすくまとまっているので良かった。
やはり読んだだけではモバイルアプリ開発エキスパートにはなれなかったので、学んだことを少しでも実践していきたい。

あと表紙のおっさんは誰なんだろう。