TechBlog

背景 宮崎のReact勉強会で小規模なLTをしたので、発表した内容をまとめる。 LTではCompound Pattern（複合パターン）について発表を行った。 概要 Compound Pattern（複合パターン）とは、コンポーネント設計パターンの一つ 複数のコンポーネントを組み合わせて、複雑なコンポーネントを構築する方法 ユースケース お知らせ機能をModalコンポーネントを使って実装している 実際に使用しているコンポーネントは以下 modal.tsx const Modal: React.FC<ModalProps> = ({onClose, children }) => { return ( <div className="..." onClick={onClose}> <dialog open className="..." onClick={(e) => e.stopPropagation()} > {/* NOTE: モーダル閉じるボタン */} <button className="..." onClick={onClose} > <Icon variant="close" className="..." /> </button> {/* NOTE: ヘッダー・テキスト・フッターなどはchildrenで表示 */} {children} </dialog> </div> ); }; modal.tsx を使った実装コード const ModalPage = () => { return ( <Modal> <Heading as="h2">システムメンテナンスのお知らせ</Heading> <div className=".

背景 最近の社内で輪読会でリーダブルコードを読む機会があった。 その際に、自分が改めて気づきがあったので、それをまとめる。 概要 輪読会では第2章と第3章を読んだため、それぞれの内容をまとめる。 本題 第2章: 名前に情報を詰め込む スコープが小さければ短い名前でもいい スコープの小さい関数で使われる変数などで、見える範囲が狭い場合は、短い名前でも問題ない。 全ての情報がみえるのので、短くていい if(debug) { const m = Map() lookUpNAmesNumbers(m) console.log(m) } 上記の例では、mという変数名は短いが、スコープが小さいため問題ない。 例えば、mがグローバル変数だとすると、mという変数名だけでは何をしているのかわからない。その場合は、別の命名を検討する。 頭文字と省略文字 エンジニアは文字を省略して書く癖がある。例えば、BackEndManagerをBEManagerと省略することがある。 しかし、これは避けるべきである。新しい人がコードを読む際に、何を指しているのかわからないため。理解できるなら問題ない。 問題ない例として、documentをdoc、stringをstrと省略することは問題ない。 ここの線引きは難しいが、理解できる範囲で省略することが大事。 第3章: 誤解されない名前 範囲を指定するときはfirstとlastを使う 範囲を指定するときは、firstとlastを使うことで、範囲を指定することができる。 例えば、以下の様なコードがあったする。 function intgerRange(start = 2, stop = 4){ ... } 上記の関数は、startの2から始まることはわかるが、stopの4を含むのか含まないのかわからない。 そのため、firstとlastを使うことで、範囲を指定することができる。 function intgerRange(first = 2, last = 4){ ... } 上記の関数は、startの2から始まり、stopの4を含むことがわかる。 ブール値の名前 ブール値の命名を否定系にすることは避けるべきである。 例えば以下のコードは、否定系の命名になっている。 const disableSsl = false 上記のコードは、disableSslがfalseの場合、SSLが有効になることがわかるが、trueの場合はSSLが無効になることがわかる。 これでは、コードの可読性が下がるため、肯定系の命名をすることが望ましい。 const enableSsl = true 上記のコードは、enableSslがtrueの場合、SSLが有効になることがわかり、可読性が上がる。

背景 ソフトウェアデザインを読んでいて網羅性チェックについて知ったので、TypeScriptでの網羅性チェックについて自分なりにまとめてみた。 概要 網羅性チェックとは、全てのケースを網羅しているどうかをチェックしていることを指す。 TypeScriptは様々なケースで利用できるが、今回は文字列リテラル型を利用して網羅性チェックを行う方法をまとめていく。 本題 以下のようなコードがあるとする。 Fruit型にはapple、banana、orangeの3つの文字列リテラル型があり、checkAllFruits関数はFruit型を引数に取り、その値によって処理を分岐している。 ここではシンプルにconsole.logで出力している。 type Fruit = 'apple' | 'banana' | 'orange'; function checkAllFruits(fruit: Fruit): void { if(fruit === 'apple') { console.log('This is an apple.'); return } else if (fruit === 'banana') { console.log('This is a banana.'); return } else { console.log('This is an orange.'); return } } checkAllFruits('apple') // This is an apple. checkAllFruits('banana') // This is an banana. checkAllFruits('orange') // This is an orange.

背景 直近でPMの見積もりを行う機会があったので、その際に参考にした資料をまとめる。 概要 こちらの参考書をもとに見積もりの方法をまとめる 本題 見積もりは工数を前提で作成していく。 工数が精度が荒い「概算見積もり」と、精度の高い「詳細見積もり」を段階的に提示していく必要がある。 概算見積もり：精度が荒いが、短時間で作成できる 詳細見積もり：精度が高いが、時間がかかる 概算見積もり 不確実性が多い段階で提出する見積もりのこと。 この見積もりを作成する時には、以下の内容を明記しておくことが重要。 「これは現時点での概算見積もりです。詳細見積もりは設計完了後に改めて行います」と日付と合わせて明記する 外部システムに影響する可能性がある場合、「外部システム連携の内容によって変動する可能性あり」と明記する また、概算見積もりを作成する時には、バッファを見込んで作成する。追加予算が発生した時に、調整が大変になる可能性がある。 詳細見積もり 不確実性をかなり潰した状態(要件定義や設計が完了した状態)で提示する見積もり Ex）ECサイトの場合、画面数や機能の詳細が明確になっている状態 正しい見積もり方の手順 見積もりの一番失敗しやすいパターンは、定例会議なので口頭のみでざっくりと見積もりを提示すること。 かならず持ち帰って見積もりを実施すること大事。 今回かの正しい手順に関しては、ボトムアップ見積もりをベースにしている。 ボトムアップ見積もり 成果物や作業を分割してそれぞれの構成要素の工数を算出して、積み上げて全体の工数を見積もる方法。 手順1: やることを細分化して積み上げ式で見積もり 誰が何をするかを明確にし、メンバーのタスクレベルを落とし込む。 以下のルールを則り、見積もり表を作成していく 工数は各領域の専門家に入力していく。PMが作成する場合でも、最終的に専門家に確認してもらうことが重要。 工数は1, 3, 5, 10, 15 …を5人日以上の工数は5人日単位で見積もる これは実際のタスクを遂行していくと、予想外の作業が発生することがあるため、バッファを積むことを目的としている。 プロジェクトマネージャーやディレクターのマネジメント工数やテスト工数などは漏れて赤字になる可能性があるため、見積もりの際には必ず入力すること。 項目 工数 費用 1 トップ画面　 5 250,000 2 ログイン画面 3 150,000 3 マイページ画面 5 250,000 4 記事画面 10 500,000 5 インフラ構築 15 750,000 6 データベース設計 15 750,000 … … … … 28 マネジメント工数 30 1,500,000 29 テスト工数 15 750,000 工数が入力すると、その人の１日あたりの単価をかけると、費用が算出できる。 こうすることで、提示された側からみても「明朗会計」になり、信頼しやすくなる。

背景 今週、社内のメンバーから以下のリーダブルテストコードの記事を見せてもらった。 かなり自分の中でささったので、Jestの場合どうするかを考えてみた リーダブルテストコード 過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方 概要 上記の参考記事を参考に、Jest(React)の場合、どのようにリーダブルテストコードを書くかを考えてみた。 今回は、UIコンポーネントとカスタムHookそれぞれのテストコードを書いていく。 本題 参考の記事にはリーダブルテストコードを書くには、以下の様に書く必要がある記載している テストコードにおいて、過度なDRYは読みやすさの敵 賢くてロジカルなテストコードより、誰でも(非エンジニアでも)読める愚直なテストコードを 脳内メモリを使わないテストコードはリーダブル 変数をなくし、上から順番に見るだけでテストの意図がわかるようにする 実行可能なAPIドキュメントだと思ってテストコードを書こう(テストコードはプログラムじゃなくてドキュメント) もっとリーダブルにするコツ 実際のユースケースに近いテストデータを使用する 「あああ」「テストテスト」「ユーザー１」みたいなテストデータはNG describe / context / itの説明を丁寧に書く 「it “適切な値を返す”」みたいな具体性のない説明はNG すべての情報が1画面に収まるテストコードが理想 上下スクロールが頻繁に発生したり、他のファイルが見に行かなきゃいけないのはNG DRY禁止はあくまで原則。適宜メリット・デメリットを天秤にかける。 「明確なメリットがあるDRY」や「可読性の損なわない抽象化」まで放棄するのはNG 上記を考慮して、React(Jest)のテストケースを書いていく UIコンポーネントテスト テスト対象コンポーネント inputタグで入力した値firstNameとlastNameが、pタグで表示されるようになっている。 // @ref: https://react.dev/learn/reusing-logic-with-custom-hooks#custom-hooks-let-you-share-stateful-logic-not-state-itself import { useFormInput } from './useFormInput'; export const Form = () => { const firstNameProps = useFormInput(''); const lastNameProps = useFormInput(''); return ( <> <label> First name: <input type='text' name='firstName' {.