サンダーボルト

相手モンスターを全て破壊する。

コミットメッセージの書き方メモ

プログラミング基礎

これ何？

コミットメッセージの書き方について今一度調べて自分なりの結論をまとめておく。

まとめ

  • そこまでこだわる必要なさそうだが、feat: やchore: といった接頭辞くらいはつけておいても良さそう
    • chore: とかつけておくと、単にライブラリを入れただけのコミットなんだな、とか refactor: だったらリファクタなんだな、とかが分かりやすい。
  • whyを書く場所には、コードコメント、コミットメッセージ、PR等があるが、後になるほど粒度が大きくなる。行単位、コミット単位、PR単位のそれぞれのwhyがあるのでそれぞれ適当な場所に書くのが良さそう
  • とはいえ、PRでも行ごとにコメントできるため、PRにも行ごとのwhyが書かれることが多い。なので、コミットから該当PRをたどる方法は知っておいた方が良い。
    • GitHubのPull Requestsの検索窓にてコミットハッシュを入力し検索すれば出てくる。
  • チームの方針と合うならAIに書いてもらうのも良さそう

Q&A

  • 接頭辞は何を使う？
  • コミットコメントはテンプレ決めてかっちりやった方がいいんじゃないの？
    • コスパの話もあるので、最低限接頭辞つけるくらいが良いのではと個人的には思っている。有名リポジトリでも接頭辞すら無いのも全然ある。
    • チーム全体が納得するならかっちりやっても良いかも。ただ将来加入する人のことも考えるとかっちりやりすぎると大変そう。
  • そもそもコミットコメントをうまく書くためにはコミット単位が大切なのでは？
    • 本当にそう
    • なので場合によってはWIP、WIPとかでコミット積んでいってあとでコミットをきれいにする、とかってパターンもあるよう
    • 個人的にはrebaseでうまいことコミットを統合したり分割したりとかはしないので、ある程度スピード落ちない範囲でよしなにやっている
    • 開発しながらどこでコミット切るか考えながらやるのが大事だよね

  • こんな意見もありますよ？

    • 個人的にはwhyとwhy notは同じようなものなのでその種別で書く場所を分けるのは反対の立場。どちらもスコープ次第で書く場所を考えるべきな気がする。
  • 日本語？英語？
    • どちらでも良さそうに思える状況なら日本語使えば？派になってきている。
    • 前は結構頑張って英語書いていた。世界を見たとき話者数も多いし、今チームに日本人しかいなくても海外の人が増えるかもとか思っていたので。とはいえ、結局チームはずっと日本人だったり、英語で苦しくなったら苦しい英語を書くか日本語で書くかとかになってしまうし、まぁ将来海外の人が入ってきても加入以前のメッセージは翻訳して読んでくれって気もするので、最近はかなり日本語寄り。個人プロジェクトで英語なんて使わなけりゃ良かったと強く思っている。
    • OSSとかで必要になればそれはそのとき頑張って書けば良いだけかなって。

リポジトリ調査

https://github.com/flutter/flutter/commits/master/

https://github.com/rrousselGit/riverpod/commits/master/

https://github.com/facebook/react/commits/main/

https://github.com/labstack/echo/commits/master/

  • flutter, riverpod, react, echoはどれもコミットメッセージのフォーマットは決まっていなさそう。皆各々、思い思いのコミットメッセージを書いている。

https://github.com/golang/go/commits/master/

  • goは影響のあるパッケージを最初に書いている

AI

dev.classmethod.jp

例えばこれを使うと良い感じにそれっぽいメッセージが生成できそう。チームの方針（フォーマットや言語など）が合っている場合は使えば良さそう。

参考

Gitのコミットメッセージの書き方（2023年ver.）

  • 巷で人気の記事。絵文字つけるとカラフルで良さそう。

Conventional Commits

  • 少し細かめで、!つけたらBREAKING CHANGEだよ、とかのルールもある

Semantic Commit Messages

  • 接頭辞つけようね、くらいの話

スクラム実践者が知るべき97のこと　メモ

読書 マネジメント

モチベーション

👆を読んだので、今後のアクションに活かすため、また時間が経ってから簡単に振り替えれるようにメモ。

メモ

第Ⅰ部

  • スクラム通りに仕事をしたからといって急になにか良くなるわけじゃない。マインドセットが重要。アジャイル宣言の背後の原則とスクラムの価値を受け入れないといけない。
  • スクラムとは、組織がスプリント内で価値を提供できるかを確認するシステムインテグレーションテストだ
  • 不要な仕事、MTGはやらない
  • 経験主義。あるチームでうまくまわっていた方法が別チームでもうまく使えるとは限らない。
  • 1つのプロダクトバックログを複数のスクラムチームで共有すると、専門性が出るが連携しづらい。1つのバックログと1人のPO、そして複数の開発チーム、という構成もあり。
  • 完成の定義について、「コードレビューされている」「単体テストされている」「受け入れテストされている」等で決めるより、独自の品質やユーザビリティの基準等を決めて運用すべき。なぜならレビューされることが大切なのではなくお客様に価値を届けることが重要だから

第Ⅱ部

  • プロジェクトの成功よりプロダクトの成功。満足が先、利益が後。契約やスケジュールから決まるインサイドアウトの考え方でプロダクトを作ってはだめ。
  • 新技術の採用とフィーチャーの開発はプロダクトの提供価値向上に必須。これにより別プロダクトを開発する必要性を減らせる。
  • 以前は、スケジュールと予算を作り、その通り実行することが成功の鍵とされていたがこれはオール・オア・ナッシングであり危険。完成したところから徐々に出荷するのが良い。その中でも分析ツール、ヒートマップ、A/Bテスト、カウンターなどを使ってうまく改善していくのが良い。
  • スクラムマスターは開発チーム内だけではなく、開発チームがやっていることが会社全体として正しい方向を向いているかを気にすべき
  • プロダクトオーナーがステークホルダーと開発チームの間に入って、コミュニケーションのボトルネックになってしまうことは避けるべき。もしステークホルダーと開発チームが話して、勝手に機能を作ったとしても、POはスプリントレビューで必ずそれに気づき、それが問題としてRetrospectiveで上がってきて、改善されるはず。スクラムは透明性を提供する。POの最も重要なタスクである優先順位付けをきちんと行えばこれについては問題ないはず。
  • POは多くの人と関わるためコミュニケーション戦略を立てないと時間がたりない。例えば以下のようにステークホルダーを分ける。そしてグループごとに目標、連絡手段、連絡内容を考えて効率的にコミュニケーションを設計する
    • 常には見なくて良い
    • 常に方向する必要がある
    • 常に満足させる必要がある
    • 緊密に管理する必要がある

第Ⅲ部

  • スクラムチームが価値基準（commitment, courage, focus, openness, respect）を取り入れ実践すると、スクラムの柱（透明性、検査、適応）が現実のものとなる。スプリントゴールを達成しようとチーム一丸になることができる。
  • 意思決定ロジックの先頭は「顧客」。顧客のために何かを判断する。優先順位は顧客＞会社＞チーム＞個人
  • スクラムアンチパターン4つ
    • 買いだめ：スプリントプランニングで一人が複数タスクを抱え込む。どれも半端に手を出して結局どれも終わらない。
    • 独り占め：一人の開発者のみで作業してしまい、協業できない
    • 専門化：各自が得意なものを実装し、問題が最後まで露呈しない。結合が遅いとリスクが高い。
    • 一般化：広く浅いスキルの開発者が複数のタスクに手を付け、詰まったら別のタスクを行う。結合が遅く、リスクが高い。
  • 上記を解決する方法として、ペアプロ、スウォーミング、モブプロなどがある
  • プロダクトバックログ、サブタスク進捗、バーンダウンチャート、ベロシティなどを積極的に公開して透明性を上げる

第Ⅳ部

  • プランニングポーカーでは見積もりに使える情報を発信し、聞き、他のタスクと比較する。発信する内容としては、以下のような内容が有益
    • 以前チームとしてこれをやった/やってない
    • 個人として活かせるスキル/経験がある
    • 以前にやったことがない
  • ユーザーストーリーの形式を「XとしてYしたい。なぜならZだからだ。」とするのは、以下が理由。セキュリティについて考えるときは、クラッカーのユーザーストーリーを考えることも有益。
    • どう作るかよりも何を作るかに集中できる
    • ビジネスサイドにも理解されやすい
  • 障害とかも含めてなんでもかんでもバグって言うと不快なので気をつける。
  • バックログリファインメントでは、詳細化、見積もり、優先順位並び替えをする
  • ストーリー分割チートシート

第Ⅴ部

  • スプリントにしっかり区切りを持って、達成を祝うようにしないと「無限スプリント」のように感じ、やる気を失う
  • スプリントゴールの悪い例/良い例。良いスプリントゴールを設定できると、何のためにこのスプリントを過ごすかを意識でき、モチベーションが上がる。
    • [悪]バグを10個修正する
    • [悪]7個機能を実装する
    • [良]UIとパフォーマンスを改善しカートからの離脱率を30%以下にするこれにより悪い購入体験が売上を減らしている問題を解決する
    • [良]ユーザーは簡単に商品を探せるようになる。このうち1つのフィーチャーを追加する。
    • [良]40ドル以上で送料無料になるようにする。そうすることで単価が上がるという仮説を検証する
  • スプリントゴールを立てるヒント
    • スクラムチームのメンバーがステークホルダーに廊下で呼び止められ、「次のスプリントレビューでは何が見れるの？」と聞かれたときを想像する。なんと答えるのが良いか？
    • XX機能まわりを強化するスプリント、とかも良い
    • このスプリントによってどのようにビジョンに近づくのか？と問うてみる
    • 複数のスプリントゴールがある場合は、1つ選んでみよう。全部が重要というのは、全部が重要でないのと同じ。
  • スプリントレビューの目的は、フィードバックを得ること。「承認をいただけますか？」ではなく、「さぁ、このプロダクトをより良くするにはどうすれば良いと思いますか？？」と問う。すると参加者はその場の目的を理解しやすい
  • デモしてフィードバックをもらうだけではなく、できればデプロイして触ってもらう

第Ⅵ部

  • サーバントリーダー：リーダーはまず相手に奉仕し、その後相手を導くものである
  • スクラムマスターへの基本的なアドバイス。1. チームに聞け。 2. 自分自身を不要にせよ。
  • スクラムマスターはコーチしたり、教えたりはできるが、メンバーを管理する権限はない
  • タスクボードや様々なデータを公開するだけでは十分な透明性があるとは言えない。適切な相手と適切な頻度で質の高い会話をすることが重要。

第Ⅶ部

  • チーム部屋に前向きな雰囲気を作り出すことで、スクラムにおけるインサイト（アハ体験）を生み出す確率を上げることができ、創造的なアイデアを出すことにつなげられる
  • スクラムイベントを生き生きとさせるコツ
    • 聞くより話す、読むより書く、座るより動く、長くより短く、同じことより違うこと、言葉より画像。
    • 具体的には、
      • デイリースクラム：順番を変える、立ってやる。
      • スプリントプランニング：付箋を使う
      • スプリントレトロスペクティブ：フォーマットを変えてみる
      • スプリント：短くする。完成の定義を絵にして壁に飾る

第Ⅷ部

  • 人はリソース（ロボット、歯車、機械）ではない
  • 改めて、スクラムの価値とは
    • 確約：献身ということ。スプリントゴールを達成するために、献身する。
    • 集中：役割ごとにうまく説明責任が分けられているため、シンプルなことに集中できる
    • 公開：全員が自分のしごとや進捗、学び、問題を明らかにする。またそれが推奨されている。
    • 尊敬：他の人のスキルや専門知識を尊重する。意見の違いも尊重する。顧客の心変わりを尊重する。
    • 勇気：要件が決して完全ではないと勇気を持って認める。変更の検討にも勇気が必要。経験主義に基づき勇気をもってスクラムの価値を守る。
  • 人間味あふれるスクラムマスター5つの特性。共感、謙虚、思いやり、信頼性、寛容。

第Ⅸ部

  • スクラムの中に留めるべき（外から口を挟まないべき）こともある。留めることで安全性が上がる。

第Ⅹ部

今後のために

  • スプリントバックログに積みすぎない（全部消化するというモチベーションが生まれにくい）
  • 同じボードを使うけど、チームを分けるという方法も検討する
  • 新技術の採用はプロダクトの提供価値向上に貢献しているか？
  • 分析ツール、ヒートマップ、A/Bテスト、カウンターなどの導入を検討
  • お客様に価値を届けられているかでプロダクトを評価したい
  • バックログリファインメント中に優先順位並び替え時間を設ける
  • 「スプリントゴールを達成するため」に、昨日のtodo、今日のtodo、困っていることをdaily scrumで伝えているか？
  • スプリントレビューのやり方を再考
  • スクラムの経験主義によって得られる学びはチームごとに違うはず。ではそれぞれのチームはどんな特性があり、何を得られたのだろうか？

2021年振り返り

ポエム

軽く言語化してみる。1年後にこの記事を読むと面白そう。

仕事

2021年4月まではメディアドゥという会社で働いていました。 メディアドゥでは コミなび という10年物の電子漫画サイトを1から作り直すという仕事をしていました。フロントをリードしつつ、スクラムマスターとしても働いていました。今でこそそれなりの見た目ですが、リニューアル前はガラケーサイト感も強かったです。

たしか2019年8月くらいから関わっていたのでかなり長いプロジェクトでしたね。Angular/Go/AWSみたいな作りで、イチからプロダクトを作って、すでに大量のユーザーがいるサービスをしっかりリプレイスしてリリースしきるという非常に良い経験をさせてもらいました。リリース当日は1時間単位で予定を決めて、みんなで同じzoomの部屋で同期的に作業して、夜中にログインまわりの対応して、で、意外と問題なくリリースできて、AWS上で徐々に増えるアクセス数を見たりして、、、と今となってはとても良い思い出となりました😊 後半はPM的な業務もやりつつ2021年3月に無事リリースをして、4月の1ヶ月はできる限りリリース後の対応をして退職となりました。

2021年5月にエンペイという会社に転職しました。

前前職の同僚が創業しており、スタートアップってどんなもんかなと話を聞いてみると

  • やりがいのある仕事がありそう（良い履歴書が書けそう）
  • 優秀な人たちと働けそう
  • スタートアップということもあり主体的に事業/会社の成長に取り組めそう
  • スタートアップなのにホワイトそう

ということでとても面白そうで、楽しく成長できそうだと感じました。分野としても自分がユーザーとしても関わりうる保育という分野で、非常に興味がわきました。

実際、最初はスタートアップということでビビっていました笑　なんか潰れたらどうしようとか、給料払われるのかな？とか、あとは小さい会社ということで無駄に雑に不安に思っていました 笑　でも、何回か話を聞かせてもらって色々正直に話してもらい、不安はなくなり、しかもフルリモートに妻は大賛成でかなり後押しされました。で、結局入社することに。

入社してからは一瞬で半年くらい経った感覚です。関わった仕事はざっくり以下の通り。

  • フロントの巨大な負債の返済
  • フロントの、最もよく使われるトップ画面の大幅リニューアル
  • スクラムの導入と運用、メンバーのコーチング
  • 採用活動
    • リファラル3人(2人は入社済み、1人は来年入社予定）
    • 面接の設計

他にも権限管理まわりやfeature flagまわりの仕事もしました。

フロントの負債返済はかなり大変でしたが、大きな問題を細分化して着実に、そして効率よく進められたかなと思っています。あのままだと確実に立ち行かなくなっていただろうなと思うので、良い仕事だったのではないかなと。リニューアルも大きなバグなく終えられましたし、個人的にはかなりVue（エンペイで初めて触れた）にも慣れてきて速度も出てきました。スクラムもまだ改善点はあれど、導入し、きちんと運用していることでかなり心地よいチームが出来上がってきていると思います。開発チーム外の営業やCSメンバーとのコミュニケーションも心地よく、ストレス少なく仕事できて、シンプルに転職してよかったなぁという感じ。

あとやはりスタートアップは主体的に事業に取り組むようになるのがでかいなと思います。それまでは何百人、何千人の会社でしか働いたことがなく、会社の業績とか事業計画とかを強く意識したことがありませんでした。自分ごととして捉えるので社内のいろんなニュースが楽しいです。

いや〜転職してよかった。

勉強

どうでもいいけど、結構疲れてきたのでここからかなり雑になりそう笑

あまりできなかったと思う。たぶん技術書も3冊くらいしか読んでないと思うな。本以外に色々技術いじったりもしたけど、でもなかなか昔ほどはできてない。やはり固まった時間をとれないので思った通りに勉強できない。

その中でもCPUの勉強をしたのは面白かった。あとはFlutterいじったり、Reactいじったり。もっといじりたいな〜〜

私生活

息子が保育園に行きだしたのが最大のイベントだった。すごく不安だったけど、楽しくやれているみたい。保育参観も感動だった。とにかく元気にいてほしい。それだけや〜。

あと車買った。夢が叶ってしまった。

小さい頃からとある車種が好きで、小学生の頃に親に買ってもらったミニカーは今でも大事においてある。数も結構あって、一番でかい当時1万円くらいしためちゃめちゃ精巧な1/18スケールのやつはデスクに飾っている✌

2ドアスポーツカーに快くOKしてくれた妻には感謝🙏息子も大好きになってくれて休日はめちゃめちゃ充実するようになった！お財布はとても寂しい感じになった！

投資

4,5年前から投資信託積立をしているけど、今年は個別株に結構手を出した年になった。適当に買ったZMがそれなりに利益出て、これはちゃんとしてほうが良いのでは？と思い色々勉強しつつやった。ずーむ、ANA、グーグル、あっぷる、デルタ航空、エクソンモービル、テスラ、とか手を出した。

結果、個別株についてはスクリーニングとか色々見るのとかやっぱだるくて自分には向いていないなと思い、先日、「吹き飛んでも良い金額でそれっぽいところ買ってガチホ」が自分には良いという結論に至った。果たして一年後の自分はこの結論を見てなんと言うのだろうか😅

2022年

  • 仕事については、自分だけではなくチームのパフォーマンスが上がるような仕事のやり方をしていきたい
  • 勉強については、やり方変えて時間増やしていきたい。いいテーマ見つかればまた個人開発とかもやりたい。

あと、なんとなーく最近ワクワクが足りてない気がするから、ワクワクをちょこちょこトッピングしていきたい。

最後に

こういう記事めっちゃ疲れるんだな、全然推敲できてないし、後日読み返したらひどそう笑

12/30の夜中に書き始めて、もう大晦日になりましたね。みなさん良いお年を。僕は5Vシェルダーが産まれたので最後努力値振って仕上げてきます。それでは。

動かしてわかるCPUの作り方10講

読書 プログラミング基礎 WIP

モチベーション

動かしてわかるCPUの作り方10講という本で勉強することになった。せっかくだから学んだことをメモしておきたい。

勉強メモ

第1講

#include <stdio.h>
 
int main()
{
  int res = 0;
  __asm__ volatile("movq $0xffffffff0000007b,%%rax"
                  :"=a"(res));
  printf("%d\n", res);
  return 0;
}
  • GCC : GNU Compiler Collectionの略でで、C、C++、Goとかのコンパイラとかライブラリが入っているもの
  • gcc hello.cでa.outというバイナリが生成される
  • gcc -c hello.cとすればhello.oというオブジェクトファイルが生成される
  • オブジェクトファイルはバイナリの前の中間ファイルで、機械語バイナリ以外にもシンボルテーブルやコメントやメタデータなどが含まれることがある
  • リンカでオブジェクトファイルどうしをまとめてリンクすると1つのバイナリを生成できる
    • a.cとb.cがあり、aがbのメソッドを利用している場合に、a単独ではコンパイルは失敗するが、オブジェクトファイルの生成だけなら失敗しない。その後リンクすればいい。 -アセンブリ言語の文法はシンプル。「命令 オペランド1, オペランド2」命令はオペレーションとも呼ばれ、mov、addなど。ニモニック(mnemonic)と呼ばれる。
  • コンピュータの基本構成はメモリ、CPU、I/O。
  • コンピュータの5大装置
    • 演算装置：CPU
    • 制御装置：CPU
    • 記憶装置：メモリ
    • 入力装置：キーボード
    • 出力装置：ディスプレイ
  • アセンブリ言語は機械語と対応しており、オペレーション(命令)の種類は5大装置と関係がある。演算命令、制御命令などがある。
  • CPUはALU(Arithmetic Logic Unit)や汎用レジスタなどがか構成される
  • ALU : 算術論理演算装置。論理演算、加算、減算などを行う。👇はwikipediaの画像。こういうVみたいな記号がちょいちょい出てくる
    f:id:nao_666:20210612163223p:plain
    ALU
  • レジスタ : CPUなどに入っている記憶素子で、最も高速な記憶装置。機械語を読み込む専用のインストラクション・レジスタ(IR)と汎用レジスタが存在する。

第2講

  • シンプルな命令セットをもつRISC(Reduced Instruction Set Computer)と複雑なCISC(Complex Instruction Set Computer)がある
  • 今回設計するCPUについて
    • 命令、オペランドを含めて15bitの固定長命令
    • データは16bitで表現する。必然的に汎用レジスタやメインメモリのデータ領域のデータ長も16bitになる。ALUも16bitが基本サイズ(?)
    • ハーバードアーキテクチャを採用。ノイマン型アーキテクチャは単一メモリ方式（命令とデータをどちらも同じメモリに柔軟に配置）。対してハーバードアーキテクチャでは命令とデータをそれぞれ別のメモリに配置するようにする。（キャッシュへの経路を2つ用意する）参考
    • レジスタとメインメモリ間のデータ転送は
      • インストラクションレジスタ↔プログラム領域
      • 汎用レジスタ↔データ領域
      • で行われるが、今回命令長は15bit、データ長は16bitとしてので、1bit違う。なので楽に実装するためにこれらを別のデータバスとして扱うハーバードアーキテクチャにする。
    • メモリマップドI/Oを採用。入出力装置のコマンドレジスタとデータレジスタを直接見る（I/Oマップド）のではなく、入出力装置に命令を出す際も他と同様にメインメモリを利用する。メモリマップドI/Oでは、アセンブリ言語で書いた際にI/Oのために特別な命令を使わないのでI/O接続していることがわかりづらい。参考

第3講

  • flagはレジスタではないのか？実態はなんなんだ...

第4講

  • カルノー図を使えば最も簡単な論理式を導ける
  • 組み合わせ回路：入力と出力が1:1で対応する
  • 順序回路：内部状態を持っており、出力が過去の入力にも依存する

自分用Macセットアップ手順

随時更新 プログラミング基礎

モチベーション

新しいPCを入手したので今後また入手した時のためにやることをメモしておく

やること

Macの設定

  • ディスプレイ > 解像度 > 変更 > スペースを拡大
  • スケジュール > Night Shift > カスタム 0:00~23:59
  • システム環境設定 > キーボード >
    • ショートカット > Spotlight : control + Space
    • キーボード > Control Stripをカスタマイズ, 左から Launchpad, 輝度スライダ, 音量スライダ, 自由枠
    • 修飾キー > (キーボード選択を確認して) Caps LockをCommandに
  • Dockの整理とDockを左側へ移動
  • 自分のリポジトリからautomatorをダウンロードしてダブルクリックからインストール
  • システム環境設定 > キーボード > ショートカット > サービス > 👆でダウンロードしてきた「ターミナルの起動」 > command + shift + space

各種インストール

マウスの設定

  • Logi Options > Point & Scroll >
    • Pointer speedを最大
    • Scroll directionを自然
  • Logi Options > トラックボール >
    • 親指のボタン > デスクトップを表示
    • 人差し指奥のボタン > Mission Control
    • 人差し指手前のボタン > キーストロークの割り当て(command + w)

Terminalの設定

gitの設定

❯ git config --global user.name "${username}"
❯ git config --global user.email "${email}"
❯ git config --global core.quotepath false # 日本語文字化け対策
❯ git config --global core.ignorecase false # ファイル名大文字/小文字変更の検知
❯ git config --global core.editor vim

VSCodeの設定

  • command + shift + p > Preferences : Open Keyboard Shortcuts >
    • Delete Lineをcommand + Dに
    • Trigger Suggestをcommand + Spaceに
    • Zoom Inをを command + shift + - に、Outを command + - に

IMEの設定

  • ステータスバー > Google IME > 辞書ツール... > 「てーぶる：
    変更前変更後
    beforeafter
    」　を登録

ライブラリ選定時の比較軸

プログラミング基礎

モチベーション

ライブラリを選定する際にライブラリ同士を比較することになる。その際の自分の基準についていつでも思い返せるようメモしておきたい。

比較軸一覧

  • ライブラリ自身が持つ機能が十分か
  • 公式ドキュメントが充実しているか
  • ライブラリをカスタマイズできるか
    • UIライブラリならデザインを変更できるか
    • ライブラリが依存する実装を変更できるか（O/R Mapperのdriverの変更など）
  • 最近もメンテされているか
  • コミッターが偏っていないか
  • 上がったIssueが放置されていないか
  • スターの数が多いか
    • 昔いっぱいついて最近はついてない？どんどん最近もついてる？
  • 学習コストが低いか
    • ライブラリ自体の利用難易度
    • ライブラリの解説記事等の情報量
    • 開発メンバーのスキルセット
  • ライセンス
  • 得意な言語なら実際にコードを読む
  • OSSでなければ価格やサポート体制

まとめ

上記の軸で比較して、総合的に判断。できれば選定したときに、どのような理由で選定したのかを残しておけばあとから振り返れる。さらに、選定後しばらくして、それを使ってどうだったかを定点観測してその内容を今後の選定に活かせればなおさら良さそうだ。

コードレビューのレビュアー心得

プログラミング基礎

モチベーション

自分がコードレビューをするときに、どういったことを観点として持つべきか、どういう態度をとるべきかをいつでも振り返れるようにメモしておきたい。

コードレビューの目的

目的

以下を確認するために行う

  • 保守性の高いコードになっているか
  • 速度/メモリ効率の良いコードになっているか

詳細

コードの保守性と、速度/メモリ効率を高めることを目的と考える。保守性については、誰にでも読めるコードにすること、変化に強いコードにすることを指す。

その他、

といったことは、基本的にはコードレビューとは別の方法で解決すべきというスタンス。ただし目的を達成する中で上記を行うこともあるし、別のフェーズで難しければコードレビューの力を借りても良いケースもありそう。

逆に言えば、保守性や速度/メモリ効率はテスト等の他の方法で網羅するのは難しいと考えている。

コードレビュー観点

目的を達成するために、どういった観点でコードをチェックすべきかをまとめる。

保守性に関する観点

いうても、基本的にはリーダブルコードに従っておけば良いという認識。

  • 単一責任原則
  • 命名
  • ドキュメント/コメント
  • 説明変数の利用(userName := x.y.z のように分かり易さのために変数を作る)
  • スコープ
  • プロジェクトが採用しているアーキテクチャに沿っているか

速度/メモリ効率に関する観点

  • 遅くても O(n^{2}) で抑える。できればそれ未満で。
  • データの持ち方を工夫してメモリを減らせないか
    • そもそもオブジェクトの構造から変える
    • intじゃなくてboolean
    • リスト長の初期値を指定できないか等

基本的には上記のスタンスだが、プロジェクトごとのコーディング規約に基づいて変わることも当然ある。

レビューでのメッセージ

  • 論理的にコードに対して指摘する（人格を攻撃しない）
  • 指摘されるのは辛いことであるということを理解して、できるだけ優しく、絵文字を交えて
  • 読みにくい/読みやすいというのは主観であり、他人と違って当然。協力して良いコードを作り上げるという意識を忘れないように
  • 楽しく！！