雑
思いつきのメモ
謎タイムライン
このページを膨らませるのは良くない自覚はある
最終的に個別のページに切ろうと思ってる
実際切ってる
Twitterに書くよりはマシだろう
適度にページを切っていく
そもそもページを切って書けやという話もある
タイトル付けるの難しいんだよ
長く考えたいことを残しているというのもある
Interfaceを使う3つの目的
特性表現
オブジェクトの振る舞いや能力にフォーカス
機能を表現する
差し替え可能性
実装の切り替えにフォーカス
Componentレベルの差し替え
実体ではなく機能にフォーカスし、実装を差し替えられる
境界分離
影響範囲の最初かと切り離し容易化にフォーカス
モジュール同士の境界
そこまで外してないけどちょっと腑に落ちない感じがあるmrsekut.icon
なんでだろう
「機能」って呼んでることに違和感があるのかも
登場する概念をバーっと列挙して、適当にグルーピングして、
その中で持つべき特性、ふるまいのようなものを洗い出す
オブジェクトはネストになってるかもしれないし、そうでないかもしれない
それはあまり関係なく、とにかく振る舞いを洗い出す
これがインターフェースになる
しかし、そのふるまいの返り値の構造はどうやって決めるのという話もある
そのオブジェクトの構造に依存したものになるのか、振る舞い側が規定したものになるのか
理想的には後者になるべき
https://gyazo.com/bfaa5ffafc949dd324361b87271d86cc
読まれないドキュメントは不要
古くなって逆に混乱する
自分が普段読んで思い出すために書く
あるいは誰かが手順を実行する前に読むようなものを書く
一度だけ書いてその後誰も読まないのでは誰もメンテしない
誰もが日常的に読んで誰もが日常的に更新できるようにする
もしそうでないような内容なら、特に小さく書くべき
UIに対する仕様とか
一画面全体について書くと古くなりがち
記述が具体的になればなるほど古くなりやすい
プログラミング、いかに条件分岐を減らすように実装するかという感じ
すなわち良い抽象化
筋の悪い抽象化をしても、例外が頻出して条件分岐が生じる
ドメインモデルの抽象化の仕方がわからない
扱うドメインのモデル(Entity, VO)のデータ構造が辛いと結局辛くなる
それらのデータ構造に対する抽象化だったりの方法論が全然見えてない
これこそ、ドメイン特化の話なので、これといった汎用的なパターンが存在するわけでもないのか
多分そんなことないと思うmrsekut.icon
どうやって汎用的な構造として表現するねん、
例えば、何かのドメインのデータ構造を見て、FunctorとかFoldableの性質を見いだせない
別にそれじゃなくてもいいんだけど
どういう調べ方をすればこの辺の知見が得られるのかもわからない
上部の関数の工夫も考えていきたい
下層の方は徐々に解像度が上がってきた
上層、メイン関数近くの関数についても考えたい
ここは、具体的なデータ構造を、汎用的な関数に流し込むところ
具体的なデータ構造を知識を持ってしまい、どうしても混雑しがち
混雑している部分が一部にまとまってるんだから良い、と諦めるのか、
更にもっと工夫できそう、というのを見つけるか
「広義のモジュール」のような概念を導入したいmrsekut.icon
何らかのmoduleについて考えてるときに、
それって関数にも(いわゆる)モジュールにも言えることだよね、というのが割とある
「関数」や「モジュール」などを区別する必要がない
何らかの責務をまっとうするもので、互いに依存し合ったりするやつたち、を総称する名前がほしい
内部の引数の種類ごとにラッパーした関数を用意してもインターフェースは何も変わっていなさそう
例えば、5段階のlogを扱う関数が合ったとして、
内部ではlogの5段階を引数で管理するが、
外部向けには、5種類のログ関数を公開する
このとき、interfaceの広さとしては何も変わっていない
強いて言えば、後者のほうが個別の変更をしやすいか
じゃあ、引数ってなに、みたいな話になってきそう
atomicに分けたものをグルーピングする
何らかの方針に沿ってグルーピングする
そこに抽象化の筋のようなものが現れる
業務中の小さな不満を気軽に書き出せる場所があるべき
独り言のように、困っている箇所や不満や疑問をだらだら書き出せる場所を用意する
メンションをつけて誰かにヘルプを言うのはややハードルがある
メンションされたがわにボールが行ってしまうので。
それ早く言ってくれたら、もっと早く改善できたのに、というのが割とよくある
職種を横断するとかなりある
営業や事務やメディア運営の仕事の中の小さな不満を、エンジニアに伝えれば瞬時に解決できるものが体感として結構あった
たぶん逆も結構あるはず
気軽に書き出せる場所がないと、直接のコミュニケーションでしか気付くすべがない
1 on 1とか(?)して丁寧に聞いていく必要があって、時間がかかる
やりたいこと、やりたくないこと、とかもどんどん書くべき
この作業おもんないんだよな、このツールのここが辛いんだよな、
これをしてと依頼されたけど、この選択の真意がよくわからないんだよな、
オフィスってうるさくない?暑くない?
みたいな
改善できるかわかないけど、見える場にないと何もわからない
スルーされる前提で書いておけば気持ちも楽
Slackでもいいけど、たぶんScrapboxのほうが向いている
5割ペン
3割型
2割実装
みたいな
哲学
予想と証明ポイ?
後継者、何かしら残る方法
有名である必要がある
AIの研究とか、筋が良くないと継承されない
数学もそういうの多いんだろうか
数学は割と積み重なっている印象があるけど
言うて、最新の数学事情とかしらんしなー
哲学はあまり有名でないけどだいぶ斬新なことを既に言ってる人がいそうみたいな印象がある
定説になる
むいしきとか
PBFは構造の一面の表現
コードレビューで構造をレビューする
早期に問題を指摘する
機能ごとに分かれているので影響ないが、
そのうち自分が触ったときに問題に気付くかもしれない
その前に指摘しておいたほうが全体的に楽、みたいな
不変である構造や性質を見つけ出して、それに依存させるというのを繰り返す営み
不変である構造が、複数の要素から帰納的に見つけられる時、それを抽象と呼んだりする
interfaceとかそういうの
普遍な構造とも言える?
これの繰り返して実装していけば、基本的には「その構造が不変でなかった」ということがない限りは修正は容易に行えるはず
プログラムを書くうえで、まずすべき作業は不変である構造はどれかを探す
まず、というかずっと
内部の構造?内部の機能(インターフェース)?
サーバ側を考えてみよう
zennのようなpostを返すようなサービスを作る時に
機能で言えば
postsを取得する
ランキング上位のpostsを取得する
検索ワードをもとにpostsを取得する
と言ったものがある
一方で、内部のデータの構造を考えるならば
posts
ユーザ
コメント
のように分かれるわけである
サービスの利用者から見れば前者の方が重要で、コードの書き手からすると後者のほうが重要なようにも思える
で、後者の分け方は別にfeatureではない
この分け方の内部に前者の分け方があると読みやすい
例えばHogeSize、PiyoSizeというものがあったとき
height, widthは個別で色々な計算過程をたどる
このとき、ディレクトリはSize単位で作るが、実際の計算過程はディレクトリで表現不可能である
monorepoとかもわざわざそんな大仰な仕組みがなくても自然に実現できるべきである
実はgitなどのVCSによる制限を食らっている可能性はないだろうか
packageの管理としてもショボい
ファイル内の任意の場所から、任意のものをimportできてしまう
featureとしてのグループと、packageとしてのグループが対応しない
なんかもっと関数とかの見た目と近くなるはず
そのpackageというまとまり
に依存しているもの、
から公開しているもの
をもっと明示的に見えるようにする
関数を作るときにその抽象、つまり引数と返り値が重要となるように、
moduleに対しても同じことが言えるはず
moduleが、どの外部moduleに依存しているのかを型やプログラマブルなツールで取り扱えるべきではないのか
実際、npm package同士の関係などはそんな感じになってる
package同士がネットワーク的に依存している
誰に依存されているかはどうでも良い
何を公開しているかは重要
何に依存しているかも重要
packageもいわばちょい大きめの関数みたいなものとして表現できるはず
依存するものと、公開するものとある
依存関係を可視化しようとする毛玉問題になりがちがだが、それは可視化の仕方が悪いと言えるはず 本当にネットワークになってはいけない
そこの関係も含めて、設計しないといけない
毛玉になるのはいらん線が全部表示されているから
package時に閉じてるものは出てこなくて良い
そのpackageの抽象度毎に調節できるばだいぶマシになる気がするんだけど
その抽象度に沿った依存関係が見たいだけなんだよな
わかり易い例で言えば、ReactでかつCAぽいレイヤー構造をしてる時に、
jotaiのatomの依存関係だけを見る、とか
そうすれば内部の具体的なロジックは捨象しつつ、
Component同士の関係といった表層部分も捨象できる
例えばViewだけ、Entityだけの関係、みたいな
あるいは、このfeature内の、view, entity, repositoryの関係、みたいな
理想的には、CAぽいやつのレイヤーごとになにか印があるとよい
ComponentとかJotaiのatomとか、hooksとかみたいに機能の制限として元からある制約を利用すると良さそう
もしかしたらUnisonとかそういう知見があるかも(知らない) 同様にファイルの上部に書いてるimport文もviewに過ぎないんだよな
importしてないのにReact型とかjestのtest()とか入ってっしゃろみたいなのもある
https://gyazo.com/f863a0957f6bf253e7f898fca70f81a8
GUIで、Aとa,b,cは同じmoduleやぞ、というのを囲ったら1つのまとまりになるみたいな
そういうインタラクションがあれば割と自在に抽象と捨象ができそう
プロジェクト内の全moduleに対し、ライブラリを使う感じで互いに参照する必要がある
これが実践できないのは、恐らく人間の問題ではなくツールがないせいだと思う
誰でもライブラリを使うことはできるし、ライブラリを設計するなら同じ発想になるはずなので
同じモジュール、同じものとみなすならスタンプ結合でもいい
その関数の抽象度によってかわるということになる
何か概念を追加する系の修正が入った時に、
段階を踏むmoduleの境界部分を先に修正して、
あとでそれ以外の部分を修正すれば良い、という感じにしたい
そうするためには、段階的なmoduleの協会ってどこやねん、というのをパッと確認できる必要がある
エディタのモジュールに対するサポートも弱い
privateなものは候補に出てこなくていい
今注力しているpackageだけのファイルツリーを表示したい
外部のpackageが出てるだけノイズ
全ての要件を認識できなくて暴発すること
こういう内部的な機能が必要に感じるものの、その全体像を捉えられない
という時に、いったん外部視点(インターフェース)で満たすべき要件を書き出した
それもテストの形で書き出した
その後、そのインターフェースを満たすように内部構造を好き勝手に作っていく
何やらGTD, TDDと近い感じのことをやってるなという気持ちになった 他の人が、構造やフレームワークやアーキテクチャや整理の方法をバンと提示する
0の状態でそれを知って、それに適用していくのではなく、
自分の中である程度考えられた、しかし、まだちょっとふわふわしている時に、
それを整理してくれる形で、そういう物に触れると効果が大きい
自分の中である程度優先順位が見えていて、それを言語化できない、となっていた時に、そういう整理を見ることで整理される
つまり、そのフレームワークの名前を知っていなくても、
頭の中で、体感で、その重要度は端から自分で提示できる、
という状態になっていると良い
とは言え、じゃあそれどうやるねんというのはむずかしい
気付くことはできそう
新しいフレームワークを見た時に、何言ってるんだ、なんでそれが大事なんだ、
と感じるときは、そもそもそれについて考える時間が足りない、とか?
自分の中にそもそもふわふわが存在していない
でも常に考えて、というのも効率が悪い
型から入るというのも有用ではあるはず
MVP自体にもUXは大いに含まれるだろう
新しい機能を、何のスタイルもしていないボタンを1つ追加すれば、機能自体の有用性を測れるかも知れないが、
それによって、元のサービスの世界観が壊れたら台無しなわけで
アクセシビリティなどが後回しになりがちなのは、それの優先度が低いと判断してるからに過ぎない
MVPの篩からは振り落としました、というだけ
対象のユーザがそれを最も必要としていると知っていればそれの優先度が上がるだけ
MVPという方針を取っている以上、最初に含まれないのは仕方がない(?)
UIを考える頭と設計を考える頭は割と違う気もする
ここのスイッチングを1日の中でやるのはあまり良くないかも
日を分けたほうが良い気もする
良いインターフェースと良い抽象化ってかなり類似する?
外部との結合をできるだけ小さくする、即ち、境界をできる限り薄くする
それでいて十分に機能を果たすことができる
interfaceの開け方がミスっていると、それを補強するために別のinterfaceを設置する必要が出てくる
その結果、結合がどんどん大きくなっていく
例えば、monadはjoinとpureだけ、reducerはeventsとstateだけ
たった2つ程度のinterfaceだけで、広範な機能を表現できる
中身の構造が全く異なるものだったとしても、
「同じインターフェースを持つなら同じもの」と見なすことができる
決まったルールで自動生成する
性質を捉える
汎用的なものを組み合わせる
monoidとかそういうの
ADTも実際かなり単純なものの組み合わせ
和と積ぐらいしかない
ほったらかしにしてる
この辺をちゃんと整理しておきたい
抽象的にプログラムを書く方法
問題に対する概念の分析し分節する
すでにあるメンタルモデルも参考にして良い
N個の要件があるよね、のようなものを確立する
基本的にコードの外でやる
無理なら、捨てる前提でコードに書き散らす
雑にトップダウンにプログラムを書いてみる
型や存在しない関数を使って書き下す
これができない場合は分析が足りない
境界の解像度も上げる
抽象的に、宣言的に書くことが大事
「こういうプログラムになって欲しい」ということをまず考える
書きやすいところから書いてはダメなのだな
徐々に具体化していく
改善する
日を開けてコードを見る
認識とズレていることん気付く
ここの気付き方も列挙すれば色々ありそう
ぱっと読んで理解できない
抽象度の高い1ファイルだけを読んで何がやりたいか理解できない
基本的に型だけ読めば流れがわかるはず
データ型と関数のI/O
もっと色々あったが忘れたなmrsekut.icon
思いついたときに逐一メモらないといけない
↑常にできるわけじゃない
頭が叩いてないと無理になるmrsekut.icon
例えば睡眠が足りてないとまず無理
exercismの嬉しさ
そこに上げられているような問題は愚直に解けばだいたい解ける
でもそれじゃだめ
分析し、抽象し、きれいに書く能力を伸ばす必要がある
分節する方法も色々ありそう
時間できる方法もあるし、責務(?)できるほうほうもある
UIになにか描画する際に、
ロジックとpresenterを分離するみたいな
責務で切ってる感
めっちゃ細かい単位で見れば時間で切ってることになるのかこれ
packageを横断する筋の良いパーツを作る力が重要
特に0→1なプロダクトを作る時
そういうパーツが直交的なもの
それを組み合わせてプロダクトを作れる
そこの方針の筋が悪いと、それを使って作るもの、全てが大変になる
(例えば、mrsekut.iconが2023年に業務でやっていたものだと、formを作るのにreact-hook-formを採用し続けていたらマジで破綻していたと思う)
中心概念となるEntity的なもののモデル化も重要だが、こういうpackageを横断するもののモデル化(?)も重要そう
後者の意識が薄かったことを最近実感したmrsekut.icon
どのライブラリを使うか?という話とも近い
ライブラリを簡単に試して見るときのそういう視点で観察するのが良さそう
ライブラリの掲げているfeatureというとよりは
レイヤーを入れること、と抽象化と具体化
numberという型を直接参照せず、、Age, Priceのようなレイヤーを入れる
これは抽象化と言うより、具体化、?
多くのものがnumberに依存するのを避け、使われ方をグルーピングしているような
逆に見て、number = Age | Priceとすれば、
AgeやPriceを抽象化したものがnumberだと捉えられる
ReactのComponentのstyleとかの話で
code:tsx
const Component = () =>
<>
<div/>
<div/>
<div/>
</>
のようなTSXを返す場合は、並列に置かれている子の数を静的に返すべきだよな、という気がした
これを親からgridでレイアウトする場合は、3つであるという情報が必要になる
(必要にならないスタイルの方法ももちろんある)
そもそも<></>を返すな、という話もある
その場合は、props経由でstyleを注入することになるが、その場合も何かしらの情報が必要になりそう
あるいは、全くそういう必要がないように、内部で完結できるようにするか
2023年のプロジェクトの振り返りはいくつかの場所で書いた
新規に事業をやるぞ、となった時に
←①
市場の調査
課題の発掘
解決策を想起
←②
設計
実装
テスト
リリース
のような、雑なフェーズがあると捉えた時、
今回のものは、マクロには②の部分までは確約されたようなものだった
ミクロには、より細かい課題を見つけ、細かい解決策を提案というのは沢山あったが
マクロで見れば、「既存のプロダクトのリプレイス」という位置づけから、課題がそこに存在するのは最初からわかっとる、という状態になっていると言える
全体から見れば、だいぶイージーゲームであるということ
今後は、社内で①の部分からやろうね、という話が出ているので、順調に、徐々に守備範囲を拡大させている感じ
↑を2016年あたりから2024年あたりまでを雑に図にすればキャッチーな発表資料になりそう
特定のクライアントと綿密にヒアリングする経験を通して、
非エンジニアとのコミュニケーションはこういう感じになるんだな、というのを知れたのも良かった
サンプルは少ないが
自分の中の当たり前が、他の人にとってはそうでないということ、クライアントに対する期待値を下げることができたこと、というのは地味に良い経験だったと言えるだろう 経営にも首を突っ込んでいく気概は最近産まれてきたが、
金を稼ぎをしたいのではなく、良いプロダクトを作りたい