はてなブックマーク

先日、関わっているプロジェクトで不要なファイルを整理していたら、3000行も削除してしまっていました。 不要なファイルを整理しまくってたら3000行も削ることになってしまった。破壊活動だ…。 pic.twitter.com/XiHOtplGuo — F.Shibusawa (@smartponzu) 2018年10月4日 既存のコードをリファクタリングしたり、要らないなと思ったファイルは容赦なく削除したりしてると、masterとの差分がとんでもないことになります。「どのファイルを削除したんだっけ？」って思って git diff --name-only とかしても変更分と削除分が混ざってめちゃ見にくいです。 そんな時に、 --diff-filter=* オプション！ --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] Select only files tha

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

俺氏「プルリク出しましたー！レビューお願いしまーす」 同僚甲「Approveしましたー！」 同僚乙「Approveしましたー！」 俺氏「（このあたりは同僚丙さんが一番詳しいけど、ちょっとの修正だし、まーええやろ）」 「ほんじゃマージしまーす！」 「ポチッ（マージボタンを押す）」 （CIで自動でデプロイが走る。同僚丙、トイレから戻ってくる） 同僚丙「……………………ふぁ！？」 「あああああああああああああああああ！！ちょっと待って！なんでそれマージしちゃったの！！！？？！？！？」 「この部分、実はこのファイルとこのファイルに影響してて修正しちゃうとバタフライエフェクト的にうんぬんかんぬん…」 （デプロイが完了する） バグどっかーーーーーーーーーーーーーーーーーーん！💣💥 こうした悲劇を未然に防ぎたい。 どんな小さなコードベースの変更だったとしても、 第三者の目を透してからじゃないと絶対に

CSSの記法やルールを運用でカバーしていくのはキツいなと誰しも思っているところだと思います。よく巷ではなんとかlintが流行っていますが、実際導入するときどんなルールで運用すればいいか迷いますよね。自分は迷いました。 そこで、今回は自分が関わっているプロジェクトで採用した stylelint でどんなルールやプラグインを採用しているかを紹介します。 前提 どんなルールが最適かは各チームによるので、細かい調整はチームメンバーで話し合ってください。 採用したルールをすべて記載しているわけではなく、特に良いなと思ったのをピックアップして紹介しています。 stylelintとは stylelint は、CSSの書き方をプログラマーに指摘してくれるnpmモジュールです。rubyでいう RuboCop と似たものですね。公式ドキュメントによると、160以上のルールが用意されているそうです。デフォルトだ