00:04
11月14日、月曜日ですね。
時刻は朝9時を回りました。
最近僕のiPhoneが不調なんですが、
いろんなサイトやアプリだったりとかから、
シェアする機能ってあると思うんですけど、
スラッグにシェアをするっていう、
いつも通りこの朝活も僕、社内スラッグにシェアしてるんですけど、
なんかシェアできないんですよね。
シェアボタンをタップしても、
ずっとローディングが続いてて、
遅れないことが起きてですね。
昨日の夜からずっと起きてるんですよね。
どうも僕自身が、
そういう何かを持っているのかもしれない。
Apple製品と相性悪いのか、
ガジェットと相性悪いのか、
そういうものを引き寄せる何かを持っているか分からないですけど、
まあいいや。
というわけで、余談でした。
はい、おはようございます。
では、本日も朝活を始めていきたいと思います。
本日はですね、
リーダーシップとかテクノロジーではなくて、
マネジメント系の方を読みたいと、
言っておきながらですね、
気になったのが、
いろんな朝活の記事を読んでるんですけど、
その朝活の記事の中で、
海外の記事のほうがバッド的に多いんですけど、
いろんな引用だったりとか、
リンクだったりが貼られてて、
そのリンク先のものをちゃんと読むってなかなかなかったので、
それもったいないなというのを、
せっかく技術的なところの共有だったり、
いろんな海外のいい記事を紹介されているので、
それを読まないのはもったいないなと思ったので、
それを今日1個ピックアップして、
読もうと思った次第ですね。
今日は技術的な記事のほうに、
ちょっとなっちゃうんですけど、
タイトルにある通り、
コロケーションってやつですね。
先日読んだCSSの記事があって、
CSSクラスネーミングコンベンション
might still be your best choice
ってことですね。
クラスネーミングにおける
CSS設計の良さっていうところ、
おすすめだよみたいな話の記事を、
数日前に読んだんですけど、
なかなか面白く、
CSSの設計だったりとか、
クラス設計ってあると思うんですけど、
そのCSSの設計として、
名前空間として、
クラスネーミングのほうが汎用性高くていいんじゃないの、
みたいな紹介記事の中で紹介された
コロケーションっていうのがあって、
これを今日は読んでみたくなりました。
今日は時間短いかもしれないですね。
この記事自体が8分ぐらいで読み終わるよ
ってことで書いてあったので、
短いんですけど読んでいこうと思います。
この記事自体が2019年の6月17日なので、
内容自体はちょっと古いんで、
あれですけど、ただ、
CSSの書き方とかではなく、
設計だったり思想周りのお話っぽいので、
通用するものはまだまだ今日、
本日でもあるでしょうと思って
読んでいこうかなと思っています。
どれぐらい効果あるかちょっとわからないですけども、
はい。
なかなか設計のお話って読める機会が少ないので、
しっかり読んでいこうかなと思います。
ついつい方法論だったり、
書き方だったりみたいな、
具体的な話ばっかり言うけど、
たまにはマクロ視点の話も読もうかなと思っています。
では早速いきたいと思います。
かけだしのろうがいさんですね。
おはようございます。
ご参加いただいてありがとうございます。
タイトルなる、これCSSのお話ですね。
03:01
ぐだぐだ、だらだらと読んでいく感じですので、
読みたい人ご注意いただければと思います。
では早速入っていきましょう。
私たちは皆、
メンテナンスしやすいコードベースを
持ちたいという風に願っています。
ですから最初は自分のコードベース、
あるいはコードベースの一角をメンテナンスしやすく、
理解しやすいものにしようと、
善意で始めていきますと。
しかし時間が経つにつれて、
そのコードベースが大きくなってくると、
依存関係、JSCSS画像などなどというのを
管理するのがやっぱり難しくなってくる場合があります。
プロジェクトも大きくなるにつれて、
そのコードベースというのが
部族の知識、
あんたや他の数人しか知れない知識になってしまう。
要は関わっている人にしか知らない知識ということですね。
になってしまって、
この種の知識というのは
その部族の知識というのは
言葉が正確かどうかは別としても、
技術的不才能一員となるよということになります。
ドキュメンタリーをしっかり公開していたりとか、
いろんなものをちゃんと言語化して
見えるところに置くと言っても、
結局知識そのものはやっぱり中の人、
書いている人じゃないと
分かり得ない知識ってたくさんありますよね。
こういう癖があるよとか、
ここはこういう風な方針になってますよとか、
暗黙の了解的なのも結構あったりすると思うので。
結局はそうなってしまうけど、
別にこれは
わざわざと
結果としては悪いんですけど、
仕方のないことだと思います。
それは技術的不才能一員となるので、
どの開発プロジェクトにも
必ず不才は抱えるということですね。
つまりは。
私はコードベースを
自分が書いた人だけでなく、
チームメイトや将来のメンテナーとか、
将来のコミッターとか
の人たちのことも考え、
そして6ヶ月後の自分自身にとっても
管理しやすいものにしておきたいと
考えています。
6ヶ月後ということの根拠はちょっとわからないですけど、
まあ要は未来の自分は他人ですよね。
過去の自分は他人っていう。
本当同じことだと思います。
たぶん3日前の自分とか絶対他人なので、
自分のコードだとしても他人と思って
眺めるのはいい話だと思いますし。
これは私たちがコードベースで
目指すべき素晴らしい理想である
ということは誰もが認めるところでしょう。
これを達成するために
私たちが自由に使えるたまざまな
作りやテクニックっていうのがありますと。
なるほどですね。
ちょっとなんか保守性とかのお話に近いものかな
と思いましたね。
1つ目のセクション。
Let's talk about code comments.
まずはコードコメントについて話しましょう。
私はですね、
コードをコメントするべきかどうか
っていうところですけど、
コメントはどうあるべきか、
予想外のことをする理由とかを
コメントで説明して、
後から来た人がその予想外または奇妙な
コードになった決定事項っていうのを
理解できるようにします。
そういうどうあるべきかについては
話したくありませんと。
もうそのまま話してるからってことかな。
なるほど、それについて少し話したかった
かもしれません。
ちなみに僕の観点でいくと、
大体この方とおっしゃる通りですね。
コメントはすべきですし、
コメントするものは何かっていうと、
ぱっと見わけ分からないものとか、
やってること自体は
理解してるけど、なんでこれをやるかが
06:01
分からないようなものについてコメントします。
つまり、このコードについて
思想を知ってもらわなきゃいけないときに
コメントを書きます。読めば分かるもの、
意図も分かるものっていうのは基本コメントは
しないようにしてますね、僕は。
はい、これはそういうところですね。
やってることは見りゃ分かるし、
コードを書いてる人ならば
読めば分かるのは絶対そうなので、
思想はコードに現れないからちゃんと書きましょう
っていうのは僕はあると思いました。
今回の記事はその代わりに、これらの
コードコメントがどこに配置されているか
っていうところに注目をしたいと思います。
えー、どこなんですね。配置先ですか。
私たちは一般的に
これらのコメントを説明するコードと
同位置において、関連するコードを
できるだけ近くに配置しますと。
うん、そうだよね。
もしこの方法が違っていたらどうでしょうと。
もしこれらのコメントを全く別の
ファイルに配置したらどうでしょう。
巨大なドキュメンテーション.md
ファイルとか、あるいは
ソースディレクトリに
マップバックされるドックスディレクトリを
作るんですと。楽しそうでしょう
っていう。楽しいのかな、これ。
やったことないですね。
ドキュメンテーション.mdって、そのプロジェクトの
リポジトリとかの、いろんなノウハウだったり
リンク先だったり、初期の
セットアップ系のことを
ドキュメンションっていうのをリードミーに書きますけど
そういう
ソースディレクトリの下のドックスに
そういうものを作るっていうのは、僕やったことないですね。
えー、ちょっと読んでいきましょうか。
楽しそうでしょう
って問いがありますけど
えー、私にとってもそうではありません。
違ったのね。あなたにとっても
違ったんですね。で、コメントを
説明するコードと一緒に
配置しないことで、いくつかの深刻な
問題が発生します。そもそもそんな
問題にぶち当たったことが僕一度もないので
これなんか面白いですね。やっぱ
いろんな現場があるってことですね。
はい。で、今回起きた
その深刻な問題三つのうちに
ありますと。で、一つ目ですね。一つ目は
間違いなくみなさんが
想像できるでしょう。メンテナンスビリティですね。
メンテナビリティ
はい。いわゆるメンテナンス性が悪いと
動機が取れなくなったり
古くなったりするのが早くなりますよ。
すでにそうなってるらしいです。この人の現場では。
で、対応するドックスファイル
っていうのを更新することなく
ソースファイルを移動また削除することになってしまいますよ
ってことです。で、続いて
アプリケービリティですね。
アプリ
アプリカビリティなんですか。ちょっと読み方がわかんないですね。
まあまあ適応性の話ですね。
で、ソースコードの
見てる人がドックディレクトリの
重要なコメントを見逃してしまったり
編集中のソースファイルに
既存のドックスファイルがあることを知らないために
自分のコードにコメントを
付けなかったりする可能性もありますと。
はい。っていうのが2つ目。で、3つ目は
Ease of Useですね。まあ
使い勝手の良さってとこですけど。はい。
これはある場所から次の場所へコンテクトスイッチ
っていうのがあって、それもこの種の
セットアップでは困難になります。
複数の場所にファイルを置くとコンポーネントを保守するために
必要なものをすべて確保するのは難しくなると。
まあ、なるほど。
で、このようなコードコメントの
形式の規約を作ることはもちろん
可能ですけど、なぜそうしたいんでしょうかと。
で、コメントを説明するコードと
09:00
同じ場所に置く方が
簡単じゃないの?っていうお話ですね。
はい。まあ、ほんと相当だと思いますけど。
えー、続けて
いきますが、えー、
so whatってとこですね。で、まあそれがどうしたっていう
セクションですと。で、さてあなた
おそらくこう思ってるでしょう。まあそうだ。
だから誰もドックスのようなことをせずに
みんなコメントをコードに閉域するんだ。そんな当たり前だと。
で、要は何が言いたいの?
っていうところをですね、っていうのが
問い合いですけど、私が言いたいのは
そのコロケーションの利点は
どこにでもあるということですということで
ちょっとずつコロケーションの話が入ってくるのかな
ここからと思いました。で、えーと
ここからですね、なんかいくつかに分かれてて
HTMLとCSSとテストと
ステートとっていうなんかいくつかの
項目に分けられてなんか
書かれてますね。ではまず一つ目
HTMLViewの話です。
例えばHTMLです。コメントを同じ
場所に配置することの利点っていうのは
テンプレートにまではまりますと。リアクトのような
最新フレームワークが登場する以前っていうのは
そのビューロジックとビューテンプレートを
全く別のディレクトに置いていましたと。
SVCとか
SVなんたらみたいな設計が昔ありましたからね。
途中でVMができて
結構に近寄ってきた
って感じはありますけどね。
この場合ですね、上記のような
問題が発生します。最近では
リアクトとかビューなどではこれらを
全く同じファイルに入れるのが一般的になっています。
Angularではもし同じファイルでなくても
テンプレートファイルは少なくとも
関連するJSファイルがすぐ隣にありますよと。
このディレクトリ構成見たらすぐ分かりますけどね。
続いてCSSですね。
CSSは結構短いですね。
これがよく当てはまる
もう一つのコンセプトはCSSですと。
CSS in JSのメリットについて
議論するつもりはもちろんないですが
もちろん素晴らしいとは思ってますが
そのメリットはこの世のものとは思えないものです。
詳しくはこちらでって別の記事のリンクが
貼られてますね。
CSS in JSのメリットをすごくこの人は
痛感しているってことだそうですね。
JSの変数とか状態っていうのを
その持ったまま
CSSとかスタイリングのところに
反映できるっていうのはやっぱり
これは魅力的ですし、あとは
CSS in JSやると
CSSがグローバルではなくて
スコープだと書き方ができるっていうのも大きいですよね。
この2つだけでも莫大なメリットがある
って感じはしますけど。
ただ前回かな
前々回から読んだ記事にある通り
CSS in JSはその代わりオーバーヘッドが
かなり大きくて、ランタイムで
時間がかかってしまうので、そのコストをかける
ってことにデメリットが大きいし、
CSS in JSライブラリそのものをまずライブラリを
ミニファイしたところで
何キロバイト読み込ませなきゃいけなくて
その分も重いし無駄だよねって話があって
まあ良し悪しはやっぱりあるよねって
感じはしますね。
とはいえ開発者体験が向上するのは間違いないと思います。
はい、余談でした。
続いてTEDの話ですね。
TEDですけど、このファイルの配置の
考え方っていうのはユニットテストにも
大いに当てはまります。
ソースディレクトリとテストディレクトリを持つプロジェクトで
ソースディレクトリをミラーリングしようとする
ユニットテストでいっぱいになっている
というのを見かけたことはよくあるでしょう。
上で説明したすべての
落とし穴がここにも当てはまります。
私はユニットテストを全く同じファイルに
置くことまではしませんでしたが
12:00
面白いアイデアとして完全に排除する
わけでもありません。
実装読者への練習として残しておきます。
これは僕はさっきのやったことがなかったし
テストでもそういう書き方をしたことがなかったので
なかなか興味深いと思いますけど
一部メリットもあるんですかねつまり。
まあいいや。
より保守性の高いコードベースを
実現するためにテストファイルを
テスト対象のファイルやグループと
同じ場所に置くことにしましょう。これはそうだよね。
これによって新しい人たち
あるいは6ヶ月後の自分ですね
がコードを見に来たときに
そのモジュールがテスト済みであるかということがすぐに
分かってそのテストを参考にしながら
モジュールについて学ぶことができるようになります。
変更を加えた際には
その変更を反映させるために
テストを更新、追加削除を変更するように
注意を促しますよと。
なるほどでした。
テストのためのドキュメントを
用意するって僕はやったことはないですけど
テストファイルを読めば
大体わかると思うんですけど
あえてドキュメントに残すというのも
一つメリットはあるかもしれないですね。
テストはテスト用のドキュメントを
作ったことがないわけではもちろんなくて
ユニットテストと言い継いテストをやるときは
こういうことを注意してくださいねとあるけど
でも僕はそれを全部Readmeに書いちゃっていることが
今までの経験上多かったなって感じですね。
なので結構Readme自体が
結構膨大になったり
長大になったりするので
その時にDocsDirectに分けて
それぞれのカテゴライズで
.mdファイルを作るってことはやりましたけどね。
まあまあまあまあということです。
で、続いて
ステート状態の話ですね。
アプリケーションやコンポーネントの
ステートも同じような利点があります。
ステートがそれを使用する
UIから切り離され間接的であればあるほど
メンテナンスが困難になります。
ステートのローカライズには
保守性だけではなく
アプリケーションのパフォーマンスを
向上させるというメリットもあります。
アプリケーションのコンポーネントツリーの片隅で
ステートを変更した場合
ツリーの最上部でステートを変更した場合よりも
再レンダリングするコンポーネントの
数が大幅に少なくなります。
状態をローカライズしましょう。
続いて
リユーザブル
ユーティリティファイル
再利用可能なユーティリティファイルの話ですね。
これは
ユーティリティファイルというような
関数にも結構当てはまりますよということですね。
コンポーネントを書いているときに
それ自身の関数に抽出できるような
素敵なコードを見つけたとします。
それを取り出して
これは多くの人にも使ってもらえるに違いないと
思ったとします。
それを取り出して
例えばユーティリティディレクトリとかに置いて
自分の人生を読み始めます。
後日あなたのコンポーネントは削除されましたが
あなたが書いたユーティリティは見えなくなって
削除した人がより広く
使われていると仮定したために
そのテストと一緒に残ってしまっています。
何年もの間エンジニアというのは
その関数とテストが実行され続け
正しく機能することを確認するために
それが全く必要ないことに
気づかないまま
懸命に働いています。
コンポーネントを削除するときは
そこで利用している関数とか
ユーティリティは普通見ると思うんですけど
15:00
見ないのかな?
こういう落とし穴があるというのは
間違いないので
ファイルチェックするという仕組みがあると
いいなと思いましたし
なんかそういうリンターとかでも
使われてないファイルですよ
リンターは確かあった気がするので
そういうのを導入して自動検知していくのが
多分いいと思いますね。
人がそういうことをしなくていいような
がいいと思いました。
その代わりに
関数を使用していたファイルに
そのまま残しておけば
話はまた違ったものになったでしょう
複雑なユーティリティ関数というのを
わざわざユニットテストするなとは言いません。
むしろしてください。
必要な場所に近いところに置いておくと
問題を回避するのに役立ちます。
それはそうですね。
近いところに置いておったら
コンポーネントを削除するときに
一緒にこのファイルもあるけど
それはいい話じゃないかなと思いましたね。
続いてプリンシプルの話ですね。
ちなみにさっきまでのところで
and for heaven's sakeという言葉で
please delete this ESLintルールみたいなところが
リンクが貼られていますね。
削除用のESLintルールというのを
一つの参考例として載せられていますね。
このリポジトリは
ESLintプラグインリアクトという
ノーマルチコンプというファイルがあって
そこのルールのドキュメントが
貼られています。
これを参考にしてくださいねということでした。
続いてThe Principleですね。
コンセプトというか
ここからコロケーションのコンセプト
というところに入っていくらしいですね。
この基本原則に集約されますよということです。
Place code as close to where it's relevant as possible.
可能な限りコードは
関連性の高い場所に配置しましょう
というところですね。
そこからまたいくつかの
具体例の話がどんどん出てくると思いますけど
一つはまずオープンソースを簡単に
オープンソースmade easy
もしくはeasierと書いてますね。
先に述べたような問題を回避する以外にも
この方法でプロジェクトを
構成することにはメリットがあります。
あるコンポーネントを
オープンソースプロジェクトにする場合
そのフォルダを別のプロジェクトに
コピー&ペーストして
それをnpmで公開するだけでよくなりますよと。
自分のプロジェクトにインストールし
リクワイヤーもしくはインポート分を更新すれば
それでOKだよと。
よくある話ですね。
これはこれで結構いい話ではあるので
ぜひぜひ皆さんもやっていただければと思います。
もちろんnpmに公開して
オープンソース化するということは
オープンソースのメンテナンスを
自分でもしなきゃいけないということは
リスクではないけど
セットでコストはかかりますよということはあるんですけど
いわゆるあれですよね
一緒に変化するものを合理的な範囲で
近くに配置すべきだという話が
今までの背景にあるので
これと似たような話ではあると思うんですけど
オープンソースにすることで
逆に言うといろんな人たちが
見てくれたりするので
それによってリポジトリ自体に
18:00
イシューが来たりとか
プロジェクトがもし来てくれたらすごく嬉しいなと思いますね。
なので自分たち以外の人たちの目が入って
サポートが入るような可能性が出てくるので
大体にして普通は来ないですけど
意外と海外の人って
使われたときに
ファンが来たりするので
そういうのは嬉しいなと思いますね。
次にExceptions
例外の話ですね。
確かにシステムの全体または一部にまたがる文書だったり
物事がどのように統合されているか
についての議論は十分にあります。
またコンポーネントにまたがる
統合テストとか
エンドツーエンドテストをどこに置くのでしょうか
というところもあります。
これらは例外だと思うかもしれませんが
実は上記の原則にもうまく従えるんですよ
ということでした。
このアプリの一部がユーザー認証に関連していて
そのフローを文書化したいのであれば
ユーザー認証に関連する
すべてのモジュールを含むフォルダに
readmeファイルを置くことができます。
それはそうね。
もしそのフローに対して統合テストを書く必要があれば
そのテスト用のファイルを
同じフォルダに置くこともできます。
エンドツーエンドのテストについては
一般にプロジェクトのルートに置く方が
理にかなっていますよと。
プロジェクトの枠を超えて
他のディレクトに置くのが
理にかなっています。
ソースファイルにマッピングされることは
まずないよと。
実際E2Eテストは
ソースがどのように構成されているか
全く気にしていませんし
ソースディレクトのファイルをリファクタリングして
移動したとしても
E2Eのテストを変更する必要は全くないですよ
ソース以下にあれば
勝手に読み込んでくれる
ということだと思いますけど
それぞれテストするファイルそのものの
置き方というのは
気を付けたほうがいいかもしれないですけど
E2Eぐらいまでとか統合テスト
インテグレーションまでいくんだったら
置き方はどうでもいいかもしれないですね
ただユニットテストレベルだと
コンポーネントの近くに置くのが
やっぱりいいなと思いますけどね
まちゃまちゃ読んできたんですが
ここで結論ですね
コンクルージョンにたどり着きましたので
最後コンクルージョン読んで終了という感じですね
まとめです。
私たちの目標はできるだけ保守が簡単な
適応性使いやすさなどなど
コメントをコロケーションすることで
得られる利点というのは他のものを
コロケーションすることで得られるものと
全く同じですよということです
もしまだ試したことがなければぜひ試してみてください
PSですね
もしあなたが
懸念の分離に違反することを
懸念しているのであれば
ペンハントのこのトークっていうのが別のリンク
を貼られてますね
その意味を再評価することを
お勧めしておきますということでした
さらにPPSですね
もう一個追加であって
これは画像やその他あらゆるリソースにも
大いに当たるということも書いておきます
Webpackのようなツールを使えば
リソースの配置はとても簡単になります
正直これはWebpackのコアバリの一つだと思ってますよ
ということで
この記事は締められておりました
CSSの話だとずっと思ってたんですけど
単純にディレクトリ構成とか設計の話でしたね
結局は
というところです
なかなか興味深いというよりも
21:00
簡単だなという感じでしたし
これに従うことでメリットは大きいだと思いました
これをコロケーションといったりするんですね
なるほどでした
一応もう一個余談として
このブロー記事はリアクトに関わるものを
ベースに書かれてますけど
最近話題のRemixというライブラリですね
Remixがリリースされる前に書かれたものですよ
Remixがどのようにリアクトアプリケーションを
劇的に簡潔化するかというのは
この別のところのところからも
学ぶことができますよということですね
このRemix
リアクトズイーンという
別の記事がリンクを貼られているので
なかなかちょっと
Remix自体も興味はずっと持っていて
触らなきゃいけないなと思いつつ
今年触る技術を
僕は限定したので
目を瞑ってます
来年ガッとやろうかなという感じがしますね
あと僕は今Remixよりも
Quickというフレームワークがあります
JSのフレームワークがあって
新しいのがどんどん生まれすぎて
疲れるんですけど
スピードがめちゃめちゃ速いというのと
JSをかなり削減できるというのを
別のブログを読んでいて
そんな削減できるによって
すごい強いじゃんというのがあって
今触り始めているという感じですね
N1問題
ランダウの
中傷的な話になったからやめよう
とにかく初期のレンダリングが
めちゃくちゃ速いんですよ
N1までスピードを上げられるということを
公式に書かれているんですね
初期レンダリングN1まで
削減できると言っていて
ほんまかいなという感じですけど
一応からくりとか仕組みを知ったら
確かにそうはなるねというのがよく分かれているので
なかなか面白いですけどね
冗談でした
Quickはめちゃくちゃ速くなりそうというのは
からくりはよく分かったので
その他に結構中のやり方は
力技で書かれたりするんですけど
おすすめしておきます
じゃなければ基本的にはなんだっけ
Remixもそうですし
やばい名前忘れました
仮想ドームを使わないJSライブラリが
いくつか出ていると思うので
その辺を使ってみるのも全然いいかもしれないですね
はいというところで
余談に余談がされましたので
以上にしたいと思います
コロケーションという思想はかなり良さそうだったので
皆さんの方でも
同じような設計になっていると思いますけど
一応改めて読んでみていただいて
自分のプロジェクトとかリポジトリどうなんだろう
というのを見てみるのがいいのかもしれないなと思いました
もしGM内でこういうことが
ちゃんと導入されていなかったり
リポジトリとか書き方みたいなルールが
整備されていないんだったら
考えていただくのは絶対いいと思いますね
今後の補修生だったりとか
プロジェクトのかかるコストが削減できる可能性が出てくるので
というところで
余談でしたけど朝から最初にしたいと思います
はい本日はですね
ゴソウロ
ゴソウゴフさんになってますね
と駆け出しの老外さんですね
ご参加ありがとうございました
月曜日の朝9時からですね早い時間から参加していただいて
すごく嬉しかったと思います
ぜひ記事読んでいきたいと思うので
興味があればご参加いただければ幸いです
今日から1週間また頑張っていけたらなと思います
終了しますお疲れ様でした
