00:07
4月5日、火曜日ですね。
時刻は朝9時10分を回りました。
すみません、ちょっと寝坊しましてですね。
起きたのが9時。
8時59分に起きてしまったので、
やっと準備が遅れましたけど。
はい、いめみのkkeethこくわはるです。
では、本日も朝活を始めていきたいかなと思います。
はい。
おだいちさんと、
まさひろさんですね。
はい、おはようございます。
毎回ご参加いただきありがとうございます。
今日はですね、
ソフトウェアとかプログラマーとしては超有名なマーティン・ファウラーさんの記事を読んでいこうかと思ってるんですけど、
ケント・ベックさんもざっと探したんですけど、
彼は書籍の方が多くて、あまりブログ的なものが軽く見つからなかったので、
今日は一旦マーティン・ファウラーさんのウェブページから記事を探していこうと思うんですけど、
マーティン・ファウラーのブリキっていう特別なリンクとかURLがちゃんと切られてまして、
そこは気になったのでそれを読んでいこうかなと思います。
マーティン・ファウラーのブリキっていうところなんですけど、
それが一つの記事になってるわけじゃなくて、
かつマーティン・ファウラーは一人じゃないんですよね。
何名かの人と一緒に書かれていて、
そのいくつかの記事をまとめてブリキっていうようなカテゴリーかな、分からないですけど、
に分けれるっぽいんですよね。
その中の記事のいくつかを今日はちょっと読んでいこうかなと思いました。
1つ目にマーティン・ファウラーのブリキっていうページにある記事のタイトルだけスカッと読んでいきますね。
1つ目がデフォルトトライアルリタイヤーってやつですね。
2つ目はリファインメントコードレビューです。
3つ目にプルリクエストですね。
続いてコンピュテーショナルノートブック。
続いてキーストーンインターフェースですね。
続いてアウトカムオーバーアウトプットですね。
ラストかな。
エクスプロータリーテスティングですか。
7つの項目にカッと分かれていて、
この中の全部別にカッと読んでいってもいいんですけど、
多分時間が足りない気がします。
一応でも今日10分オーバーしたので終わりは9時40分の予定です。
その中で僕がちょっと気になったのが
リファインメントコードレビューとキーストーンインターフェースだったので、
この2つを今日はちょっと読んでいこうかなと思います。
正直言うと我々の業界の神様みたいな人なので、
ちょっと気になるというか、
どんなことを言われるのかっていうのをね。
逆で今までこの人のブログとかは全然読んでこなかったのかっていうのは
ちょっと自分でもびっくりはしてますけどね。
では早速読んでいきたいと思います。
まずコードレビューからですね。
コードレビューというと開発チームのワークフローにおける明確なステップを
03:02
思い浮かべる人が多いのではないでしょうか。
最近ではといってもこの記事は2021年の1月28日ですね。
すみませんちょっと救急車がうるさいので通り過ぎました。
私の家の目の前が総合病院なので救急車はよく通るんですよね。
申し訳ないです。
はい、では続き戻りますね。
最近ではプルリクエストで実施される統合前のレビューが
コードレビューのための最も一般的なメカニズムであり、
多くの人がプルリクエストを使用しないことで
コードレビューを行う全ての機会が失われると
部分別に考えているほどであります。
コードレビューに対するこのような狭い見解っていうのは
レビューのための多くの明確なメカニズムを無視するだけでなく、
より重要なことにおそらく最も強力なコードレビュー技術である
チーム全体による永続的な改良を無視することにもなるので
ソフトウェアに最も広く浸透されている考え方の一つというのは
ソフトウェアは私たちが構築して完成させるものだという考え方で
それゆえ建物建設や建築という終わりのない比喩が使われるのですと
すみません、建物であって
それゆえ建物の建設や建築という終わりのない比喩が使われるのですと
しかしソフトウェアの重要な特性っていうのは
ソフトウェアがソフトでありプログラマーのエディターで
最初に構成されたときと同じように
リリース後も簡単に変更ができることです
できはするけど、ネイティブアプリとかは
変更してもリリースするときにまたストアを通さなきゃいけないから
一概にはそうじゃないと思いますが
ウェーブ系であればその通りとおっしゃる通りだなと思いますね
だからこそ、エリック・ドンバン
違う、エリック・ド・ネンバーグさんかな
分からないです、僕が全然知らない方です
という方は建築は悪い比喩であり
街づくりに置き換えた方が良いというふうな賢明な主張をしているのですと言ってますね
はいはいはい
価値あるソフトウェアというのは通常常に変化しているものです
そのソフトウェアがもたらす価値について
より深く理解することで機能が追加されていきます
しかし、新しい機能を追加するだけでなく
そのソフトウェアがどのような変化を可能にするかについて
チームが着実に学んできた教訓を取り入れながら
ソフトウェアを改良する機会もあるのです
さっき言ったソフトウェアの開発というものを
建築というふうに例えるのが悪くて
街づくりに置き換えた方が良いよというところですけど
それについてちゃんと記事のリンクが載っていますね
replacedbytownplanningというのがちゃんとリンクが載っているので
もし興味がある方はそれも読んでいただければと思いました
06:01
続きましてまた読んでいきます
今のところの主張はそうですねという感じですね
だいたい共感が大きいなと思いました
続いていきます
適切な環境さえあれば半年前に書かれたコードを見て
その書き方に問題があることを発見しすぐに修正することができます
これはこのコードが書かれたときに欠陥があったのかもしれないし
その後コードベースの変更によって
このコードが全く正しくなくなったのかもしれないですね
いずれにせよ重要なのは問題が起きたらすぐに修正することです
コードを読んですぐにはわからなかったことがわかったら
ウォード・カニンガムが言ったように
その理解を自分の頭から取り出してコードに落とし込む責任があるんです
そうすれば次の読者はそれほど苦労せずに済むからです
ウォード・カニンガムさんも僕が存じ上げない方なんですけど
でもその通りかもしれないですね
コードを読んでてその瞬間ではわからないけど
一旦自分が持っている理解ですね
途中まででもいいのでとかどこまで理解したかっていうのを
一回頭から取り合いしてそれをコードに落とし込むっていうのは大事なことだと思います
そうすれば次の読者は苦労しないと言いますけど
その次の読者が実は自分かもしれないですね
未来の自分が次の読者になる可能性が大いにあるので
そういうことも踏まえた上で
ちゃんとコードに落とし込んでおくっていうのがいいかもしれないと思います
続いて
この洗練されたプロセスっていうのは
コードレビューで行われるものと全く同じではありますが
コードがコードベースに追加されたときではなく
コードを見るたびに引き起こされます
これは私にとって非常に重要な洞察でした
結局のところコードレビューが改善しようとする問題の多くは
将来そのコードが読まれたときに初めて問題となるものなのです
なるほどですね
ちょっと読みますね
それまでは気にしないほうがいいというのが強い主張なのですと言ってますね
それまでっていうのは将来コードが読まれたときっていうところですね
そこまでは別に気にしないほうがいいっていうのが強い主張なんです
はいはいはい
すると交通パターンが変わるように
6ヶ月後にはコードの文脈が変わり
そのコードが必要とする修正も変わっているかもしれません
またこの方式ではコードを読む全ての開発者がレビュアーとなり
一般的なしばしばあやふやに正当化されるガイドラインではなく
コードの実際の仕様に基づいてレビューすることができるようになるため
09:06
より多くの人を巻き込むことができますと言ってますね
はいなるほどでした
今回のこの記事自体はコードレビューというところに観点を置いているので
分かるかなと
本来のコードレビューはもちろん過読性だったり
次の人が読むためにコードをより良くしたいというのもありますけど
システム的に正しいかとか何か不具合ないかとか
いろんな観点でコードレビューすると思うので
一概にコードレビューが改善しようとする問題っていうのが
将来コードが読まれたときに初めて問題となるものっていうのが
ちょっと僕今ピンと来なかったですか
言ってることは正しそうな気がするんですけど
具体的なイメージができなかったという感じです
いわゆる人にフォーカスを置いたという観点で
コードレビューというのを言うと
確かにその問題は全然あると思いますね
次回の読む人がっていうのは全然それはあると思うので
ただいわゆる比喩的な話として
大規模な集合銃とかを追加すると
交通パターンが変わるっていうのが面白いですよね
これは確かにソフトウェアとかプログラミング室の中でも
同じことは起きるなと思いましたね
6ヶ月ぐらい開発ずっとしていれば確かに
大規模な集合銃になってしまっている状況は
大いにあると思いますよね
そうなったときにコードの流れと言いますか
人の流れもそうかもしれないけど
データフローとかいろんなものが変わってきてる気がするので
修正するやり方とかも変わるかもしれないですね
特にフロントエンドは特にそうかもしれないですね
でもAPIはそんなに大きく変わることは多分ないと思います
最初の設計が割と物を言う領域なので
フロントエンドこそ作りながら物事を決めていったり
分割化したりやっぱりここに統合しようとしたりとか
データ設計するとかって変化するのが大きいかもしれないですね
一般的によく作られるようなガイドラインとか
いろんなルール的なものがありますけど
そんなものができたとしても
コードの実際の使用に基づいてレビューすることができる方が
大事なんじゃないのって思うし
そういう人の方が多くの人を巻き込めるのでっていう話をしました
了解です
続いていきましょう
次元が高いというか
高い話をされている印象がありますね今のところ
続いていきます
ある監修の有効性について考える方法っていうのは
それが独占的なものであったらどうなるかを考えることです
12:01
もしコードレビューの仕組みが
後から来たプログラマーからのイテレーションだけだったらどうでしょう
その結果より頻繁に読まれるコードの領域に
レビューの注意が集中することになります
より頻繁に読まれるコードの領域にレビューの注意
それはそうです
確かにプログラマーのレビューする観点が
イテレーションだけだったら確かにどうなんだろうって感じしますね
それは大抵注意を引くべき領域なのですと
懸念されるのは読まれないコードがレビューされなくなるということですね
それは枯れてればいいかもしれないですけど
枯れたところでよりいろんなプログラムと連携したりとか
相互に関係し合うようなことがもしあるんだったら
そこはレビューに入れたいと思いますね
しかしほとんどの場合それは問題ありません
良いテスト習慣を持つチームはコードが動作することを確信できますし
パフォーマンステストはパフォーマンスの問題を特定することができます
そう考えるともしコードが再び見られる必要がないのであれば
理解しやすくするために能力を使う必要はないでしょう
このようなケースはほとんどないと思いますが
参考となる試行実験です
なるほどね、そういう態度を取る方ですね
はい、テストで担保しましょうってことですね
なるほどでした
再び見られる必要がないんだったらそのまま
ある意味放置じゃないんですけど
ちゃんとテスト習慣を持つチームとしては
それは無視してもいいかもしれないですね
とにかく理解しやすくするための能力っていうのは
今後は別に使う必要はないでしょう
読まれる必要がないので
ただそのようなケースはほとんどないという風に言っているので
もしあるんだったらしっかりテストカバーで
持っておいた方がいいという感じではありますけど
あとはそのパフォーマンステストも
入れておいた方がいいかもしれないですね
後々既存のコードとか以前書いたコードとか
プログラムが原因でパフォーマンスが悪化するみたいなことは
よくある話なのでそういうところも担保する方がいいと思いますね
たとえコードが読まれないとしてもということですね
これは良いチンプスでしたね
では続いていきます
しかしほとんどはニアイコールすべてでありますと言っていますね
そりゃそうでしょって感じですけど
英語的に言うと
but most not equal all という変化ですね
ここで明らかに例外っていうのは
セキュリティの問題ですと言っていますね
コードは攻撃者が悪用を発見
悪用は悪い使い方ですね
悪用を発見するまで何年も問題なく動作します
その時点で私たちはそのレビューの欠如を嘆くでしょうと
ずっと動いてたところに悪い人がアタックをしたと
その時に何年もレビューに欠陥があったと
そういう悪用する方のところが方法があったねっていうことですけど
15:03
を見つけてしまってそれを嘆くでしょうと
それは仕方ないと思いますね
ほぼ事故に近いですね
やっぱり攻撃者がいるよってことは常に意識することは大事だと思います
これは影響が大きいがまれな安全性の問題の例であり
特別な精査に値しますと
しかしだからといってコードレビューの仕組みとして
リファインメントを意識的に利用するべきではないということではないよって言ってますね
むしろまれにしか発生しない高インパクトの懸念事項を認識し
我々の状況下で必要とされる程度まで
その種の特定の問題を監視するために
ワークフローを調整すべきでありますね
あるいは監視のワークフローを作るべきよという話をしてますね
脅威分析によってさらに注意が必要なモジュールと
そのモジュールが直面するリスクの種類を警告する必要はあります
セキュリティ上の懸念がある場合は
対象を絞ったコードレビューが予定されるかもしれません
結局はその観点は多い
監視するような環境であったりとか
準備っていうのはしとくべきですよねって話はしてますね
難しいですね本当に
コードレビューでそこまで担保するかっていうと
セキュリティの勉強
基礎的な勉強は僕らも全然します
頑張ってやってはいますけど
とはいえやっぱり限界はあるなっていうのもありますので
難しいところですね
でも最近だとスニーク社とかが使っている
そのソフトウェアのモジュールだったりとかっていうのを
自動的な検知をして
少なくともバージョンが古かったりとか
ここにはこういうセキュリティエラーがありますよみたいなことを
自動で検査してくれるソフトウェアがあったりするので
僕は結構スニークをお勧めしてますね
開発レベルの自動をやってくれますね
よくあるESLintとかと同じレベルで
スニークがセキュリティのチェックを流してくれたりもします
もちろんそれだとヒントが多かったりするし
そんな開発レベルでセキュリティテストを流されると
開発の体験が悪いので
プッシュするときとか
マージ前のプロリクエストのところで流すとか結構いいかもしれないですね
そういうソフトウェアもありますよということでした
次で最後かな
このような永続的なコードの改良を行うためには
他のプラクティスが必要になります
もし私がコードを変更するのであれば
既存の機能を壊さないという確信がやっぱり必要です
そのためセルフテストコードのようなものが必要です
またコードを変更しても他の人と大きな衝突
18:01
コンフリクトを起こさないというような確信も欲しいと言っています
そこで継続的インテグレーションが必要です
私たちはみんなリファクタリングに長けていて
コードを効率的に変更できる必要があります
これはプログラマーならみんな持つような感じはしますね
リファクタリングではみんな長けてるし
意外とみんなリファクタリング好きだなという感じがありますね
これは多くの開発者がコードベースの任意の部分を
変更することを期待されているということに依存しているので
我々は集団的または少なくとも弱い
少なくとも弱いってどういうこと?
コレクティブかっこオアアットリストウィークって書いてますね
ちなみにそれ自体のリンクが貼ってますね
少なくとも弱いコード所有権を持つことが最善であるという風に言えています
コードオーナーシップを持つことが最善であるという風に言ってますね
これは結構大事な観点ですね
コードオーナーシップはその開発しているメンバー全員が持っておく
っていうのはすごい大事なことだと思います
たまにコードレビューしてくれるけど
そのレビューしてくれる人に依存したりとか
それはレビューが悪かったんで僕の問題じゃないとか言い出す人
僕過去に経験したことあるんで
その人と仕事するのは嫌だなって思いましたけど
逆に言うとチーム開発をしてレビューにも自分も関わっているんであれば
逆に言うと今見ているコードが自分が書いてないものであっても
自分たちのオーナーシップのもとをやってるっていうのを
持つことはすごく大事かもしれないですね
マインドというか観点と言いますか
ちょっと余談でした
しかしこのようなスケールを持つチームがあれば
コードレビューの戦略の実質的な部分として
彼らの定期的な改良を利用することに頼ることができるのです
要はチームに頼れるっていうのが大きいような話ですね
何はともあれコードレビューとしての
リファインメントの役割についてもっと考えることが重要だと思います
マージュ前のレビューにのみ焦点を当てることの危険性の一つっていうのは
コードベースにおいて変更がどのように機能するかを
チームが軽視することにつながってしまいますよと言ってますね
確かにとはいえマージュ前のレビューのみで焦点を当てること
基本的な開発としてはそうなってしまいかねない気がしますけど
ただ機能開発だけで言えばそれはそれで結構だと思いますけど
ちゃんとアプリケーションというかシステムという風に
完成させるところにおいて
いろんな観点のレビューだったりいろんな観点のテストをすることは
すごい重要だと思っていますので
それは皆さんもすると思いますよね
クリティもそうですしパフォーマンスもそうですし
いろいろなんかモンキーテストとかやって
自分たちがそもそも想像しないような使い方っていうのを
結構ユーザーはしたりするのはよくある話なので
そういう観点でもいてモンキーテストをするとか
いろんなテストをするっていうのも一つの準備だと思いますし
21:01
そういうレビューをしていくのもいいかもしれません
もし私が原始的なメインラインを持っていて
原始的なメインラインって言ってることはちょっとよくわからないですね
難しいなー
結構難しい言葉を使われる方なんだな
そのメインラインにマージされる全てのコミットが原始的であること
あー多分違うなこれ原始的っていうのが
えーすいませんこれ約がおかしいな
ディープAを使ってるんですけど
えー原始的プリミティブみたいなワードがどっかで使ってる気がしますね
はい、まあいいや
とにかくメインラインにマージされる全てのコミットが原始的であることを保証したら
そのコードベースが6ヶ月後も原始的であると断言できますかって言ってますね
メインラインっていうのはGitHub的なソースコードのメインのラインってことですね
メインのブランチって言ってもいいかもしれないですね
メインブランチでやっててそこにマージされる全てのコミット
Apple EXOでもいいと思いますけど
が原始的であれば
えー6ヶ月後もそれが同じことが言えるよっていうのは断言できるでしょうかっていうと
はい、それは問いですね
なぜなら6ヶ月前のあるコードに関する良い判断ですね
が今はもう良い判断ではないことを意味するからですと
コードをリファインすることでその変化する使用方法に対して
古いコードを評価することができてその健全性を維持することができますと言ってますね
はい、まあ過去のコードについて
リファインすることができるような体制まで組んでおくのがいいという話でした
以上、でえーっと
リファインメントコードレビューという記事でしたね
はい、まあちょっと言葉的に難しかったりするし
どっちかっていうとなんかマインドセットとか環境周りみたいなところに
視点が置かれたお話だったなっていうのがありますね
でもまあまあ
おおむねその通りだと思ってますし
おおむねこれに従っていくといいんだろうなっていうのはよく分かりましたね
はい、そんな感じでした
ちょっと難しかったのでこれを浅く理解してるのと
あと寝起きで全然言葉が浮かんでこなかったので
本当にタイトル通りグダグダ読んでる感じですね
申し訳ないですけど
はーい、じゃあ残り時間ですね
7分しかないんですけど
もう一個の方の記事ですね
キーストーンインターフェースって方もちょっと読んでいこうかと思います
どこまで学びになるかちょっと分からないですけど
まあこういうのはチャレンジしていくしかないのでやっていきたいと思います
キーストーンインターフェースですね
ここでは2020年の4月29日に書かれた記事ですね
僕真っ先に読んでこれキーストアインターフェースと思ってたんですけど
キーストーンでしたね
タイトルはあってますね
じゃあいきます
ソフトウェア開発チームっていうのは
自分たちの仕事をできるだけ頻繁に統合することで
生活がずっと楽になることに気づきますと
まあまあそれはそうかもしれないですね
24:01
はい
統合って言ってますけど厳密に言うとマッチなので
マージ的な観点ではないということですね
統合は
一致させるというか
まさしく言葉通りマッチですね
マッチングさせるというところだと思いますね
はい
で
また頻繁に本番環境にリリースすることにもちろん価値を感じています
それはそう
しかし中途半端に開発された機能をユーザーに公開したくはありません
この頻繁に対処する
頻繁にっていうのは頻繁に中途半端な機能をリリースすることかな
とにかくこの頻繁なリリースっていうものに対処するための
有用なテクニックっていうのは
全てのバックエンドコードを構築し
統合するがユーザーインターフェースは構築しないことであると言ってますね
機能は統合されテストされますけども
UIは最後まで保留され
要のように機能を完成させユーザーに公開するために追加されます
なるほどね
UIは待て保留するっていう風に言ってますね
なるほど
まずはバックエンドのコードってことですね
気持ちは分からんでもないし実際そうなると思いますね
例えばプロジェクトを始めるとしても
いわゆる本来解決したい大元のソリューションというか目標みたいなのがあって
それを具体的にシステム開発っていうソリューションが選択されたとしましょう
なったときにやっぱりまずやるのは要件定義とか
機能の一覧がガーッと出てきたりとか
これはどういう風に使っていくものだとか
ソフトウェアに何を落とし込むかみたいな話をバーッとしてくるじゃないですか
そこから結局インターフェースって絶対見た目が出てくるので
デザインの話が出てくるのと
バックエンドAPIとあとデータ設計ですよね
みたいな話が出てくると思います
その辺が全部決まっていって
続いてフロントエンドっていうところの領域に話が来るので
最終的にUIが決まっていくっていうのはもちろんその通りだと思っているし
今僕らフロントエンドエンジニアがいわゆる泥をかぶるじゃないですけど
最後の砦みたいなところですね
結局今フロントエンドでビジネスロジックをやろうと思ったら
側の方でも表現できるようになっているので
そういう意味でフロントエンドが大変な領域でいるっていう感じは正直ありますけど
でも仕方ないと思いますね
物事を決めていく流れとしてフロントエンドとかUIっていうところが
最後になっていくのは仕方ないなと思っています
ただでも最後結局ユーザーはその見た目というか
UIを使ってシステムとかアプリケーションを使っていくことになるので
最後要になるのは結局僕らフロントエンドだったりする
っていうふうに意識も僕は持っていたりします
もちろんバックエンドよりフロントの方が大事かというと
そんなことはもちろん絶対ないですね
何をやりたいかというと結局データをどう管理して
どのようにユーザーに表現させたい
ユーザーに何を体験させたいかっていうのがあるので
27:00
デザインも大事ですし
もちろんバックエンドAPIも余裕で大事ですよ
それを僕らは色付けて出すだけみたいな言われ方しますけど
でもその出すところが悪かったらユーザーはやっぱ離れてしまうので
結局全部は大事ですけどね
余談でした
戻ります
この簡単なテクニックですね
の例としてユーザーにですね
顧客に急ぎの注文させることがあります
このような注文っていうのはお客さんがどんに住んでいて
どのような配送業者がそこで営業しているかによって
価値が変わっていきます
商品の性質っていうのは
倉庫で使用されるピッキングアプローチに影響を与えます
配送先や時期に注文された商品の種類によって
急ぎの注文に対応できるお客さんもいるかもしれないですね
特に倉庫とかカタログ顧客サービスなど
様々なシステムとの統合が必要になるため
かなりの量のビジネスログが必要になるでしょうと
他の機能を数日おきにリリースする必要がある一方で
この作業には数週間かかるかもしれないですね
しかしユーザーにとっては
急ぎの注文はオーダーフォームのチェックボックスに過ぎないようです
それはその通りだと思います
裏の作業だったりロジックだったり
連携回りとかっていうのを考えると
更新には実はすごい時間かかる可能性はありますよね
っていう話をしてますけど
これはおっしゃる通りですね
でも確かに急ぎの注文するっていう
オーダーフォームのチェックボックス付けて
注文っていうボタンを押すだけにできないですねユーザーは
それは本当にその通りだと思います
こういう観点はユーザーにもってほしいとは思わないですけど
でも裏でいろんなものが動いてるんだな
ぐらいの想像力を持っていただけると
嬉しいなと思いますよね
とにかく機能開発がお前ら遅いじゃんって言われるのは
つらみしかないなと思いますけど
理由があるから遅いんですよって感じですよね
さっきのチェックボックスですね
チェックボックスをキーストーンとして
これを構築するためにチームは
数回のプロダクションリリースの間に
基礎となるビジネスロジックと
内部システムへのインターフェースの開発を行いますと
ユーザーはこのような潜在的なコードの全てを
意識することはもちろんないです
最後のステップで要となるチェックボックスを
可視化する必要がありますが
これは比較的短時間で行うことができます
このようにして全ての潜在的なコードっていうのは統合され
生産に入るシステムの一部となり
短時間のフィーチャーブランチに起因する問題を
軽減することができますと言っていますね
ここから画像が3枚ありますね
ユーザーがいわゆるシステムを触っていて
その先にいわゆるギアがいっぱい
散らばっている画像なんですけど
最初はWe begin a new feature adding codeですね
我々がまず新しい機能っていうのをコードとして
追加していきますよと
次の画像ですけど
同じ画像ですね
ユーザーが画面を触っていて
30:00
右にギアがあってそこに矢印が飛んでいる
みたいなのが変わらないんですけど
次の画像は
but not adding UI to use it
今足した新しい機能の
UIについてのコードはまだ足しませんと言っています
We can integrate, test and release that codebase
我々はインテグレーションのテストだったり
リリースだったりっていうのを
コードベースで行うときは
with the new logic hiddenですね
可視化されて見えてないところですけど
新しいロジックもそのコードベースに
中に生み込んで
インテグレーションだったり
テストしたりとかリリースすることも
我々はできます
ただまだUIは追加しません
最後に
our last step is to add the keystoneですね
キーストーンという表現がやっと意味わかってきたけど
最後にそれとして
UI、ユーザーが使うシステムの見た目のところに
落とし込むよってことを言ってますね
そういう流れがいいんじゃないのっていうのが
マーチン・ファウラーさんの主張でしたと
気づいたら41分になってしまったので
これ以上読むと皆さんが
次のシフトとか
次のアクションの時間を奪ってしまう可能性が
大変に申し訳ないですけど
あともうちょっと時間かかるかな
読み切ってしまいます
ごめんなさい
もしお時間が都合悪い方は
抜けていただいても大丈夫です
これ後ほどAnchor.fmでも配信しますので
もし興味ある方は聞いてください
じゃあいきます
続いていきますね
潜在的なコードっていうのは
それがアクティブである場合と
同じ程度の信頼性でテストされる必要があります
これはシステムのアーキテクチャがほとんどの
アーキテクチャがほとんどのテストが
ユーザーインターフェースを通して行うように
設定されている場合に可能になります
ほとんどのテストがUIを通して行われないように
設定されている場合は有利
これが流行です
潜在的なコードってそういうことか
ユニットテストやテストピラミッドの
開レイヤーっていうのは
この方法で簡単に実行できるはずです
テストピラミッドっていうのは
いわゆる下に行けば行くこと
流度の細かいテストっていう意味ですね
いわゆる短大テストって言われるのは
そのピラミッドの下の方にあって
次にインテグレーションテストがあって
上に行けば行くことはシステムテストとか
最後は総合テストみたいなところですね
E2Eテストとかも上の方に行きます
そういうものもあります
テストピラミッドでググっていただけた画像
出てくると思うんで
分かりやすいなと思いますけど
この方法で簡単に実行できるはずです
ブロードスタックテストでさえも
非可テストっていう
単体テストにする仕組みがあれば
全然実行は可能ですよと言ってますね
場合によっては
UI自体にかなりの動作があることもありますけど
設計上面に見えるUIを
天井のオブジェクトにすることができるのであれば
これもテストすることができます
すべてのアプリケーションが
33:01
皮の下と書いてるんですけど
英語的にもそんな感じだな
非可か難しいですね
この記事通り非可でいきますね
すべてのアプリケーションが非可で
広範囲にテストできるように
構築されてるわけではないんですよと言ってますね
しかしこれを行うために必要な努力っていうのは
要石を使用する機能がなくても
価値があることなのですと
この方独有の言葉がすごくいっぱい出てくるので
すごく難しいですね
要石キーストーンのことですね
キーストーンを使用する機能がなくても
価値があることなんですよと言ってますね
UIを通して実行されるテストっていうのは
プロセスを自動化する最高のツールを使っても
セットアップに常に多くの手間がかかります
より多くのテストを非可および
階レベルのテストですね
特にユニットテストに移行することで
デベロップメントパイプラインを
劇的にスピードアップし
コンティニュラスデプロイですね
CDを可能にすることができますよと言ってます
これらへんはその通り
もちろんほとんどのUIは
チェックボックス以上のものになりますけども
多くの場合キーストーンにするほどの
作業ではありません
ウェブアプリでは複雑な機能は
独立したページになることが多く
完全にビルドしてすることができ
キーストーンは単なるリンクになります
デスクトップではいくつかの画面があり
それらを表示するための
メニュー項目がキーストーンとなります
いわゆる要素というか
コンポーネントみたいな感じですかね
僕らで言うと
とはいえUIを単純なキーストーンに
パッケージできない場合ももちろんあります
そんな時はフィーチャートグルを
使うことになるでしょうと
しかしこの場合でも
キーストーンを考えることで
機能トグルというのが
UIにのみ適用されることを
保証することができ
そうすると便利になりますよと言ってますね
これによってバックエンドのコードに
多くのトグルポイントが
散在することを避け
トグルを適用する複雑さを軽減し
シンプルなトグル構築を
使用することができ
いざという時
逆に言うと簡単に削除することも
できますよと言ってますね
いきなり出てきた
トグルってことなんですけど
一応フィーチャートグルズっていう
別のリンクがありますね
これももちろんマーチン・ファウラーさんの
ブリキですね
今読んでいる
ブリキの中にフィーチャートグル
っていうページがあるので
そこを見てください
って言ってますね
あともう一個出てきましたね
シンプルトグルメカニズム
ってありますけど
こちらも別のリンクが
貼ってあるので
それを見ていただいても
いいんじゃないのっていう話ですね
じゃあラスト2ブロック読んで
終わりですね
いやもうマーチン・ファウラーさんの
たとえとして
ワードがたとえる
独自なワードが本当に多いので
結構これはコンテキストの
高いブログだなって思いましたね
はいじゃあ最後のブログですね
UIを最後に開発すると
バックエンドのコードが
UIと連動しないように設計されたり
36:01
UIに必要な注意が
遅くまで与えられず
反復の欠如とか
貧弱な誘惑代金に
つながるというような
一般的な危険があります
これはよくある話ですね
フロントエンドが
APIとのつなぎ込みするときに
全然動きませんとか
予想してもどう違ったとか
そういう話とか
細かいところでいくと
このポストに対して
パラメーター足りません
みたいな話とかですかね
いろいろありますけど
それはよくある話だと思いました
はい
でもこんな理由から
キーストーンアプローチっていうのは
小さくても完全に動作する機能を
迅速にリリースするために
縦に薄くスライスして
製品を構築することを推奨する
全体的なアプローチの中で
最も効果的に機能しますよ
縦に薄くアプローチするということは
結局最後のUIまで実装して
それをリリースする
というところが重要だと
言ってますけど
それをなるべく薄くすることで
とにかく細かく細かく
頻度高くリリースをしよう
という観点です
ここではユーザーインターフェースの
例を挙げましたが
もちろんAPIだと
他のインターフェースにも
同じアプローチが使えますと
消費者のインターフェースを
最後に構築し
それがシンプルに保つことで
大きな機能も小さな塊で構築し
統合することができます
はいそうね
スモールリリースができるということですね
ダークローンチですね
ダークローンチっていう風な
ワードを使うの面白いな
そしてダークローンチっていう
これまたマーチンファウラーの
プリキュアの別のページがあるらしいですね
はい
というのがあるので
ダークローンチっていうのは
新機能が構築されると
呼び立たれますけど
ユーザーには結果が表示されない
というバリエーションになりますと
これはバックエンドシステムへの
影響を測定するために行われ
いくつかの変更に有効です
全てがうまくいったら
要素を追加していきましょう
という風な話で
閉じられています
はいすみません
今日はめちゃめちゃグダグダして
大変申し訳なかったし
不運な話だったと思いますけど
一旦今日は以上にしたいと思います
でですね
明日以降どうしようか
また悩ましいんですけど
やっぱりマーチンファウラーさんの
記事の結構有名な記事の
いくつかバーっと
ネットで調べたら
気になってきたので
その辺も気になるので
読んでいきたいとこですけど
明日は一旦また
ウィークリーフロントエンド東京さんの
記事をさようかなと思ったりはしました
なので具体的な
ピンポイントな機能とか
違えばライブラリーとか
フレームワークとかの話を
するかもしれないですし
結局また思想的な話を
するかもしれないですけど
なんかピックアップして
読んでいきたいかなと思います
はいじゃあすみません
ぐだぐだしましたけど
今日の朝活はこちらで
以上にしたいと思います
火曜日ですね
今日も一日頑張っていけたらなと思います
また今日もご参加いただいた
多くの方々
大変にありがとうございました
また明日もよろしければ
一緒に学んでいけたらなと思います
ではお疲れ様です
