この本、中古でなんと5900円もしたんですが、買って会社に持っていったら

M君「え？？この本また買ったんですか？？」

と言われまして…。　なんと2冊目を買ってしまったらしい（笑）

まぁ、詳しく話すと私が処分しようとしていたところを勉強熱心なM君が自宅に引き取ってくれたのを忘れていたといういきさつでした。

まぁ、古い本なんですけれども。

まだ2023年に通じるところはいっぱいあります。

 

1章　ビジネスソフトウェアの「ラストマイル」を解決する

 

プログラマーの皆さんは感じたことがありませんか？プログラムが出来上がってからが…長いと…！！

正確に言うと、98%ぐらいできてからが、その先の2%ぐらいにめちゃ時間がかかるんですよ。

Windowsの検索みたいだねっ！！

これは、他のお仕事とはだいぶ違うところで、ソフトウェアを作らない方にはなかなかわからない部分だと思います。

なぜかというと、ある程度できてからしかわからないことが多すぎるからです。

それを、ここでは「ラストマイル」と表現しています。

本書からの抜粋ですが

「ラストマイルで実施されるテストでは、システムのレスポンスタイム、トランザクションのスループット、可用性、セキュリティという

非機能要求が満たされているかを確認することに、多くの時間が費やされます。そして、それをテストできるのはソフトウェアが完成した後なのです。」

そう。そうなんですよ。

アプローチとしては本書曰く

「『システムのレスポンスタイムは5秒以下にする』、という決め方だとソフトウェアが完成してからしかテストできないが、

『ディスクへのランダムアクセスを1秒間に2500回以下にする必要がある』という決め方ならソフトウェアの作成段階でテストできるし、カウンタ機能をつくれば自動テストに組み込むことができる」

という話です。確かに！！

5章　オブジェクト指向エクササイズ

 

ソフトウェア設計を改善するために次の9つのことをやってみよう！という話です。

1．1つのメソッドにつき、インデントは1段階までにする

2.  else句を使用しないこと

3.  すべてのプリミティブ型と文字列型をラップすること

int とかは何の意味も持たない。時間とかなら、時間型しか渡せないので、ずっと保守性が高まる。

4. 1行につき、ドットは1つまでにすること

5. 名前を省略しないこと

6.すべてのエンティティを小さくすること

50行を超えるクラス、10ファイルを超えるパッケージは作らないこと

7．1つのクラスにつきインスタンス変数は2つまでにすること

クラスには2つ種類があんねん！とアンミカさんが言いました。

それは1つのインスタンス変数の状態を管理するクラス、2つの独立した変数を調整するクラスです。

ほう。

そして、それを混ぜてはいけません。

なるほど。。。

８．ファーストクラスコレクションを使用すること

実はですね！この本の、この部分だけを読みたくて、この本を買いました！！！

最近仕事で、コレクションをどうクラス設計すればいいか悩むことが多くあったので、ファーストクラスコレクションについて、詳しく知りたかったからです。

実際のところ、12行しか書かれていませんでした（笑）

大事なことは

・他のメンバ変数を持たせないようにする

・フィルタとか作ってもいいかもね。

・2つのグループの結合やグループの各要素に対するルールの適用なども扱ってもいいかもね

・コレクションはただのプリミティブな型の一種に過ぎないので、独自のクラスにラップする意味はある

12行だけでしたが、きっと三蔵法師がインドで仏典を手に入れたときぐらい満足できました。⊂(^-^)⊃

9.　Getter, Setter, プロパティを使用しないこと

エッ

「求めるな、命じよ」

だそうです。

「求めるな、命じよ」については、下記の解説がわかりやすかったので、こちらを見てみて下さい。

https://zenn.dev/miya_tech/articles/2289a177cdf2ff

---

 

＜これらのルールを見て思ったこと＞

オブジェクト指向的に考えるのが難しい理由って、プログラムを書く時の思考はどうしてもオブジェクト指向と反対から始まることが多いからじゃないかと思ってます。

プログラミングの入り口は

「あるデータがあって、それをＡという場合はＢに、Ｃという場合はＤに」

みたいに始まることが多いんですよね。そしてそれが膨れ上がっていくのが大体のプロセスだと思います。

そうすると、上のルールを守ることはまったくできません。

オブジェクト指向的な発想は反対側からなんですよね。

「あるデータとは何なのか。どういう役割なのか。構造はどうなっているのか。」

を決めることから始めないとなんですよね。

最近、プログラミングとは概念を構造的に伝える手段なんじゃないかと思います。

 

ところで、この本を中古で買ったんですが、めっちゃ線が入っていて、この本を持っていた人は大変な勉強家だったんだな！と思います。

なんかそういう本っていいですよね( ˊᵕˋ )

 

 

今日はPHPerKaigi2023を現地に行って聞いてきました！

いつも私はこういうブログは1週間ぐらい経ってからしか書かないんですが（笑）

今日はモチベが高いので、今日中に書きます！(`･ω･´)　眠いけど…。

さてさて、木曜日から会社で業務の合間にオンラインで見てました。

見たセッションと、その感想をちゃちゃっと書いておきます。

---

木曜日

技術負債とプロジェクトと私たち

 

発表者さんのWeddingParkでは技術的負債をなんとかするために

①テストコードの導入
②カバレッジの目標を設定
→目標達成に追われないカバレッジ値の設定が必要だった

されたそうです。

そう。テストを作らねば。
なんですが、テストを作るのが面倒　(´ω`)
最初のうちは、意識高くカバーしていても、切羽詰まってくると
「この辺、そのうちリファクタするかもしれんし」
という言い訳などで、テストコードを書かない部分が増えてくる。

↓

これはマジの技術的負債ですね！
なんとか、これを防がないといけないな…。

発表をしていたWeddingParkさんでは、テストコードを書きやすいように環境を整えたり、コード自体を書き直しされたそうです。
弊社も、環境はあるんだけどね…。

PHPUnit 10 概論

PHPUnit10で新しくなることで、印象に残ったのは下記のことです。

・テストイベントが新しくなるらしい。
・テストの結果とテスト自体の問題を区別するようになった。
いくつかのテストの結果やテスト自体の問題では、発生してもテストを中止しなくなった。

DataProviderという機能が紹介されてたんですが、これについて私は知らなかったので、勉強になりました。( ˊᵕˋ )

---

金曜日

見たいセッションあったんですが、業務多忙につき、一個もみれなかった。(>_<)

---

土曜日

練馬に行きました！

計測できるレガシーさを捉え、コード改善に対処する

 

途中からしか見れなかった(>_<)。

「レガシーコードだねぇ、おじいさんや。」

「そうだねえ、おばあさんや。」

と言ってるだけじゃなくって、ツールを使ってそのレガシーさを測るべしという話（だと思った。）

とにかくたくさんのlintが紹介されてました。

知らなかったツール→phpmd、Rector、PHP CS Fixer

PHPの配列の内部実装について学びたくなった。

 

そうなんだ~！ということばっかりでした。スクショいっぱい撮った。

JavaだとArrayListとかLinketListとかHashMapとかあるけど、PHPは配列だもんね。

なので、詳しくは上記のリンクにあるスライドを見ていただくのが一番いいかも。

成瀬の挑戦状

 

このセッションの10分ぐらい前に「ドメイン駆動設計入門」という本を読みましたという投稿で紹介した本を書かれた成瀬 允宣さんに直接お会いできて、色々話せたので嬉しかったです！( ˊᵕˋ )

で、その時に挑戦状を頂きましたが、まったくわからず

「？」

となってた私は本当に凡です。(´ω`)

クジラのこと、Dockerにつながってなくってｗ　Twitterが落ちてる時に出てくるクジラかな？って思ってましたから（笑）

いやー、皆さん本当に頭がいいな~　それとも、競技プログラミングとか（？）こういうことに慣れてればすぐできるものなのかな。

シーザー暗号、とか初めて聞く言葉がいっぱいありまして、なんかいつも接していない分野のことが知れて面白かったです。

問題をもっと前に知っていればよかったな。

人生、宇宙、すべての答えは42らしい（笑）。成瀬さんの博学さに脱帽ですね！

プログラマーってSF好き多いですよね。

PHPerチャレンジ解説セッション

 

こちらも、問題を解く系のセッションでした。最近ではカンファレンスでこういうのやるんだ~　ってなってました。

これも、事前に問題を知っていればもっと前のめりに聞けたかもしれないですが、問題を知らないので、ちょっとぼんやり聞いてました…。

しかし

「PHPのVMを書き換えてevalの動作を変えてしまう」

とか言っていて「マ？」って思ってました…。

「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」

って言葉を初めて知りました。

---

そして、懇親会！

懇親会が一番楽しかったです。( ˊᵕˋ )　200人ぐらい参加されてたのかな？

元々、知らない人と話すのが好きなのですが、コロナからはそういう機会がめっちゃ減ってしまって、特にプログラマーさんと話す機会が減ってしまったので、久しぶりでした。

PHPだけじゃない、いろんな言語の話を聞いたり、他社さんの仕事の話を聞いたりするのは勉強になります。

ただ、私今回一人で行ったんですが、こういう飲み会の場で最初一人なののアウェイ感がつらい（笑）

（本当は弊社のK君が来るはずだったんだけど、急遽体調不良でオンライン視聴でした。弊社のほかの人もオンラインで見てたと思う。みんな横浜ずみだからね。）

 

現地に行く一番の収穫は、自分のモチベーションが上がるということだと思います。

PHPerKaigiって有料なんですよ。

会社から経費が出る方もいるかもしれませんが、自腹で来ている人もいるはずで、土曜日にお金出してこういうところに来る人って、意識がめちゃ高いですよね。

そういう人たちの勉強したい、プログラミングが好き、という純粋な気持ちが感じられて、自分の気持ちがアガるのが好きです。

また、すごいと思える人にいっぱい会えると自分が「井の中の蛙」だなって、まだまだがんばらないといけないなと思わせてくれます。( ˊᵕˋ )

 

この本は、以前「失敗の科学」という本の感想を書きましたが、その本に紹介されていた本です。

いや、いい本です。

失敗の科学にだいぶ内容が似ていますが、要は成功するためには、

「ちょこっとずつやって、ちょこっとずつ失敗することを積み重ねることが、成功のために大事」

ということです。

起業だけではなく、コメディアン、建築家、映画、戦争まで多岐な例にわたって、こういうことがいいんだよという話が紹介されています。

いくつか印象に残った話を書いておきます。

・事なかれ主義との決別

「時にはエラーを起こすのがクールだと教え込まないといけない。事なかれ主義の安全策を取ってはならないと覚えこませるのだ。」

「デザインとは複雑かつ把握困難な様相を呈する問題を解決に導くために、批判的かつ創造的な思考を適用してそれらの問題を理解し、視覚化し、描写するための方法論である。」

これ、どっかのスタートアップとかの話かな、と思うんですがアメリカ陸軍の話なんですよ。

意外ですよね。これも、数々の失敗を乗り越えてこのようなことを教えるに至ったそうです。

・失敗の心理的影響を克服する精神的強さと、当初はすばらしく見えたアイデアに固執せずに新しいアイデアを探る思い切りが必要

・「固定的マインドセット」対「成長志向のマインドセット」

固定的マインドセットというのは、例えば困難な仕事を与えられたときに

「この仕事をするのに能力があるから成功する　or この仕事をするのに能力がないからから失敗する」

となる考え方ですね。

成長志向のマインドセットというのは

「この仕事をするのに自分はどんなことを学べるだろうか」

ということを考えるそうです。

固定的マインドセットの人は失敗したときはつまりその人に

「能力がない」

というレッテルを張られることなので、失敗を極度に恐れる、自分が失敗しそうなことはやらない、という傾向にあるそうです。

一方、成長志向のマインドセットの人は、失敗したときにもそれは自分の成長の機会ととらえられるので失敗を恐れない傾向にあるそうです。

まぁ~　この話はうなずけますよね。

周りにいる人も目に浮かぶというか。他人を批判しがちな人って失敗を極度に恐れますよね。

ちなみに、子供のうちからこういう傾向があるそうなのですが、

「能力をほめずに努力をほめる」

方がいいそうです。

子供が何か達成したときに

「あなたは頭がいいから○○なのね」

というと、失敗すると

「僕は頭が悪いと思われる」

と思って、失敗を避けるようになるそうです。

ですが、

「あなたはよく努力したね」

というと、次も努力すればいいので、失敗を避けるようにならないそうです。

 

・質問をする

人は6歳ぐらいから質問をしなくなる。なぜかというと、それは教育の問題で、学校に行くと自然と

「質問をして先生に面倒をかけるよりも、正しい答えを導く方が優秀な生徒」

という刷り込みが行われるからだそうです。

それね~。アメリカって日本と比べると人の考え方が自由なイメージありますが、それでもそうなんですね。

大人になって、いろいろなことを聞くと、

「こいつ、何も知らないアホなんか」

と思われたりするのが怖くて質問できないという人が多いと思います。

でも、質問をしないといろいろなことがわからないですよね。自分の思い込みでいろんなことを判断するのは危険すぎます。

 

というわけで、いろいろと得られるものの多い本でしたが、同じような話が、同じような人の実話で繰り返されるので退屈に感じる側面もありました💦