はじめに レビュワーにとってコミット履歴は追いやすさはとても大事だと思う一方で、最初からきれいな履歴を保つのはけっこう難しいです。修正が漏れたり、あとから必要な箇所が分かったりして、コミット履歴が予想より膨らむことも多々あるのが実際の開発です。 あとから履歴を書き換える そんなときはこのコマンド（git rebase -i）です。 平たく言うと、コミット履歴の編集、統合、順番の変更などができるコマンドです。 使い方 例えば以下画像のような、「前のコミットで修正漏れてたのでしゃーなしワンモアコミットしちゃった」みたいなケースを考えます。 step１. rebaseを開始したいコミットハッシュを特定する 今回は、hash ddddd を hash ccccc に統合したいので、直前のコミットである hash bbbbb のコミットハッシュを取得します。 $ git log commit fff

はじめに 本記事の想定読者は入社１~２年目くらいの新人、および褒めが苦手なベテランの皆さんです。 新人の叫び とにかくいろいろと不安が多い！！ 自身の取り組みが価値を生んでいるのか不安... 自分がやっていることの方向性が合っているか不安... 成長実感の機会が少なく不安... そんな感じでいろいろと不安... これらの不安を分かりやすく解消してくれるのが「褒め」である 褒めない（苦手な）マネージャーやベテランの価値観 いろいろな理由で「褒め」をする動機が弱め これぐらいの仕事は（n年目ならば）できて当たり前 社会人として給与をもらう立場なのだから、メンタルやモチベーションコントロールはプロとして自分で管理すべき 褒められないと不安になったり落ち込むのは幼稚すぎる、会社は学校じゃない 自分自身の経験的に、褒められずに仕事を覚え、成長してきた なので、特に「褒め」に対するモチベーションが大き

はじめに Qiita株式会社様 主催の『Qiita Engineer Festa 2024 後夜祭 ～アウトプットの祭典！～』で登壇させてもらえることになったので、私が書いた記事の内容をベースに、アウトプットを出すための個人的な考えを話してきました。 今回の記事は、テックブログ感の薄い内容ではありますが、Qiita関連イベントの延長線上だと思って見逃してください。 登壇のきっかけになった記事： 発表スライド： もくじ アウトプットを出したいなら具体的に困るところから 1. 具体的なアクションには具体的な課題（困りごと）が必要 2. 具体的なフィードバックを得るためには具体的なアクションが必要 3. 具体的な課題解消には具体的なフィードバックが必要 4. 具体的なアウトプットには具体的な課題解消が必要 5. 具体的なアウトプットは対自己と対他がある " WILL " を持つことで、具体的な困

※ 最小の意思決定にしては粒度が粗めですがイメージはつくかなと思います 開発プロセスも同様で、目的に対して複数のステップを踏むことがほとんどですよね。リファクタリングであれば単体テストをあてる ⇒ メソッドの内部実装変える ⇒ テストのリファクタリングする、みたいな。 こうした１つ１つの小さな意思決定という単位で履歴（意図）を残すことは、開発者の責任です。なぜなら、変更の差分はPRを見ればわかりますが、「なんでその意思決定（コードの変更）をしたのか？」はコミットメッセージを見ないと分からないからです。そういう意味で、開発者の Why? を把握するために、最終的なPRの差分がどのようにして出来上がったのかを知るために、最小単位の意思決定の履歴はレビュワーが欲しいと思う重要な情報なのです。 コミットメッセージが簡潔で分かりやすい コミットが意思決定の最小単位になっている と関連しますが、意思決

はじめに ついこの前、経験の浅いメンバー向けに単体テストを書きまくってもらう研修を実施したのですが、経験が浅いと「どうすれば単体テストを書ききれるか？」の見通しがうまく立てられないんだろうな～という印象を受けました。 なので、できるだけ体系立てて説明ができるように記事に残そうと思います。 想定読者 単体テスト経験の浅いメンバー（入社1~2年目くらい） レガシーコードの単体テストに苦手意識を持っている人 大前提 前提１：とってもレガシーなコードである 前提２：「これでだいたいのテストは書ける、しかし良いテストかどうかは分かりません」 20年物のレガシーコードなので、正直、難易度めっちゃ高いと思います。レガシーコードへの単体テストは特殊技能と言っても過言じゃないです。 また、最初から良いテストを目指さなくていいと考えています。良いテストなのかどうかを考えるのは、まず「なんでもテスト書けるぜ！」

はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には３つのレベルがあることを知る な

はじめに 知識のおすそ分けです。 目次 単体テスト対象のメソッド in 抽象クラス 抽象クラスに単体テストを書くときのハードル 抽象クラスに単体テストをあてる方法５つを紹介します 方法１．抽象クラスが継承されている具象クラスに単体テストを書く 方法２．抽象クラスを継承する具象クラスを新たに作成して単体テストを書く 方法３．テストクラスで匿名クラスを作成して単体テストを書く 方法４．Mockito.Spy を使う 方法５．Mockito.CALLS_REAL_METHODS を使う おわりに 開発環境 JUnit 5 Java 8 以降 単体テスト対象のメソッド in 抽象クラス 以下のような抽象クラス AbstractMyClass.java に定義された getHogeString() メソッドに単体テストをかぶせたい！という状況を想定します。 public abstract class

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。

18:45~ | 開場 19:00~ | オープニング 19:10~ | LT * 5 - 開発生産性と開発者体験の向上に向けたCI/CD改善の取り組み：PRONI株式会社/末澤 尚也さん - AWSで構築するCDパイプラインとその改善：株式会社スマートラウンド/山原 崇史さん - CIは5分以内！素早い開発サイクルを支えるCI：ファインディ株式会社/浜田 直人さん - CI/CDボトルネックの把握とその先へ：サイボウズ株式会社/加瀬 健太さん - デプロイ再考2024：株式会社estie/杉田 毅博さん 20:20~ | 懇親会 参加の動機 私自身がこれからCI/CDをやっていく人としてまず「自組織のあるべき姿を描く」ため、自組織の現状と理想とのギャップを知る必要がある。理想状態を知るためには他社の取り組み知るのも１つの手だよなと思ったので、参加してみよう、という動機。 感想 結論、CI

はじめに この記事では、学んでいくためのマイルストーンとして「知ったかぶりができること」を設定するのもアリなのでは？ という提案をします。 初学者でなくても『どうやって学んでいこうかな～』は全エンジニアの関心事だと思うので誰かの行動のきっかけになれたらうれしいです。 目次 （エンジニア）人生は勉強や！ 「知ったかぶり」を再定義する 「知ったかぶり」を可視化する 無知の知はすぐに自覚できる どうすれば人に説明できるようになるのか いったんここまでのまとめ 脳内イメージの解像度をどう上げていくか アウトプット先を意識したインプットをしよう " 知ったかbrilliant Journey of Engineers " さあ、なにを知ったかぶりしていこう？ おわりに （エンジニア）人生は勉強や！ 技術は高速かつ複雑に成長しているので、新たな分野を学ばなきゃいけない機会はどんどん増えていく。また、そ

はじめに 年次関係なく誰でもできる小さな品質改善活動の話をします。 私事ですが、今年の1月に同じ部署内のCI/CD Grp.に異動しました。 CI/CD Grp. という名前ではありますが、組織でやっていきたいのは Developer Productivity Engineering で、CI/CD関連の業務以外にもいろいろと自由にやらせてもらえてます。 『いいコードを学んだけど、最近コード書けてないや』と、ふと思ったのでせっかく書くなら品質上げるコミットをdevelopブランチにマージするナニカをしようと思ったのが本記事の背景です。 仕様化テストとリファクタするぞ！と意気込んでました 今まで一生懸命がんばってきた甲斐があって、保守しやすいコードを書く大切さを理解し、意図をもってコーディングできる自信がついてきました。（成長したね...） 『CI/CD Grpメンバーとして、他グループの開

この記事で伝えたいこと（忙しい人向け） 新人ほど「保守していく」ことの感覚が腹落ちしにくいのではないか説 我々は保守しやすいコードを書くべきであり、保守しやすいコードを達成するための手段として原理原則やデザインパターンが存在している 保守ってなんで必要なんだっけ？という体系的な理解を持ったうえで、具体的なテクニックを学んでいくことが大事 // 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、