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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本記事の想定読者は入社１~２年目くらいの新人、および褒めが苦手なベテランの皆さんです。 新人の叫び とにかくいろいろと不安が多い！！ 自身の取り組みが価値を生んでいるのか不安... 自分がやっていることの方向性が合っているか不安... 成長実感の機会が少なく不安... そんな感じでいろいろと不安... これらの不安を分かりやすく解消してくれるのが「褒め」である 褒めない（苦手な）マネージャーやベテランの価値観 いろいろな理由で「褒め」をする動機が弱め これぐらいの仕事は（n年目ならば）できて当たり前 社会人として給与をもらう立

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Qiita株式会社様 主催の『Qiita Engineer Festa 2024 後夜祭 ～アウトプットの祭典！～』で登壇させてもらえることになったので、私が書いた記事の内容をベースに、アウトプットを出すための個人的な考えを話してきました。 今回の記事は、テックブログ感の薄い内容ではありますが、Qiita関連イベントの延長線上だと思って見逃してください。 登壇のきっかけになった記事： 発表スライド： もくじ アウトプットを出したいなら具体的に困るところから 1. 具体的なアクションには具体的な課題（困りごと）が必要 2. 具体

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

public class MyClassTest { /** * AAAパターンで書けるようにAAAを１つ１つクリアしていく意識を持つ */ @Test void test() { // Arrange：準備（テスト対象クラスのインスタンス化） MyClass myClass = new MyClass(); // Act：実行（テスト対象メソッドの実行） String actual = myClass.doSomething(); // Assert：検証（実測値と期待値の比較） assertThat(actual, is("hoge")); } } また、詰みポイントへの対処は後述します。（参照：コンパイラを通すフローチャート） step４．テストを実行してみてNPEを解消する コンパイラは許してくれたけど、実行してみたら容赦なく Null Pointer Exception がやって

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこ

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

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる２

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

私の場合、自身の興味関心（インプット対象）と仕事が結びついているので、アウトプットの行動が業務内容にかなり依存しています。ですが業務外の内容だとしても、上記の学びのサイクルは当たり前のフローかと思うので、だれにでも適用できるものだと思っています。 そうだね、アクティブラーニングだね。 アウトプット先を意識したインプットをしよう この記事の根幹を揺るがす発言なのですが、正直な話、知ったかぶりはある程度知識があればできてしまうんですよね。しかし『インプット過多』、これは知ったかぶりアンチパターンです。 一般的な「知ったかぶりへの嫌悪感」は、嘘を教えられたことによる信頼の失墜や、理解の浅さが露呈している他人への嫌悪ですよね。（もちろん人間性の問題もありそうだが）これは無知の知を自覚できない状態で自信だけが大きくなることに起因します。（まさにダニング=クルーガー効果） なので知ったかぶりアンチパタ

ほかにもいろいろできることはあるかと思うので、 １週間ごとにテーマを区切ってやる みんなを巻き込んでキャンペーンする みたいな感じで楽しく継続的にやっていければベストですね！ さて、どこからやっていこう？ コスパを考えたら「多くの人が読むコードから」やっていければベストですが、計測が難しいです。 なので、「より多く変更が加えられているクラスから」、がいいのではないでしょうか。 その中でもさらに優先順位をつけるとするなら、 自分が過去に修正を加えたコードとその周辺から 静的解析の結果で判明したCodeSmellがある箇所から 今やっている機能強化・不具合修正しているところから テストカバレッジが低い箇所から などでしょうか。 ここはメンバーや組織の方針などを考慮して決められたらいいと思います。 ▼ 参考 ▼ 「特定ディレクトリ以下の変更回数の取得」に関しては以下のGitコマンドでテキストファ

// 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、そのうえで自分なりに勉強をしているはずなのに、実務ではなかなか手が動かない 変更指示に対して、「先輩が言っているんだし正しいんだろうな」とその場では指示の理由や目的が分からないまま修正を行うことがある（分かっていないため別の機会で同じ指摘を受けることがある） 自身のコーディングには判断基準や根拠がなく、なんとなくの判断に頼ることがある 上