チーム開発の振り返り(その2)

f:id:ryoutaku_jo:20190224144011p:plain

【結論】
・新機能をマージさせる際は、その機能が追加された事で
 他機能に悪影響を及ぼさないか考慮する必要がある

・本番環境とローカル環境とでは、DBに保存されているデータなど
 異なる点が多々あり、それが動作に影響を及ぼす可能性を考慮する

リファクタリングは大事

【目次】

【本題】

前回の続き

前記事の続きです。

ryoutaku-jo.hatenablog.com

今回は、今後に活かす為の改善点をまとめます。

改善点(1):管理体制

今回のチーム開発では、スクラムマスターとして、
チームメンバーが円滑に開発を進められる様にサポートする役目も
担っていましたが、上手く役目を全う出来なかったと感じる場面が多々ありました。

例えば、下記の様な事象についてです。

・マージさせると、かなりの割合でコンフリクトを起こしていた
 →チーム間で同じファイルを編集しない様に、タスクを管理する必要性を学びました。

・新機能をマージ後、関連する一部機能が動作しなくなってしまったことがありました。
 →新機能実装時には、影響範囲を考慮して開発を行う必要性を学びました。

改善点(2):本番環境とローカル環境の違いに配慮した実装

デプロイの全工程を担当していたので、
新機能をマージ後のデバックも行っていました。

その中で、ローカル環境では正常に動作していた機能が、
本番環境では機能せず、原因調査に何度か苦しめられました。

・ローカル環境と本番環境で、データベースに保存されているデータが違い、同じ様に動作しなかった。
 →過去に登録したデータとの整合性や、どういったデータが登録される可能性があるか考慮して設計を行う必要性を学びました。

環境変数を、ローカル環境でしか設定していなかった
 →本番環境の両方で設定を行う必要がある

・デプロイ時に環境変数を読み込む記述が漏れていた
 →capistranoでの自動デプロイで利用するためには、明示的に環境変数を指定する必要がある

・画像ファイルの拡張子を記述しなかったことで、本番環境では表示されなかった
 →それでもローカル環境では正常に画像を読み込めるが、コンパイルの関係で本番環境で読み込めなくなる

改善点(3):メンバー間の環境の違い

前項と似た内容になりますが、自身のローカル環境では
正常に動作しているにも関わらず、別メンバーのローカル環境では、
動作しなくなるという事象が何度か発生していました。

・各メンバー毎にデータベースに保存されているデータが違うので、同じ様に動作しないことがありました。
前項と同様に、どういったデータが登録される可能性があるか考慮して設計を行う必要性を学びました。

AWSのアクセスキーといったメンバー間で共有できない情報がある為、
それらが共有できないことによる影響範囲を考慮した実装を心がける必要があると学びました。

改善点(4):ソーシャルログイン

本番環境でソーシャルログインを実装する場合、アプリのHTTPS化が必要なので、
無料ドメインを取得しましたが、AWSに取得したドメインを上手く紐付けできず、一旦実装を見送ることになりました。

アプリのHTTPS化については、個人アプリで挑戦しようと思っています。

改善点(5):リファクタリング

完成を急ぐあまり、一貫性が無く、場当たり的なコードで対処することが多々あり、可読性を落とす結果となってしまいました。
また自分では理解できるが、他人が見た時に理解できるかまだ配慮した命名ができておりませんでした。
この点については、「リーダブルコード」などの技術書で基本のお作法を理解するとともに、
OSSのコードリーディングなどで命名の実践方法に対する理解を深めて行きたいと考えています。

《今日の学習進捗》

就活対策(履歴書・面接対策など)に着手。

学習開始からの期間 :78日
今日までの合計時間:791h
一日あたりの平均学習時間:10.2h
今日までに到達すべき目標時間:712h
目標との解離:79h
「10,000時間」まで、

残り・・・「9209時間!」