やまろぐはてな

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

CSSとわたし、正義と悪、そしてこれから。

この記事は CSS Advent Calendar 2017 16日目の記事です。

テック的なことを書こうかと思いましたが、これまでの人生を振り返ってきて自分にとってのCSSとは何か、そしてこれからどうやっていくべきかみたいなことを書こうと思います。Qiitaに書くのもあれな内容と判断したのでブログの方にしました。

「はじめて公開された」CSS

自分が、個人の制作物以外で「世の中の人に初めて公開された」CSSはこちらになります。

github.com

なんだかよくわからないものばかりになっております。自分で推測しますが、どこかしらのテンプレートから拝借してそのまま置いてみた感じかなと思います。まぁ当時の独学でアレコレやったド素人が書いたものなのでそんなもんです。

美術系の大学出身*1なのですが、一応サイトを作れる人間だったので当時の卒業制作展のサイトを勝手に担当していました。

卒業年が2008年なのですが当時はiPhoneが出回り始めて、いわゆる「スマートフォン対応」というものを徐々にしていかないといけない時代だったと思います。当時の自分はレスポンシブ対応することまではできなかったなりに、「PCはPCの体験を、SPはSPの体験をすべき」という考えをもとにSPページを用意して .htaccess でユーザーエージェント判定をして振り分けなんぞやってました。

当時の有名美大の卒業サイトと見比べると月とスッポン、いや比喩することすら失礼にあたる可能性があるくらい出来は微妙なのですが、素人なりに真新しいことは無理にやらず、ちゃんと情報にたどり着ける阻害しないようなスタイル、そしてCSSは分けてスタイルも分割するなんていう生意気なことをやっていたんですねぇ。(ただし内容はグダグダな感じです)

CSS2 => CSS3

f:id:cardboarder:20171214231200j:plain

さて、思い出語りから話をガラリと変えてしまいますが、CSS3というものがこの世に出てからどれくらいが経ったのか皆さまはご存知でしょうか。

調べたところどうやら「CSS2.1」が確定された2011年より策定が進んでいる*2とのことで、誕生?から6年ほど経っているようです。

先程紹介させていただきました卒業制作展サイトにもCSS3 Media Queriesを使用したり、box-shadow要素やgradient、border-radiusといった要素を使用しておりました。

これまで自分の中でCSSというものはサイトにある要素を「整える」ものという認識でいて(今もそんな感じかとは思いますが)、キッチリとやるために必要なものだと思っていました。

それがCSS3になって、より多彩な表現の幅を広げてもらえるものになったと思い、当時は画像などで対応せざるを得なかったものをCSSで対応してくれる革新性には驚かされました。

CSSとはこんなにも自由なものなのになったのか!それはとても素晴らしいことだと当時の私は感嘆しておりました。

プリプロセッサ、ポストプロセッサとの出会い

f:id:cardboarder:20171214231345j:plain

手書きでCSSを書くことが当たり前だった私が転職先で「えっ素でCSS書いてるの…マジ…?」と言われるくらいには古いやり方だったようで、双方に驚きがあったようです。

素のCSSを弄る時代はいつの間にか終わっており、代わりにLess、Sass、Stylusといったプリプロセッサ言語で楽にCSSを書ける、管理しやすくすることが出来ることを知ってから、世界はこんなにも広かったのか!というような気がしました。

中でもStylusとの出会いは特に衝撃的でした。何故かというとインデントで階層管理して、あの煩わしかった{}やコロンも省略可能で記述スピードを爆速にしてくれるのには感動しかありませんでした。

出力された後に調整する「ポストプロセッサ」なるautoprefixer、minify、PostCSSといったものにも触れ、ブラウザごとのバージョンに合わせて、またはCSSの機能を拡張してくれるなど、これらもまた私にとっては大変重宝しているものたちでした。

「設計思想」というものがある

f:id:cardboarder:20171214231609j:plain

これまでCSSについてなんとなくで書いてきた私でしたが、仕事をしたり、インターネットを潜っていると「世の中にはCSS設計思想というものがある」ことを徐々に知りました。

有名どころですと、OOCSSSMACSSFLOCSSBEMなどでしょうか。

設計思想とはいわば、CSSをこういう風に切り分け・管理・拡張すると運用や再利用がし易い設計となるのではないかという考え方をもとにそれぞれのアプローチが提案されています。

自分が業務として体験してきたのは、SMACSS、BEM、そしてECSSです。

f:id:cardboarder:20171214225459p:plain

当初はBEMを使った設計を全面的に目指そうと考えていたのですが、ECSSが我々の業務内での設計とfixするのではないかと考え、今はECSSをベースとした設計思想で作成しています。

これまでの経験則として、ファイル数は増えるがもっとも追加や更新のコストを軽減しうるものではないかなと感じています。

CSSは世間で「忌み嫌われている」言語だった

そんなこんなで便利なツールや意味のある設計思想を使ってCSSを書くことが楽しくなってきた筆者にとある避けられない事実を突きつけられました。

それはCSS

  • 「明確な解決法もなく」
  • 「保守しようにも破綻しかねない」
  • 「一番考えるのが煩わしい」

言語ということだったのです。

おいおいそんなこと言うなよ!こんなにも素晴らしく楽しい世界にそんなことなんて…そう思って私が振り返ってこれまでのCSSを見てあることに気づきました。

「同じように生み出されたstyle.cssなのに、よく見ると…ルールや内容が全然違っている…!」

クライアントワークを行う上で、要件や仕様というものが決まっていると、それに準拠するために設定などを見直す必要がでてきます。また、外部の方に制作を依頼するときも少しでも綻びがあるとそこから新たなるルールが発生してこちらがオーバーライドしかけるという事態も起こり得ていたのでした。

加えて運用案件においてもソースコードが誰かしらの手に渡り、制作意図もうまく伝わらぬまま変わり果てたstyle.cssとなって残り続けているものもあり、それをメンテナンスしなければならなくなるということもあったそうな(この段落はフィクションです)。

もちろん下準備した我々がそうした事態を考慮できてなかった問題もあるのですが、それにしてもここまで顔が違くなることはあるのか?多少の設計やプリプロセッサは違えど、何故みんな同じようにできなかったんだ?などかつての思い描いていた何でもできる素晴らしいCSSは一体何処へ…?

もしかしたらCSSを誤解していたかもしれない

そうした失敗への気付きから今一度CSSについてを考え直していました。

こんな書き方をしてしまえば身も蓋もないのですが、よほど長期運用するサイトであったとしても、万能薬として効く設計思想やプリプロセッサ、そしてそれをもとに得られる、再帰性があり可読性も高く更新しやすいCSSを生み出すということは、まず難しいということです。

これはCSS自体が悪いものなのか、と考えることもできるのですが、私自身はそうではなく、むしろそうしたCSSに合わせられないサイト設計、UI設計が良くないのでは? というある種の責任転換みたいな、しかしながらそうしない限り破綻が続くような考えを持つようになりました。

「なんでや!自由度の高いサイトデザインができなくて何がWebや!」という意見もごもっともだと思います。

ですが、結局のところウェブに残るものとは文化資産に近いそれらだと思っており、そういった文化をメンテもできない冗長性しかないもので管理するのはいかがなものか…とも考えられるのです。

なので、極端ではありますが、現状CSSとの付き合い方はこうするしかないのかなと思っています。

  • サイト設計やUI設計といったものをメンテナンスできて要素を更新するにも容易に対応できるものとした上で、正義のCSSを生み出す
  • 新たなクラスをどんどん生み出し、他のセレクタなどに影響を出さないことを前提とした闇鍋のような悪のCSSを生み出す

極端過ぎる。でも結局はどちらかになると思ってます。

ただ、正義のCSSを生み出すために、CSSに対してみんなで優しくしろ、という訳ではないと思っています。

何故かというと、CSSに優しい設計を考える上で、CSS以外もきちんとどう運用すべきか、どう管理すべきか、どう設計すべきかなどが徹底されて初めて成り立つものだと思っているからです。

だから世間で忌み嫌われているCSSは、自由度が高すぎるがゆえに「なんでもしてくれる床上手な処女」のような空想上のものとどこかで錯覚しているのかもしれません。CSSもほかの言語と変わらぬきちんと運用されないと破綻されるものと一緒なのです。

CSSを見直すヒントたち

そんなCSSたちをどうやって見直していけばいいか?という部分においてヒントとなりえそうなものがあるので紹介していきます。

宣言ブロックは慎重に精査する

kojika17.com

kojikaさんのブログでも述べられていたように、CSSにおいてプロパティや値を管理する宣言ブロックについてはあまり意識していなかったようにも思えます。

たしかにどこかで !important を入れてしまうとそれをオーバーライドするために元あった宣言ブロックのルールが破綻してしまいかねないことや、汎用的に使いこなしたいのにwidth指定やテキスト方向などが変更できないものなど、想定していたものと別の形になってしまうことがあります。

こうした事態を避けるためにもデザインの確認やある程度余白を意識した宣言を書くようにしないといけません。割とタグに直接書く悪習はなかなか治らないので、そこで左右されないように大元をも見直すことも大事かと思われます。

stylelintにおける品質維持

f:id:cardboarder:20171215010857p:plain

JavaScriptの構文チェックに使用されるeslintというLintツールがあるのですが、それのCSS版Lintツールに「Stylelint」というものがあります。

CSSを綺麗に整形できているか?統一化された書き方ができているかという面で有用なのですが、他にも「!importantを使っていないか?」「階層を深くしすぎていないか?」「プロパティが重複していないか?」などの宣言ブロック関連のチェックをしてくれるものもあります。

標準のLintルールが割とすぐに使える(エラーも少なめ)なところもあるので、必要な部分を徐々に継ぎ足して、ルールをもった可読性のあるCSSを実現させましょう。

コンポーネント指向におけるパーツごとでの管理

f:id:cardboarder:20171214232901p:plain

正義のCSSを生み出す上で、私の中での1つの解として考えているのがコンポーネント管理です。 レイアウト、ページ、パーツという単位で切り分けそれらを組み合わせる…いわゆるアトミックデザインのそれに当たりますが、とにかく範囲をぶつ切りして影響範囲を減らしていく過程というのは必要なのだと思いました。

そういう意味ではNuxt.jsというプロダクトがまさに適応しうるのでは?と考えております。CSSに関してはstyle scopedが使用できるので、より閉鎖的に他とバッティングすることもなくセレクタの命名問題点も解消できるかもしれません。

github.com

ただ、問題点を解消できる参入しやすいプロダクトだと思うのですが、まだまだ汎用的に使用するには有用な情報が少ないので、「まだ」確実な一手とはなってないかと思います。ですが参考にしうること(ディレクトリ構成など)は多いと思います。

他にもReactをVueライクにするone-loaderというプロダクトもあるみたいです。

github.com

正義のCSSをやっていこう

f:id:cardboarder:20171214233002p:plain

上記3点の他にも解決しうるものは探せば出てくると思うのですが、それをこれからすぐにやり始める・導入するというのもなかなか難しいことのように思えます。何故ならこれからのCSSを失敗しないようにしても、これまでのものを無かったこと・解決したことにはならないからです。贖罪とはならないのです。

私自身も数多くの「悪のCSS」を生み出し続けてきました。生み出してきたものを無かったことにすることはできませんが、彼らをもう一度、正しい方へと導いていくことはできるかもしれません。そのためにも何故こういう状態になっているのか・どうすればまとめられるのかを見直していくことが必要になります。

ですが、かつては皆が信じてやまなかった「正義のCSS」として作られていたはずのものであるならば、実現しようとしていた正義の片鱗のようなものがどこかにあるはずです。そこを頼りにかつての正義(もしくは新たな希望)を取り戻しに行くことはできるかもしれません。*3

最後にこの言葉をもって終わりとしたいと思います。ご覧いただきありがとうございました。

悪に報いるには正義をもってし、善に報いるには善をもってせよ。

孔子

*1:今は学部ごと移動して事実上の消滅

*2:https://allabout.co.jp/gm/gc/376450/

*3:もしかしたら最初から破綻を前提とした「純粋悪なCSS」も存在すると思いますが、その場合は闇に葬り去るか完全にリセットした方がいいかもしれません

「さくらインターネットのエンジニアは Vue.js をこんな風につかってます」レポート #さくらの夕べ

connpass.com 10/25(水)に、さくらインターネットが主催の「さくらの夕べ」にてVue.jsの業務内活用についての発表がありましたのでそれの個人的まとめです。こういう話聞くと久々にやるかみたいなモチベになります。(はやくやれ)

第1部「はじめてのビュウ」

www.slideshare.net

さくらクラウドの料金シミュレーションをVue.jsで作った https://cloud.sakura.ad.jp/payment/simulation/

経緯

もとはAngular1系。UIはそのままで一部のみ変更。URLでの記憶機能や時間割計算も対応できるようにした。

課題

メンテコストがキツイ。フロントと何故かバックエンドのダブルメンテ。

Vueの採用理由:

  1. 覚えることが少ない。久しぶりに手をいれるときにも思い出しやすいんじゃないだろうか
  2. 公式のライブラリでまかなえるので継続メンテが期待。vue-routerとかVuexなど
  3. 日本語情報が充実している。Vue.jsの公式ガイドは親切丁寧でだいたい分かる https://jp.vuejs.org/index.html
  4. 人気と勢いが凄いのでメンテする人は後続ができる期待

実装の時に気をつけること

構成、命名規則について

コンポーネントの構成を決める際に、テストしづらい、使いまわせない、分割できないといったものにならないように気をつける ItemContainerという親を作るとItemGroupの場合はどっちが親?となる

<ItemGroup>
  <ItemContainer> <= こういった構成なら分からなくもないが単体だと分からない
    <Item />
    <Item />
  </ItemContainer>
</ItemGroup>

Catrgory、ItemListなどの的確な名前づけをした。親子関係と役割を想起しやすいようにしよう

<Category>
  <ItemList>
    <Item />
    <Item />
  </ItemList>
</Category>

ディレクトリ構成について

  • 単一では意味をなさない組み合わせではじめて意味をなす <components>
  • 単一で機能できるコンポーネント <layouts>
    • 関連するものはひとまとめにしておく
    • スタイルも一緒に梱包する
buttons
├─ AddFieldButton.vuw
├─ RemoveFieldButton.vue
└─ SaveButton.vue
bill
├─ bill.vue
└─ bill.scss

VuexでのStoreについて

Store構成 => コンポーネント内部だけで知っておくべきこと(タブの開閉)、全体として知っておきたいもの(合計金額)を洗い出していく。

アプリケーションが大きくなると見通しが悪いが、Vuexのmoduleで見通しをよくするようにしておく。

const moduleA = {
  state: { ... },
  mutations: { ... },
  actions: { ... },
  getters: { ... }
}

const moduleB = {
  state: { ... },
  mutations: { ... },
  actions: { ... }
}

const store = new Vuex.Store({
  modules: {
    a: moduleA,
    b: moduleB
  }
})

store.state.a // -> `moduleA` のステート
store.state.b // -> `moduleB` のステート

第2部「Vue.js 導入の経緯と実例紹介」

経緯

さくらインターネット上にはさまざまなwebサービスがあるが、実はフレームワークが乱立している問題があった(好きにやっていい裁量がある)

  • Angular
  • Vue
  • jQuery
  • prototype
  • ember

課題

  • 結果としてプロジェクトへの参入コストが増大している問題が起こる
    • 似たような機能開発でもフレームワーク毎に別の実装になったり、技術が分散され共有されにくい
    • いつの間にかフレームワーク使われてたけど知られてなかったのようなことが起きる
    • ほか学習コストや属人性について
  • フルスタックフレームワーク(Angular)を使うにしても開発のスタートを切るためには時間がいる
  • デファクト・スタンダードとなるものを選定する必要がある

Vue.jsの普及

そんな中、社内SlackにVue.jsを推す影響力のある人がおり、反応してみた。 実はウェブアクセラレータや幾つかの過去のプロダクトにはVue.jsが使用されていた模様。

何とかして良さそうなVue.jsを普及してみたい。が、実績についてはあまり無かった(ウェブアクセラレータくらい)。 そのため、社内での利用事例を増やすために小さいプロダクトからVue.jsを導入してみることにした。

実際に取り入れてみる

さくらインターネット20周年に際して、TOPページのリニューアル案件が立つ。そこで一部にVue.jsを導入してみることにした。

www.sakura.ad.jp

スライダー

https://gyazo.com/6fd8efd405d14355e133d4edb69525fe

Ajax読み取り箇所

https://gyazo.com/d0d00bb90171bb6137c17377c92d5547 Vue-resourceを使用。

Vue.jsでの制作実績

やってみた結果

  • デザイナーと協業しやすそう(シンタックスとして分かりやすい)
    • エンジニアとデザイナーが分業しやすい
    • ロジックとhtml、スタイル箇所がtemplete内で分けられるので棲み分けが良さそう
  • 導入スピードがダントツでよかった。
  • 日本語ドキュメントが充実している、プラグインが豊富なのも良い
  • CDNなどでソースに直接入れ込むことが出来るのですぐ使える https://gyazo.com/01764c33a12dbc94f2a7428f79b028b2
  • Vue.jsはあくまでもjQueryの置き換えになるわけではない。新たなロジックの書き方を知る必要はある
  • 2.5が出るまではTypeScriptの対応が未知数だった
  • 他のフレームワークも良い部分があるので、Vue.jsを使うなら「なんでVue.js使うんですか?」に答えられるようにする
  • 今後の開発において大きめのコントロールパネルでVue.jsを導入する予定

第3部 「とにかく楽してVue.jsでTypeScriptを使いたい」

ダーシノさん https://twitter.com/bc_rikko

  • さくらクラウドのネタ機能担当フロントエンジニア
  • Vue1.x系での2行Contributor

www.slideshare.net

静的型付ができることで最近話題になっている(ことにしてほしい)TypeScript。 Vue.jsでもせっかくなので使ってみたいと思ったけどVue2.4以前ではかなりつらいことが多かったのだが、Vue 2.5からTypeScript統合の改善がされ、だいぶ楽になったよという話。

今回はサーバーサイドエンジニアもメンテナンスができるように、ということで型定義がおそらく好まれているだろうことを推測し、TypeScriptを全面導入。

thisprops型推論ができて、class構文ベースの記述が以前は必要だったがそれがいらなくなるなど改善された箇所が多く、つらくなくなった。 jp.vuejs.org

便利なVue.js + TypeScript体験一式も配布。ありがたい。 github.com

第4部 NUXT.jsでウェブサイトを作れるのか?(未完)

ja.nuxtjs.org

Nuxt.js とはユニバーサルな Vue.js アプリケーションを構築するためのフレームワークです。

具体的には何ができるのか?

  • SPA
  • SSR
  • 静的サイトジェネレーター <= 個人的にコレを試したいと思っている

静的ジェネレーターの代替

を他にも検討しているが、Vue記法をつかいたいため、Nuxt.jsを推したい。

コマンドで切り替え可能

"scripts": {
  "dev": "nuxt",
  "build": "nuxt build",
  "start": "nuxt start",
  "generate": "nuxt generate"
}

SPAにする場合は --spa オプションを付与。

問題点

  • アプリのヘッダーやHTML属性はvue-metaを使わないと更新できない。
  • 新しいため、まだまだ知見が少ない

参考・関連URL

HTML5 Conference 2017 行ってきたよ

events.html5j.org

去年 → HTML5 Conference 2016 行ってきたよ - やまろぐはてな

自分用まとめです。結構長くなった。

続きを読む

backlog上で案件・進捗管理をしていた自分がGithubに触れてみた感想

転職してから業務管理ツールをサイボウズ(勤怠が主だったけど)→backlogに変わってずっと進捗管理をそこで行ってきた。2年くらいになるけど、Redmineとかには触れないでも、方向性とかやり方を模索しながらうまいこと立ち回ってきたように感じる。

そんな中こないだより弊社でもbacklogでは案件自体の管理、Github上で修正・ソース管理を分割していこうという流れが出来てきて実質2案件くらいの開発案件では行っている。自分も1つ案件に入ってきたのでGithub上で仕事している。そんな中で思ったこととか感想とかを書き綴ってみるなど。

案件の可視化に関しては圧倒的にbacklog優位

見やすさとか検索のしやすさであれば圧倒的にbacklogかなと思った。そりゃ案件管理ツールとGit連携サービスとを比較するのであれば酷なのではあるが、ガントチャートを見たり案件内でどういう課題が作られているか・進行しているか、などのディレクター、マネージャー、エンジニア、デザイナーなどの全員が案件の動きを見る面ではかなり強いなものなのだと感じる。

Github上でもマイルストーンやIssueを作ってあげたりwikiで詳細を書いてあげたり、backlog同様に1つのプロジェクト内で案件管理することは不可能なことではないしうまくやれる方法は模索できるとは思うが、それ相応の準備(勉強)とかがいると思うので、Githubを使って案件管理をしよう!というよく分かってない浅はかな思考をもつエンジニア・ディレクターが居たら首を締めてあげるのが人情というものです。

あと自分はGitの履歴を見る上でネットワークで図示されたのを見るのでbacklogのは割と分かりやすくてよいのだけれど、Githubはそこに行き着くまでが若干分かりづらいかなとも思った。見れるには見れるんだけど。

f:id:cardboarder:20170918011956g:plain

逆行して考える力の必要性

新しい案件が走る場合、まず要件定義なり客の要望などをしっかりと固めてあげて、そこからどういうものを作るかを明らかにするものだけど、それを完成するに辺り何が必要なのか、何をもってして完了と言えるのか、という部分を明確にしなければならない、というのがGithubでプロジェクトを進行していてわかった・感じたことだった。

GithubではIssue(課題)を立ててどういう機能を作っていくか・作ったときに出たバグを潰すかというのがあるが、Githubの仕様上、立てたIssueはCloseこそできるが完全に削除することができない(消すにはプロジェクト自体を削除するとかになる)のでバカスカバカスカ立てても結局精査する時間もあるので、Issueを立てるのは慎重にやる必要があると思う。

つまり課題を立てる上で、何をもってそれをプロジェクトやバグ修正の完結に向わせるか、それを完結させるために用いるものがあるとしたら何かということを考えてものを作るのが進行管理者でも作業者でも求められることなのではないかなと感じた(全員が全員できるようになれという話ではない)。

あとIssue立てる時にテンプレみたいなのも設定できるので、活用していくと良さげ。 Creating an issue template for your repository - User Documentation

CIツールと連携できる強さ

backlogには無い機能として、CIツールとの連携がGithubにはある。Travis CIとかCircle CIとかで自動テストとかデブロイをやってくれるのが凄まじい。これは正直自分のプライベートプロジェクトでは試してなかったので勉強になった。

連携自体は割と簡単で各サービスにサインアップしてプロジェクトを連結させるだけ。あとは設定ファイル(.ymlとか)を弄ってpushして自動で走らすなどしておけば、コミットログの横にチェックマークが出てちゃんと出来てますよーという確認ができる。

gyazo.com

コード品質管理をどうするかということでテストなどを走らせるというのがあり、今までだとこうした連携がなかったので、厳密なものは自社のガイドライン遵守でコード内容が守られているかとかを目測確認したり、そこまででなかったら結構省略することもあったので、PullRequestよろしくレビュー文化みたいなのをやっていく上でも、こうした指標は便利かなと感じた。

作業の進行上、どうしてもWIP的なものであってそれらもチェック走るなどのめんどくささもあるが、一応スキップする機能はあるみたいなので(Circle Ciだと[ci skip]ってコミットメッセージに打てば走らない)内容に合わせて送るようにすれば問題なさそう。

芝が濃くなる嬉しさ

backlogと関係ない完全に私的な内容だけど、芝(=Contributions)が濃くなるのは単純に嬉しい。個人開発をやれている人なら毎日濃くはなるだろうけど、実際問題なかなか芝を濃くしていくのは難しいと思う。通常業務であればbacklogのプロジェクト上で結構頻繁にpush作業をしているので(跨いでるプロジェクトが多いのもあるけど)、自分の芝はもっと濃かったのではないかと思っちゃう。

gyazo.com

もちろんContribution activityとかをしっかり見れば何をしていたかは分かるのだけれど一見のインパクトというものは凄いなとも感じるところ。あとはモチベ維持につながるとかかな。


ようやく本業でもGithubを利用し始めて、個人で使う分では色々と見えなかった部分が見えてきて楽しくなってきたところではある。自分のプライベートリポジトリもいい感じにできそうだなというのも分かってきたので業務と合わせてうまく活用していきたいなーなど。

そんな感じで、こちらからは以上です。

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

medium.com

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


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

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

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

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

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

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

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

余談

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

こちらからは以上です。