技術とかの雑なToday I Learnedメモ

画像を貼れるようにしたい、フロントエンドと素朴なコードベースという記事を読んだ

画像を貼れるようにしたい

なにかと画像とか貼りたい場面があるんだけど、今は画像を置く場所を決めていないのでどこに置くか悩んでいる。

画像のことを考え出すと知らないことだらけで、みんなどこに置いてるんだ?となった。会社のプロダクトとかだと S3 に置いたりすることが多いとは思うけど……。

最初の投稿で参考にさせてもらったと書いたmiyaoka.devのリポジトリを見てみたら、imgurというサービスを使っていた。

できれば無料がいいな……と思っているのだが、実際のところどうなのだろうか。とりあえず Issue 化した。

フロントエンドと素朴なコードベースという記事を読んだ

今日のタブ記事

フロントエンドと素朴なコードベース

React はフレームワークではなくてライブラリなので良くも悪くも自由であり、Rails のような CoC(なんちゃら over Configuration、設定より規約の略だった気がする)なフレームワークと真逆な感じという文を見て「わかる〜」となった。

React に限らず Vue とかもだけど、もともと Rails 畑でせっせと農作業していたので、フロントエンドを触り始めるようになってから「こういうファイルはどこに置けばいいの?」とかでめちゃくちゃたくさん悩んだりした記憶がある、し今もよく悩む。

好みとかによって色々な書き方があるし、Redux のような状態管理ライブラリを使ってアプリケーションを作るとなると ducks パターンとか re-ducks パターンとか色々なディレクトリ構造のパターンが出てきたりして、どれが良いかどうかはアプリケーションの性質や開発者によって色々変わるよね〜という印象。

個人開発するぶんには自分が好きだと思ったり最適だと思った書き方や構造を躊躇なく採用すればいいんだけど、複数人でのチーム開発となるとそうもいかなくて、ある程度の秩序が必要だな〜と感じていた。

その「ある程度の秩序」というのをこの記事が絶妙に言語化されていてすごかった。

コーディング規約を作って「コードレビューのエビデンスにする」というのは参考にさせてもらおうかなと思った。自分は「これはこう書いたほうが読みやすいと思います」みたいなコメントをしたことが何度かあるんだけど、最近こういうコメントをすると「それってあなたの感想ですよね?」と脳内のひろゆきが言ってくるようになった。この書き方は自分にとっては読みやすいけど、レビュイーから見たらレビュイーが書きやすいし読みやすいと思う書き方だからこうなっている、という話でもあるかもしれない。

パフォーマンス的にこっちの書き方がいいとか、別のファイルで利用するときにこう書いておいたほうがわかりやすいとか、そういう根拠があって良し悪しが判断できることだったら正解があると思うんだけど、そうじゃないことも多い感じがする。そもそも JavaScript はセミコロンありなしでまず派閥があるし、自由だなあという気持ち。

コーディング規約をフロントエンドチームで定期的にメンテナンスして、なぜそうすべきなのかという根拠や理由が明確になっているのはすごくいいなと思った。全体で決めたことであればそれはコードレビューの基準として適切というか、「その社内でのコードレビューにおける公式ドキュメント」みたいな感じになると思う。

かっこいい記法に酔いしれるみたいなことはたぶんあんまりない(たまにいい感じに書けたときに自分すごいみたいなことを思うときがある)けど、そもそもこの記事で言われている「かっこいい」の基準とかもなかなか難しい。

「(この書き方ができるという言語仕様を知らないので)この実装は複雑だし可読性が低いです」ということを言ってしまうと、じゃあ言語仕様を知らなくても読めるような書き方をしましょうという話や、いやその言語を使う道の人であればこれくらいは調べたりして知っておいたほうがいいのではないかとか、そういう話が色々出てきてしまう。

Linter / Formatter をうまく活用しつつ、「今の会社 / チームではこうしていく」というのがうまくまとめられていくといいな〜。

あと Atomic Design を捨てた話も面白かった。

自分が作ったコンポーネントが「module か organism か」という問いは定性的だけど、新構造においては「特定ページに属するか、複数ページにまたがって使用されているか」という明確な境界条件によって配置ディレクトリを判断できる。

自分はこっちのほうが判断しやすいと感じる。参考にさせてもらおう。