2016年
2016年のまとめ。サクッと振り返り。
去年のはこちら 2015年
仕事
昨年度に引き続きiOSを中心に。
- Carthageの導入
- CocoaPodsの1系へのマイグレーション
- パフォーマンスチューニング(描画改善、MessagePackの導入調査)
- Universal Linksの導入
- アプリのイントロダクション画面の作成
など下回りの整備などを数多くこなしていました。
もちろん、下回りの整備/改善系は腐敗を防止(遅らせる)ために必要な作業です。
ただ今年はそこにフォーカスしすぎたのかなと少し反省しています。
テスティングライブラリの依存解決をcocoapodsからcarthageに移行したり、bundler導入したりちょいちょい下回りの整備してるのです。こういった環境整備系の作業好きだし向いてる気がするんだけど、これ系ばっかになってはいけない（自戒を込めて）
— ざわざわ🎍 (@to4iki) 2016年12月15日
来年は、もう少し機能開発とのバランスを意識しようと思います。
プライベート
- Qiitaに4記事
- はてなブログ(読書ログ中心)に14記事
- その他、#shinjukultという身内だけのコミュニティで3回ほどLT
昨年と変わらずくらいのアウトプット量かなと。
来年はより技術的なアウトプットを増やし、対外的な自分マーケティングを意識したいところ。*1
旅行
南の方を中心に(宮古島、ベトナム、台湾)
来年もあったかいところに行きたい🌞
来年の目標
*1:多少、手段と目的が逆になっても良いところだと考えている
「最強シンプル思考術」を読んだ
- 作者: 吉田塁
- 出版社/メーカー: ディスカヴァー・トゥエンティワン
- 発売日: 2016/05/14
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
TL;DL
- モデルは意図を説明する存在、知識を"要約"したシンプルで分かりやすい説明
- "モデルを作る"と"思考する"の両輪を回していくのがモデル化
- 要素・事象をどのように分割するか、関係性から抽象化・具体化を考えどのようにバラしていくか、バラした要素からどのように全体を適切に説明できるようになるかの往復運動(思考)こそがモデル作りの本質
モデルとは
- 根本は無駄を省いて物事をシンプルに考える
- シンプルに考えるためにモデルを使う
- モデル: 複雑なものごとをシンプルに表現したもの
- 型がモデル
モデルの作り方
- 四角(要素)と線(関係)だけであらゆるものに関するモデルを作成できる
- "分かることは分けること"
モデルを作るメリット
- モデルを作ると、漏れなく、重なりなく 物事が整理されていることが確認しやすくなる
より良いモデルを作るには
- なんのためにモデル化するのかを一言で表してみる
- 具体 is a 抽象
- 抽象化とは汎用性を高めること。汎用性を高めることで広い文脈でモデルを用いることが出来る
- モデルを使う場面を意識して、その場面や目的に合った抽象度でモデルを作る
「POODR」を読んだ
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz,?山泰基
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: 大型本
- この商品を含むブログ (1件) を見る
オブジェクト指向の規則が纏まっている本。
(依存関係を管理し、インターフェースを作るためのコードの書き方についての規則)
設計に緊張が伴う理由は、これらの規則を破るためです、上手に破ることを学べば、それは設計者の一番の強みとなります。
TL;DL
ソフトウェア設計の核は
- 作成するソフトウェアの共通部分を探し出しモジュール化する
- 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする
1.オブジェクト指向設計
- オブジェクト指向設計とは多態を実装する部分を決めること、依存関係の管理
- 如何にI/Fを定義するか、実装オブジェクトを隠し抽象I/Fでやり取りをする
- 「対応しない」責任を決めることが鍵
- 設計の行為と実装の行為が乖離したとき、オブジェクト指向ソフトウェアは失敗する
- 少し知識を得たころが危険。知識が増え、その見返りを求めるようになり、執拗に設計するようになってしまう
- 不適切な場所に原則を適用し、存在しないところにパターンを見出す。手段と目的が逆になりがち
2.単一責任のクラスを設計する
- クラスを変更する理由は複数存在してはならない
- = 一つのクラスには複数の責任（=役割）を持たせない
- 提供したい機能(責任、役割、関心)
- 1つのクラスに専念するクラスは、その1つのことをアプリケーションの他の部位から隔離します
- この隔離によって悪影響を及ぼすことのない変更と重複のない再利用を実現する
3. 依存関係を理解する
- メソッドチェーンは依存を作り出す
- DI, 依存の隔離, 抽象への依存
- クラス内で別のインスタンスを作成するのはやめよう(生成は外で)
- クラス名を知っておく責任、そのクラスに送るメソッド名を知っておく責任がどこか他のクラスに属するのでは
- 依存方向の選択
- “自身より変更されないものに依存しなさい”
- 領域分け, 方向の制御
4. 柔軟なインターフェースを作る
"手放しの信頼が、オブジェクト指向設計の要"
— ざわざわ🎍 (@to4iki) 2016年9月25日
- 再利用困難 = 自身について外部に晒しすぎている + 近隣オブジェクトについて知りすぎている
- 合意と約束を意識する
- このクラスが必要なのは知ってるけどこれは何をすべきなんだろう => このメッセージを送る必要があるけど誰が応答すべきなのか
- メッセージを送るためにオブジェクトは存在する
- オブジェクトがそのコンテキストから完全に独立していることが求められる
- 誰の責任なのかを明確にする、知識を隔離する
- 「どのように」を伝えるのではなく「何を」頼むか
- 「私は自分が何を望んでいるかを知っているし、あなたがあなたの担当分野をやってくれると信じている」
- 明示的なI/F: 「どのように」よりも「何を」になっている
- リファクタリング: デメテルの法則(Law of Demeter, LoD)
5. ダックタイピングでコストを削減する
- オブジェクトが何で「ある」かではなく、何を「する」か
- ポリモーフィズム: 多態性(多岐にわたるオブジェクトが同じメッセージに応答できる能力)
- メッセージの送り手は受け手のクラスを気にすることなく、受け手はそれぞれが独自化した振る舞いを提供する
6. 継承によって振る舞いを獲得する
- 継承とは根本的に"メッセージの自動委譲"の仕組み
- 理解されなかったメッセージに対して転送経路を定義する
- 2つのオブジェクト間の継承関係を定義するだけで転送を自動で行う
- サブクラスはそのスーパークラスを"特化したもの"
- 新たな継承の階層構造へとリファクタリングする際は、抽象を昇格できるよう具象を降格させないようにする
- サブクラスがsuperを送る == そのアルゴリズムを知っている
p172. post_initialize のようなフックメッセージを用意するだけ。そうすることで、サブクラスは必ず super を呼ぶ責任から逃れら れます。「いつ」初期化が行われるか知らなくてよいのは大きい。結合度の低減です。
7. モジュールでロールの振る舞いを共有する
- オブジェクトは自身を管理すべき = 自身の振る舞いは自身で持つべき
StringUtil.empty(“”) - クラスによる継承 == である(is-a) / モジュール == のように振る舞う(behaves-like-a)
- サブクラスはスーパクラスと置換できる(リスコフの置換原則)
- サブクラスとスーパークラスを疎結合にする(サブクラスからsuperの送信をしたくない)
- サブクラスが自然と特化できるようにテンプレートメソッドパターンを用いる
8.コンポジションでオブジェクトを組み合わせる
- コンポジション: 組み合わされた全体が単なる部品の集合以上となるように個別の部品を複雑な全体へと組み合わせる行為
- 大きいオブジェクトと部品がhas-a関係になることで繋がる
- コンポーズされたオブジェクトは"ロール"を担うオブジェクトのI/Fに依存する
- 集約はコンポジションのようなものだが、独立したライフサイクルを持つ
- コンポジッションは親が消えたら自身も消える、集約は消えない
9. 費用対効果の高いテストを設計する
- テストの目的はコストの削減
- 良い設計は自然と抽象に依存する、独立した小さなオブジェクトの集まりになる
- テストはオブジェクトの境界に入ってくる(受信する)か、出ていく(送信する)メッセージに集中すべき
- オブジェクトは自身のパブリックインターフェースを構成するメッセージに対して"のみ"、状態についての表明を行うべき
- 受信メッセージはその戻り値の状態がテストされるべき
- 送信コマンドメッセージ(副作用)は送られたことがテストされるべき
- 送信クエリメッセージはテストするべきではない(受け手のパブリックインターフェースの一部なので、必要な状態のテストはそちらで実装しているため)
- テストダブルとはロールの担い手を様式化したインスタンスで、テストでのみ使われる
- ダブルがメソッドをスタブ化する
- SpockにおけるMock、Stub、Spyの違い - uehaj’s blog
- [PHP] PHPUnitのスタブとモックの違いとは – 端くれプログラマの備忘録
「モック」は模擬運用するための模造品
実際のオブジェクトを置き換えて、 (メソッドがコールされたことなどの) 期待する内容を検証するテストダブルのこと「スタブ」はとりあえず動かすための代用品
オブジェクトを置き換えて、 設定した何らかの値を (オプションで) 返すようなテストダブルのこと
- 大量のプライベートメソッドを持つものは新しいオブジェクトが負う責任かもしれない
- 状態のテストとは対照的にモックは振る舞いのテスト。メッセージが何を戻すかを表明するのではなく、メッセージが送られているという期待を定義する
- 送信メッセージが送られたことの証明は、モックに期待を設定すれば終わり
- 最も良いテストとは対象のコードと疎結合であり全てに対して一度だけテストをし、それが適切な場所で行われているもの(コストを上げることなく価値を追加する)
See also
「小さなチーム、大きな仕事」を読んだ
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
- 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
- 出版社/メーカー: 早川書房
- 発売日: 2012/01/11
- メディア: 単行本
- 購入: 21人 クリック: 325回
- この商品を含むブログ (36件) を見る
「37シグナルズ」の仕事を行う上での哲学・思想が詰まった本
仕事の進め方だけではなく、生産性をどのようにして維持するか、競合相手についてどう考えるか、プロモーションをどう行うか、人を雇うときの考え方、どのようにしてダメージコントロールするか、会社文化に対する考え方など多方面の話題に触れている。
著者のビジネス体験がそのまま綴ってあるが、根本の考え方は"ソフトウェア開発"(小さく回していくアジャイルやUNIX思想)に通ずるものがあると感じた。
TL;DL
思うだけでは何も変わらない。動き出すこと(形にすること)が大切
気になった箇所をメモ。
計画は予想にすぎない
- 計画を作っただけで、実際には制御できないものをコントロールした気になる
- 計画なしに仕事をするのは恐ろしく思えるかもしれない。しかし現実と折り合わない計画にしたがうのは、もっと恐ろしいことだ
失敗から学ぶことは過大評価されている
- してはいけないことについては学べるが、次になにをすべきかがわからない
- 一方で、成功から学ぶことは、次の手段を与えてくれる
制約を受け入れる
- 少なければ少ないほどよい。資源が制限されると、それでなんとかしなければならなくなる。そこに無駄の余地はなく、創造性が求められる
- 中途半端な一つの製品ではなく、よくできた半分の製品
- ディテールは後から
決断して前進する
- これについて考えようではなく、これについて決断を下そうと思う
- 何かを説明する必要があるときそれを形にしてみよう
解決策はそこそこのもので構わない
- 柔道のような（最も少ない動きから最も多くを得る）解決策を見つける
- その課題をとっとと片付けて次につなぐ何かを作るだけ
熱意を優先順位と混同するな
ヒーローにはなるな
- やめることが最善の方法となりうることを覚えておこう
- 本当のヒーローは、仕事をさっさと片付ける方法を見つけだし、とっくに帰宅している
基本的にノーと言おう
- ただ正直でいよう
料理人を見習う
- 彼らが有名なのは、自身の知っていることを全て外に出し皆と共有しているからだ
- 共有することを恐れてはならない
造花が好きな人はいない
- 欠点を見せることを恐れてはならない。不完全さはリアルであり、人はリアルなものに反応する
- 不完全の美しさ(ワビサビ) = 本質だけになるまで切り落とす。だが詩を取り除いてはいけない
文化は作るものではない
- 文化はつくるものではなく、自然に発達するものである。新しい会社には独自の文化がない
- 文化とはふだんの振る舞いの副産物だ。文化とは方針ではない。無理に文化をつくろうと考えないこと。熟成には時間がかかる
- いる人の振る舞いや思い考え方が文化になる
ひらめきには賞味期限がある
- アイデアは不死身だ。永遠だ
- 一方ひらめきは永遠に持続できるものではない
- ひらめきとは「今」のものだ。虜にされたら仕事に専念すること
See also
前日のタスクをわざと途中でやめておくメソッド
Rebuild: 139: Productivity Extremist (higepon) で話していた。(1:13:00~くらいから)
スムーズにタスクを進めるために前日のタスクをわざと途中でやめておくメソッドめっちゃワロタ。なんか納得した。 #rebuildfm
— Shodai (@Ringoski) 2016年5月5日
rebuild.fmで話していたのは、コンパイルエラーの例。
自分はコード書いてて詰まった時は、
悩み悩み時間だけが延々と過ぎてしまい、終電で諦めて帰るパターン。
家で寝る時間を忘れてまでなんとかしようとして、結局寝落ちするパターン。
これらのパターンは大体に応じて、翌日脳がすっきりした状態だとスッと解決したり、 軽微なミスだったりする。
心理的に、「どうにかキリの良いところまで終わらせよう」という気持ちになるのは正常で、
ただこのような時は大概焦っていたり時間的なリミットが近づいて冷静ではいない気がする。
(さっさと帰ろう/寝よう)
中途半端な状態という気持ち悪さはあるが、 何をやるのか自明な状態*1で応じたほうがスムーズにタスクに取り掛かることができ(やることは決まっている)、 後のタスクをテンポ良くこなすためのリズムも出来上がるのかなぁと思っている。
"敢えて前日に仕事を残して、翌朝のスタートをスムーズに"
実践しよう
「今日からはじめる情報設計」を読んだ
今日からはじめる情報設計 -センスメイキングするための7ステップ
- 作者: アビー・コバート,長谷川敦士,安藤幸央
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2015/10/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
混乱(Mess)を解きほぐして整頓、理解(センスメイキング )する方法を説いた本
"なぜ"起きて”どう"解決するかを判断できる人 = 問題解決能力が高い人は仕事ができる人だと思うので、 どういった思考で問題を捉え、解決に導くかを考えさせられる本だった。
TL;DL
情報設計とは、
現実を直視・コンテキストとチャネルを判断し、それらを踏まえた複雑さの中から情報を選び出し、
意味が伝わって良い結果が得られるような"カタチ"にすること。
以下、各章毎のメモ。
1. 混乱を見極める
- 情報はデータでもコンテンツでもない
- 行う事は知ること
- データやコンテンツが不足している状況でどのような情報が生み出されるかを考えるのが大事
2. 意図を表明する
- 良いとは何か？ 私たちの意図することが良いや悪いの定義の仕方を決める
- 良く見えることと使いやすいことには等しく注意を払うべき
- 誰が重要
- なぜから始める
- どうやっての前に何を
3. 現実を直視する
- 現実と向き合うことで解決策を見つける事ができる
- 現実と深く対話するために「オブジェクト」「メンタルモデル」を育てる
- スコープ(範囲)とスケール(規模)を決めてからスタートする
- 道具箱を拡張する*1
4. 方向を決める
- 「なぜ」から「何を」
- 階層(場所)を、階層間の影響を意識する
- 小さな決定が次へ次へと繋がる
- 言葉の定義が大事
- 名詞に、それに合わせた適切な動詞を組み合わせると要件(必要なもの)を示すことができる
5. 距離を図る
- 現実と意図の距離
- 進捗度をどのように評価すべきか、意図を分解し具体的な目標へと置き換える
- 不明瞭であるのが普通
- 良い、悪いは主観的なもの
- 重要なものは複雑な現実の世の中で達成したいと思っていることに対して誠実であること
6. 構造で遊ぶ
- 曖昧さは明快さを犠牲にし、正確性を柔軟性を犠牲にする
- 曖昧さはシンプルさを隠す
- パターンを意識する(階層構造、並列構造、シーケンシャル)
7. 調整に備える
- 新しい問題に遭遇した時に、その問題に対応するために自分の進むべき道をそれに合わせて調整する
- はっきりするまで議論しよう
- フィルターになろう。コーヒーかすではなく
