コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

GitHubのコミットメッセージの考え方を整理したいときに読みたいスライド『Rails コントリビューションから学んだ Git / GitHub 術』

スライド・記事回顧録

期末とロール転換でエンジニア的な仕事が減っているのもあり、スライド回顧録です。

speakerdeck.com

動画版は下記

GitHubのコミット粒度とか書き方のお作法って育ってきた環境にめちゃくちゃ依存するし、ややもすると「プロダクトを作ることが仕事なのにそんな細かいところでいちゃもんつけるのは成長を阻害している」という旨のことを言われかねないので、意識合わせが難しいジャンルの1つです。

そこに関してOSSの場合はこういう書き方がいいという解説をされているもので、日々の開発にも参考になる部分が多々あります。

すべてを真似する、とまでは行かなくてもいいですが、ここから必要なエッセンスをチームに適応するなど使える部分は多いのではないかと思っています。

関連リンク

スライド内で紹介されている良い事例のPRは下記

記述全般では個人的に参考にしているのはt_wadaさんの以下ツイート

Googleには重厚な「評価ガイドライン」がある

Tips

Googleの検索品質には綿密なガイドラインがある。という紹介だけ。

リンク元

https://twitter.com/searchliaison/status/1050447190320009219

どんな内容なのか

大きく3つのパートに別れ、さらにブレイクダウンしている

Part 1: Page Quality Rating Guideline (ページ品質評価ガイドライン）
Part 2: Understanding Mobile User Needs（モバイルユーザのニーズを理解する） 
Part 3: Needs Met Rating Guideline（ニーズを満たす評価ガイドライン）

めちゃくちゃ文量多いので読めてない、が、後半戦はかなりモバイルに話の焦点を当てているのでモバイル向けに考えることの重要性がありそう

参考リンク

エンドユーザからみた製品の品質をわかりやすく表す「狩野モデル」についてざっくりまとめる

ざっくりまとめ

品質の話を最近やるので

「狩野モデル」とは

エンドユーザの満足度を縦軸、横軸を物理的な充足を縦軸とした二軸で品質のカテゴライズをするモデル。

f:id:shinkufencer:20190317225412p:plain
狩野モデルの図

大きく3つに分かれる

当たり前品質(基本品質)

図では青の曲線で示される部分。満たしていることが当たり前で、満たしていないと必要最低限のものを満たしていないというもの。

一元的品質(性能品質)

図では緑の直線で示される部分。性能品質と称されるように性能、すなわちスペックなどを表現する部分。低すぎるとスペック不足と言われ、高いとスペックが高いということで称賛されるもの

魅力品質

図ではオレンジの曲線で示される部分。不足していても特に問題だが、加わっているとその魅力な部分として表現される品質。

開発においてどう考えるか

当たり前品質は開発における実装すべき要件の部分、魅力品質はUIの触り心地に当たることが多いので、「最低限実装すべき機能」と「あると望ましいけど機能」を洗い出す際に利用できる観点だと思われる。

参考リンク

bundlerのpathを指定しない場合のインストール先

Ruby

実は知らなかったシリーズ

概略

通常のgemと同じところにインストールされる。

ネタ元

By default, Bundler installs gems to the same location as gem install.(中略) Therefore, git gems are downloaded and installed into ~/.bundle rather than $GEM_HOME or $BUNDLE_PATH. - Bundler: bundle install

意訳with機械訳（グーグル訳）すると

デフォルトでは、Bundlerはgem installと同じ場所にgemをインストールします。
(中略)
git gemは git gemは $GEM_HOME や $BUNDLE_PATHではなく~/.bundleにダウンロードされインストールされます。

参考リンク

APIのURL設計に迷ったら読みたいスライド『RESTful API の みつけかた』

スライド・記事回顧録

スライド回顧録です。

speakerdeck.com

RailsのAPI設計などしていると、どうしてもそのURI設計に悩む。ありがちなものは思いつくが、新しいプロダクトに挑んでいるとどうしてもそうも行かない。そんなときに読み返したいのがこのスライド。

ありがちな名付けミス、どういう名前をつけるとわかりやすく保てるかという指針の資料としてすごい役に立つ。

参考リンク

よい当たり前を維持する努力

雑記

日曜日なのでちょっとポエミーな雑記です

急場しのぎのコード

「リリースを急がなければならない」

この言葉が免罪符となり、分割がちゃんとなされていないロジック、そばしのぎのマジックナンバー、再利用性を無視しした同一意義のメソッドの乱立、そしてかかれないテストコード。このようなコードが時たま見受けられる。そしてそこをレビューで指摘すると返ってくる言葉は

「価値を届けることが大事で、ソースコードが汚くても仕方ないでしょ」

評価ポイントのズレ

その場ではユーザに影響のないコードだとすれば、影響が出るのはどこか、それは「次に修正するとき」である。最初のコードを作る人は無から有を作ることが評価ポイントになりがちで、それが持続的に正しく運用できるかは評価ポイントにはならない。なぜなら新機能を提供することがビジネス的に求められていることであり、それがない限りは持続できるかすら怪しいからである。

両立させることが真にできる開発者

「次の修正」つまり「変化させやすいコード」というのと「価値の提供」というのは両立できないかというとそうではない。特にRailsのようなフルスタックフレームワークは価値を提供するベースの機能はフレームワークが用意しているので、そのレールに乗れば速やかに提供できるし、そのレールの範疇であれば変化にもある程度は追従できる。それができるかできないかを左右するのは何かというといろいろ考え方はあるとは思うが、大きく影響するのは環境ではないかと思う。

「当たり前」を正しく持つ

日々の行動は無意識にできるようになれば、そこに対して抵抗感のようなものはなくなる。「当たり前」として正しい習慣をインプットしてしまえばいい。「再利用性を考える」「テストコードを書く」「マジックナンバーは使わない」どれも当たり前に、普通の行動として染み込ませていけば使うことは無くなる。その当たり前を育むのは個人の気持ちの持ち方という部分もあるが、それを継続的に実現させるのはそれを是とする環境ではないかと思う。

「当たり前」を「当たり前」に維持できるように

「当たり前」はいいかえれば「常識」である。その環境の常識として根付かせるには全員の共通の見解とする必要があるし、その環境に革命家が訪れたら常識は一気に覆る。なので常識を常識として維持する努力を怠ってはならないし、その常識がちゃんと維持すべきものかは常日頃から見極めながら、育んでいかないといけない。

参考リンク

アプリケーションプログラミングインターフェースの使い心地

雑記

APIを考えるときはインターフェイスの使い心地がよくなるように考えましょうという話。

使い心地の良いインターフェースとは

きのこ本に以下のようなことがある

良いインタフェースとは次の2つの条件を満たすインタフェースのことです。 正しく使用する方が操作ミスをするより簡単 (中略) 誤った使い方をすることが困難 - 正しい使い方を簡単に、誤った使い方を困難に | プログラマが知るべき97のこと

ユーザーインターフェイスの例が強く上がっているのでUIにおいての文脈で考えすぎるがAPIもアプリケーションインターフェイスなのでこの話があてはまる。 APIで活かすときには次のようなアイデアが思い浮かぶ。

2つの良さを踏襲するためのアイデア

APIに誤った使い方を困難にするにはどうすればいいかはいろいろアイデアがある。

  • パラメータは最低限にする、最低限にすれば誤って使うことはないし、操作ミスはしようがない
  • パラメータは単純にし、複数な意味を持たせない
  • 読み違いを起こしそうな名付けはしない、そのまま読めば正しく使える。
  • 汎用的にしすぎない、汎用的にすると限られた入力項目で多くのことをやろうとして煩雑になるし、責務がぼやけやすい

などなどがある

これを踏襲することの良さ

これを実践していくと、単純にひとつひとつの処理が単純化していったり、テストが書きやすい状況がかなり作られていく。プログラムとしては非常に扱いやすく、見通しがよくなる。

短くまとまり、見通しの良いプログラムは使う側としても誤った使い方が思いつかないから直感的に使えるし、用途によって別々に分かれてくるのでその場にあった最適な道具を選んで使っていくように、使い心地がよいインターフェイスになる、と思う。

参考リンク