ターミナルでSSH接続先を補完させる
ターミナルでSSH接続先を補完させる。
iterm（に限らず）[SSH]の接続先をタブキーで保管できるようにする。 bash-completionを使う。
# macの場合
brew install bash-competion
.bashrcに記述を追加
if [ -f `brew --prefix`/etc/bash_completion ]; then . `brew --prefix`/etc/bash_completion fi
ssh {tab} と入力して補完されれば成功。
~/.ssh/kwnon_hosts のホスト名が候補に出るらしい。
参考
- [sshのhost名を自動補完させる - Qiita https://qiita.com/soramugi/items/846e6eac0ce1d3dc1e42]
json-serverでREST APIサーバーの(本当に最小限の)モック作成
この記事はZenn.devに引っ越しました。
ふりかえりに関する用語・略語のまとめ
新人教育のふりかえりをどう進めようか考える過程で復習・調査したことばのまとめ。
フレームワーク、指標、etc
網羅的なリストではなく、私がなにかの機会に思い出したり聞いたりしてメモに残そうと思ったもの。
きまぐれで更新。
※主にふりかえりam
に影響されると更新
参考
フレームワーク
DPA : Design the Partnership Alliance
ふりかえりに限らず、場の雰囲気を決めるための活動。
ふりかえり時に提示するグランドルールの元にする、アイスブレイクとして使う等。
以下の5つの質問から3つ程度を選び全員で答える、それをふりかえりの指標とする。
- どんな雰囲気を作り出したいか？
- その雰囲気を作りだすためにどんなことをしますか？
- 困難なときお互いにどのようにありたいか？
- この関係にどのようなものが持ち込まれると、さらに豊かになるか？
- あなたは個人として、この関係にどんな貢献をしますか？
ふりかえりのアクティビティ紹介：DPA - Qiita
ふりかえりam - ep.1
KPT
- Keep: 良かったこと（続けること）
- Problem: 悪かったこと
- Try: 取り組みたいこと（Keepの強化・Problemの解消）
上記のカテゴリごとに5分〜10分程度で付箋に書き出して共有しながら進めていく。
後述する指標に基づいて具体的で達成基準のある改善案（Try)を生み出すことが重要。
KPTA（Action）として、次に取り組む具体的なアクションを作って担当割するところまでやるパターンもあるらしい。
YWT
- やった
- わかった
- 次にやる
期間中にあったことを思い出す、成長したことを確認する、次に学ぶことを探す。 成長、学習にフォーカスしたポジティブな性格が強いフレームワーク。 新人研修など教育的な面が強い状況で使いやすそう。
FDL
- Fun: 楽しかったこと
- Done: 達成したこと
- Learn: 学んだこと
期間内にやったことを思い出しながら上記3カテゴリのベン図中に配置していく。
楽しかった＆達成した、学んだけど達成してない、学んだ＆達成＆楽しかった、など。
YWT以上に学習やモチベーション向上にフォーカスしたフレームワークという認識。
仕事に対して楽しみや学びを喜べる程度の意識・文化のチームでないと機能しなそう。 あるいは研修のグループワークなどカジュアルな活動のふりかえりとして導入するとハードルが下がりそう。
ファン・ダン・ラーン(FDL)ふりかえりボード - Qiita
Timeline
期間内に起こった「出来事」とそのときの「感情」をセットにして書き出していく手法。
KPTやYWTは課題解決や習慣の強化のための手法だが、Timelineは記憶の想起・共有のための手法。
まずは個人で出来事と感情を書き出していき、その後チームで共有する。 ポジティブな感情とネガティブな感情を表すために2色の付箋を使うとよい。 個人で出来事を思い出す際、時系列順に期間の最初から思い出す必要はなく思い出したものか次へ次へと連想していけばよい。 必然的に最近の出来事をまず思い出すため、連想していくと自然と新しいできごとから古いできごと、と並んでいく。
ふりかえりのアクティビティ紹介：Timeline - Qiita
ふりかえりam - ep.2
指標・その他
SMART
目標設定の指標。
ふりかえりの文脈だと、KPTなどから次のアクションを考える際に実現可能なアクションを考えるためのポイント。
- Specific（具体的に）
- Measurable（測定可能な）
- Achievable（達成可能な）
- Related（経営目標に関連した）
- Time-bound（時間制約がある）
目標設定の5つのポイント「SMART」とは？ | GLOBIS 知見録
MORS
ふりかえりの文脈ではないが、以前読んだ本に似たような指標があった。
なにかを教えるときは人そのものではなく行動に着目すべきという内容で、「行動」の指標として挙げられていたもの。
- Measurable (計測できる)
- Observable (観察できる)
- Reliable (信頼できる)
- Specific (明確化されている)
Developer Summit 2020 メモ
視聴したセッションのメモ。ボリューム満点すぎて全然書けてないが、備忘として。
- A-1 その後のソフトウェア・ファースト
- C-2 心理的安全ジャーニー ～Slackで安全を実装する5つの手法～
- B-3 現役開発者が語るSalesforceテクノロジーとデジタル・トランスフォーメーション
- B-4 フルリモートで事業にコミットするエンジニア組織とは
- B-8 リモートワーク×Employee Experienceでつくる ～with コロナ時代の「Work fun! Management」とは～
- A-9 プロダクト作りのトランスフォーメーション
A-1 その後のソフトウェア・ファースト
及川 卓也(Tably)
人と技術、組織が鍵。その育成を支援している。
ソフトウェアファーストはソフトウェアが一番偉いという意図ではなく、
ソフトウェアによってスケールすることを最初から認識して、戦略として考える事が重要。
SIer
Sier自社のメリットだけでなく顧客の利益最大化を目指してほしい。 日本のIT他国に対して遅れている。顧客の国内競争だけ見ていては不足。 海外の競合まで見て世界レベルの物作りを志してほしい。
世界のライバルに勝つ、でもまだ視座が低いのでは？
コロナウィルスなど世界が抱えている課題の解決を目指してほしい。
自社が儲かる<顧客が儲かる<日本が儲かる<世界が儲かる
顧客や国内だけを食っていると顧客や国内の縮小によって自社の収入源も失われていく。
ソフトウェアとは？
米国：ビジネス…MSなどをソフトで成功した企業がある 欧州：科学…標準化などアカデミック 日本：製造…工場による大量生産のイメージ
リモートワーク
対面からオンラインになって情報が欠落しないわけがない。
ソフトウェア・ファーストの時点では否定的。
子育てや体調面をカバーする福利厚生としてのリモートは必須。
そうでない場合、拠点間の情報格差を埋めるコストが生じる。リモートが本当に最適な方法か？
リモートワークで顕在化した課題。ハンコなど。見えるようになったのはいいこと。
実は不要だったものが見えるようになった。
C-2 心理的安全ジャーニー ～Slackで安全を実装する5つの手法～
片岡 俊行(ゆめみ)
心理的安全ジャーニーSlackでの５つの実装方法｜Ray Kataoka｜note
心理的安全性
無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だという安心。
くつろげる状態ではなく安全な状態。工事現場の「安全」のイメージ。
新しいことに挑戦するには協力が必要。
心理的安全性が求められるのは挑戦の状況。
無知・無能：催促・・・新しいことへの挑戦者
批判・横槍：協力・・・挑戦者を助ける者
通常モードは？
必要なのは信頼。
催促に対して善意から協力してくれているという信頼。
信頼を得るためには親和が必要。
利他自損。見返りを求めず相手のために労力を払ってくれる。
親和を得るには催促・協力が必要。機会がないと深まらない。
そこで関係性を深めるために感謝・賛成を示して相手を認める。これを小さく日々積み重ねる。
心理的安全ある・ない問題の要因。
クリティカルシンキング不足、アサーションの有無、態度。
個人スキルの問題であり訓練して鍛えられる。
実装方法(ゆめみのSlack事例)
ルール
ルールとペナルティの明確化。
イエローカードを2枚受けると一部の権限を失う。
砂場
ゆめみでは全メンバーが専用チャンネルをもつ。Timesと近いが異なる。否定感情を吐露するチャンネル。
雑談チャンネルがあるので日常の出来事プライベートの開示できているが、感情の開示はなかなかできないので、それを促すチャンネル。
補助
AMA（Ask Me Anything) Slack社が実施している施策。
MBWA（Management by walking around) マネージャが話しかけて回る施策。
B-3 現役開発者が語るSalesforceテクノロジーとデジタル・トランスフォーメーション
田中 奈穂子(freee)
田中 宏樹/神田 貴博/林 良行
B-4 フルリモートで事業にコミットするエンジニア組織とは
民輪 一博(K.S.ロジャース)
リモートワークは向く人、向かない人はいる。
ルールを明文化することが重要。全体が見えるReadme。
全体で使うツールは統一する。
B-8 リモートワーク×Employee Experienceでつくる ～with コロナ時代の「Work fun! Management」とは～
新村 北斗(Works Human Intelligence)
【デブサミ】リモートワーク × Employee Experience でつくる～with コロナ時代の「Work fun! Management」とは～ - Google スライド
（今までの）目標設定、フィードバック、評価…
これまでは顔色、過ごし方など会って見て分かる情報があったが、在宅によって得られなくなった。
リモートワークで対面コミュニケーションがなくなり「様子を見る」ということができなくなっている。 行動や評価が明確になるよう今までより具体的な目標設定が必要。
Work
この在宅期間にどう目標設定するか？
| 職務特性 | 心理状態 | アプローチ |
|---|---|---|
| 技能多様性、タスク完結性、タスク重要性 | 上司と腹落ちする目標を決める | |
| 自律性 | 自分で決める | |
| フィードバック | 組織として与える |
Fun
なぜ目標設定するのか？
現状を変えたい⇛やりたい、やならなければならない、やりたい
【やりたい】状態にしたい。
Management
目標の特性
創出・開発
向上・強化
改善・解消
維持・継続
主題：簡潔な題名
副題：なぜしたいか、誰をどんな状態にしたいか
アクションプラン：いつまでに、何をするのか最低3つ、できれな5つ以上書く
達成の定義：
運用五箇条
- 目標設定は時間がかかるものである
- 目標設定はいつでも追加・修正してよい
- 達成できたら素晴らしい・できなかったら分析する
- 進捗管理をするのではなく、障害を取り除いてあげる
- 節目でFBを得られる機会を必ず設ける
A-9 プロダクト作りのトランスフォーメーション
市谷 聡啓(レッドジャーニー)/粕谷 大輔(はてな)/門脇 恒平(プレイド)
在宅勤務でパフォーマンスが低下していると仮設を立てて計測してみた。
計測が目的であり良し悪しを図ってはいけない。
命を守るための在宅勤務なので、結果を受けて改善していくことが重要。
計測方法：プルリク消化数
3ヶ月計測した結果、個人差はあるがチームとしては影響していなかった。
WorkingAgreementを作った。
- 必須な会議体
- レビューフロー
- リリース当番など
スプリントに合わせて見直していく。
在宅勤務によって裁量が増えたが、チームとしててのイベント参加など強制力のある一定のルールは必要。
またルールが明確な方が基準がある分新しいことにもチャレンジしやすい。
伝統的な単体テストと一般的な単体テストの違い
SIer, メーカー, IT子会社などトラディショナルなシステム開発現場における「単体テスト」は正しい(？)意味での単体テストと違う意味で使われていることが多い。
そんな現場でもCI/CDとか自動テストとか頑張っていこうね、という空気はあったりなかったりするが、そもそも単体テストの概念が違うのでテストの粒度とかテストコードとか、会話が噛み合わない。
そんなトラディショナルな現場でテストコード書いていくには、言葉を正しく理解して根本的なところから攻めていかない何も始まらないよね、というポエム。
トラディショナルな手法を否定するとかこうするべき、という話はとくになく単にこういう齟齬がありますよ、というお話。
言葉の意味としての単体テスト
コンピュータプログラミングにおいて単体テスト（たんたいテスト）あるいはユニットテスト（英語: Unit test）とは、ソースコードの個々のユニット、すなわち、1つ以上のコンピュータプログラムモジュールが使用に適しているかどうかを決定するために、関連する制御データ、使用手順、操作手順とともにテストする手法である。
テストの粒度に関して同じくWikipediaより
手続き型プログラミングでは、ユニットは、モジュール全体のこともあるが、より一般的には、個々の関数や手続きである。オブジェクト指向プログラミングでは、ユニットは、クラスなどのインタフェース全体だが、個々のメソッドであることもある。
テスト技術者資格制度のシラバスでも同じように書いてある。
JSTQB-SyllabusFoundation_Version2018.J03
テスト対象
コンポーネントテストの典型的なテスト対象の例：
• コンポーネント、ユニット、またはモジュール
• コードとデータ構造
• クラス
• データベースモジュール
トラディショナルな単体テスト
トラディショナルな文脈での単体テストはクラスやメソッドというユニット単位ではなく、「単機能」を指すことが多い。
SierやメーカーITの開発現場では「単体テスト仕様書」というものがあり、データのパターンや画面入力のパターンがケースとして羅列されている。
この「単体テスト」仕様書は基本的に機能単位で作られる。
もっと具体的にいうと、画面単位やバッチ単位の「単体テスト」仕様書となる。
単体テストを実施する際は、アプリは開発サーバーにデプロイされ開発機DBに接続しており、開発者はブラウザからアクセスしてテストする。
で、画面をスクショとってExcelに貼るわけだが、それはまた別のお話…
以下のサイトがまさにそういう表現になっていた。
単体テスト・結合テスト・総合テストの違い、観点や注意点を簡単に説明する | 若手プロマネの羅針盤
「関数やメソッド単位にロジックの不具合を検出する」と定義されるのが一般的だが、どの単位で単位テストを実施するのかは、プロジェクト毎に定義すべきである。 つまり、単体テストを画面やバッチ機能単位で実施しても良い。
テストコードやCIが一般的じゃなかった頃は、どこもこういうものだったのだろうか？
いずれにせよ、単体テストを上のように定義するとテストコード書いてどうこうなる世界ではなく、ユニットテストかとEnd to Endテストとかゴチャ混ぜというか、区分がない。
加えて、テスト仕様書はだいたい会社としての標準フォーマットとか開発ルールとして定められている。
「次の案件はテストのやり方変えよう！テストコード書いていこう！」
となったとしても、ルール側にも干渉しないと、多分テストコード書いた上でいつもの「単体テスト」も実施する羽目になる。
おしまい
トラディショナルな現場で脱レガシー、というか生まれた瞬間からレガシー化していく事象と戦っている人はたくさんいて、テストコード書きたいしリリース頻度も上げたいけど、そもそもテストコードを書く技術とかCI環境とか、そういう技術的な話以前の壁が険しくてつらいね、というお話。
Sierとか大企業の内製とかでこういう呪縛を脱した事例を知りたい。
テストコードの書き方は勉強できるし教えれるけど、この壁に対して現場のエンジニアレベルでどう戦っていいのかわからん…
あとこういう事象はエンプラ界隈だと常識だと思うけど、Web系とか自社開発系だと驚愕の事実だったりするんだろうか。
de:code2020 セッションメモ
Microsoftのカンファレンスであるde:code2020視聴時のメモ。
開催期間：6 月 17 日 (水) – 7 月 17 日 (金) 17:00 オンラインにて
- A01 React Native で Windows アプリ開発 ~React Native for Windows~
- A02 Azure Bot Services を使って Teams bot を開発する
- A06 Azure Kubernetes Service と Azure DevOps による GitOps の実践
- A04 Azure ならこうする、こうできる！
- A11 Azure 10 周年の節目に見直したい、Azure インフラのちょっと大事な話
- A14 「あつまれ フロントエンドエンジニア」 Azure Static Web Apps がやってきた
- A31 Development from anywhere! 全ての開発者が生産性を維持するためにマイクロソフトが貢献できること
- A51 未来を生き抜く子どもの教育、マインクラフトで扉を開くコンピューターサイエンスの学び。
- B01 今日から始めたくなる Power Platform 入門編 ～デモで分かるローコード開発の無限の可能性～
- B41 Power Apps の可能性 ～やらない技術者に未来はない？～
- M13 開発者が語る！ Microsoft Teams アプリケーション開発の実例とコツ
- Z02 セキュアなソフトウェアを実現する、GitHub のコード解析のご紹介
- Z03 GitHub 新機能のご紹介（2020 年 5 月発表）
A01 React Native で Windows アプリ開発 ~React Native for Windows~
React Native for Windows とは
React で Android/iOS の UI を作ってネイティブコード生成。TypeScript 開発も可。
2020 年 2 月からハイパフォーマンスな C++版が Windows のデフォルトになった。
Native Module や Native UI Components を使うことでネイティブ UI や API を利用できる。
ReactNative のコンポーネントをネイティブ開発に組み込むこともできる。
デモ：Android と Win のプレビューを出しながら開発。開発コードはWinとAndroidに同時に反映される。
A02 Azure Bot Services を使って Teams bot を開発する
Azure Bot Services Bot 開発の IDE。エンドポイント定義、SDK、Bot とチャネル間のフレームワーク。
BotFrameworkSDK
Step1:ローカルでエミュレータ使って開発
Step2:ローカル Bot に Teams から接続。Teams ＞ 365 ＞ Azure(Bot チャンネル)＞ ngrok ＞ローカルサーバ
Step3:AzureAppService に Bot をデプロイ。Teams ＞ 365 ＞ Azure・・・逆順で帰ってくる
Step1:ローカル実行（エミュレータ）
空プロジェクト＞拡張 FW ＞ BotFramework
再起動して新しい PJ ＞ Echo Bot テンプレート＞実行・・・Bot サーバは OK.
BotFramework エミュレータを入れる（GitHub から入手）
エンドポイント設定して動作確認。
Step2:ローカル実行（Teams）
Azure ＞ BotChannelsRegistration
ngrok で localhost のポートをトンネルしてエンドポイント生成。BotChannels に登録。
appId,appSecretswoVS の secret.json に設定。
Teams アプリのマニフェスト作成（アイコンと manifest.json を zip）して Teams から Upload。
Step3:AppService
Azure の AppService を立ち上げる。
VS ＞発行＞ AppService を選択して発行。
Secret 設定、BotChannels のエンドポイント更新。
A06 Azure Kubernetes Service と Azure DevOps による GitOps の実践
IaC ＋ Kubernetes によってコードによって、宣言的にインフラ構築が可能になった。
変更追跡も容易になった。
IaC のデプロイや切り戻し、CI への攻撃が課題になってくる。
GitOps
マニフェストを Push すると GitOps 側で環境との差分を検知。差分があればデプロイ実行。
インフラ側に Push 用のエンドポイントを容易する必要がない＝悪意あるデプロイを受けない。
Pull型。
A04 Azure ならこうする、こうできる！
AWS と Azure の比較。
課金と管理の単位が違う。AWS はアカウント単位だが Azure はサブスクリプション単位。
特定のリソース群ごとにサブスクリプション(課金単位)を分けて管理することも可能。
Azure のマルチ AZ 構成では IP のセグメント分ける必要がない。
Azure の AZ はペアが設定されていて（東京と大阪など）マルチ AZ はを選択するとそれらが使われる。
教材としては MS Learn が無償で使える。Azure の無償環境もついてくる。
A11 Azure 10 周年の節目に見直したい、Azure インフラのちょっと大事な話
Azure10 年の歩み。
デビューは 2008 年。当初は 1 日止まるメンテナンスなどもあった。現在はほぼ無影響でメンテナンス。
可用性セットは１つのデータセンターのクラスタのひとつ。
クラスタ内の 1 台が落ちても大丈夫だが、クラスタで共有している電源や空調などが落ちると全滅する。
可用性ゾーンは、電源などが独立したクラスタの組。
ゾーンがまるごと落ちてもサービスを継続できる。
A14 「あつまれ フロントエンドエンジニア」 Azure Static Web Apps がやってきた
いままでは WebApps…オーバースペック。BlobStorage…機能不足。
クラウドデザインパターン：Coulout Static Hosting Patttern
Azure Static Web Apps
GitHub Actions と統合された CI/CD。GitHub のリポジトリとフォルダ指定すれば OK.
プロダクトと別にプレビュー用のサイトにデプロイ可能。
AzureFunctions と統合されたサーバレス API
無料プランあり。コンテンツはグローバルに配置、CDN あり。
A31 Development from anywhere! 全ての開発者が生産性を維持するためにマイクロソフトが貢献できること
リモートワークによって 52%が生産性 UP（アメリカの調査）
Code from anywhere
リモートアクセスのセキュリティ、セットアップ時間、
- Vidual Studio Codespaces クラウド開発環境。ブラウザベース。
VisualStudio Intellicode AI による高性能は
Collaborate from anywhere
VisualStudio Live Share VS の拡張機能。共同編集が可能。
- GitHub
Azure Boards アジャイル用のかんばんツール。スクラム対応。
Ship from anywhere
GitHub Actions Azure と連携すると手軽にデプロイ。
- DevTest Labs
- Azure Monittor, Insight
- Azure Policy
マイクロソフトが実施していること
- カルチャー醸成
- Teams 上でのカルチャーチャンネル
- ランチ、コーヒー、通話しながら散歩、ゲーム
- 情報共有
- ヘルプリスト
- リモートワークの指針
- ハードウェアガイダンス
- ベストプラクティス
- 技術セットアップ
- モニター、周辺機器など作業効率を損なわない環境
- VSCodeSpace、WindowsVirtualDesktop などクラウド利用
- 価値提供
- リズムを維持し、Teams 上で実施
- Azure Boards, Whiteboard を活用
- ペアプログラミング
A51 未来を生き抜く子どもの教育、マインクラフトで扉を開くコンピューターサイエンスの学び。
マイクラでのバーチャル卒業式。大学の校舎、政府公式にサーバー提供、昔話を再現、音楽の実験、etc
マイクラのバージョンによるが、科学実験やプログラミングが可能。
- Python を学ぶ
- マイクラ内のコードビルダーでコーディングやブロックプログラミングが可能。
- コマンドを学ぶこともできる
- 現実世界の AI の働きを学ぶ
- 学習のプロセス
- 想像：なにをつくるか
- 調査：どう作るか
- 試行：つくってみる
- 修正：作り直す
- 発信：作ったものを発信
- Minecraft カップ 2019
B01 今日から始めたくなる Power Platform 入門編 ～デモで分かるローコード開発の無限の可能性～
- PowerApps ノーコード・ローコードでアプリ開発
- PowerAutomate ワークフロー機能。RPA 機能も追加。トリガーとアクションを設定する。
- PowerBI データ可視化、分析。
- PowerVirtualAgents Bot 開発。
データコネクタ、カスタムコネクタによって手軽にほかシステム連携。
CommonDataService：GUI で触れるデータストア。
キャンバスアプリ GUI でシンプルな画面開発。スマホ機能、カメラ、MR など利用可能。
モデル駆動型
ダッシュボードなど複雑なモデルを開発。
モデルを定義して対応するフォームを開発する。
PowerApps ポータル 社内ポータル向け。 Azure,Google などの認証基盤を使って認証機能をつけることもできる。
B41 Power Apps の可能性 ～やらない技術者に未来はない？～
ハンズオン。
SharePoint で用意したテーブルを用いて申請フォーム作成。
ブラウザ上で部品を並べてアプリ作成。
Windows フォームアプリや OutSystems のもっとシンプル＆イケてる版。
M13 開発者が語る！ Microsoft Teams アプリケーション開発の実例とコツ
タブアプリケーション
Planner のようにタブとして表示するもの。Web アプリを Teams 内で表示しているようなもの。
認証などを Teams 向けに改修すれば既存の Web アプリの流用も可能。
ボットアプリケーション ちょまどさんのセッション参照
Z02 セキュアなソフトウェアを実現する、GitHub のコード解析のご紹介
セキュリティ侵害の 53％はコードの脆弱性が原因。 セキュリティリサーチャーは不足している。リサーチャーによって CodeQL のクエリなど日々開発されている。
コードのセキュリティ
依存関係のセキュリティ
- 安全なデプロイメント
Z03 GitHub 新機能のご紹介（2020 年 5 月発表）
Fukabori.fm ep13メモ「ペアプロやテストの疑問」
概要
最近気に入って通勤中に聞いているFukabori.fmというポッドキャストから第9回のメモと所感など。
注：
この記事は気になった部分のメモに自分の解釈や所感を加えたものです。
正確な記録を目指したものではないので興味を持った方はぜひPodcast聞いてください。
13. ペアプロやテストの疑問とか、ソフトウェアエンジニアの育成とか | Fukabori.fm
twadaさんをゲストに、ペアプロやソフトウェアテストの疑問、エンジニア組織の内製化、ソフトウェアエンジニアの育成などについて語っていただいたエピソードです。
ゲスト
@t_wadaさん。説明不要。
ペアプロの組み合わせ
ビギナーxビギナー
お互いに何が正解か分からないので開発としては効果が出にくい。
コミュニケーションを促すチームビルディングとしては有効。
ベテランxベテラン
開発時の戦力としては最高。
リアルタイムに複数の観点から意思決定できるのが強い。
アーキテクチャや全体の設計を決めることになる開発序盤に、迅速かつ効率のいい判断をしてもらいたい。
ベテランxビギナー
ベテランのドライバー比率が高くなりがちだが、ビギナーにベテランのスキルを伝承する点で効果的。
またベテラン自身の作業も教えながら喋りながら作業することになるため、普段サボりがちな部分(コメントとかコミットメッセージとか)を丁寧に作業することになり、結果的に品質は上がる。
コードレビューのインフラ投資
GitでもRedmineでもいいので、コードレビューが発生する環境を整えるだけで品質は上がる。 必ずしも全コードが見られるわけではないが、見られる可能性があるというだけで丁寧に書くようになる。 また開発が軌道にのったらツール導入というのは導入コストが高くつくので、最初から導入すべき。
非専門ドメインでのペアプロ
自分にドメイン知識がなくても相手の知識を引き出すことはできる。
ペアプロはひたすら喋る。喋っている本人も気付きがあるので、それを引き出すことが重要。ドメイン知識だけでなくベテランxビギナーのペアプロでも同様。
テスト時にスタブやモック使う？
t_wadaさん的にはPCにインストールできるものは本物を使う。
モックやスタブは自分の妄想で都合よく書いてしまう。
自分が信頼できないので使えるなら実物を使うようにしている。
private関数をテストするか？
private関数はテストしない。
振る舞い、使用に対するテストではなく実装に対するテストになってしまう。
テストしたいということはなにかしらの責務をもたせてしまっているのでは？その場合、違うクラスのpublic関数として定義するべきではないか検討する。
組織の都合などでどうしてもテストが必要なら黒魔術的に頑張る。
単体テストの指標
ブラックボックス、ホワイトボックスとあるが単体テストでも仕様、振る舞いに基づいたブラックボックステストの考え方のほうがよい。
テスト指標にカバレッジが使われることがあるが、テストの強度に対する指標にはならない。 カバレッジ100%ならバグがない、とはならない。
カバレッジの数字時代ではなく、実行されていないコードを見つけるツールとして有用。 開発者の思い込みや勘違いに気づかせてくれる。
カバレッジの値ではなく傾きを見る。
現在のカバレッジは高いが低下傾向なら問題ありだし、今が低くても上昇傾向なら改善されている。こういう見方なら管理者の指標としても役立つ。
CIのたびにカバレッジをとって蓄積することが重要。
