コーディング前に何を考えていますか？

考えが浅いと評価

具体的にどういった点が不足していると言われているのでしょうか？まずはそこの言語化が必要だと思います。
そこを伝えられていないのだとすると、評価する側にも課題があるような気がします。具体的な課題として言語化できないのであれば、「評価」とは言えないのではないでしょうか。

例えば、あなたから見て「考えが浅くない人」はどういった点が違うでしょうか？自分の周りにいる人の仕事を観察することで、不足ている点がわかるかもしれません。

どのようなことを考えているのでしょうか？

まず第一に「何を解決したいのか」という点を考えます。そこを掘り下げずに言われたことを実行すると、的外れな回答になったりします。目的をよく考えることで解決へのアプローチがいろいろと検討できます。そもそもコードを書く必要は無いかもしれません。

コードを書く形でのアプローチが必要だと分かったなら、解決のために必要な要素を考えていきます。
合わせて保守性やセキュリティなどの非機能要件についても考えていきます。
その他にはスケジュールであったり、プロジェクトやチームの状況も考えます。

またどの段階まで考えることができたらコードを書き始めているのでしょうか？

ぼんやりと必要な要素が見えてきたら書き始めます。
事前の設計も重要ですが、同時に机上の空論でもあります。コードを書かなければ見えてこないものもあるので、「準備を完璧にする」のような意識はありません。

質問に対して回答してみましたが参考になるでしょうか？
最初にも言いましたが、まずは具体的な課題を明らかにすることが必要だと思います。それは「言語や設計に関する知識」かもしれませんし、「非機能要件の考慮」かもしれません。あるいは「コードを書く目的」かもしれません。思い当たるものがあれば、記載されるのが良いでしょう。そうすればより具体的な回答が得られると思いますよ。

新規作成ではなく、不具合修正や機能追加が中心なんですね。
その時は
「既存のプログラムの設計思想を理解する。」
から入りますね。
複数人の手が入っているときによくあるのが元の思想をぶち壊す改造ですが、なるべくノイズを排して元の思想を汲み取りましょう。

既存の思想と使えそうな部品を把握したら、自分が入れようとする修正をどうするのか考えます。
・元の思想にあっていること
・既存の処理に影響を(なるべく)与えない
・今後の修正などに利用できる処理を作る際は部品として整備しておく
あたりが、改造や不具合修正のときに特に考慮してる点ですね。

設計は「シンプルに」を意識して、一番無駄のない形にまで絞り込めたと思ったらコードを書き始めています。

試験まで意識した設計や、仕様変更も考慮する設計など、全工程通して楽できるように考えていくと、コーデング前にも色々仕込むことができるようになりますよ。

私はシナリオをコメントで書いてリファクタリングした後、テストパターンを考えてから実装するように心がけています。
シナリオが詳細設計、テストパターンはテスト仕様書のノリです。

例えば履歴テーブルに何かを保存する実装を任された際に
//1.引数でもらったデータをDB用に加工する
//2.トランザクションを張る
//3.DBに書き込む
//4.エラーが無ければコミットする
//5.帰り値にDBの書き込み結果を返す
と一連の流れを書いてシナリオ上で不足や必要な情報を整理します。

改善点:2と3はDBに書き込む際は基本実施する他でも使っているのでは？
→　2.自動でトランザクションを張って履歴をDBに書くメソッドに書き替え

改善点:DBのテーブルはどれだっけ？
→　1.引数でもらったデータをtable.history(date,details)に加工する
　　→　でもこれだと履歴作成者の情報無いから誰が実施したか後で追えない
　　　　→　DB見直し後、table.historyに追加する

といった形です。
また、さらに単体テストのパターンを考慮するとより効率的なテストや
余りにもパターンが多い→少なく出来ないか？
といったテスト駆動開発の要素を加えることでテスト効率なども配慮した実装が出来るようになります。

多分実装前に考えるというよりは知識の問題かと
実装段階ではある程度処理の流れがイメージ出来ていて、考えるというよりは選ぶに近いと思います
例えば
・フロントエンドで認可をしてバックエンドは全開放にしてる
・構造体を作らずに手続き的に処理していたり、責務・コンテキストなどを無視している
・適切なアルゴリズムがあるのに使われていない
こういうのは実装前に考えるというより知識をつけるしかないです

普段はQiitaにコメントを書くことはないんですが、ちょうど新人教育などで思うところもあり意見させてください。
書かれた内容からは具体的な状況はわかりませんが、レビュアーから「考えが浅い」と評価されるという一点での意見になります。
私がコードレビューで「考えが浅い」と指摘するとしたら、具体的なコードの指摘をする以前の意識の問題、コードの指摘をしても伝わらないと判断している場合で、確かに新人に多いと思います。
コーディングする前に考えることですが、『そのシステムが問題なく稼働し続ける』前提で可読性、保守性、影響箇所などを判断し、その説明ができていれば間違っていたとしても「考えが浅い」などとは言わずに「こう書いた方がより良いと思わないか」と指摘すると思います。
既存システムに手を入れることは知らない人が書いた小説に加筆修正するようなもので、正解などないですからね。
ただ極端な例だと「別のシステムで似たような処理があったのでコピペしました」とだけ説明されたら指摘修正の必要がなくても「考えが浅いな・・・」と言いたくなるかもしれないなと思いました。

具体的にどういった点が不足していると言われているのでしょうか？
具体的な箇所については言われていません。
研修では課題をいくつか取り組んでいくのですが、その過程で成長が見られなかったことがこのような指摘につながったのかなと思っています。

設計思想を理解する
私はこの部分が難しく感じています。
処理のロジックは理解できるのですが、設計思想が理解できたという感覚は掴めません。設計思想についてもう少し説明していただけるとありがたいです。

具体的なコードの指摘をする以前の意識の問題
これはコードを見るだけで判断がつくものでしょうか？私とレビュアーは普段の業務では接点がなく、基本的にはコードレビューのときだけ交流があるという感じです。

たくさんの意見を書いていただきありがとうございます。
意識の部分では確かに直すべき点があったと感じます。もしよければ後輩や新入社員に対して意識の面でどうあってほしいかを教えていただけると幸いです。
私の意識を変える際の参考にさせていただきます。

どうぞよろしくお願いいたします。

私はこの部分が難しく感じています。
処理のロジックは理解できるのですが、設計思想が理解できたという感覚は掴めません。

初心者にありがちなのが、
・「動けばいい」と考えているとしか思えないような修正をする
というのがあります。
確かに仕様通りには動くけど、その修正はあかんやろ。という修正です。

ロジックが仕様を満たす。
これは大前提ですが、これだけだと「コードを書く前にもっと考えろ」となります。

色々考えないといけないことはありますが、例をいくつか書いてみますね。

まず、業務で作成するプログラムは、ビジネス文書だと考えてください。
理解しやすいように無駄なく簡潔に、第三者に見られることを意識して書きましょう。

とにかくプログラムの流れを読んでください。
オブジェクト指向なら、主要なインスタンスの基底クラスが参考になる場合も多くあります。
処理はどうやって実現しているのか、
・いくつかのブロックに分けてそれぞれ別の設計思想を持つ。
・フレームワークをベースにして統一したインタフェースで流れを見やすくしている。
・アプリケーションに特化した処理と汎化された処理を明確に分ける。
など、大小様々な工夫を組み合わせて処理は実装されています。
（もちろん、何も考えずに作られたスパゲッティなものもありますが・・・）
設計書にそのあたりが書いてあることもあります。
が、残念ながらそういう物は無い事が多いので、ソースから読み取るスキルは重要です。

流れが読めたなら、その流れに逆らわないように実装してください。
流れを無視して書くと、「もっと考えろ」と言われます。

実装する際にも、
・構成要素間がどれだけ粗結合になっているか。また、結合関係は整理できているか。
・同じような処理が複数ヶ所に散らばっていないか。部品化は適切にできているか。
などは意識してください。
例えば、Xという共通モジュールがあって、A,B,Cなどから使われている場合で
・Dというモジュールを作る際にXの処理と同じような処理をD内部に盛り込んだ
・Xの処理を拡張する際に、AのリソースをXから参照するようにした
などと、元の設計を崩すような作りにするのは御法度です。

などは一例ですが、結局の所
元のプログラムを書いた人はどう考えていたのかを読むことが重要です。
デバッグの際にも「なぜ間違えたのか」と「どう実装するつもりだったのか」が理解できるようになっていると根本的な対応が取れるので、場当たり的に対処しなくなります。

とはいえ、
慣れるまでは色々と見えてこないとは思います。
慣れるまでは、コーディング開始前に
「元のプログラムはこういう流れになっているので、こういう処理を実装しようと思います」
と、チームリーダーなどに実装方針をレビューしてもらうのが無難だと思います。
そうすれば少なくとも実装後の「もっと考えろ」は無くなるはずです。

私も質問者様と似たようなキャリアなので参考程度にお願いします！

私はコードを書く時、以下のことを考えています。

・何を？
・どこに？
・どのように？

例えば、nullかどうかをチェックして早期returnする処理を書く場合、何を？という質問にはnullチェック処理となります。

次に、どこに？を考えます。
・既に似た処理はある？
・共通処理にできない？
・新規で作る必要がある？
・他の人はどんな感じで書いてる？
とかですね。

どこに？を判断するためには、ディレクトリ構成と責務の分離について考えます。servicesとかrepositoriesとかそういうディレクトリがあると思います。これらのディレクトリ名は意味があるので、調べてみると何を書けばいいかわかると思います。

これらの各ディレクトリには、そのディレクトリで何をするべきか？という責務があります。その責務に沿う形で実装することを心がけます。

先ほどのnullチェック処理を書く場合、私はservicesに処理を書くと思います（プロジェクトルールにもよりますが、私はservicesに置きたい）。

最後にどのように？を考えます。
ここで初めて実装内容について考えます。
・こういう処理にしよう！
・このライブラリを使おう！
みたいなことはこのタイミングで考えます。

nullチェック処理の場合、if使って引数の値をチェックしようとかそんな感じです。

コーディングに限らず、設計でもそうですが、具体と抽象を繰り返すのがいいと思います。設計する時はコードを書く時、つまり具体について考えます。コードを書く時は設計根拠や要件といった抽象について考えます。先ほど、何を？どこに？というのも具体と抽象の切り替えです。何を？という具体を、ディレクトリ構成や責務という抽象で考えます。このように、具体と抽象を往復すると問題解決しやすいです！

あとは以下のコーディング原則を知っていると書きやすくなると思います！ご存知かもしれませんが一応共有しておきます！

・DRY原則
・SOLID原則

この業界だと色々大変だと思いますが、
お互い頑張りましょう！

コーディング前は何も考えません。
設計時点、または規約の制定時点で固めます。
可能であればという前提で、指摘を受けた内容の「本来あるべき姿」と「自分の現実」をパターン化させるなどいかがでしょうか？
また、指摘の理由について記録・分析をしたら、傾向や対策が見つかるかと思います。
例）
・セキュリティ上、好ましくない（インジェクション等）
・パフォーマンス上、好ましくない
・プロジェクトの規約に則ってない
・可読性が著しく低い（コメントの入れ方が「他のPGと比べて」パターンがズレている）
・修正の際の調査過程や検証内容について、良案が他にあった　など。

みなさま、貴重な意見をたくさんありがとうございます。
すぐに改善できるとは思っていませんが、意識しながら少しずつ改善していければと思います。

「なぜ間違えたのか」と「どう実装するつもりだったのか」が理解できるようになっていると根本的な対応が取れるので、場当たり的に対処しなくなります。

具体と抽象を往復すると問題解決しやすいです！

これらの意見は特に参考にしようと思いました。
また指摘の理由についても積極的に尋ねて、対策をしていこうと思います。

本当にありがとうございました。
これからも頼らせていただくことがあると思いますが、よろしくお願いいたします。