Zenn
Open14

プロフェッショナルプログラミング Python

Python
silvasilva

Webアプリケーション開発の流れ

Webアプリケーションは以下の手順に従って開発が行われる。

  1. 要件を決める（何を実現するか決める）
  2. 要件から必要な機能を明らかにする
  3. 機能から必要な画面を明らかにする
  4. 設計をする
  5. 機能を作る
  6. 画面を作る
  7. 動作を確認する
  8. 完成
silvasilva

便利なライブラリ

  • pandera ・・・DataFrameのバリデーション処理を行える
  • argparse・・・コマンドラインオプションの定義を作成する
silvasilva

Pocフェーズにおけるプログラマーの振る舞い方

Pocとは、新しい技術の利用や新製品開発の開始前に、実現性を確認する実験的なプロジェクトのこと。Pocに携わるプログラマは以下のようなことを心掛ける。

  • 期間を区切って作業を計画し、期間内でベストを尽くす
  • 迅速なプログラムの作成とより多くのデータ収集
  • 製品化における課題のリストアップ
  • 効果的で迅速な情報共有をする
silvasilva

チーム開発で使えるツール

  • Redmine・・・オープンソースで開発されている課題管理システム
  • GitHub Projects・・・IssueとPull Requestをまとめて管理できる。
  • 1password・・・パスワードの管理ができる。
silvasilva

課題管理とレビュー

チャットを使った課題管理

課題、チケットとは？

  • 課題・・・プロジェクトを達成するうえで解決すべき事象。画面の仕様を決めたり、バクの修正をしたりすることなどがある。これらのプロジェクトに必要な課題を明らかにし、優先順位やスケジュールに合わせて作業を進めていくことが課題管理の主な目的。
  • チケット・・・課題を管理する一つの単位。GitHubではIssueと呼ばれる。
silvasilva

課題管理を始める前に

課題管理を始める前に、必要な設定を行う。具体的には以下のようなことが挙げられる。

  • メンバーの追加
  • バージョン・マイルストーンの設定・・・
    仕様の確定など、節目ごとにその情報をバージョンとして課題管理システムのプロジェクトに登録する。期日が決まっている場合は、登録の際に設定する。
  • チケットの種別の設定・・・
    チケットに種別を定義する。例えば以下のようなものが考えられる。
    • 仕様検討
    • 機能
    • バグ
    • タスク
  • チケットのカテゴリーの設・・・
    プロジェクトがある程度の規模の場合は、機能単位にチケットのカテゴリーを登録する。例えば、以下のようなもの。
    • 管理画面
    • ユーザー画面
    • 結合テスト
    • 環境構築
    • その他
silvasilva

チケットを作成する

チケットは以下のような項目を記入して作成すると良い。

  • チケットの種別
  • 件名
  • 本文
  • ステータス
  • 優先度
  • カテゴリー
  • 担当者
  • バージョン
  • 開始日
  • 期日
silvasilva

チケットのワークフロー

チケットは以下のような流れをたどる。

  1. 新規
  2. 処理中
  3. レビュー
  4. 処理済み（場合によっては2に戻す）
  5. 完了
    チケットは必ずその作成者がチケットを完了させる。チケットの担当者がチケットを完了するのではないので注意！こうすることで、チケットの担当者が勘違いしたままプロジェクトが進行することを防ぐ。
silvasilva

チケット駆動開発

チケット駆動開発では、コーディング前にチケットを作成する。

チケット番号と同じ名前のブランチを作る

例えばチケット番号が#100であればブランチ名をt100とする。
単一チケットのためのブランチのことをトピックブランチと呼ぶ。ある一つのチケットに対応するために、複数のチケットへの対応が必要なときは、mainブランチからトピックブランチを作成した後に、作成したトピックブランチから新たなトピックブランチを作成する。

ブランチのマージ

ブランチをマージするときは以下の点に注意する。

  1. 親ブランチと子ブランチの間でのみマージする
  2. 子ブランチ同士でマージしない
  3. 子ブランチから派生させた孫ブランチの内容を直接親ブランチにマージしない
silvasilva

レビュー

レビューの留意点

レビューを依頼するときは以下の点を意識する。

  • 情報を揃える
    レビューを依頼するときは、レビュアーがレビューをするために必要な情報を揃えることが重要。具体的には、ソースコードの差分や参照した仕様書、要件定義書、画面イメージなどのドキュメントをまとめて伝える。
  • コーディングスタイルを揃える
    レビュー時にコーディングスタイルで指摘を受けないようにする。
  • レビュアーに確認してもらいたいことを整理する
    レビューを効率よく進めるために、レビュアーに何を見てもらいたいのかを伝えることが重要。
    例えば以下のようなことを書く。
    • 不安なところ
    • 工夫したところ
  • レビュー指摘に対応する
    レビューで受けた指摘はもれなく対応する。
silvasilva

開発のためのドキュメント

開発に必要なドキュメントとは何か？

ドキュメントを書く目的

ドキュメントには情報の属人化を防ぐ意味がある。属人化したプロジェクトには以下のような問題がある。

  • 特定の人に負荷が集中
  • 調べ津時間が増大
  • 認識の祖語が多発

開発に必要なドキュメントを洗い出す

開発ドキュメントが最も重要だと感じるのは新たにプロジェクト参加したとき。組織が新たなメンバーを加え、チームになじんで力を発揮してもらうための施策をオンボーディングという。

silvasilva

オンボーディングに必要な項目

  • プロジェクトの概要
    開発するメンバーが、システムの利用者、目的を利用することで全体像のイメージがしやすくなり、その後の説明が頭に入りやすくなる。
  • プロジェクトの主要技術、開発手法
    どのようなフレームワークやミドルウェアを使用しているか、メインで使用しているクラウドサービスは何か、ドメイン駆動設計のような設計手法や、スクラムのような管理手法を採用しているかどうかを書く。
  • プロジェクトの関係者、体制
    関係者リストや体制図があれば、何かあった時に誰かに相談しやすくなる。
  • スケジュール
    スケジュールが決まっている場合は、それも必ず書く。
  • 仕様ツール、サービス
    Slack、Google Driveなどの情報共有ツールを使用している場合は、それも書く。
  • プロジェクト固有の用語
    プロジェクト固有の知識が用語集という形で提供されているなら、ドキュメントやソースコードを読む助けになる。
  • サーバー、ネットワーク構成
    機能を開発するためには、システムを取り巻くサーバーやネットワークの設計によって最適な手法も異なる。
  • データ設計、ER図
    データベースを使用した開発では、テーブルの関連や、カラムの定義を理解する必要があるため、ER図やテーブル定義書を載せる。
  • 非機能要件
    性能要件やセキュリティ要件のような非機能要件がある場合はそれを書く。
  • 開発対象の仕様
    開発をするには、対象の機能要件に基づく仕様を定義する必要がある。
  • 環境構築方法
  • 開発ルール
    コーディング規約など開発のルールを載せたガイドラインを記載する。
  • 各種手順書
    レビューを受けたり、テスト環境にデプロイするといった様々な手順やワークフローを正確に実行するための手順書が必要。
silvasilva

資料を育てよう

以下のような場合は資料を改善するチャンス！

  • 説明に必要だと感じたタイミング
  • 新メンバーが資料にない情報を聞き出したとき
  • 資料の間違いに気づいたとき
  • メンテナンスが困難な古い資料は削除する