ポンコツPdMの開発メモ – 学習と現場をつなぐ

2026/9/18

privateメソッドをモックしたい？通信の失敗をテストするなら、置き換える場所を変える

公開メソッドの中でprivateメソッドを呼び、その中で外部へ通知している。通知の失敗をテストしたくて「Mockito private モック」と検索した。この場合、置き換えたいのはprivateという実装上の区切りではなく、外部通信です。この記事では、通知サービスを例に、privateの名前に依存せず、通信失敗時の動きを確認する形へ変えます。新しく書くテストでは、まず通信を差し替えられる依存にする。純粋な整形処理は公開メソッドの結果から確認し、成功・失敗を作りたい外部依存を置き換えます。既存のPow ...

設計・テスト・レビュー

2026/9/18

クラスやメソッドは何行で分ける？CSV取込を例に、切る場所を決める

レビューで「このメソッド、長いので分けて」と言われた。とりあえず30行ずつ切ったら、途中の変数を大量に引数へ渡すことになり、前より追いづらくなった。この記事は、長い処理を任され、分割する境目に迷っているJava開発者向けです。行数のルールを増やすのではなく、入力・出力・失敗が説明できる仕事のまとまりを見つけます。行数は見直すきっかけ。切る場所は処理の意味で決める。分割後の呼び出し元を読んで、何をしているか分かること。途中の状態を追うために、あちこち往復しなくて済むことを確認します。 CSV取込には、別 ...

学習・成長

2026/9/27

エンジニア転職はいつ考える？学習で解ける壁と職場環境の壁を切り分ける

「もっと学べば前に進める」と思っても、試す仕事や相談相手がないなら努力の量だけでは解けません。まず、足りないものを分けて考えます。この記事の立場学習で補える不足は学ぶ。学習だけで変わらない環境は相談し、改善しなければ他社も比較する。たとえば「設計をやってみたい」と勉強しても、任されるのは以前と同じ作業。年数や資格の数だけでは、学習が足りないのか、試す機会がないのかは分かりません。転職活動を始める前に、知識と仕事の機会・支援を分けて確かめる。それでも現職で改善の見通しが立たなければ、外の仕事を比較する ...

仕事・チーム開発

2026/9/18

リモートで新人から質問が来ない｜「いつでも聞いて」より途中の成果を見る

環境構築を頼んだ新人から、一日連絡がなかった。終業前に聞くと、午前中から認証エラーで止まっていた。「困ったら聞いて」と伝えたはずなのに、どうして黙っていたのだろう。この記事は、リモートで新人の受け入れやOJTを担当する人に向けたものです。本人が質問できるようになるまで待つのではなく、質問が来なくても行き詰まりを発見できる仕事の渡し方を作ります。最初の仕事では、完了報告だけを待たない。途中で見せる成果、止まったら連絡する条件、受け手の返信時点を決めます。「分からないことはない？」より「どこまで動いたか見 ...

実装・エラー解決

2026/9/18

Spring Bootで500エラーが出たら｜再実行する前にログと更新結果を確認する

注文を登録したら画面に500エラーが出た。もう一度押せば通るかもしれない。でも最初の注文が登録されていたら、二重になるかもしれない。この記事は、Spring Bootアプリで初めて500エラーの調査を担当する人向けです。例外名を探すだけでなく、同じ操作を繰り返してよいか、どこまで処理が進んだかを確認する順序を示します。更新系の操作は、500だから失敗したとは限らない。まず対象リクエストを特定し、保存や外部送信の成否を確認します。原因の確定を待たず、分かった影響と次の連絡時点を共有してください。 500 ...

仕事・チーム開発

2026/9/18

仕様確認メールの書き方｜食い違う資料から、相手が答えられる一通を作る

設計書ではユーザーIDが必須になっている。しかし前回のレビューでは任意と決まったはず。このまま実装すると、外部連携側と条件が合わないかもしれない。確認メールを書こうとして、経緯を全部説明したら長文になった。この記事は、そんな仕様の食い違いを、設計担当や顧客へ確認するエンジニア向けです。相手に答えてほしい問いを一文目に置く。その後へ、食い違っている根拠、実装への影響、判断が必要な時点を付けます。短くする対象は挨拶の重複であり、判断材料ではありません。「確認をお願いします」だけでは、回答が決まらない次 ...

学習・成長

2026/9/27

新人エンジニアの目標設定例｜「Javaを勉強する」を仕事で確認できる成果に変える

目標シートに「Javaの理解を深める」と書いたら、上司から「具体的には？」と返された。資格名や学習時間を足したものの、実務で何が変わるのかは自分でも曖昧なまま。この記事は、初めて業務目標やOJTの目標を作るエンジニア向けです。立派な将来像を作る前に、今できずに困っている仕事を一つ選び、その成果を誰と確かめるかを決めます。目標は教材の消化量ではなく、仕事でできるようになることから作る。「何のために」「何を残すか」「どう確認するか」を先に書き、そのために必要な学習を選びます。「一冊読む」は行動。「調査結 ...

学習・成長

2026/9/18

コピペしたコードが説明できない｜「動いた」の次に確認する三つの前提

別のバッチを参考に処理を書いたら動いた。でもレビューで「失敗したら、どこから再実行される？」と聞かれて答えられない。コピー元にも同じ処理があるから大丈夫だと思っていた。この記事は、既存コードを参考に改修できるようになったものの、採用理由や失敗時の動きを説明できない人向けです。コピー自体を禁止する話ではありません。コピー元で成立していた前提が、今回も成立するかを確かめます。全部を読む前に、結果が変わる条件を一つ選ぶ。入力・失敗・再実行の三つを問い、動く理由を予想してから試します。説明できない条件は、調べ ...

実装・エラー解決

2026/9/18

Javaのスタックトレースの読み方｜Caused byの後、どのコードを開けばいい？

ログに何十行も赤い文字が出ている。Caused byが大事だとは聞いたけれど、一番下の例外名を検索した後、どのコードを直すのか分からない。この記事は、Javaの不具合調査を初めて担当する人向けです。ゴールは例外名を覚えることではなく、失敗した値と、その値を作った処理を調べ始められることです。原因例外を読んだら、自分たちのコードへ戻る。一番下の例外名は「何が失敗したか」の手がかりです。それだけで、悪い入力を作った場所や直し方までは決まりません。まず、調べる一件を選ぶ同じ時刻に複数のリクエストが動く環 ...

実装・エラー解決

2026/9/18

git add後の変更はコミットされる？消したデバッグログが残る理由と確認方法

レビューへ出したコードに、削除したはずのデバッグログが残っていた。エディタでは消えているし、手元のテストも通っている。なぜ古い内容がコミットされたのか。 git addの後に編集した内容は、自動ではステージへ反映されません。この記事では、通常のgit commitを使う場合に、何が記録されるかを二つの差分で確かめます。commit -aやファイルを直接指定するコミットは、今回の例には混ぜません。 addは「このファイルを予約する」ではなく、「今の内容を次のコミット用に置く」操作。add後の修正も入れるなら ...

« Prev 1 2 3 4 … 17 Next »