現在の現場でコーディング関連で勉強になっているポイントについてまとめてみようかと思います。規約エラーなどなるべく自動化できるものは自動化を。エディタに共通のものを入れて迅速に検知できるようにするCIで規約エラーのものを落とすようにするどこまで対応するかは現場の事情によりますが、テストにてパターンの多いものを検証できるようにしておくコスパを考えて、自動化しすぎないことも検討に入れる命名プログラミングを始めた当初から大事さには気づいていましたが、日々実感することが多いです。規則性を持たせる(特にルーティングから自動で決まるものに注意。ControllerやUseCaseなど。)冗長すぎるものは避ける(そもそもアーキテクト設計がしっかりされているとそこまで冗長にはならないはず・・・)フォーマットの決まっている値(会員番号など)はValueObjectで定義するですかね。以前のリンク(クリーンアーキテクチャーがらみの話題など)でも書きましたが、どこに何を書くのかのディレクトリ構造ですね。Controller、Serivce、Infrastructure、Modelなどでの責任がどこまでか(リクエストを受け取るだけなのか、ビジネスロジックを受け取るのか否か、など)の意識です。現実案としてはある程度折衷案を取ることも大切になってくるかと思います。ここを意識することで命名にも聞いてくるポイントかと思います。意図せず連想配列を使うことを避ける→追加時に柔軟性がある一方で、中身がブラックボックスになり、可読性が少し落ちる。引数を分けたり、オブジェクトで管理することなど。定数系の値は基本Enumを使う→単純に保守性が高いからという意味もありますが、可動性の向上と、値自体に意味を持たせたいため。中途半端ですが、ここら辺で。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。関連記事APIのエラーコードに関してAPIのよく使われるHTTPステータスコードに関して。基礎の基礎で当たり前に使ってましたが、基本的なことに関してまとめ。4XXエラーのタイプ分けに関して。メモリとポインタ、配列と連結リストWEB+DB(vol91)で使えそうな連載記事がありますのでブログにメモリます。テーマはデータ構造です。...画面の制御フローなど複雑な帳票系アプリではよくあると思うのですが、ある入力値が複数の場所から影響を受けており、制御がなかなか難しいときなどがあります。...トランザクショントークンについてフォーム画面で入力を行うときにはPOSTでデータを受け取ってエラーチェックしたり、データベースに入力をしたりします。その時に何も考えずに安易に送信→受信の際に以下のようなトラブルがあり得ます。