00:06
7月3日、日曜日ですね。
ございます。昨日もありました。
本日はですね、ちょっとバタバタと実は準備してて、
昨日の夜、自分と、自分の奥さんですね、と、
2人で、もう1人か、知り合いの3人のエンジニアと、
勉強会を開いてたんですけど、
結構深夜、てっぺん回るまで、
懇親会で結構話が盛り上がってて、
結果、伸びすぎてしまってですね、
頭はちょっと痛いんですけども、
なんとか起きれたので、今からやっていきたいと思います。
ちょっと声が荒れてるというか、
焼けてるかもしれないので、そこだけ申し上げないですけども。
というわけで、さっそくやっていきましょう。
朝活をやりたいと思います。
いぶみのくわはらです。
タイトルにある通りですけど、
今回も、昨日に引き続き、
CUPID、読むのかわからないですけど、
for joyful codingの記事の続きを、
ダラダラと読んでいこうと思います。
前回までで、第5つのフィロソフィーというのがあって、
1つ目がコンポーザブルというやつですね。
2つ目が、何だっけ、
ミニックスフィロソフィーか、ミニックス哲学でした。
昨日はミニックスフィロソフィーまで終わってたので、
今日は3つ目のプレディクタブル、
予測可能性みたいなところですね。
ここから入っていきたいと思います。
予測可能性ですね。
コードというのは見た目通りのことを一貫して、
また確実に不愉快な驚きなしに実行する必要があります。
またそれを確認することは可能であるばかり、
だけでなく容易でなければならない。
確認することは可能だけでなく容易でなければならない。
この意味で予測可能性っていうのは、
テスト可能性の一般化でもあるというふうに言ってます。
テスタブルっていうのは、
プレディクタブルのさらに一般化したものですよってことですね。
なるほど。
予測可能なコードっていうのは、
期待通りに動作し、決定論的で、
まず観察可能であるべきであるというふうに言ってますね。
今のところはその通りなという感じはしますね。
じゃあ行っていきましょう。
Behaves as expectedというところですね。
期待通りに動作をするっていうところからですね。
kentpexのシンプルな設計の4つのルールがあって、
それの一つ目っていうのは、
コードがすべてのテストに合格することだそうですね。
一応その4rules of simple designっていうのが、
記事別に切られてますので、
これは軽く開いてみますけど、
リンクありますね。
一応4つあって、
fewest elementsとreviews intentionとnode deprecationと
03:02
passes the testって書いてますけど、
そのpasses the testが一番プライオリティが高いっていうふうになってますね。
これ気になるので、
明日読んでみようかなと思いますね。
多分今日この記事終わらないと思うので、
明日もし終われば読んでいこうと思います。
じゃあすいません。記事戻りますね。
4つのルールの一つ目は、
コードがすべてのテストに合格することですと。
これはテストがないときにも当てはまるはずです。
予測可能なコードっていうのは、
その構造や命名から意図した動作が明らかであるべきです。
それもそうですね。
これはよくあるリーダブルコードですね。
にもよく書かれてますけど、
変数名もそうですし、関数名かプラス名もそうですね。
ちゃんと意図が分かるものにしましょうっていう、
名前の大事さを絶対語られてますので。
もしこれを実行するための
自動化されたテストがないのであれば、
簡単に書くことができるはずですと。
まあそうだよね。
しっかり名前も分かったりとか、
予測可能なコードができてるんであれば、
テストを導入することは別にそんなに
ハードルは高くないんじゃないかと思ったりしますね。
また、見返るフェザーはこのようなテストを、
キャラクタリゼーションテスト、
特性化テストと呼んでたりします。
で、彼の言葉を借りるんであれば、
キャラクタリゼーションテストって、
しかもそれ用の別でまた記事のリンクがあって、
それも貼られてますね。
で、その彼のキャラクタリゼーションテストの
言葉を借りるんであれば、
ある意味システムが生産に入るとき、
それ自体が使用となるのです。
それはそうでしょう。
持っているときソースコード自体が
使用あったりしますからね。
ドキュメントのような意味もありますけど。
テスト駆動開発を道具としてではなく、
宗教として考える人も実はいるようです。
なるほどね。面白いことを言い出しましたね。
This is not necessaryと言っているので、
これは別に絶対に必要なものではないですよ
という話もしていました。
私はかつて複雑なアルゴリズム取引アプリケーションに
かかったことがありますが、
そのアプリケーションのテストカバレッジは
実は7%程度でした。
使いたくないな。
取引アプリでテストカバレッジ7%は
僕はちょっと使いたくないです。
お金を扱うんですよ。
これらのテストは均等に配置されていませんでした。
コードの多くには自動化されたテストが全くなく、
あるコードには非常に多くのコードがテストがあり、
微妙なバグだったりエッジケースをチェックしていました。
なぜならそれぞれのコンポーネントが一つのことを行い、
その動作は単純な予測可能であるため、
大抵の場合変更は明らかだからです。
ほう。
ん?本当に言ってるの?
テストカバレッジ7%だったと言ってるけど、
06:03
うーん、何か意図がちょっと分かんなくなりました。
自動化されたテストが全くなくて、
あるコードには非常に多くのコードがテストがあり、
そのようなテストというのは自動化していないテストですね。
はいはい。
自動化されたテストがないから、
カバレッジも7%だったということなのかな?
ちょっとよく分かんないな。
ちょっとその意図が。
どういう意味か分かんない。
ただその一つのところに思いっきり超高度なテストがあって、
微妙なバグとかエッジケースをひたすらチェックをしていた。
なぜならそれぞれのコンポーネントが結局一つのことを行って、
その動作は単純な予測可能である。
ああ、そういうことか。
なるほどですね。
別にカバレッジ100%を目指さなくても、
アプリケーションとしても、
そこ一つに注力をしていけば別に問題はないというか、
そのやろうとしている、
使おうとしているものの品質的なところは担保できるということかな。
はい。
動作がやっぱり単純で、かつ予測可能でもある。
し、大抵の場合変更は明らかにあったからということですね。
確かにそういう意味で行くのであれば7%もいいですけど、
同性テストを書くならやっぱりカバレッジを上げたいというのはありますけどね。
僕ら開発者としても安心はできるというのもあるし、
後ほどの追加開発だったり拡張したりとか保守するときの観点でも
あったほうが僕はいいんじゃないかなと思ったりはしますけどね。
はい。
まあまあいいや。
ちょっと続きいきましょうか。
これ自動化されたテストがそもそもなかったり、
そのテストは均等に配置されてなかったと言っているので、
まあそうかもしれないですね。
テストコードを書いていったらさすがに各メソッドを実際通るとかっていう話もしたりするし、
結果的にカバレッジは上がると思うので、
実際このアプリケーションがテストコード導入、自動テストですね。
が導入されるんだったらカバレッジは上がると思います。
まあでもある意味でその予測可能性というところの一つですね。
機体通りに動作するっていうこのセクションの趣旨でいくのであれば、
別に100%というかカバレッジを上げなくてもいいし、
そもそも予測可能であるし、
やることがやっぱり明確になってて分かりやすく、
単純になっているのであれば別に7%でも
ちゃんとアプリケーションとしての品質が担保できるようなテストも実は用意できますよっていうことだと僕は思いました。
はい。
じゃあ続いていきましょう。
次はですね、ディターミニスティックですね。
いわゆる決定論的代表の話をしてですね。
ソフトウェアは常に同じことをするべきだと。
非決定論的に設計されたコード、例えば乱数発生器とか動的な計算であっても、
定義可能な動作または機能の境界があるはずですと。
メモリやネットワーク、ストレージ、処理の境界、時間の境界、
他の依存関係に関する期待値を予測できるはずですと。
09:02
決定論っていうのは幅広いテーマでありますと。
予測可能性を目的とする場合、決定論的コードっていうのはすごい堅牢で、
信頼性が高くかつ弾力的であるべきですと。
堅牢性っていうのはカバーする状況の幅や安全性のことを言ってます。
限界っていうのはエッジゲース。
限界やエッジゲースがその代わり明らかになるべきですってことですね。
信頼性っていうのはカバーする状況において期待通りに動作することですと。
毎回同じ結果を得られること。
適当性に近いですね。
最後、回復力。
さっきは翻訳したときは弾力的であるって言ったけど、
今回は回復力っていう風に翻訳されてますね。
多分弾力性の話だと思いますけど。
これはカバーできない状況、
つまり入力や動作環境における予期せぬ節度に
どれだけうまく対処できるかっていうことです。
この3つが大事ですねって言いました。
続いて、オブザーバブルですね。
観察可能なってところのセクションですね。
コードっていうのは制御理論的な意味で観測可能でなければなりません。
これは設計時にのみ可能です。
複数のコンポーネントが相互採用すると、
特に非同期ではすぐに創発的な振る舞いと非線形な結果が発生します。
コードを最初からインストルメント化するっていうことは、
その実行のとき、実行時の特性を理解するための貴重なデータを得ることをイメージします。
私は4段階のモデル、2つのボーナスステージがある。
4段階のモデルを次のように説明します。
それは4段階だけど、現実には2つのボーナスがあるから6個だって言ってます。
4つの方はですね、
インストルメンテーションとテレメトリーとモニタリングと
オルタ…ん?
オル…ちゃうわ。アラーティングですね。はい、失礼しました。アラーティングです。
一個一個いきましょう。
インストルメンテーションっていうのは、あなたのソフトウェアが何をしているかをまず明らかにすることです。
次、テレメトリーはプル型、つまり何かを求めることであればプッシュ型、メッセージを送るなどであれ、
プル型であれ、プッシュ型であれ、その情報を利用できるようにすることです。
3つ目はモニタリングで、モニタリングはインストルメンテーションを受信し、それを可視化することです。
はい、最後はアラーテーションですね。アラーティングか。アラーティングは可視化された…
もう今日ひどいな。監視されたデータ、あるいはデータのパターンに反応することですって言ってます。はい。
で最後、ボーナスの2つですね。
ボーナスの2つはプレディクティングとアダプティングですね。はい、プレディクティングは予測の話ですね。
12:04
はい、予測っていうのはデータを使って事象が起こる前に予測することですって言うんですね。はいはい。
なるほど。前に予測することですね。これは確かに良いシステムですね。
はい、で最後アダプティングですね。これは適応っていう意味ですけど。はい。
適応とは予測された節度を先取りし、そこから回復するために…回復…バウンディングかな?
はい、回復するためにシステムを動的に変化させることですと言ってますね。
今回はリカバーとかちゃんと回復ですね。っていうところでした。
いわゆるほとんどのソフトウェアっていうのはステップ1を通過することさえできません。
ステップ1ってのはインストゥルメンテーションですね。
インストゥルメンテーションっていうのはソフトウェアが何をしているかを明らかにすることですって言ってますけど、
ここすらまず最初通過しないことが結構多いらしいですね。
はい、実行中のシステムを防御したり変異させたりして動作速力を高めたりするツールっていうのもありますが、
アプリケーションに設計された意図的なインストゥルメンテーションにはかないませんって言ってますね。
それはそうですよね。外部的にいろんなものを導入したりとか便利なツールを入れるのは全然いいですけど、
そもそものアプリケーションがやっぱりしっかり設計されていたり、
意図的な分かりやすさとか予測可能性みたいなところですね。
に特化していることには勝てないというのはその通りだと思いますね。
以上、すみません。朝からやっぱりちょっとグダグダしたんですけど、
3つ目のフィロソフィーであるPredictableのお話をしてきました。
すごい共感性も高いですし、
やっぱり3つ目読んでて思いましたけど、
昨日読んだ1つ目2つ目にもやっぱり通じるところがあって、
今はどこのこの5つのフィロソフィーというか要素って言うんですかね。
どれを今注目してコードを書いていくのかっていうのに
意図を置くのは結構いいことだと思いました。
書いている途中であったりフェーズであったりとかレビューだったりとか段階とか色々ありますけど、
それに応じて今からはちょっと別のフィロソフィーでやりましょうみたいな風に使うのが
多分この5つのフィロソフィーの使い方かなと思いました。
本当に前回読んだ通りで相互作用してるなっていうのがよくわかりますね。
やっぱり内容をちょっと被ったりというか、
他の分野とこれって同じような話だったりするんじゃないのとかいうのがよく出てきますね。
出てくるんですけど、やっぱり観点の違いがやっぱり大きいと思います。
観点というか思想ですかね。
僕らは今この観点でこの物事とかこの原則みたいなところに従っているなという風に感じるので、
それによって物の見え方というか次のネクストアクションが違うなという風に感じましたね。
はい、じゃあ余談が過ぎたので次行きましょう。
4つ目です。
ちょっと翻訳するので少々お時間をお待たせいただければと思います。
15:03
4つ目が長いので。
4つ目はちなみにIdiomaticってやつですね。
なので…
Idiomaticやばい、なんだ。
まあIdiomなんですけど、日本語にするとやっぱり文法じゃなくて公文とかじゃなくて簡易翼ですね。
はい、出てきた。
じゃあ行きましょう。
ちょっと今は二日酔いで頭フラフラしてるんですけど。
はい、いいわけですね。
じゃあ行きましょう。
簡易翼です。
コーディングのスタイルってのはもちろん人それぞれになります。
スペースとタブの使い分け、インテントの大きさ、変数の命名規則、中括弧や括弧の配置、ソースファイル中のコードのレイアウト、
その他数えきれないほどの可能性があります。
これにライブラリ、ツールチェーン、ライブウェイのパス、バージョンコントロールのコメントスタイルやコミットの流度など、
いろんなものの選択肢を重ねることができるのです。
あなたはバージョンコントロールを使っていますね。
まあそうですよね。
残念ながらこの国ではバージョンコントロールを使っていないけどシステム開発をしているという現場はまだ多分数えきれないほどあるんだと思います。
まあ過労死でSVNというのを使っているという状況を見たことも去年かな、1回ありましたね。
バージョンコントロールやってますよって言われたし、生体管理しっかりやってますって言って、
ギットかなと思ったらSVNですって言われて、しかも自社バーボですって言われて、
ほーそうかーそうですかーっていうところも僕も経験しているので、
まあでも使ってないよりはマシだと思いました。
ただギットに移行しなかったのでわざわざ、
えーとなんだっけ、トータスSVNだっけ、なんか久しぶりに、
あ違うトータスSVNじゃないですね、なんか別のSVNを確かに入れましたね。
いや懐かしいと思ってましたけど。
はい。
余談がしすぎますね今日は。
はい戻ります。
このようなことはやっぱり慣れない行動を扱う上で、
余計な認知的負担を増やすことになりかねませんと言ってます。
これも記事がありますね。
エクスターナスコグニティブロードかな、
エクストラナフ、エクストラナスコグニティブロードっていうことで、
はい認知的負担ですね。
これについてもまた別途記事のリンクが貼ってます。
ちょっとだけ見ます。
ちょっとだけ見ますが、
これはコグニティブロードっていうウィキペディアのリンクですね。
すさまじい。
やっぱ長いですね。
長いのはリファレンスの量が51個もあるからです。
すごい。
記事自体はそこまで長くはないですね。
ただもちろん一発で1日で読み切れるとは思わないんですけど。
気になったら軽くガッとこの後読んでみて、
気になったら別でちゃんと朝から読みたいと思います。
18:04
では戻りまして、
慣れないコード扱いで余計な認知的負担を増やすことにはなりかねません。
いろんなコーディングのスタイルが人それぞれであって。
問題領域と解決空間を理解するだけでなく、
誰かが何を意味するのか、
そしてその決定が意図的で文脈的なのか、
恣意的で監修的なのかっていうのを解釈しなければなりません。
ユーザーへの共感、サポートへの共感、将来の開発者への共感、
それのいずれもが将来の自分かもしれません。
いいことを言いますね。
未来の自分も他人ですし過去の自分も他人です。
人間が理解できるコードを書くということは、誰かのためにコードを書くということです。
これがIdiomの意味だと言っていますね。
この文脈ではあなたのターゲットオーディエンスは以下の通りですと。
オーディエンスは大体3パターンに分かれているそうですね。
1つは言語、ライブラリ、ツールチェーン、エコシステムを熟知しているというところ。
2つ目がソフトウェアを理解している経験豊富なプログラマー。
最後は仕事を成し遂げようとしている人。
この3つがターゲットのオーディエンスだそうですね。
わかりました。
まずは言語ですね。
Language、Idiom。
言語のIdiomですね。
まずコードですね。
コードはその言語のIdiomに従わなければなりません。
言語によってはコードがどのように見えるかについて強い意見を持つものがあり、
あなたのコードがどの程度寛容的であるかを簡単に評価することができます。
また、あまり意見を言わない言語もあり、その場合はスタイルを選択し、
それにこだわる責任が生じます。
GoとPythonは意見が分かれる言語の2つの例です。
僕は実はGoとPython両方ともまだ書いたことがないですね。
文法だけサラッと舐めただけなので。
わざわざこれについて説明があるので読んでいきましょう。
Pythonのプログラマーは寛容的なコードを表現するために
Pythonicという言葉を使います。
いいですね。
そういう言葉があることがそもそもいいですね。
Python REPLからこれをインポートするか、
シェルからPython-m disを実行すると現れる。
素晴らしいイースターエッグっていうのがあるそうですね。
イースターエッグっていうのがよく分からないですけど。
イースターエッグもリンクが貼られてますね。
Wikipediaにイースターエッグっていうところのリンクが貼られていました。
もしかしたらPythonエンジニアの方々はご存知かもしれません。
これはThe Zen of Pythonと呼ばれるプログラミング格言のリストですね。
同時しその中にこの一行が含まれており
寛容的なコードの精神を表現しています。
21:03
すみません、僕はZen of Pythonっていうのだけは知ってました。
それがイースターエッグのところにあるんです。
これは逆に言うと気になったので後ほど見てみたいと思います。
じゃあ続きますね。
それを行うための明白な方法は一つであるべきで、
できれば一つだけであるべきだ。
これ昨日も出てきたワードですね。
なるほど。
結構この方はThe Zen of Pythonっていうところに結構重きというか、
信頼性を置いてるんだなっていうのはよくわかりました。
でもこれは僕も共感大きいですね。
行うための方法は一つで、
しかも一つであるべきだっていうのは正しいと思いますね。
寛容的なコードの精神ですね。
続いてGoの話ですね。
Go言語にはGoFmtというコードフォーマッターというのが付属していて、
付属してないですね、そもそも。
すべてのソースコードが同じ見えるようになります。
なるほど。
Pythonと似てる感じですね。
Pythonはインデントがすごくきついというか、
強制力の高い言語なので。
これによってインデントや中格好の位置、
その他の構文の伏線に関する意見の相違を一気に解消することができます。
つまり、ライブラリーのドキュメントやチュートリアルで見る
どのようなコード例も一貫してみるように見えるのです。
Effective Goというドキュメントもあり、
言語定義を超えた寛容的なGoを紹介しています。
Effective Goもちゃんとリンクがあるので、
これも後で眺めてみよう。
各言語それぞれでそういうのがあるのがいいですね。
ちなみにPythonの、僕は書いてなかったけど、
後輩の子がPythonやってた子が一人だけいまして、
その子に聞くと、さっきのThe Zen of Pythonはほんとに、
基本的にPythonエンジニアは、
うも言わさずこれに従うみたいなぐらい結構強いものらしいですけど、
逆に言うとそれだけ信頼性も本当に高いものらしいですね。
だからみんな同じようなコードになるって言ってて、
言語の生態系レベルでそれが成り立っているっていうのは、
すごいということは言いますね。
こんだけプログラミングって、プログラマーはそれぞれ各人で、
やっぱりなんだかんだ癖が出てきたりとか、
考え方、好みがいて結構分かれるんですけど。
でもPythonという言語においては、
最終的にみんなこのThe Zen of Pythonに従っていくし、
それによってはフォーマッターとかの解釈とか、
書き方とかっていうところに従うので、
結構コードが似るっていうのは、
僕はある意味で素晴らしいことだと思いますね。
レビューもしやすくなりますし、
意図が分かりますね。
みんな同じようなコードを書くので、
読めば分かるっていうところがはっきりするので、
すごくいいなと思いましたね。
Goにもそれと似たようなものがあるんですかね。
GoFmtというフォーマッターが、
しかも最初から言語そのもの付属してるんで、
みんなこれを使うんじゃないかなと思いますね、おそらく。
24:02
JavaScriptみたいに、
いろんな何たらリントとかヒントみたいなのが、
乱立しなくなるのがいいなと思いました。
最近はJavaScriptでもESリントほぼ一択だと思いますけど、
いいなと思いましたね。
それはリンターで、フォーマッターか。
フォーマッターは多分Pretierになると思いますけど、
ESリントFixっていうのもあったりするので、
どっちに従うのかなっていうのは、
別の議論でありますけど。
それをGoの場合は、
さらにEffectiveGoというドキュメントもあって、
それを見て、
言語の定義を超えた寛容的なGoを紹介するので、
それを見てみるのもいいんじゃないかという話でした。
なるほどね。
僕はGoを全然知らなかったですね。
これも気になりました。
どんどん続けましょう。
残り4分しかないので。
もう一方の端には、
Scala、Ruby5、JavaScript、
そしてユージョワルパールのような言語があります。
パールっていうのは、
TiMtoWtDi、
なんていうのかわからない。
なるほど。
Tim Todayって発音するんですね、これ。
Tim Todayって発音しますけど、
別にはTiMtoWtDiっていうことです。
っていうものがあって、
正しくこれを訳すと、
There is more than one way to do itということですね。
ということですね。
それの頭文字を作りました。
っていうのがあるらしいですね。
そのパールっていうのは、
Tim Todayの頭文字を取ったもので、
Tim Todayの発音をしますっていうのは、
重複して書いてるんですね。
関数型、手続型、
オブジェクト思考のコードを書くことができ、
言語を知っていても浅い学習曲線となります。
パールにはそういうのが用意されてるんですね。
これはパール5、6からかな。
もっと昔からののがあるんだったら素晴らしいなと思いますね。
値の並びを処理するような単純なものであれば、
これらの言語のほとんど、
次のようなことができるようになります。
イテレーターを使うことができます。
インデックス付きのfor loopを使うことができます。
条件付きのwhile loopも使えます。
関数パイプラインとコレクター、
マップリダクションというのは使えます。
あと、末尾の最適的な関数を書くことができます。
つまりそれほど大きくないコードであれば、
このような例をそれぞれ見つけることができ、
また互いに組み合わせて使うこともよくあります。
で、繰り返しになりますが、
これらはすべて認知的負荷を与え、
目の前の問題について考える能力に影響を与え、
深く実践を増大させ、喜びを減少させます。
for loopはそうですよね。
基本的にいわゆるループ的なものとか、
イテレーター的なものとか、
さらに何だっけ、
再起的なものですかね。
確かに認知的負荷は急に上がります。
コードイディオムというのは、
関数、型、パラメータ、モジュールの命名、
コードのレイアウト、モジュールの構造、
ツールの選択、依存関係の選択、
依存関係の管理方法など、
27:01
あらゆる流度のレベルで発生します。
テクノロジースパックがどのような
意見を持っていようとも、
その言語のイディオム、エコシステム、
コミュニティ、好みのスタイルなど、
時間をかけて学べば、
あなたの書くコードは、
より共感されやすく楽しいものになるはずです。
ある技術に対するあなたの学習曲線は、
あなたがその技術で書いたコードよりも
短命である可能性が高いので、
今すぐあなたにとってよく読めるコードを書きたい
という衝動を抑えることが重要です。
うむ、それはすごくわかります。
その人は長くは存在しないはずですから。
そうですね、それも確かにそうと思いますね。
イディオム的なコードを書いていると
確信する唯一の方法は、
時間をかけてイディオムを学ぶことです。
はあ、結局そういうことになるのか。
最後ですね、ローカルなイディオムですね。
ローカルイディオム、ずっと書いてますけど。
官用句のスタイルについてコンセンサスがない、
あるいはいくつかの選択肢がある言語の場合、
良いとはどのようなものかを決めるのは
あなたとあなたのチームであり、
一貫性を促すための制約やガイドラインを導入するのも
あなた次第ですと。
これらの制約はIDEにおけるコードフォーマットルールの共有、
コードのリントと批評を行う、
レビューとかですね、行うビルドコップのツール、
もしくは標準ツールチェーンに関する合意など、
単純なもので良いよと言ってましたね。
一応リントっていうところにWikipediaのリンクがありますね。
ソフトウェアのリントなので、
僕らがよく使っているリントの話だと思います。
で、アーキテクチャー決定記録6っていうのがあるらしい。
6っていうのは単純にこの記事のリンクのことですけど、
アーキテクチャー記録っていうのがあって、
厳密に言うとアーキテクチャーディシジョンリコースか、
こちらもちょっとADRっていうのがあるらしいですね。
っていうのはスタイルやイディオムに関する
あなたの選択を文書化する素晴らしい方法です。
一応これのリンクも注釈にあります。
この人は本当にいろんなドキュメントとか、
本とか論文とかいろんなものを読んでますね。
これらは他のアーキテクチャーの議論と同様に、
重要な技術的決定であることに変わりはないですよと言ってました。
なるほどね。
このADRっていうのが素晴らしい方法なんですけど、
他のアーキテクチャーの議論と同様で、
技術的決定であることに変わりはないよってことを言ってますね。
こういうのもありますよってことでした。
ローカルなイディオムって言ってますけど、
そんなに今まで読んできたイディオムとあんまり変わりはないかなって思いましたね。
ただそのスタイルについての、
イディオムのスタイルについてのコンセンサスがないとか、
もしくは複数の選択肢があるっていう場合ですね。
そのときに何を良しとするかっていうのはローカル、
つまりあんたが所属するチームとかメンバーとかの、
しっかり合意を取りましょうという話でしたね。
30:02
その代わり一貫性を促すための、
約安のガイドラインを導入するのも、
やっぱりあなた次第ですねって言われてますね。
本当に細かいルールだったら、
確かにリンターとかのフォーマッターのルールを決めて、
それをドキュメント化っていうか、
コードに組み込んでって自動で判定するようにすればいいんじゃないかなと思いますね。
でもそんな複雑じゃなくて単純なものでいいよって言ってましたね。
何ならば別にそのルール細かく決めなくて、
最初は適当にインターネットで公開されてるとか、
よく使われてるなみたいなものを一個選んで、
そのルールに従っていくのもいいんじゃないかと思いますね。
とにかくみんながちゃんと分かりやすく、
予測可能性とかのところが大事なので、
そのためにツールを入れるんだったら、
細かくやるのは走り始めた後でいいんじゃないかと思いましたね。
というところで、すみません。
予想通り今日1日で終わりませんでしたね。
これを読んだのはPredictable予測可能性と、
あとIdiomaticが4つ目ですね。
簡易枠っていうところの4つ目でした。
では最後ですね。
明日はこのドメインベースってところを読んでいきたいと思います。
明日で頑張って終わらせたいなと思いますけど。
ドメインベースと読んだら最後、
Concluding Sortsという方で、
結論的考えのところを読んで終わりにしたいと思います。
じゃあ多分これ終わりそうですね。
という感じで、今日もダラダラ読んできましたけど、
あさかつこれで終了したいなと思います。
日曜日ですので、皆さんもゆっくりお休みいただければと思いますし、
影響を養っていただければなと思います。
暑いので体調管理だけ要件をつけていただければなというところでした。
ではこれであそこで終わります。
お疲れ様でした。
