Zenn
Open23

フロント開発マネジメント

kzk4043kzk4043

開発時に決めたほうがいいもろもろ

kzk4043kzk4043

開発管理は基本スプシがいいかもな…やっぱりBacklogは柔軟性が下がる。。
まあプロジェクトが流動的すぎるのが問題なのかもしれないが…
唯一の欠点はタイムラインの管理だが、それはSlackに流してリンクするのがいいかも

Backlog

  • 1階層しか親子作れない
  • プロパティの柔軟性
kzk4043kzk4043

進捗管理

kzk4043kzk4043

結局スプシが良い気がするな…Backlogとかの進捗管理ツールは一覧性と柔軟性で劣る
バックログとの境界線で参照が弱まって困る場面が地味に出てくる。スプシで統一したい気持ち。

kzk4043kzk4043

実装とレビュを別管理にするのはほぼワークしなかった。一緒にした方がよさそう

kzk4043kzk4043

TODO管理

どこか１つにまとめる？よしなにする？

  • スプシ
  • Backlog
  • コード上にコメント
    • コメントの書式を決めておく
kzk4043kzk4043

github設定

  • 最新ブランチを取り込んでないとマージできないようにする
kzk4043kzk4043

勉強会

1時間/週で、全員参加の勉強会用MTGを設定→かなりいい感じだったので他案件でもやりたい

定期

  1. utilsなど共通系について共有
  2. BFFとか他チームと決めたこと共有
  3. レビュ観点増えたら共有

都度

  1. 新しい技術を採用していれば、その週に起きた問題と解決策の共有
  2. 新しく決まった方針について、背景等含めて共有
  3. その他案件で必要になりそうな勉強
kzk4043kzk4043

トピック例

  • 新規技術
    • 馴染のなさそうな概念について
    • この書き方が良さそう
    • 出会ったバグについて
  • 案件について
    • リーダが持っている情報（仕様変更など）の伝達
  • フロント/仕事一般について
    • MPA/SPA
    • レビュについて
    • 宣言的な書き方
    • 見積の仕方
    • gitブランチ戦略、基本的な操作
    • リマインドの仕方、Slackの管理
    • 二重クリック防止

メンバによる勉強会も募集

kzk4043kzk4043

ついでに全体共有のなにかがあればやってもいいが、会の役割が分散するので別途共有会を定期開催した方が良い気もする。

kzk4043kzk4043

前工程

きちんとデザインが完全Fixしてから設計に移れるのであれば下記の限りではないが、結構デザイン間に合わないからWFで設計進めるパターンがある。
その場合、WF/デザインで決めることを明確にしておかないと、デザインフェーズで要素が増えたりすると苦しい。

  • WF
    • OK
      • △ページの増減
      • 要素の追加、削除、変更
    • NG
  • デザイン
    • OK
      • スタイル変更
        • マージン、フォント、フォントサイズ、色味
        • 位置：ものによってはアウト？
      • 文言変更
        • 固定文言ならいいが、動的文言で参照先DBとかが変わってくると辛い
      • 画像
        • 画像自体
        • 画像サイズ、アスペクト比
      • 論理的に成り立たない
    • NG
      • WFでやること

NGは絶対やらないという意味ではなく、変更管理にまわして

  1. 追加工数をもらってリリースまでにやる
  2. 追加工数をもらってフェージングする
  3. やらない

みたいな判断をする

kzk4043kzk4043

デザインシステム

デザインシステムまでちゃんとするかは場合によるが、デザインシステム的要素は最初に合意していないと苦しい。実装上もパターン分岐が増えてしまう。

  • button: font-size
    • small: SP12px/PC14px
    • medium: SP14px/PC16px
    • large: SP16px/PC18px

的なルールをまずは作って統一すべき。
ルールというかコンポパターンを作っちゃうのがよい。

  • ボタン、リンク、カルーセル、headingなど基盤パーツのルールぎめ
  • padding, marginなどの量子化

すでにデザインがある特殊ケースで作成を諦めていたが、結局作ったほうが早かったかもしれない。結局統一した方がよくない…？みたいな話が最終盤に出てきて、実装も修正だし、デザインも修正だし、あとあと響いてきている。
どうせ直すならなるべく早い工程の方が総工数下がるのは真理。

kzk4043kzk4043

husky(commitメッセージ)

https://zenn.dev/xeiculy/articles/60fffa58a8bd36

commitizen初めてきいた

kzk4043kzk4043

https://typicode.github.io/husky/get-started.html
https://github.com/arvinxx/gitmoji-commit-workflow/tree/master/packages/commitlint-config
https://github.com/commitizen/cz-cli
https://github.com/leoforfree/cz-customizable

# husky
ni husky -D
nlx husky init

# commitlint
ni -D commitlint-config-gitmoji commitlint
echo "module.exports = {extends: ['gitmoji']};" > commitlint.config.cjs
echo "npx --no -- commitlint --edit "$1"" > .husky/commit-msg

# commitizen
ni -D commitizen cz-customizable
touch .cz-config.cjs
echo "exec < /dev/tty && node_modules/.bin/cz --hook || true" > .husky/prepare-commit-msg
kzk4043kzk4043

CSS

kzk4043kzk4043

section間のマージンの取り方

  • margin-top/bottom
  • padding/bottom
  • 背景が色付きの場合
    • それがトルツメされた場合