見出し画像

プロダクトが完成するまでのcommitから振り返る！

とあるY

謝辞

内定直結のエンジニア実習ができるサービス【アプレンティス】に参加しています。そのカリキュラムでチーム開発に取り組みました！

https://www.youtube.com/watch?v=3B8RyrN9bls

今回PHPで初めてがっつりチーム開発する機会を頂きました。山浦さん、メンターさん、チーム開発に協力して頂いたみなさん、本当にありがとうございます😭今回多くの学びを頂き本当に感謝しております。また苦しい時に励まして貰えて嬉しかったです。

⚠️この記事は作成途中です

また、この記事は完全に自分に向けた記事です。次回のチーム開発でより良い成果を上げるにはどうすればいいかに焦点を当てて記述しています。ターゲットが絞られるため有用でない情報が数多く含まれています。興味を持って開いて頂いた方々ごめんなさい🙇

この記事の対象者

  • 次回チーム開発に臨む前の自分

概要

今回開発したプロダクトはチーム特化のタスク管理アプリです！
実装までの一週間で自分がどのようにして動いたかを言語化し振り返り今後の改良のために作成しています🫡

ボリューミーな内容になっていますので興味のある箇所の目次に飛んでいただければと思います！


方針

  • 一人以上プルリクにLGTMがあればmergeする

2024年3月14日

下準備

First Commit

やったこと

  • README.mdを追加

記入内容

  • ターゲットの概要だったり

  • メリット

  • キャッチコピー

  • プロジェクトでの共通用語

  • 要件

  • 資料

  • 導入する環境

今振り返ってみると

  • README.mdだと誰が読んだか確認することができない

    • 【対策】GitHubのタスク管理のLabelを使って誰が確認したかを把握するようにする！

最初のREADME.mdの要件は以下の感じです。

フィードバック

タスクに対して抽象度が高すぎました。データベースに登録されるデータは具体的にすべきだったと反省しています。以下がタスク出し直前の要件です。

また以下が最終要件です。

ワイヤーフレームを参考に、「何をするか」を中心に機能要件を追加し、それを基にタスクの分割を行いました。個人でのペースを元に要件を定義してしまい他のメンバーはむっちゃしんどかったと思います。

ゴールが遠いとメンタルに影響するので良くないです、メンターの方が最低限のゴールを他のメンバーに1on1で提言してくれたおかげでチーム一丸となってデモできるコンテンツに仕上がりました。本当にありがとうございます🙇

次のコミット


DATABASE SQLの追加

DBeaverを使ってテーブルを作成すると勝手にER図も作ってくれます！
この時点で結構重大なやらかしを2点しておりました。

  • 複合主キーのデメリットに気づかず設計

  • on delete cascade抜け

    • ER図を作成するのが目的になっていたため

    • 仕様にDELETEが含まれていなかったため(追加される可能性があるた念のため付けておくに越したことはない！）

    • ER図だけを作るのが目的だけだとしても合意が取れたらちゃんと設計（振り返り）していく！

複合主キーについて

今回作ったプロジェクトでは多くの複合主キーを持つテーブルを採用しました。
以下にparent_tasksテーブルの画像を示します。

複合キーを採用した理由は、データの取得や管理を直感的に行いやすくするためです。

上記parent_tasksテーブルを例に

$$
\begin{array}{|c|c|c|} \hline
project\_id & user\_id & id \\ \hline
1 & 1 & 1 \\ \hline
1 & 2 & 1 \\ \hline
\end{array}
$$

このような形でデータを管理することができます。

特定のプロジェクトに対して所属するとあるユーザーは必ずid1番からn番目までのタスクを保持するって状況を想定していました。

やらかし


複合主キーの挙動を勘違いしていました。

どう言った挙動を想定していたかというと
先ほどのparent_tasksテーブルに以下のレコードのみ挿入されていたとします。

$$
\begin{array}{|c|c|c|} \hline
project\_id & user\_id & id \\ \hline
1 & 1 & 1 \\ \hline
\end{array}
$$

ここに以下の条件でレコードをauto_incrementで挿入します。

$$
\begin{array}{|c|c|} \hline
project\_id & user\_id \\ \hline
1 & 2 \\ \hline
\end{array}
$$

自分の考えは以下のように増えると思っていました。

$$
\begin{array}{|c|c|c|} \hline
project\_id & user\_id & id \\ \hline
1 & 2 & 1 \\ \hline
\end{array}
$$

しかし実際は、

$$
\begin{array}{|c|c|c|} \hline
project\_id & user\_id & id \\ \hline
1 & 2 & 2 \\ \hline
\end{array}
$$

となりました。

複合主キーの問題について気づけたのもメンバーが1個の主キーで行くことを提案してくれたおかげでした。これがなければ絶対にCRUD間に合わなかったので本当に助かりました！

どうすれば複合主キーを使えたか

上記のSQLを突っ込んでもらってデータが返ってこなければidに1を設定し、返ってくればインクリメントするコードを記入すればいい！

SELECT文を考える工程を一個入れないといけないのでどちらにせよ書き手に負荷を与えてしまいます😢

2024年3月25日 (月)

締切まで残り6日と19時間

稼働時間11時間

使いそうなSQL文を作成

PHPで流用できそうなSQL文を先にタスクとして割り振ってGitHubのチーム開発に慣れていない自分や他のメンバーがGitHubのPull Requestからmergeまでの流れを把握するなどに使うための軽めのタスクとして割り振りました。

ただ自分自身もこのタスクを消化してしまったのが今回の反省点だったなと思っております。

やらかし

グルーピングして集計するようなSQLのタスクを先にやってしまいました。似たような集計処理が出てくるため、他のメンバーにやってもらってしんどそうならHELPに入るように動いた方がよかったです。主要になる機能にトライしてもらうのが大事！プロダクトのイメージが付きやすかったと思います。

フィードバック


みんながSQLに取り組んでいる間に自分はPHPでどのようにしてデータベースにアクセスしてCRUDするかのドキュメントを作成すればよかったなーと反省しております。
この時点では、まだ時間に余裕があったので自分自身が進捗を出すことよりもメンバーが稼働できるようにいかにドキュメントを整備するかが重要！

自分自身で進捗を出そうとしていたのはこの時点では当初のスコープでゴールできると踏んでいたからです😱

今回はビジネスではないのでみんながいかにタスクを回せるかに焦点を当てなければなりませんでした！成果物は二の次でみんなで楽しくチーム開発できたという成功体験を重要視すべきでした！

今回のタスク出しの反省点として、バックエンドに主眼を置いたタスクの書き方をしていなかったことがあります。

そのため、タスクに着手する人はフロントとバックを両方考える必要があるのでむちゃくちゃしんどい思いをさせてしまいました。ごめんなさい。

作ったクラスの呼び出し方だけちょろっと書いてこうすればCRUDできるでーっていうのだけ渡してました。いきなりフレームワークもどきをぶっ込むとメンバーの不安が溜まるためちゃんとChatGPTで文章作ってもらってから自分で検閲したドキュメントを渡せばよかったなー

後から一緒に土台を作ったり、教えてもらったりする時間が欲しかったとメンバーが言ってくれたので今度フレームワークを使わないプロジェクトがあったら一緒に土台を作るタスクをやってみようと思います🫡

他のメンバーの動き

MySQLが動作するメンバーはSQLのタスクをやってくれていました。そのおかげで環境構築をしている間にPHPのタスクにスムーズに取り組めました。

ルーティング

アクセスするPHPファイルを作成しました。

2024年3月26日 (月)の最終進捗

メンバータスク一覧画面


2024年3月26日 (火)

締切まで残り5日と19時間

稼働時間11時間

環境構築

メンバーのマシン環境
- Windows WSL
- Mac Intel (自分)
- Mac M1, Windows
- Mac M1

M1メンバーの環境でデータベースに日本語の環境が適用されないため「なんでやろ？」と色々調査していました。この時に中途半端な知識で余計な時間を食わせてしまって本当に申し訳なかったです😢

調査したこと

  • SQLの設定でデータベースの設定をUTF8mb4の設定に変更

  • そもそもDockerのイメージが日本語対応してないっぽいのでconf.dなどにmysqlをutf8mb4にする変更を追記

  • docker立ち上げの際に、sudo aptなどでutf8mb4が入るようなコマンドを流す

    覚えているだけで、上記3点をやって時間だけを奪ってしまい本当に申し訳なかったです。

結局M1で色々試してこの日は環境構築できませんでした。
付き合わせてしまったメンバーには本当に申し訳ありません😢

この時点ではまだリポジトリにマニュアルを記載していました。
マニュアルをリポジトリに記入することのデメリットは以下です。

  • pull request, LGTM, mergeの負担

  • 作業しているファイルを一旦変えてマニュアルのmdを閲覧する手間

フィードバック

  • Windowsを持っているメンバーには動作する環境でタスクをお願いする

M1のメンバーは4人中2人！
環境構築がうまくいかなかった場合、チームの戦力が半分になってしまいます。また自分も構築に参加すれば稼働しているメンバーは1人のみ！他のメンバーが最大人数でどうすれば一番タスクを回しやすいかが大事！
メンバーがタスクに取り組みやすいようにするためにここでしっかりやってもらうと決めたタスクのアシストとかを整備すべき!

  • マニュアルはGitHub Projectsのタスク管理 tasksboard(以下、タスクボード)のカラムに記載してスピーディーに閲覧できるように！

  • メンバー名+確認済みLabelを追加することで情報の伝達不足を防止！

  • M1などのOSが異なる環境構築を扱う際は実装フェーズの前に必ず動作検証！

データベースへ接続するためのクラスを作成

SQLを進めてくれていたメンバーがVCで「これほんまに終わるんですか？」と不安がっていました。（この時点ではほぼ画面に何も表示されていなかったため）

少しでも安心させるために「DBからデータを取得して画面に表示させる処理」を実装しました。
その後に、データベースへの接続がしやすくしてフレームワークぽく使えるクラスを導入しました。
こいつのおかげでトランザクション処理とかエラーのキャッチとかできたので謎のエラーとかデータベース不整合で苦しむことなくプロジェクトを乗り切りました🫡

やらかし

こういった土台になるようなコードはPull Requestの方でしか簡単な説明を記入していませんでした。
mergeはLGTMが一人以上の時に行われる方針でした。

そのため、Pull Requestがクローズされると確認漏れが起こると思いタスクボードの方に確認カラムを追加しました。そこで他のタスクをやるメンバーが困らないようにマニュアルの追加や閉じてしまったpull requestにリンクを貼るように変更しました。

Pull RequestのFile Changedの機能でコードレビューできることを知ってからそっちをコードのマニュアル代わりに使っていました。

  • 悪かった点
    FIle単体の抽象的な説明、このファイルではpopupの見た目を扱っていますなど、読み手が必要な情報を得るためにそのファイル全体を通しで読まないといけないレビューを書いていました。

フィードバック

コードレビューの際はそのコードが誰に流用されるのかの視点を持つ！
実装して終わりじゃない！タスクが終わったら一旦読む人の視点に立ちましょう！

また以下に実装したコードを載せておきます。

今だったら、こうレビューします🫡

DataSourceクラスについて

  • データベースにアクセスして、CRUD処理をするためのメソッドを呼び出せるようにするクラス

beginメソッドについて

  • トランザクション処理を開始するクラスです、

  • トランザクションとは、

    • データベースの操作の一種、トランザクション内の全ての操作は、全てが成功するか、全てが失敗する（すなわち、何も変更がない状態に戻る）かのどちらかとなります。これにより、データの整合性を保つことができます。

    • 例えば、銀行の口座間での送金を考えてみましょう。ある口座から別の口座への送金は、一つの口座からお金を引き出す操作と、もう一つの口座にお金を入れる操作、この二つの操作で構成されます。これらの操作は一緒に行われ、どちらか一方だけが行われることはありません。もし一方だけが行われると、お金が消失したり、逆に無から生まれるという問題が発生します。これを防ぐために、これらの操作は一つのトランザクションとして扱われます。

  • selectメソッドについて

    • sql文を引数にする

  • commitメソッド

    • データベースのデータの更新を確定する

  • rollbackメソッド

    • commit確定前に不具合があった場合エラーを返してくれる

DBから取得したデータをブラウザで表示

他のメンバーの動き

他のメンバーは画面のヘッダーやリンク機能、ページネーションなどフロントの処理を進めてくれていました。この時にリセットCSSの追加が抜け落ちていたので次回からヘッダーのタスクをやる際に追加したいと思います🫡
他のURLに飛んでもヘッダーとフッターが表示される仕組みを作ってくれたりしてほんま助かりました！見た目がつくと希望が見えるのでほんま助かります

2024年3月26日 (火)の最終進捗

メンバー一覧画面


評価一覧画面

この時はまだ従来のスコープで進めようと思っており、両方の画面を作ってもらっていました。


2024年3月27日 (水)

締切まで残り3日と19時間

稼働時間11時間

M1環境構築の対応が完了！

もう一人のMac M1メンバーが環境構築に力を貸してくれたおかげでうまく動作しました。助けて頂いて本当に感謝しております😢

本番ページにDBから読み込んだデータを表示

やらかし


PHPでwebサイト作るの久々でまぁ表示させて後で綺麗にしたらいいやろのノリで時間もないし少しでもメンバーに希望が与えられるように汚く書いてたなーと反省しております。初手からメンバーの作ってくれたviewsフォルダにサーバーの処理と表示の処理を一緒にぶち込んでしまいました🥺

最初のレビューで、メンバーに指摘してもらえたおかげでサーバーの処理とviewsの処理を分けることができました。これが無かったら魔境のコードがさらに魔境になっていた・・・

表示させたページ

メンバー一覧画面

コアページのレイアウトとDBに登録されたユーザー名を取得し、本日の日付とともに表示

画面のCSSを整えたことで、見かけ上の安心感を与えました。

メンバー一覧画面

またここからちょこちょこgit add .忘れするようになってcommit メッセージが不明になっていきました。ついでにservicesフォルダを作ってデータガチャガチャするロジックをそこで作業しようってことにしました。servicesフォルダについてのコメントはpull requestのところしか残していなかったので反省せねば

フィードバック

もしもコミットメッセージを間違えたりgit addを忘れてしまったら

git reset --soft HEAD^

しよー。データは消えないから大丈夫！resetは怖くない！不安ならgit logで確認すればいいし、消してしまっても復元できる！不安なら新しくbranchを切っても大丈夫！pushの前には必ず

git branch 
git status

でpushできる状態か確認するて癖をつけよう！

ポップアップ表示処理を追加

大体画面が見えて他のメンバーが希望が見えたと言ってくれたので他のタスクに入りました。

ポップアップは初見だと書くのが大変だと思うので、先にpopupを表示させるだけの画面を作り、そこでボタンをクリックするポップアップが表示される処理を作りました。今見返すと、どこの画面にアクセスしたら動作するかくらいしか書いていなくて、レビューしてませんごめんなさい😢

以下ポップアップの動作


フィードバック

追加したらコメント書く！コードだけで理解してもらおうと思わない！
今思えばChatGPTとかでコードぶん投げて解説してもらいつつ間違ったところを訂正するスタイルにすればよかったなーと反省しております。業務用だとセキュリティ的にむずいけど今回はその選択取れたなー🫡

次へのフィードバック！！！

自分の作ったbranchがmainとmergeできない！

rebaseコマンドとmergeコマンドの理解が不足していました。

rebaseコマンドを使えば最新のmainのbranchになってめちゃくちゃ便利ってイメージで使ってました。だからメンバーにも布教していました。

しかし、以下の問題が発生したんです。

rebase中にコンフリクトが発生した場合、それぞれのコミットでコンフリクトを解決する必要があります。これは大量のコミットがある場合や、同じコンフリクトが何度も発生する場合には手間がかかります。

なのでrebaseするとコンフリクトを修正しても次のコンフリクトが発生してずっとmergeの処理に追われてしまいました。
しかも自分は途中までGitHubのエディターでmerge処理していました。これでかなり作業時間圧迫されてみんなに迷惑かけました。ごめんなさい🙇

GitHubへの理解の甘さが今回かなり浮き彫りになりました。

知ったつもりになっていることが本当に多く個人でうまく行ったことが必ずしもチームでできるとは限らないです！

チーム開発ができる機会を提供して頂いた方々や共にチーム開発に協力して頂いたメンバーの皆さんには本当に感謝しております。

締切2日前からメンバーの方にmergeの方が問題が起こらないから楽なことを教えて頂いて対策できるようになりました。あれがなければずっとrebaseで苦しんでました😢本当にありがとうございます🙇

フィードバック

  • コンフリクトしそうなmainはrebaseしない


他のメンバーの動き

  • データベーステーブルの作成と更新を行うために、2つのSQLファイル（`exe.sql`と`after_the_second_time.exe`）を使用していました。
    初めてテーブルを作成する人は`exe.sql`を、2回目以降の更新を行う人は`DROP`文を含む`after_the_second_time.exe`を使用していました。
    しかし、これによりデータを追加するたびに2つのファイルを更新する必要があり、作業が大変でした。そこで、チームメンバーの一人が`IF EXISTS`文を導入しました。
    これにより、テーブルが存在する場合は`DROP`文を実行し、存在しない場合はスキップするという処理が可能になりました。
    その結果、2つのファイルを1つにまとめることができ、作業の効率化に大いに貢献してくれました😀 本当に感謝しております

  • ユーザーごとに専用のデータを取得して曜日ごとに配置し直してくれました！、結構配列的にややこしい処理なんですが頑張って実装してくれたんで作業が進んでめちゃくちゃ楽になりました！

2024年3月27日(水) 最終進捗

日付などのデータはまだ整形されていません

2024年3月28日 (木)

締切まで残り2日と19時間

稼働時間11時間

データの詳細を表示するポップアップを作成

先日の反省を活かしてできる限りコンフリクトしないように他のメンバーと被らないタスクに集中していました。

前回作ったポップアップの中身はこうやって作るんだよーってノリでプルリクしたと思います。

pull requestの処理を見ていると、popupの簡易的な処理をmainに巻き込んでcommitしていました。微かな記憶を辿るとmainで作業してしまって、稼働中のメンバーとコンフリクトしないし時間推してるから合意取ってpushしてしまいました😱 

このタスクをcommitするまでにおよそ2時間30分ほどかかっていました。
そのうち、テキストのデザインをいい感じにするのに体感8割くらい時間を割いていた気がします。

とりあえず仮決めで後からいくらでもみんなでブラッシュアップできたのに目の前のタスクに集中しすぎてしまいました。

フィードバック

mainに留まらない！main　branchをgit pullした後は必ずdevelopなどの避難branchを作ってそこに移動しましょう！mainで作業するのはダメ絶対！

タスクに入る前は深呼吸！、メンバーに一声「何か力になれることありますか？」と言う、チーム全体の状況を見て動く！　次のアクションに対してはどれくらいかかりそうかタイマーをセットする！
それ以上を超えたら別のアプローチ!

プロパティをいじる系の処理はタスク出ししてあとは時間が余ったらみんなで消化する！　ロジックの方を優先！

タスク詳細ポップアップで子タスクを増やしてスクロールする機能を追加

メンバー一覧画面の仕様でスクロールすると左右に動くUIにしたかったため、他のメンバーにどうやってスクロールして実装するかのコードを書いてこいつ見ながら実装してーって感じに誘導しました。　わからないところはCSSで見せながらここのプロパティ弄ったらいけるでーって感じの説明をしてしまいました。この段階から結構口頭で伝達してる😢　投げやりな説明だったけどちゃんとスクロール機能実装してくれてめっちゃ助かりました！

最終的な見た目はこんな感じです。

また、ViewsフォルダのphpファイルのとこにJSの処理も一緒に書いてReactっぽい書き方をしてしまいました。後ほどJSファイルに分離したけどよく考えてファイルの仕分けしないとー

フィードバック

ディレクトリの構成とかも最初に決めておく!
チームでやる時はファイルを無闇に増やさない!
増えた場合も、ちゃんと不要になったら削除できるようにしておく！

親タスク登録ポップアップを追加

+と-アイコンはSVGをダウンロードして使ってもよかったのですが、SVGにあまり精通しておらず既にあったshadowとかをすぐに使い回せそうになかったので擬似要素で作りました。

またここら辺でメンバーにCSSのアニメーションについてレクチャーしたと思います。ボタンがどうやってアニメーションしてるかや、検証ツールを使ってアニメーションの変更方法などについて話した記憶があります🫡

やらかし

擬似要素を追加したことで、どのボタンが追加されたか、どれが削除されたかが分かりにくくなってしまいました。svgなどの画像なら、パスを指定してあるのでビジュアル的に一目で見つけられたと思います。申し訳ありません😢

ボタンが一目でわかりにくいと思い、Pull Request に追加されたボタンのDOMの場所を明確に記載し、バックエンド担当のタスクのメンバーがどの変数を扱えばいいかを記載しました。

次に、タスクボードの確認カラムに情報を記載し、ドキュメント化することで、Pull Request が埋もれてしまわないようにしました。ただし、作成したドキュメントのアナウンスを忘れていたと思うので、今後のフィードバックとして活かして行きたいと思います！

さらに、致命的なミスとしてこの時点でfetchを使ってデータベースとapi通信するって処理が抜け落ちていました。タスクを追加する処理を担当していたメンバーにはめちゃくちゃ迷惑をかけてしまいました。ごめんなさい

フィードバック

作成したドキュメントは、使う人に読んでもらってフィードバックを貰おう！　

自分が書いたドキュメントの存在を忘れないで！　質問があった時に照らし合わせながら自分のドキュメントのどこに不備があるか確認してブラッシュアップ！！

ドキュメントは書いて終わりじゃない！　読む人が認知できるように直接通知する

他のメンバーの動き

ポップアップを作っている間に2週間分のサンプルデータを挿入してくれたり、スクロールできるように機能を追加してくれたり、プログレスバーを作ってくれてめちゃくちゃ助かりました！

2024年3月28日 (木)の最終進捗

2024年3月29日 (金)

締切まで残り2日と19時間

20時間

メインページとポップアップのドッキング

15分ほどで終わると思っていたタスクが4時間ほどかかってしまいました。そのため、他のタスクをやっていたメンバーへのフォローが遅れてしまいま
した。

【バグの原因】
buttonのEventHandlerの箇所にpopupのEventHandlerを追加していたせいでbuttonの数だけpopupのEventHandlerを登録するバグを仕込んでしまいました。

また、ドッキングのついでに進捗度の数字を選択するとカラーが変わるなどの処理を追加してしまいました。(必須の処理ではなかったので後回しにすべきでした）

こういった処理を追加することで、バックエンドとの連携を行うチームメンバーのコードを負荷を上げてしまいました。
また、ドキュメント作成やファイル整理などの作業も増えてしまいました。

時間が限られている場合には他のチームメンバーが効率よく作業できるように、最小限のコミットに意識を向けることが重要です！

フィードバック

イベントハンドラーも１対多などのリレーションを意識する！
ドッキング前に動いていたからと言って油断してはいけない！
ドッキング前にボタンを複数増やして正しい挙動を取るかテストする！

複合主キーの廃止

ポップアップのバグ取りにかなり苦しめられて迷惑をかけまくってました。メンバーのタスクで複合キーだとデータを追加できないという話を頂いたので本当にできないか調査のために2時間30分ほど時間を奪ってしまいました。その間にタスクを振れなかったので本当に申し訳なかったです。
当時はどうやったら複合主キーに値を挿入するか考えが及ばず、また今後のタスクを楽にする観点から主キーを一個にすることに決めました。
判断が遅い👺

フィードバック

タイマーを入れてタスクをこなす！
思った以上に時間がかかりそうならチームに共有！
チーム開発はタイムアタック！

apiでpostするファイルを作成

今回の要件は動的なWEBページです！

メンバーから今まで渡していたコードではPHPのデータをGETできてもPOSTできないことを教えて頂きました！
これでいけるよーって言ったのに、実際は無理で、完全に自分の認識不足でメンバーのタスクの邪魔をしてしまいました。めちゃくちゃ迷惑かけてしまい申し訳なかったです。

そのためどうするかはapiとかajaxとか使うっぽい話を教えて頂いたので、とりあえずapiでpostするファイルだけ作りました。この時点でどういった処理でこのファイルをJavaScriptでどうやって起動させるかについてはまだ深く考えていませんでした。（メンバーと一同じタスクをやりながら考えるかーと思ってました）

やったこと

定数を設定してデータベースに登録するphpファイルを書きました。

fetch処理の追加

調査して、fetch処理でデータ渡す処理を自分で書いてメンバーにこうやって使うんやでーというプルリクを出しました。

自分が書いたサンプルのfetchのコードは送信した後、JavaScript側でjsonでデータを受け取る処理を書き忘れていたのですがメンバーの方が追加してくれたおかげで、その後のタスク詳細ポップアップの処理にめちゃくちゃ活躍してくれました！ありがとうございます！

新しいデータをDBに保存


フィードバック

後から見返すと確認カラムとプルリクの両方を見返すのが大変だったなと感じています。
誰かに参照されると思うプルリクは、前回のプルリクで書いたからいいかで省略しない！毎回重複しても見る人が使いやすいようにDBのデータの流れを記入する！

他のメンバーの動き

他のメンバーは以下の処理を頑張ってくれました。

  • 進捗度によるバーの着色

  • ボタンを複数から1個に訂正

  • ユーザー名をその場に固定

  • 複数あるタスクを画面に表示

色んなことで自発的に動いてめちゃくちゃ助かりました！
また口頭でログインしているユーザー一人だけにボタンをつけることをお願いしてしまいました。ここから結構ドキュメントが雑になって行ったと思います😢
めっちゃ雑にタスク出ししたのに、ちゃんとこなしてくれて助かりました😢

以降随時更新！

2024年3月29日 (金)の最終進捗


2024年3月30日 (土)

締切まで残り1日と19時間

16時間

2024年3月29日 (土)の最終進捗


2024年3月31日 (日)

締切まで残り19時間

15時間

2024年3月31日 (日)の最終進捗

この記事が気に入ったらサポートをしてみませんか？