ソースコードを階層整理する必要はあるのか？
ソースコードを階層整理する必要はあるのか？
nishio.icon
Scrapboxの「階層整理は破綻する」に馴染みすぎて、ソースコード見た時に「あれ？なんでコンポーネントをcomponentsなんてフォルダに入れる必要があるのか？」という気持ちになっている
わかる基素.iconfumito.icontakker.iconblu3mo.icondnin.icon
全部フラットにしたら何が問題になるのか試してみたくなってくる
ファイルシステムベースのフレームワークでは明らかに問題が出ますが、それ以外だとどうなんだろう基素.icon
特に問題は起きないのではと思っているkuuote.icon
フラットな階層に大量にソースコードが置かれているプロジェクトはある
厳密な例ではないが、gitやtmuxなど
階層に分ける理由の1つに、見やすさをあげられることがある基素.icon
IDEを使って開発していると階層の位置をあまり意識せずにファイル名とかを検索して直接アクセスすることが自分は多いので気持ちがそこまで理解できない
もちろん階層を前提とした設計になっているソフトなら別
同じく、ファイル名や中身の検索、参照による移動でコードにアクセスするので正しく記述できていればそこまで意識することないのではとkuuote.icon
俯瞰したい欲なのかもしれない、あるいは全部把握したいkuuote.icon
階層に分けずにファイル名をちゃんとつけようとすると長くなってしまうのかもyosider.icon
あるいは何か法則を決めてファイル名をつけるという作業が階層を分ける作業と同じことのような気もする
ある程度は曖昧検索が解決してくれそうkuuote.icon
pageとかtextとかかなり単純なファイル名にしている分、かなり衝突確率が上がっている
あるいは category1-categoryX-fooみたいにフラットに名前書いてもいいけど
まあそれもありっちゃありですが、directoryで分けるのと何も変わらなくなりますねtakker.icon
そゆことですねーtakker.icon
気づかなかった
ファイル一覧から目で探すのが困難になるがそもそもそれをやるのがおかしいnishio.icon
やってた()takker.iconkuuote.iconnishio.icon
nishio.iconさんのkozaneba日記でdirectoryを廃してフラットにファイルを置く話を読んでから、ちょっとだけ真似しているtakker.icon
うーん、VSCodeとScrapboxが合体してほしい…w
Scrapboxとはだいぶ趣が違うけど「Goto Definition」「Find All References」「Show Call Hierarchy」辺りは関連性により動いて便利だと思いますkuuote.icontakker.icon*2
大体既に言われてるけど、検索でファイルにジャンプできるし、呼び出しや定義にジャンプできるし、だいぶ近いよねnishio.icon
だけどまたなんか足りないのは何が足りないのか、下に関連ファイル一覧が出ればいいのか？？
定義へのリンクがシステム的にはないので、たくさんの箇所で利用されてる概念は大きなリンクになり、人間が定義にシュッとジャンプすることが困難になる /Chosakukenhoを見て「第何条」をリンクにした場合、それが「定義」である条文へのジャンプになるためにはページのタイトルが「第何条」という無味乾燥なものにならざるを得ないのだなーと感じた 「第四十六条」ではなく「公開の美術の著作物等の利用」をタイトルにしたくなるのだけど、そうすると「第四十六条」のリンクが「定義へのジャンプ」ではなく「使用箇所の一覧」になってしまう
同様の問題で悩んでためしに「46条 公開の美術の著作物等の利用」のように全部入りをリンクにしてみたけど、他人の文章を引用してリンクするハードルがやや上がってしまうのが難点基素.icon
Kozanebaで試しにやってみた感想nishio.icon
「Baのダイアログに入力欄を出そう」→Ctrl+P BaDialog
エラーを直そう→エラーメッセージからジャンプ
保存したデータをロードしたときに適切に処理を→Ctrl+P load→あれ？ないぞ？
saveから周囲を目で探して目的の位置にたどり着いた
解説: Firebaseからのロードはアプリからロードのトリガーを引いているのではなく、Firebaseの更新通知でトリガーを引かれてる
なのでアプリのコードとしてはset_up_read_subscription.tsxになってた
Scrapbox的発想だと表記揺れ吸収の一種なので、これのコメントに[load]とか書いたらCtrl+P loadで出るようになるといいのにな
「特定の種類のコード全部を指定する」のに階層は役立つってのはありそうsta.icon
src/、test/
test/に放り込んだもの全部をテストコードとして扱えばいい（テストコード全体、の指定が楽）
これが（たとえば階層じゃない例として）フラットの場合、「テストコード全部」を表現するのが一手間
ファイル名やファイル内容に特定文字列を書くか
これがテストコードですリストみたいなのつくってそれをメンテするか etc
「テストコード全部」を表現する機会ってそんなにありますか？mrsekut.icon
jestならhoge.test.jsのようにかけば階層がなくてもテストできるわけだし、hoge.jsの兄弟にいたほうが見つけやすい
使用しているtest libraryにも依るのかもしれない
テストコードどう置きたいかのスタンスにもよるのかもしれませんsta.icon
sta.iconは「ソースと一緒には置きたくない」派。ソースのコメントにテストコード書くみたいなの好きじゃない。「このコードのtestあるのか？」を知るのは不便だが許容（それよりも綺麗に置くことが大事）
と書いてて、これこそ階層意識に毒されているのではないかと思った（mrsekut.iconさん言ってる方が普通に便利そう）sta.icon
これを見てて僕はPythonのdoctestは小さめのプログラムに対してはよく使うなぁと思ったnishio.icon
関数冒頭のコメントにその関数はどんな入力にどんなものを返すかを書いてる
「文芸的プログラミング」的？？
あ、わかった、foo.jsのテストをfoo.test.jsに書く的なことを考えてる時のテストはユニットテストで、僕が「テストコードを分ける」と書いた時に脳内にあったのはCypressを使ったUIのE2Eテストだった なのでテストコードと実装のファイルは1対1に対応しない
+1。なるほど、そういえば仕事ではFT(Function Test)もコードで書くことがあったsta.icon
testと実装が別の場所にあると、この実装ってtestあるのか？ってならないですか？
カバレッジを可視化するツールを使う前提nishio.icon
「テストコード全部実行する」という使い方をするので全部実行できないと辛いですsta.icon
python unittestだと一気に実行できたりする
逆にhoge.jsのテストコードだけ実行する、はあまりしない
人による？
確かに、テストコードは分けたいなnishio.icon
逆にテストコード以外にそういうのはあるか？
文芸的に書いてれば大丈夫! 増井俊之.icon
またはファイル名とページタイトルのアナロジー
というより、エディタによるファイルの扱いとScrapboxによるページの扱いの比較か
共通点
検索できる
呼び出し箇所にジャンプできる
違い
ファイル名にはいろいろ制約がある
英語が推奨されている
スペースや記号を入れにくい・入れられない
ページタイトルは長くなっても気にならない（むしろある程度の長さがあるほうが好ましい？）のに、ファイル名は短いほうがいいと感じるのはなぜだろうyosider.icon
入力するのが大変だから？
現代は補完があるので問題ない
増井俊之.icon
短いソースはScrapboxに書けばいい気がしている
このページを作ったときにイメージしていたのは100ファイル以上が関係してあって動いているようなプログラムnishio.icon
コードスニペットを階層的管理しなくてもいいって点には異論はない(し、僕も現時点で既に階層管理してない)
デカいプロジェクトで使ってみたいものですが 増井俊之.icon
つまらないコードスニペットでも、Scrapboxにいろいろ書いてると有用なことがあるかもしれない
そうなると、階層的管理など必要なくなるかもしれない
例
Gyaimの変換アルゴリズムをScrapboxに書く それを使ってGyaimをビルドできる
文書とコードが一体化する
こういうことを以前考えたりしていたなkuuote.icon
importする時にバージョンが固定されると嬉しいということを考えていた
/nishioに関連した話題がありそうだったので探してみたがなかったtakker.icon 「階層」「フラット」「ディレクトリ」「フォルダ」で引っかからなかったのでないと思ってしまった
なるほど。フラットをscrapbox的と表現しているわけか
この言い換えを思いつかないとたどり着かないな