開発哲学
#memo
エンジニアとしての姿勢と立ち位置のメモ
出来る限り正しく実装する
正しいとは?
設計に即した技術選択
使用する技術に即した設計 と表裏一体
用途にマッチし、条件を満たしつつ必要過多ではない技術のほうが良い
複雑な技術はそれだけ理解にリソースを掛ける必要がある
言語の仕様に即した実装
より用途にマッチした関数/メソッドが無いかドキュメントを見る
for でカウンターを使って回しているその繰り返し処理は foreach でも良いんじゃないか?
違う用途の者を無理矢理マッチするようにして使わない
span に event を付与してボタンとして使ったりしてないか?
ライブラリの用途に即した使い方
重量級のライブラリを脳死で入れるのではなく、用途に即した物を調査する
その jQuery、JS の Web API で十分じゃないですか?
なぜ正しくするのか
理解に掛かるリソースを減らすため
書いた本人や長い期間コードに触っている人はすぐ理解できるかもしれないが、以下のような人がすぐに理解するのは難しい
そのプロジェクトに新しく参画した人
久しぶりにコードを見た人
正しくする、つまり標準に準拠する事でより早くより少ないリソースでコードを理解できる
標準に準拠することで、インターネットにある沢山の叡智が適用できるようになる
公式のドキュメント
個人の備忘録やブログ
など…
正しくない事を是としないため
正しくないんだから是な訳がない
一度正しくない状態を認めると、今後に軌道修正するのは難しい
癖がつく
負債を残さないため
正しくない事は確実に負債となる
もちろん正しい事も負債になるが、負債の大きさが違う
でも正しくするのは難しい
ドキュメントを見る癖がないと手癖で書いてしまう
レビューがないと正しくないと見抜くタイミングがずっと先になってしまう
だからこそ、レビューを積極的に行うと共に CI を導入すべき
なぜレビューをするのか
正しさを検証するため
仕様を満しているか
品質を高めるため
パフォーマンスに影響が出ないか
より良い実装方法がないか
チームとして責任を持つため
開発はチームで行うのだから、個人が品質や正しさの責任を持つべきではない
チームとして、正しさや品質を担保するべき
しっかりレビューできないならレビューをするな
とりあえず LGTM をせず、責任を持ってレビューする
無責任なレビューはノイズでしかない
なぜ CI を導入するのか
レビューはつらい
他人が書いたコードを読み込む必要がある
必要に応じて動作や仕様をを確認しなければいけない
自分の作業が中断される
大きな変更などはとくにつらい
レビューを補助するための CI という考え方
レビュアーがテストを手作業で走らせなくて済む
コードを読まなくてもある程度の現状を確認できる
ブランチ単位の自動デプロイなどでメインラインにマージする前でもすぐに動作確認ができる
CI がこけてるならマージするな
もしメインラインの時点で CI が通らないなら、即急にこけないように対応すべき
こけてる状態でマージをすると、こけてる状態が普通という常識が発生しかねない
まともに動かない CI はノイズでしかない
あらゆるユーザーに優しい UX を目指す
自分にとっては良くても他人にとっては良いだろうか、という視点を常に持つ
その他人も、あらゆる人を想定しているだろうか、という視点を常に持つ
視覚や聴覚に障害がある人の事だけではなく、非日本語圏の人や、クローラーなどのコンピュータも想定する
あらゆるユーザーが使い易い UI は無理
たとえ実装可能だとしても、複雑なものは開発に支障がでる
使い易い状態を保つのはとても難しいし、コストが掛かる
だからこそ、あらゆるユーザーに優しい UI、UX を目指す
使い易い必要はないし、複雑である必要もない
むしろ、不必要な機能を減らしてシンプルにしていく
その代わりに、出来る限りメタデータを提供する
メタデータがある事で各自が自分に即した拡張をしていく事ができる
DX を意識する
つらい状態でパフォーマンスは出ない
深すぎるネスト
大量のデッドコード
古すぎるライブラリ
どんな改変をされたのか分からないライブラリ
大雑把な仕様
すぐに動作確認できないような動作環境
テストが動かない or そもそも無い
レビューする人が居ない
つらい状態で作られた物は大きな負債になる
品質を担保しずらいので
DX に意識を向けて、つらい事を減らす
最初は時間がかかるかもしれない
習慣付ける事が重要
一人でもサボるとチーム全員に波及しかねない
顧客に、なぜ DX を意識するのか理解してもらう
一見無駄に見えるような改善もプロダクトの価値を上げている、という事を認識してもらう
DX の改善や維持に対するコスト割いて貰えるようにする
DX を改善する事で、プロダクト・チーム・メンバーの価値を上げる
プロダクトの品質が向上する
チームがより魅力的になる
メンバーのプロ意識が高まる
チームとしての総意を大切にする
大抵のプロジェクトは完全な個人開発じゃない
でもプロジェクトを開発するのはチームという単位になる
なぜ大切にするのか
メンバーに納得感を持たせるため
チーム内で齟齬が発生するのを防ぐため
大切にするために
そこそこの頻度で定例をする
チームで現状や将来のタスクを確認する
出来るならプランニングポーカーなどでタスクの見積りをする
過去のタスクについて振り返りをする
チームの方向性を決める
その他チームで決めたほうが良い物について相談する
メンターによる面談をする
メンバーどうしで温度感に大きなバラつきが出ないように調整する
メンバーのチームの現状に対する考え方や期待する事などをヒアリングする
心理的障壁を下げる
分報(times)の導入などを検討する
とにかく気軽に仕事について NDA を気にせずに話せる場所を作る
メンバー間での交流を促進し、開発効率を上げる
開発を止めない
プロジェクトにとって開発は新陳代謝
新陳代謝を止めたプロジェクトは腐ってしまう
陳腐化からは逃れられない
ドキュメントを書く
コード読めば分かるとかいう戯言は今すぐやめてください
困った事と解決内容は全部ドキュメントにするのが理想
サンプルデータを整備する
サンプルデータがないとデバッグすらできない
出来るなら質の高いサンプルデータを提供する
本番から抽出したデータ
大量のデータ
取り得るパターンを網羅したデータ