実装がうまくいく時

はじめに

実装がうまくいったな〜という時に、何を意識していたかメモします。

逆に失敗する時は大体この中のどれかを忘れています。

エンジニアやチームの個性によって上手くいくもの・いかないものがあると思いますが、参考になれば嬉しいです。

処理を言語化できている

どんなコードを書くのか、日本語で説明できます。

自分が1番得意な言語は日本語なので、
日本語で説明できないことはコードに落とし込むこともできません。

例えば「変数Aを引数に、メソッドAを呼んでid=>インスタンスAのマップを作る」といった感じでしょうか。

ただ全処理を詳細に言語化すると時間がかかりすぎるので、理解度が高い部分は言葉の粒度を荒くします。
※「サービスのメソッド呼んでマップ作る」など

自分がこれからどんなコードを書くのか、言語化すると手戻りも減って実装がうまくいきます。

必要なときに必要なものをつくる

必要にかられて初めて実装します。

「後で使いそう、、」と思って必要性が低いコードを追加しても大体「使わない or 後で書き換える」からです。

個人的によく失敗するパターンが
「リソースを節約しようとして、無駄に複雑なコードを書いてしまう」です。

自分がよく触るApexはリソース制限が厳しく「処理時間・クエリ発行回数・ヒープサイズ」などを常に意識するのですが、

意識しすぎて最初から「この情報はマップのキーに持っておいて、2つ先のメソッドで使って、、」と複雑な処理を書きがちになってしまいます。

そして先読みして書いたコードは、
しばしば書き換えることになります。

初めから最適解を組める方もいるかもしれませんが、今の所自分には難しいなと。

先読みしすぎず、その時必要になったものを小さく作るようにします。

先に呼び出し側から書く

以下の順番でコードを書きます。

1. 呼び出し側
2. 呼び出される側

理由は以下です。

• 呼び出し側がゴールになるので、ゴールから逆算しながらコードを書ける

• 複雑な処理は呼び出される側で吸収するので、できることが少ない呼び出し側を先に書いてあげる

自分の場合は以下のような書き方になります。

• フロントもバックエンドも書く時

  • フロント（呼び出し側）を先に書いて、その後バックエンドを書く

• バックエンドだけ書く時

  • 1番最初に起動する関数（呼び出し側）を先に書いて、その後呼び出される側を書く

自分が言語化した通りに進められるのが理想ですが、
書いてるうちに「あ、これ考慮漏れてた」というのはどうしても起こります。

そんな時に呼び出し側から書いていると**考慮漏れに気づきやすくなり、直しやすくもなるな〜**というのが印象です。

まとめ

皆さんの「自分はこうやると実装うまくいくよ」というのも教えていただけると嬉しいです。

最後まで読んでいただき、ありがとうございました。