ライト、ついてますか―問題発見の人間学を読んだ

読書記録

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

大変に面白かった。個人的には、色々な啓蒙に富んでいるし今日からぜひ使っていきたい！と思える視点に満ちているという点で、「アイディアの作り方」に通ずるものを感じる。

自分は以前から「思考の枠を外す」と呼んで大事にしている視点がある。意識的に、色々な「もしooだったら」を、極端なくらいに脳内で入れ替えた上で今目の前にある問題を眺めてみる〜というものだ。
この本は、まさに「枠」を俯瞰して眺めてみようという取り組みが大量だった。

全体的には(本当であれば)難しいことを語っているように思う。しかし非常にユーモアの聞いた語り口と、思わず笑ってしまうようなスパイスの効いた(時に効きすぎた)イラストによって、この本の存在を「芯の強い”教授”」から「分け隔てない友達」のようにしていると感じる。
高度な問題をバシバシとやっつけていくような本も良いものだけど、こうやって気軽に頭を使ってみたくなるようなものも良いもの。

読書メモ

以下、実際に読みながら作っていたメモから。
琴線に触れた部分なんかの感想が中心。

(ただ、寝る前にベッドの中で読み進めた部分についてはメモがなかったりする😇)

第1部

P27
ユーモアのセンスのない人のために問題を解こうとするな。

個人的にも「ユーモアって大事よね」というのは常日頃思っていて、ブレスト何かをした時には「ギリギリふざけてないか少しふざけている」ような案を序盤で出せるように、という意識をしてさえいる。それがあってこの一文はグッと来た。

「ふざけたことを言っている」として発言を遠ざけたり蓋をしないで、「そんな馬鹿な！」というくだらない話も一旦受け止めて乗っかってみて、それが柔軟で豊かな視点の獲得につながる〜みたいな話かな。ブレストを「大喜利」のような感覚でやってみる、というのもそれに繋がる話かもしれない。
この文言自体が「おいおい本気で言ってるのか？」みたいなある種のナンセンスさを感じるような部分もあり(ユーモアを持ち合わせているかどうかで手助けしない相手を選ぶの？)、見事な再帰構造だなーって思う。

第3部

P60
たいていの不適合は、認識さえすれば容易に解ける。(中略)たいていはその不適合と付き合わなければならないものの方から処理できるものだ。人間というものは実に適応力に飛んだものだから、ほとんどどんな種類の不適合にも身を合わせてしまう。ただしそれは、当人たちが実はそうでなくてもいいのだ、ということに気づくまでのことである。そのとき、トラブルが起こる。

「トラブルが起こる」なんてネガティブな表現をしてるからビクッとしたけど、これは「問題が問題と認識されて、問題となる」って話だよな。
これはとても「そうだよな」と思うし大事にしたい部分。「思考の枠を外す」なんて言葉が個人的に好きなのだけど、まさに「いま目の前にある当たり前を、当たり前じゃないかも知れないという視点で眺められるか」というのは大きなヒントになるように思う。それが「実はそうでなくても良いのだ、ということに気づくまでのことである」という言葉で描かれている。

P62
どんな新しい「解決策」も、問題の定義が間違っていた時にそれと気づくのは、もとの設計者よりは利用者の方である。だがひとたびはじめに感じた親しみのなさが薄れると、人の適応性ゆえに不適合は目に見えなくなる。このことから、次の規則がどんなに重要かは、分かるわけだ。

結論に飛びつくな、 だが第一印象を無視するな

この後に続く「視点の新鮮さ」と合わせて、重要な示唆だなーと感じる。「なにか変だよね」「どうも使いにくいな」というのは、教育されていくと薄れるものだから、それに対しては「素人」の持つ新鮮な目線がいるよねーという風に思った。

ちょっと思ったのが、例えば「精神的にエネルギーが減っている時に、部屋が散らかっていてもそのまま過ごしてしまう」みたいなやつ。これは「部屋を片付ける気力がない」というのが問題なのだけど、もしかしたら「現状に適合する(抵抗をしない、新しい刺激を求めない)」みたいな力が大きく働いている状態なのかな・・・？「疲れている時はクリエイティブなアイディアが出てこない」みたいなのは馴染みのあるパターンだと思うんだけど、それと同じような事が同じような原因で生まれているのかもな、なんて気がした。

P69
こうなっていれば、答えを何か考え出すのに困難を覚える人はほとんどいない。コチラは「正解」を求めているのではなくて、彼らの意見を求めているのだ、という風に見えるので、威嚇的雰囲気の大部分が消滅するのである。意見なら誰でも、またはほとんど誰でも持っている。そして自分の個人的意見ということになったら、誰でも大家なのだ。

「何を求められているのか」というのを、言外のニュアンスまで含めて見極めようとしがち。
他人への問いかけはそういうとこを意識しながら行いたいし、逆に自分が解答者になっている場合は、そういう無意識なフィルタに邪魔されていないか？は意識しておいたほうが良さそう。

P70
われわれは、可能な場合にはいつでも、問題をまず自分たちにとって最大の快適さをもたらすような意味的レベルに置いてみるものだ。

暗黙的に、問題を大げさに考えすぎたり、その逆に余り単純化して硬直したりする・・・ていうのは、「求められている意味的レベルがズレている」ことによるのかも知れないな。知っている人からしたら「そんなやり方しなくてもここをこうするだけでさ」みたいなやつとか。

P75
10 意味に気をつけよう

※ 章全体に対する感想

なにかの問題を言語化する際に、書き手もしくは読み手が「言外の意味」を補完してしまう、それが極度に問題そのものを難しくしてしまう場面がある・・・みたいな話。
(なので、「明らかに他の解釈が仕様のないような表現を心がけよう」みたいな話だと思うのだが。)

これは凄い難しいよなぁ、そうだよなあ、と思いながら読んだ。頭が痛くなりそうなくらいだ。「そこに少女がいます」といった場合に「その時以外はいなかったのか」「少女以外、例えば少年以外はいないということか」みたいな。教習所の問題文がそんな感じなんだっけ？というのは、SNS等でもよく流れてくる。
でも、実際、気分や相手との関係地によって「教習所」になってしまうことはあるし、或いはそれを意識していないと問題文を書く人が読み手に対して「ここが教習所であることを期待する」ようになっちゃう・・って事はよくあるかも知れない。
で、章のタイトル、「意味に気をつけよう」だ。

第4部

P89
他人が自分の問題を自分で完全に解ける時に、それを解いてやろうとするな

「同じ課題設定でもそれを私(たち)の問題であるとされることで全力で解くようになる」みたいな話、面白いな。
「もしその解決方法を教師が提案していたら、受け入れられたとしても熱意を持って実行されなかっただろう」みたいな。あるいは、「これは彼の問題である」という視点で(他人が)解決策を出そうとすると、また変わる・・とか。

問題の持ち主が「彼」の場合は「タバコを吸うのを禁じる」という「彼が解決するように求める」、「私達」の場合は「みんなでタバコを辞める」とでもいうような(そこにいる90％以上の人はタバコ吸ってないのに！！)、「毎週1人ずつ、タバコより感じの良い楽しくなるやつを持ってくる」っていう。言ってみれば、そもそも「タバコが害」なのではなくて、喫煙者の彼も「楽しむための手段としてタバコを採用した」ってわけで、この「楽しむための集団は何があるか」という課題を共有した感じかな？だから「取り上げる」じゃなくて「皆で享受する・与える」みたいな方向性に変わっている、っていうように見える・・・

第5部

P110
第2の理由は「自然」の無関心さである。もし問題の原因を、人、または現実の事物ないし動作に求めることが出来るのであれば、解決の可能性に関する足がかりが得られる。問題の源泉に手が届くことによって、または問題を作り出した張本人の動機を理解することによって、われわれは問題を解消したり、それを軽減する道を見つけたりすることが出来る。

「変えられる部分」が原因だと考えたら初めてそれが「問題」になる、という感じか。どうしようもない部分に原因を求めると無力さに繋がるし、「公理」として逃れられないものになりそう。
第4部の「それは誰の問題か」同様、「どこに属する問題か」という視点はめちゃくちゃ大事なんだな・・・

P118
問題の出どころはもっとしばしば我々自身の中にある

ややこしいイザコザが発生してしまい、事態が硬直しかけたが、相手を1にの人間として誠意を持って接する(まず名前を聞いて、侮蔑的なあだなではなくて固有名詞で語りかけるようにする！)ことで氷解・好転してどうにかなった・・・という話。誠実さを持って接することで、あちらも「この問題をどうにかしよう」という知恵と力(小銭)を出してくれた、と。

ここまで読んで、「あぁなるほど、そうやって自体がいい方向にガラッと変わる、転回することもあるか。気をつけたいね」と思う反面で、「しかし今まで読んできた他のエッセイと違って、理知的と言うよりは道徳的な話だなぁ」なんて感じていたら「追って書き」である。

P119
追って書き この章は、本書の中でも失望感を与えることの、もっとも多い章の一つである。(中略)悪玉が善玉で、善玉─つまり読者自身─が実は悪玉だったと知るのは、がっくりとくる経験である。

こっちの気持ちを見透かされているのか！？と思って笑ってしまった。
この「実は自分が悪玉」問題、肝に命じておきたい話ではある。あの「自分が老害になっていやしないか」と気づかされ、頬をぶん殴られたような気持ちになった瞬間が思い出される。

オブジェクト指向の考え方 5th Editionを読んだ

読書記録

新しくオブジェクト指向の本の翻訳本が出るみたい、という情報が流れてきたので購入。

オブジェクト指向の考え方 5th Edition (impress top gear)

オブジェクト指向の考え方 5th Edition (impress top gear)

  • 作者:Matt Weisfeld
  • 発売日: 2020/10/23
  • メディア: 単行本（ソフトカバー）

全体所感とかレベル感とか

読み終わっての全体的な所感としては、「思ったよりサクサクと読める内容だったな」というもの。高度な議論を扱った本なのかな〜って思ってたけど、寧ろ逆で、プログラミングを初めて少し経って「オブジェクト指向ってどんなものなんだろう？」と気になり始めた人などに良いのではないか、と感じた。(何も調べないで買うから！)
実際、こういった話題を扱ったものにしては本書中に具体的なコードが少ないような印象。・・・これはつまり「コードで考える方が自然」でない層への配慮なのではないか、という気がする。
12章、SOLID原則の段に至るまでは「極力、オブジェクト指向とは"現実にある物質(オブジェクト)をモデリングするような考え方"であるかのように扱おうとしている」ような印象すら覚えるほどに、「リアルワールドのモノで喩える」試みが見られた。 *1 そういう点をとっても、「オブジェクト指向ってどんなものなのか」に触れる人に向けた本なのかな〜と感じる所存。

前書きの「対象読者」を確認すると、

  • 本書は、オブジェクト指向プログラミングの概念を広く紹介することを目的としている
  • 本書を学ぶことによって、より高度なトピックについての書籍に進むための基礎が構築できるはずである

と述べられているので、やはり「入り口」的な性格が強いかな？と。

あと、「新しい本な感じがする」っていうのも読み易さに繋がるんじゃないかな〜と何となく。
本文中に「Swift」とかって言葉が出てくると、「あ、結構新しいやつだ」って感じがするw

自分は「オブジェクト指向を初めて知る」という目的だとオブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)が大好きなのだけど、その手前で読んでみても良いかも知れない。(あちらは、デザインパターンにまで突っ込んでいくので)

主張について・特徴的な所

とりわけ「振る舞いと実装の分離 / インターフェイス*2」について強調しているような雰囲気を感じる。
オブジェクト指向プログラミング、つまりオブジェクト同士がメッセージのやり取りを介してつながる・・と言った時に「どのメソッドに、何を渡せば、どんなものが返ってくるのか」という抽象的な情報がインターフェイス。そして「インターフェイスだけに注目しておけばいい」という点が、オブジェクト指向プログラミングを価値のあるものにしているよね！というところか。(もちろん、そこから「カプセル化」の価値が導き出されるし、「ポリモーフィズム」についても同様)。

また、「継承の問題点」や「コンポジションの重要性」について強調しているのが興味深かった。
「Chapter1 オブジェクト指向概念への招待 / 1.1 基本概念」から引用すると、

歴史的には、オブジェクト指向言語は、次のようなものによって定義されてきた。すなわちカプセル化、継承、そしてポリモーフィズムである(これを「古典的」オブジェクト指向と呼ぶ)。 (中略) これらの3つに加えて、著者は、コンポジション(合成)も含めたい。 (P2)

とさえ述べている。

大体は「古典的オブジェクト指向」の3要素で終わってしまうと思うので・・・そこから踏み込んで「継承か、コンポジションか」という議論にまで持っていってるのは個人的には本書で1番のお気に入りポイント。
「やっぱり継承って難しいよね」みたいな話は、特にgolangの人気が出てきてから良く目にするようになっていない？と個人的に思っているのだけど、その「危うさ」と提案としての「コンポジション も 正しく使おう」という説明は、良い話。
「Chapter 7 継承とコンポジションをマスターする」や、特にその中の「7.4.1 継承はどのようにカプセル化を損なうか」に詳しい。

扱っている話題の広さ

目次を見ると、扱っている話題の範囲の広さを感じると思う。(公式サイトに載っている)

book.impress.co.jp

「基本的な概念」に始まり、「クラス設計のガイドライン」「フレームワーク」「デザインパターン」「SOLID原則」にまで進む。 (「フレームワーク」の話は、期待しすぎると内容のあっさりさを少し残念に感じるかも知れない。あくまで「再利用性を高めることとオブジェクト指向」という文脈で「フレームワークというアイディアの詳解」という話かな、という感じ) これを250ページちょっとでやる。

「オブジェクト指向とはなにか」から「実際の開発の現場にどう影響しているか」みたいな視点でいくと、このくらいまでが守備範囲に含まれてくるのか〜という印象。

「設計のガイドライン」はオブジェクト指向を覚えたての人でも明日から仕事で活かせる感じするし、SOLID原則とか分かるとアーキテクチャっぽい話にもつながっていくし、と。

まとめ

サクサクと読めた！！ので、積ん読にしないでザッと読んだの良かったな。昨日届いた(というか、発売日が2020/10/23でその日に届いた)のを今日読んだ感じ。 出てきくるコードは難しくない(雰囲気で読める)、そもそも少ない、UMLもゴクゴク簡単なクラス図に限定して使われているのでアレルギー少なそう。
文章も平易だったように感じる。

OOPとかに興味持ってきた〜って人にオススメしやすそうな1冊なのかな、って印象！

*1:12章に入った途端に、”オブジェクト指向が人間の考え方に近いというアイデアは、単なるマーケティングである。オブジェクト指向が人間の考え方に近いということはない”というボブおじさんの言葉が紹介されている

*2:書籍中だと「インターフェース」という記述になっていたけど、自分はこっちのほうが慣れているので

SQLパフォーマンス詳解を読んだ

読書記録

仕事で回ってきたタスクで「はぁ〜〜SQL真面目にわからないとだな〜〜」という熱が高まったので、積ん読の順位を入れ替えて読んだ。

を見て f:id:o0h:20201013031330p:plain ってなってたやつです。

4月か、もうずっと前な感じあるぅ。

結論としてめちゃくちゃおもしろかったな、ずっと雰囲気でやっていたインデックスの管理について、雰囲気をつかめたような気がする・・・

「カーディナリティが低いカラムにインデックス張っても意味ないよ」みたいな話とか、理屈で掴めたのがめっちゃ良い。目が覚めるような感覚を覚える。
また、「もしかしたらインデックスヒントやったらワンチャン・・？」みたいなノリで試して→「やっぱ駄目ですよね！アハ！！」とかいう戯れをこれまでに何度も繰り返してきたのについては、少し勘所を掴めそうな気がする。(これはMySQL8以降で変わる部分もありそう、下位バージョンにおいては、機械がよしなにやってくれなそうな部分〜を人力で支援するぞ！！という機会がありそう。みたいなイメージ)

もっと初歩的なことでいうと、「複合インデックス作る時は順序が大事だよ」とか、そういう部分まで含めて、あ〜なるほど〜〜〜って感じに。

いつも技術書等を読む時は、「おっ！」と思った部分は原文を抜き出して自分の感想を添える！という形にしているのだけど、この本は抜き出しが多すぎて比率的に引用って呼べる範囲を超えてそうだな・・・・・という感じすら覚える。

カバーリングインデックスの話も良かったなぁ。。

以下、読書メモ(の一部！！

  • 検索ツリー
    • ルートノード > ブランチノード > リーフノード
    • リーフノードは、ノード同士を双方向連結リストで相互参照している
    • 「リーフ」が、実際のテーブルの行データ情報(=ROWID)を持っている場所
    • 実際にテーブルのデータにアクセスするまでに、ツリーを走査し→リーフノードを手繰り→テーブルからデータを取る、という流れになる
      • この時に、「ツリーだけで済む」ようであれば、極めて低コストで済む。(リーフノードから先については、コストが嵩みやすい)
      • これは「ツリーの深さは増加しにくい」という性質のために、「ツリーだけなら走査しても試行回数がたかが知れている(数回レベル)」というもの
      • 逆に、「ひとつのリーフノードだけでも、数百のエントリを保持していることがある」(P6)
  • カバーリングインデックス
    • where/order/select等、「使う必要がある列(の値)」が全てインデックス上に含まれている場合、「インデックスの表」に載っているデータだけを使って「実際のテーブルのデータ」にアクセスしないで処理を完結させる
  • セカンダリインデックス、クラスタ化インデックスあたりの話
    • セカンダリインデックス = 主キーでないインデックス
    • 主キーはBツリーインデックス、索引構成表、クラスタ化インデックス。ROWIDに直接紐づく
    • セカンダリインデックスは、クラスタ化インデックスに保存された”元のデータ”を経由して、ヒープテーブルにアクセスする
    • 「物理的なポインタ(=ROWID)」をもたず、論理キーを扱う
      • クラスタインデックスのキーの値だけを保持
      • これを「クラスタリングキー」といい、多くの場合は索引構成表のプライマリーキーとなる • それによって、インデックスの順序を入れ替えることが可能になっている
    • 索引構成表を使うと、ROWIDを用いてヒープテーブルにアクセスができるため、テーブルアクセスのコストが低い
    • セカンダリインデックスを利用してテーブルにアクセスすると、まずセカンダリインデックスで検索し(INDEX RANGE SCAN)→クラスタインデックスを検索する(INDEX UNIQUE SCAN)という風に、2つのインデックスを検索することになる。
  • numericな値
    • WHERE numeric_string = 42はインデックスが効かないが WHERE numeric_number = ’42’はインデックスが効く
    • これは「文字列を数値にキャストする」か「数値を文字列にキャストするか」の違いで、前者については、例えば '042' '00042' といった値も数値にしたら42ではあるが、インデックスが作られているのはあくまで0042 といった値に対してなので、つまり「対応するインデックスが存在しない」状態になるため
  • 複合インデックス
    • (col1, col2, col3)というINDEXに対して WHERE col1 = ? AND col2 = ? はインデックスが効くが、 WHERE col2 = ? や WHERE col1 = ? AND col3 = ?は効かないよ
    • 例えば「アーティスト名・アルバム名・曲名」という並び方で作られた索引に対して、「アーティスト名」だけで探す〜はできても、「曲名」を条件に探すっていうのは効率悪いでしょ(それなら全部スキャンしちゃうかもね)っていうイメージ
  • インデックスと順序
    • INDEX RANGE SCANはインデックスの順番で結果を返す
    • 複合INDEX(col1, col2)を作った場合、「col1で絞り込んでcol2でソートする」のようなwhere/order byを付けた場合でも、INDEXをスキャンした通りの結果をそのまま返せる = DBは明示的なSORT工程を踏む必要がない
    • ただ、これは「col1で絞り込んだ範囲であればcol2が順序よく並んでいる」といった場合に限るので、クエリの改修に注意が必要な感じ

あとはこの辺りをもう少しちゃんと読み込みたい

use-the-index-luke.com dev.mysql.com

Clean Agileを読んだ

読書記録

最近になってようやく・少しずつ「アジャイル」なるものに興味が出てきたな・・・というタイミングで、「新しくClaen Agileっていう本が出るよ」というのを、翻訳者の1人である角さんのツイートで知った。
こんな良いタイミングで、こんな良さそうな本！！と購入。最近、書籍購入の財布がガバガバなこともある。

読後の感想としては、「アジャイル(未)入門」な自分が触れても充分に楽しめた！
内容も然ることながら、文章が凄い読みやすかったし面白かったな・・全体を通じて、(しばしば技術書や翻訳書にあるような)専門的・歴史的・横暴で権威的な眉間にシワを寄せながら付き合っていかなきゃいけない箇所みたいなのがなかった。文量的な軽さも相まって、読みやすいな〜って感じ。

アジャイルやXPについての具体的なやり方・プラクティス・ノウハウについては踏み込みすぎず、あくまで「アジャイルって(本来は！)こういうものなんだぜ・・」という部分を語っている本だな、と思う。理念というか初期衝動というか。
「アジャイルって聞いたことあるし何となく存在は知ってるんだけど、計画期間を短くして回すやつ？それ以上の違いってどこなんだろ？」みたいな雑な認識をしてる人が読んでみると、「なるほど、その辺りが本質なのか」という輪郭が掴める気がする。

まさに副題の「基本に立ち戻れ」という通り、これは「この先、具体的にアジャイルやXPについて学んだり実践したりして、少しずつ自分なりに理解を深めていく中で、何度も帰ってくるべき故郷みたいな本になるかもな」という予感。
もっというと、「2章: アジャイルにする理由」と「6章: アジャイルになる」の前半、「7章: クラフトマンシップ」かなぁ。本質さえ抑えておけば道を誤らない、”実装論”や”プラクティス”は些細なことになるのではないか？という感覚がある。その点、これらの章が本書の中でも「なぜ」「どうすれば」に簡潔に答えてくれているような気がして。

以下、読みながらとっていた読書メモを見返しながら、特に気に入った部分とか。

P43

アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。できるだけ早く知りたいのは、そうすれば状況をマネジメントできるからだ。(中略)アジャイルはデータを生成する。アジャイルは大量のデータを生成する。マネージャーはそれらのデータを使用して、プロジェクトの成果を可能な限り最高にする。

"アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。" は、読んでて1番「おぉっ！」と思った箇所かも。
「フィードバックサイクルを短くして、現状をしっかり見つめて機敏にやる」みたいな話だもんな、そうだよな・・「成功確度を上げる」というのと「速くする」ってぜんぜん違うよな。それに加えて、「要求とは常に変化し続けるもの」となれば、より「細かく方向修正していく余地を持つ」ことが大事になる。そのためにフィードバックを集めるのか。
”プロジェクトの成果を 可能な限り最高に する"、なるほど。

この「データ」というのは、例えばストーリーポイントの消化状況だったり、バーンダウンチャートに現れている状況だったり(この前節のタイトルが「アジャイルが生成するデータ」)。「能動的に(積極的に)フィードバックを集められるようにモニタリングして、”適応的”にやっていく」っていうことか。

P44

プロジェクトの鉄十字に戻ろう。「品質」「速度」「費用」「完成」だ。マネージャーは、プロジェクトから生成されたデータをもとに、どれだけの品質、速度、費用、完成度のプロジェクトにするかを決める。 そのためにマネージャーは「スケジュール」「スタッフ」「クオリティ」「スコープ」を調整する。

可変変数はどれか、という話。この後に「(クオリティは)速く進みたければ上げるしか無い」って書かれていて、なるほど「クオリティも非可変か」と思った。
ガラクタを作っても遅くなるだけ！

P59

しかし、その新メンバーのトレーニングは誰が担当するのだろうか？これまでコードベースを雑然とさせてきた人たちだ。新メンバーはすでに確立されているチームでの振る舞いに従うことになる。 さらにまずいのが、既存コードが強力な手本になることだ。新メンバーは現状のコードを見て、チームの仕事を推測する。そして、雑然とさせることに加担し、それを続けていくことになる。

そう！！！！コレ！！！！！！！！！って感じ、思わず膝を叩きそうになった・・。 「プロダクトの成長性を規定するのは既存コード」みたいな感覚。この辺り、前にカンファレンスで話した時にも触れた部分に近い。
あと「腐敗は侵食する」という。ただ、よくも悪くも「コードを書いている内にプログラマの腕や見識は高まる」ものなので、つまり「既存資産が良いコード」である確率はゼロになるんだよな。 普段から「今あるコードよりちょっといいコードを書こう」くらいの気持ちを強く持つことは必要かもしれない、或いは「未来の誰かのお手本を作っている」という緊張感が欲しい。全力を出さないで良いと考える合理的な訳がなくなる。

P122

シンプルな設計とは、必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持するプラクティスである。

  1. 全てのテストをパスさせる
  2. 意図を明らかにする
  3. 重複を排除する
  4. 要素を減らす

1はTDD当たり前として、2〜4は個人的に考える「良いコード = 筋肉質なコード」に近いなー！「最もシンプルで、最も小さく、最も表現力のある構造」って良すぎる。
「プログラマーの意図を明らかにする」 = 「表現力を高める」で、「表現力を豊かにしたあとで、重複を排除する」なのか。 「すべての重複を排除したら、クラス、関数、変数などの構造的な要素の数を減らすべきであることを示している」。これも「ローカル変数をなくす・メンバを減らす・・を意識して徹底するとコードの読みやすさを上げやすい」っていう自分の体感に適う。

アジャイル〜〜なトピックだと、次は「みんなでアジャイル」→「アジャイルサムライ」→「エクストリームプログラミング」か「SCRUM BOOT CAMP THE BOOK」辺りを読もうかなぁ〜って予定

CakePHPにDIコンテナが入った(る)と聞いて見学に行ってきました

CakePHP4

ということがありまして、20201005現在で「4.next」に取り込まれているｽﾃｨﾀｽです！
※ 現行の4.1のパッチバージョンについてはmasterに向けられるので、 4.nextは「次のマイナーバージョン」である4.2を指します

「CakePHPにDIコンテナが入ったらどんな感じに使われるんだろう？」というのは個人的にかねてより興味範囲でした。
そこで、このタイミングで「どうやって取り込まれたのかな？」を見てみようという試みです。

なお、本文中の英語で表記している単語(※略称を除く)はCakePHP中のクラスや名称を、カタカナで表記している単語は一般名称を指しているつもりです。

  • そもそもDI/DIコンテナ？
  • CakePHPとDIコンテナの距離感
    • CakePHPとService Locator パターン
    • CakePHPとDI、或いはインクリメンタルな導入
    • CakePHPとDIコンテナ
  • まとめ
続きを読む

PHPファイルのgit-diffを見やすくする

PHP

小ネタ。

cakephpのPRをほげ〜〜〜っと眺めていたら

ということで、やってみるか！！となった次第です

cf:

試してみる内容

before

<?php declare(strict_types=1);

namespace App;

class Hoge
{
    public function __construct()
    {
        // @todo
    }

    public function __destruct()
    {
        // @todo
    }


    public function make()
    {
        // このメソッドで
        // 何かしらして
        // 良い感じに
        // 頑張ろうと
        // 思っています
        $args = func_get_args();
        file_put_contents($this->getOutputPath(), $args);
    }

    private function getOutputPath()
    {
        return __DIR__ . DIRECTORY_SEPARATOR . 'hoge_output';
    }
}

diff

25c25
<         $args = func_get_args();
---
>         $args = json_encode(func_get_args());

という感じで、Hoge::main()の6行目を修正してみます

試してみる

gitatributes設定無し

f:id:o0h:20201001103529p:plain

こんな感じで、class は分かりますが後は行数ベースで頑張る感じです

gitattributes設定あり

f:id:o0h:20201001103546p:plain

コンテキストの粒度が「メソッド main() の中である」という事を明示するようになりました！ 詳細な情報がパッと見れるようになって嬉しいですね〜〜

(・・・何で拡張子.phpのファイルに対して「phpと見なして差分を扱ってください」って設定が必要なんだろ？)

これでfinalやtraitといったキーワードにも対応できるらしいです。
やっぱりgitとphpはソース読めるようになりたいな、と改めて思いました。。。