やまろぐはてな

yamanokuの技術メモとか戯言。真面目に見たり見なかったりしてください

コミットメッセージとコミットの粒度について思ったこと

medium.com

見た。以下思ったことです。


コミットメッセージが結構雑になる問題ってのは、自分が考える中としてコミットの粒度が割とデカい場合になるんじゃないかなと思ってる。

例えば数ページマークアップしたときに、ページごとにコミットを切るよりかは、全ページの作業をコミットさせておく方が分かりやすいし、どこまでの進捗なのかも一見しやすいかなと思う。もちろんページ内で機能が複雑化している場合はその限りではないと思うけど。

なのでコミットのメッセージを分かりやすく書く、ということと同時にコミットの粒度をどれほどのものにするか、という意識と進め方を持たないとこの辺はなりたたないのではないかなーと個人的に感じている。

基本業務の流れとして、バグや機能追加の課題が振られてそれらを対応完了するまでを1コミットとしているけど、LPなどページ単位で対応するときは、場合によっては、1ページ単位でコミットを切ることがある。

あと良くない癖なので直さなきゃなんだけど、その日に対応する修正もまとめて対応して「00/00対応分修正コミット」とかで切って細かく書かなかったりもする。修正範囲の意義を全体的なものとして捉えていると、修正する1機能というよりかはそれに付随するもとしてまとめて対応しないと、という意識になっちゃうのでその辺は進行管理とも付随する問題かなと感じる。

この辺の粒度対策としては、ブランチをいかに細かく切って作業するかにかかってるんじゃないかと思うので手を動かす前にまずブランチ切っとけ、終わったらマージしとけを工程の中に入れておかんと危ないなとは感じた。まあもし単位がデカくなってもやり直しが一応できるのがGitの良いところではあるけど、出来る限りそういう修正はしたくないよね、と。

課題の建て方としてもそうだけど個人としては、もう少し部品化・機能化するイメージで進めてみてもいいかなと感じた。この辺は実験として新規のプロジェクトとか、個人がメインで動いていたプロジェクトにもっかいアサインしたら試してみようかなと思ってる。誰かとやるんであればその時のルールには従います。

余談

昔、コミットの内容なんか見なくてもファイルの内容みればどうなったか分かるだろみたいな言説を聞いて、当時はまあそうだよなと思ったけど、結局属人性を加速させかねない危険な発言だったと徐々に分かってきて、1回限りではない・他人の手にも渡るリポジトリ内では、出来る限りは詳細的に書くように努めたいと思ってる。

こちらからは以上です。

PostCSSの雑感

f:id:cardboarder:20170806221911j:plain

業務で実験的に使ってみたんですが、

まだこの気持ちが強い。とりあえず1プロジェクト終えた後にちゃんとした感想やります。

ただこういうのがプラグインであるのは感動した。

github.com

以上雑日記でした。こちらからは以上です。プラグインの翻訳記事とかつくれば価値出ますかね?

記事を書くときに気をつけること

自分が所属している会社もこないだからQiita Organizationに参加して各自記事をアップしたりしています

qiita.com

こういうところに書くのも日々のモチベや多忙さに左右されるので継続は難しいなと感じるところですが、記事を共有するというのは慣れていないとどうも参入障壁がデカい気がします(いわゆるアウトプットが慣れてない場合)

そんな訳で少しでも参入障壁や苦手意識を取っ払うために自分の中で記事を共有するときに念頭においてることを以下書いてみます

重複する内容じゃないか

これは当たり前ですが既に世に出ているものでそれが十分だったらそれでいい訳です。いわゆる新規性がまったくない場合

もし間違ってたりアップデートしている内容があったら編集リクエストなり指摘を入れればよくて(直すかどうかはおいておき)、わざわざ自分が書くことはないと思います。それでも残したいならメモ帳にでも書いとけ

既存のものを組み合わてみる

もしかしたら大半のことは上記のことで弾かれてしまうと思いますが、別にそれは単一の内容だから被ってしまうのではと思います

いわゆる「点と点をつなげたもの」を調べてみるといいです

例えばバグをみつけて改修するときに、それに基づく情報やtipsがあったとして、そこに行き着くまでに試したことやダメだったことは一つの財産たるわけです

簡単に直せることはもちろん大事ですが、そこに行き着くまでのプロセスや何故こうしたらできたのか、ということを知ることが一番大切です。

そうした結果に行き着くまでのいくつもの点をつなげてみると、より洗練されたものになるのではないでしょうか

qiita.com

日本語情報があるか

ここら辺は有志がwikiなりしかるべき場所にまとめたりしてますが、無かったら書くに値するかなと感じます

少なくとも検索かけて1、2ページに有効な手や翻訳記事がなかったら共有する価値は十分あるかなと思います

結構プロジェクトによっては、とあるバージョンのまま日本語記事が書かれていない場合もあったりします。

qiita.com

実際に試した内容か

正直tipsをこういうのがあるよ!と言って書いたりすることもありますが、ブラウザの互換性やバージョン、バグらへんを完全に無視したものもあったりしてそれはノイズとなんら違わないです

なので実際にやってみた雑感なり、ここを対応するときは注意みたいなことを追加で書いておくだけでだいぶ優しい記事になりえると思います

試した結果とかはjsfiddleとかcodepenとか実際のプロジェクトに置いて各自で試してもらうなど、形として残しておくとなお良いかと思います

qiita.com

試した・変えてみたことがどうなったか

色々な実験や改善策、アップデートが日々行われているとは思いますが、そうした試してみた結果、どういう現状になったかというのは一つのネタになり得ます

もちろん上手くいくことがすべてではなく、失敗して共有すらできないこともあるかと思いますが、できる限り咀嚼してみて同じ轍を踏まないようにしてあげる(たとえ届かなくても)のも、業界全体を良くすることだと思えば価値はあるかなと思います

yamanoku.hatenablog.com

yamanoku.hatenablog.com

個人でやってみたこと、社内で試したこと

ここら辺は場合によっては書ける書けないの領域もあるかとは思いますが、ネタとしては使えるものもあったりします

たとえば「社内でこうしたツールを使ってみたけどもっと使いやすくしてみた」「オレオレ設定だけど意外と人に使われてるよ」「みんなこうやってるけど自分はこんなパターンで試した」など、その人、その企業ごとで独自性をもったものになり得ると思います

yamanoku.hatenablog.com

この辺は宣伝にもなりそうなんでQiitaなり諸般の場所で書くのは程度問題にはなりますが、個人ブログや企業ブログに書いてみるというのもありかもしれません。それが結果として興味を持ってもらえる材料にもなるので

ゆるく書く意識

最後に一番重視していることとして、ゆるくやるということを忘れないようにしています

こんなに気をつけておいてゆるくって何でやねんってのはあると感じるかもですが、その辺と力みすぎてしまうのは別物だと思います

対人が見るものだから粗相のない文章を、と力むよりも、見た人がなるほどなとか、わかるわ〜と共感してくれるような語りかけ調で見てくれるのがいいよねと感じてます

あとは勢いにまかせて一気にやると良いです

 

そんなわけで自分が記事を書く時に意識していることたちでした。大したものを書いているわけではないですが、みんなでゆるく知見を広げていこうぜよ。

こちらからは以上です。

 

合わせて読みたい

yamanoku.hatenablog.com

書いた記事をアップデートすること

qiita.com

この記事を書いて早いもので1年経った。CSSプロパティの記述順に関してはひとつの解決の足掛けにはなれたのではないかと思っていたけれど1年たった今では記述順よりも煩わしいコンポーネント管理問題や他人とどうCSSを弄ればいいかなど悩みは尽きない。そんな記事を書いていたことも忘れかけていた中で最近ふと気にかかった言葉がある。

技術記事ってだいたい書いた当時の情報からアップデートされないよね

まあだいたいはその通りであるというか、記事に直近の追記以外でこのプラグインやら記述はもう使えませんよみたいなのって本当に丁寧な記事以外では全く見かけないしQiitaでもそんなにはないんじゃないのかーという感じではあるわけです。

これは俺がフロントエンド界隈にいる限りなのか、それとも単に手前の視野が狭いだけなのかというのは分かりませんが、少なくとも自分の界隈はそういったもんだと思っています。

別に記事なんて公式ドキュメントではないんだし、いちボンクラが書いたものをいちいち更新しなきゃいかんのかというのもダルい話ではある。でも、そんなボンクラが書いたような記事でも必要な人はそれを頼って見に来ることもある。どこの誰かは知らないけれども。そう思った時に自分は必要な人間側になった時にどう思うかというと多少なりともアップデートはしていてほしいなという気持ちにはなる。

そもそもがインターネットのものはアーカイブもできて、上書きできるものであるという前提を見失っていた気はします。

これは別にQiitaに寄稿した記事に限らずこのブログもそうだし、果てはGithubのドキュメントや社内のwikiやら議事録に至る何までどこの誰がどういう探索をしに来るかは知らんけども、今一度あの時書いたもの、作ったものを見直してみるのはどうかという感じにはなってきているそんな今日のこのごろです。

Promise処理について雑にまとめる

Promiseとは

簡単に言うと非同期処理を行う時にコールバック地獄、ネストの深層化を回避して記述をだいぶ楽にするオブジェクト。ES2015です。

非同期処理とは

例えばAの処理の後にBの処理があるとする。javascriptとはシングルスレッドで動く同時に処理を行うということができないものなので、通常であればA、Bの処理で動く。その辺の順番を変えて処理を行うのを非同期処理という。

分かりやすい例はApiと連携するAjax通信を受け取ったレスポンス(200とか404とか)の結果によって処理を行うやつ。

非同期処理の例

例 – ajax通信後順番に処理を行う

var fetchSomething1 = function(done) {
  // API1にアクセス
  doAjaxStuff(someOptions, {
    success: function(data) {
      done(); // 成功したら渡されたfunctionを実行
    }
  });
};

// fetchSomething1と同じようにそれぞれ別のAPIにアクセスするfunction群
var fetchSomething2 = function(done) { /* 省略 */ };
var fetchSomething3 = function(done) { /* 省略 */ };
var fetchSomething4 = function(done) { /* 省略 */ };

var doSomethingFinally = function() {
  // APIにアクセスして取得してきたデータを使って何かする
};

こういう関数を登録しておき、順番に処理を行うとする。通常だと

fetchSomething1(function() {
  fetchSomething2(function() {
    fetchSomething3(function() {
      fetchSomething4(doSomethingFinally);
    });
  });
});

こうなるが、これが

fetchSomething1()
  .then(fetchSomething2)
  .then(fetchSomething3)
  .then(fetchSomething4)
  .then(doSomethingFinally);

こうなる。コールバック地獄、ネスト深層化問題の回避がよく分かる。

// Callback
fetchSomething1(function() {
  fetchSomething2(function() {
    fetchSomething3(function() {
      fetchSomething4(doSomethingFinally, function() {
        // fetchSomething4のエラー処理
      });
    }, function() {
      // fetchSomething3のエラー処理
    });
  }, function() {
    // fetchSomething2のエラー処理
  });
}, function() {
  // fetchSomething1のエラー処理
});

// Promise then & catch
fetchSomething1()
  .then(fetchSomething2)
  .catch(/* fetchSomething1のエラー処理 */);
  .then(fetchSomething3)
  .catch(/* fetchSomething2のエラー処理 */);
  .then(fetchSomething4)
  .catch(/* fetchSomething3のエラー処理 */);
  .then(doSomethingFinally)
  .catch(/* fetchSomething4のエラー処理 */);

エラー処理も含めると更に分かりやすくなる。こういう風に書くと見やすくなってメンテナンス性も上がりますね。

ブラウザ対応状況 – CanIUse

f:id:cardboarder:20170528175745p:plain

発表されてからだいぶ時間が経ったのでブラウザ対応であれば、現状IE11以外だったら大丈夫。

パフォーマンス対決

jsPrefにて計測。

Promise vs Callback

f:id:cardboarder:20170528202919p:plain

Native Promise vs Callback

f:id:cardboarder:20170528202638p:plain

非同期処理だとそこまで差はないけどそのまま使うPromiseだと圧倒的にCallbackのがパフォーマンス良い。素で使わないほうがよさそう。

おまけ – Promise と async/await のイメージについて

このGifが一番イメージしやすい。

参考