良いコードを書きたい
shwldReactのカスタムフックであるコンポーネントのpropsを生成するみたいなのたまに見る。
あれをやるときにはコンポーネントと命名に関連を持たせることと、近くに置いておくとわかりやすい。
- Dialog
- Dialog.tsx
- hooks.tsx
function useDialog()
function Dialog(): JSX.Element
Reactで凝集度を高める際に、同一ファイル、ファイル名、ディレクトリによって近くに配置することによっても凝集度を高められる。
GraphQLでよく言われるコロケーションもこの観点だと思う。
shwldファイル内の変数、メソッドを数えて、ディレクトリをクラスみたいに考えるとLCOMで計算できる的な発想
shwldなので、技術駆動パッケージングといわれるものによって凝集度が下がることの説明もこれでできないかな。
フレームワークが技術要素ごとに分けてしまっているからそれに習って分けている人が多いやつ。
とはいえRailsであればMVCの3レイヤーは技術駆動でわけるべき（パッケージにするとしたら一緒にしないだろ感）
なので、Railsでこれをやるならmodels内で更に階層をわけるとかが良いと思う。
concernsはモデルと遠くなるので、ログ出力や、フォーマット変換などの本当に共通のメカニズムや、DSLを置く場所としたい
shwldまた、応用としてディレクトリを分けない場合でも、命名によって凝集度を高めることもできそう。
Reactなら、
[ドメイン][コンテキスト]コンポーネント名[Type].tsx
みたいにすることで、良い感じでファイルがまとまって並ぶので意識すると良い。
例えば ACommunityAddToShortListButton なら
ACommunityAddToShortListButton.tsx
ACommunityEditToShortListButton.tsx
ChatConversation.tsx
ChatConversationName.tsx
Sidebar.tsx
...
みたいな感じ。うーん、命名規則はいいけど、ちょっと観点違う気がするw
REF: https://medium.com/@wittydeveloper/react-components-naming-convention-️-b50303551505
shwldAngular styleのcommitメッセージを取り入れてみる。
何回か取り入れようかと思ったけど結局定着しなかった。再度やってみる。
目的:
- commit粒度と単位を改善する
- OSSプロジェクトなどでなんとなくイケてる感を醸し出す
https://github.com/negokaz/git-fancy-message-prefix これを入れたので絵文字によって視認性とテンション上がって今度は定着しそう
よかったら周りにも布教していこっと
feat: 新機能
fix: バグの修正
docs: ドキュメントのみの変更
style: コードの動作に影響しない、見た目だけの変更（スペース、フォーマット、欠落の修正、セミコロンなど)
refactor: バグの修正や機能の追加ではないコードの変更
perf: パフォーマンスを向上させるコードの変更
test: 不足しているテストの追加や既存のテストの修正
chore: ビルドプロセスやドキュメント生成などの補助ツールやライブラリの変更
DDDの仕様パターンはとても読みやすいと思う
class AlcoholPurchaseController < ApplicationController
def create
なにかしらのエラーを返す処理 unless AlcoholPurchaseSpecification.can_purchase?(current_user)
購入処理
end
end
なんかいいコードになりそうなフレーズ (出典: ミノ駆動本)
- 現実の営みにはないメソッドを追加しないこと
- 同じようなロジック、似ているロジックであっても、概念が違えばDRYにすべきではない
- 疎結合高凝集をめざせ
- 設計にbestはない！betterを目指せ
shwldYAGNIについて
検討まではやっておいてあえて作らないみたいなことが必要そうなケースが多そうなんですよね。
検討コストはかかってしまう。そこで損失回避性によってもったいなくなる（作らないけど）
実際みなさんどうしているんですかね。
エレベータピッチとかをよく自分の中に落とし込んで、先に使う必要性が出てくるかを予見できるようになるという高レベルな解決策もありそう
shwld例外
例外をキャッチすることで分岐をさせるな。例外という言葉通りの使い方をしなさいね。
予見できることは例外ではない。
ただし、繰り返し処理内などでは有用かもしれない。