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はソース読めるようになりたいな、と改めて思いました。。。

PHPお手軽スタートキットを作った

petproject

先日、色々と調べごとをした結果を踏まえて「よ〜し、いっちょ自分でコード書いて試してみっかな！ライブラリでも作るかい！！」って気分になりまして。
その際に↓みたいなツイートをしていたのです。この辺りの”標準”みたいなのあんま分かってないな〜って。

いちいち「何が必要かな・・？」って考えるの結構ストレスになりそう。CIとかテスト周りとか整えるのも面倒くさくない？
そんな事をボヤボヤと考えている内に「そういえばGitHubにテンプレートプロジェクトって機能があったよね、使ったこと無いな」と思ったので、「ぼくのかんがえる最低限整ったPHPプロジェクトの雛形」を作ってみました。

github.com (コミットがメッセージも切り方も適当すぎてぶん殴られそうですが・・)

「今どきなPHPプロジェクトってどういう感じなんだろ？」っていうのにも興味があり、自分なりに考えて”それっぽいやつ”は入れてみたつもり。

なお、必要なツールを考えるにあたってこのPHP QAツールがすごい！2019を参考にさせていただきました🙌

なにができるの

  • ✅ PHPの実行環境としてDockerfileを入れてある
    • IDEから叩くような想定。というかPhpStormのCLI Interpreter
    • 一緒にmysqlも入れた、docker-composeで使う
  • ✅ ↑にXdebugが入れてある
  • ✅ PHPUnitをサクッと動かせるようにphpunit.xmlを入れてある
    • 地味に書き方忘れません？
  • ✅ PHP_CodeSniffer, PHPStan, Psalmも入れてある
    • 「最初から入ってれば負担も少ないはずだ」と思って、レベルはぎっちぎちにした
    • phpcsはPSR-12とSlevomatCodingStandardベース、PSR-12とぶつかるルールとか一部緩和
    • phpstan-strict-rulesとphpstan-phpunit入れた
    • psalm/plugin-phpunitも入れた
  • ✅ GitHub Actionsでphpunit phpcs psalmを叩くようにしてある
  • ✅ ↑を実行した時にreviewdogでコメント飛ばすようにしてある

作ってて思ったこととか

  • とりあえず「最低限」ってレベルならコレでいけそ、って感じにはなった
    • 色々と触りながら育てていく前提
    • lint周りとか色々と気になる部分出てきそう
  • GitHub Actions自分で触ったこと無いんだよな〜〜*1やりたいな〜って気持ちもあったので、少し欲求が満たされた。良かった
    • CIの設定ファイルだけ入れておけばすぐに動くの便利だな、すげーやGitHub Actions
    • 毎回Dockerイメージをbuildしてるからキャッシュとかした方が良いんかな？
  • codecovとかのよく使いそうなSaaSの記述はどうしようかな、と思ったけど一旦入れてない
  • READMEファイル置いてあるけど、このレポジトリの説明どこに置けばいいんだろ？
    • READMEとREADME-exampleみたいなのを分ける必要がありそうだな、紛らわしいし
  • バッヂ類は充実させたいな！
  • composerのcreate-projectも対応させてみよ。やったことないし

他の人の考えたやつも見てみてぇ〜な〜〜

*1:後になって気づいたけどやった事あった・・w https://github.com/Connehito/cake-sentry/pull/35/files

BASE株式会社を退職しました

前にも働いている会社を退職した事があったのですが、この度BASE株式会社を退職しました。 1社目・2社目はそれぞれ4年前後在籍していたので、そこから比べると期間的には短くなりますが、色々なものを初めて見たり学ばせてもらえたんじゃないかな〜と感じています。

続きを読む

やったこと・書いたもの{2020,07}

やったこと・書いたもの

OSS

github.com ずっと鬱陶しがってたやつ直した。
ぐちゃぐちゃと考えないで、ごくごく単純なやり方で良かったなぁと気づいた・・・・

github.com 以前cake4対応を完了したのをawesome-listに対応してもらったもの。
3.0.1が出てからでいいかなぁ〜とか思ってたけど何もバグ修正や更新が現れないので、そろそろいっか！となり。

勉強会・LT

その他