$shibayu36->blog;

株式会社アンドパッドでエンジニアをしています。プログラミングや読書のことなどについて書いています。

git grepの結果に、その行を書いたAuthorを表示する

あまり知らないコードを触るときに、周りのコードを参考にしたいことが多い。しかし、そのコードの技術スタックに詳しくない場合、どのコードは筋が良いかというのが全く分からないことがある。そういう時に、その分野に知見がある人が書いたコードを参考にしながら学習したい。

そのように知見を素早く吸収するために、git grepの結果に、その行を書いたAuthorを表示するとどうかと思ったのでやってみた。

git-grep-with-author

#!/bin/bash

git grep -n "$@" | while IFS=: read i j k
do
  author=$(git blame -L $j,$j $i --line-porcelain | grep '^author ' | cut -d' ' -f2-)
  echo -e "$i:$j:$author:$k"
done

例えばRailsのrepositoryで使うと

$ git-grep-with-author ActiveModel
actionpack/lib/action_controller/metal/params_wrapper.rb:52:Prem Sichanugrist:  # If you're going to pass the parameters to an +ActiveModel+ object (such as
actionpack/lib/action_controller/metal/strong_parameters.rb:260:Francesco Rodriguez:    #   Person.new(params) # => ActiveModel::ForbiddenAttributesError
actionpack/lib/action_controller/metal/strong_parameters.rb:424:Francesco Rodriguez:    #   Person.new(params) # => ActiveModel::ForbiddenAttributesError
actionpack/lib/action_controller/metal/strong_parameters.rb:873:Prem Sichanugrist:    # This is required by ActiveModel attribute assignment, so that user can
actionpack/lib/action_controller/metal/strong_parameters.rb:1157:yuuji.yaginuma:  #     # ActiveModel::ForbiddenAttributesError exception because it'd
actionpack/test/controller/redirect_test.rb:6:Jon Moss:  extend ActiveModel::Naming
actionpack/test/controller/redirect_test.rb:7:Jon Moss:  include ActiveModel::Conversion

のようにファイル名と行の後に、Authorを出してくれるようになった。便利。

「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ

開発組織をスケールする方法を学びたい - 「ユニコーン企業のひみつ」を読んだ - $shibayu36->blog;に引き続き、開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのかのヒントを得るために、「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ。

めちゃくちゃ良かった!この本では、組織のスケールで重要な局面を採用・人事管理・組織・文化・コミュニケーションの5つとし、それぞれに対して何を気をつけるべきかについてまとめてくれている。特に自分の興味と合致する「採用」「組織」の部分は本当に参考になった。例えば「組織」のところで組織構造を考える原則について紹介されているのだけど、非常に端的にまとまっていて印象に残った。

  • 組織構造を設計する際に忘れてはならない2つの重要な目標 3105
    • 小規模組織の敏捷性をいつまでも失わず、作業を素早く進められる組織構造
    • 社員一人一人を製品とその成功に直結させる
  • 組織設計の原則 3107
    • デリバリーチームの構築:着想から公開まで全てに必要な職能をもれなく備えた自立型チームを作る
      • 未処理案件の大部分(最高で95%)を他チームに依存せずに本番環境に移せるチームが、真の意味で「自立型」と呼べる 3185
      • 大規模プロジェクトの臨時チームの立ち上げの時も同じように行う
    • 自律性の確保:割り振られた目標を最良の形で達成するためにはどのような行動を取るべきかを自決する権限をチームに与え、選択したアクションの影響を必ず測定させる
      • 自律性とは、一定の制約の範囲内で、どの作業を進めるかを決める自由をチームが有すること 3227
        • 制約とは、ビジネス上の優先度、組織全体の目標、チームの権限など。チーム間の足並み揃えにはこの制約は必要
      • チームの自律性がより広範な戦略的目標のために無視されてしまうことがあるが、次の2点は守りたい 3280
        • チームは常に少なくとも勤務時間の半分を自由に使えるように。戦略的な取り組みは半分まで
        • ただし例外として、戦略的な取り組みの中でそのチームがボトルネックになっているなら、チームは作業時間の全てを使ってでもボトルネックの解消に努める
    • 目的の明確化と成功度の測定:どのような目標を掲げれば前者レベルの成功に最も寄与できるかを把握する必要がある
    • 継続的デリバリー:フィードバックを頻繁に得られ、製品の質の向上や顧客思考の思考が定着する。短期間で成果を反映できるためチームの満足度も高まる。市場投入までのリードタイムを減らせる
    • 継続的学習を重視する文化の醸成:振り返りと改善をし続ける
  • 自立型チームを柱にした編成に付き物のリスクは二つ 3679
    • チーム間コラボレーション不足、スケールメリットが見込めなくなる
    • Spotifyでは横の繋がりを作るための仕組みを用意

こんな感じで学びが多いのでおすすめです。

「価値が最低の段階で問題発見し解決すべき」と「ソフトウェア開発のプラクティス」

最近「HIGH OUTPUT MANAGEMENT」を読んでいて、製造工程では「価値が最低の段階で問題発見し解決すべき」という話が出てきた。この言葉を見て、ソフトウェア開発のプラクティスも結局こういう話だなと思った。例えば

  • リーン開発は、価値最小の段階でユーザーに見せてしまって検査し、問題発見する
  • TDDは価値最小の段階で自動テストによって検査する
  • 機能横断型チームは、価値最小の段階でいろんな専門性の観点から問題発見できる
  • セキュリティのシフトレフトは、価値最小の段階でセキュリティ面の問題発見ができる
  • Design Docは価値最小の段階で方針や設計の問題発見ができる

なんとなくいろんな言葉が繋がっていって面白いなと思ったのでブログにメモしておく。