さてさて、もう8月が終わって、9月なんですね。早いですね...
今年も残り4ヶ月しかないと考えると、時の流れは早いと感じます。
ということで、前回に引き続き8月編になります。今月は色々と盛りだくさんでバタバタしておりました。
GitにおけるStash
開発している中で、初めて「Stash」という存在を知ったので、簡単にまとめていきます。
Stashの概要
Git Stashは、作業中の変更を一時的に保存するGitの機能。
この機能を使うことで、現在の作業状態を保持したまま、別の作業に切り替えることができます。
言い換えるのであれば、一時的な引き出しのようなもので、作業中のファイルの変更内容をこの引き出しに入れておくことで、必要なときに取り出して使うことができるとのこと。
Stashされた変更は、コミットされていない状態で保存され、ローカルリポジトリ内に保持(リモートリポジトリにはプッシュされない)されています。
例えば、「user-profile-update」というブランチで開発をしている途中で、mainブランチでバグ修正をする必要が出てきたものの、まだコミットできる状態ではない状況を想定してみます。このままmainブランチに切り替えてしまうと、これまでの変更が消えてしまうので、Stashに一時的に退避した後、mainブランチをチェックアウトすることで、変更を保存しつつ、別の作業をすることができます。
最近は、GUIでGit操作ができるので、Gitコマンドを使う機会が少ない(ほぼない)ですが、コマンドでも操作できるように使っていきたいですね。
ちなみに、Git初学者の方向けに、下記のサイトで実践的に一通り学ぶことができるので、オススメです。
Stashコマンドの使い方
- 変更を保存する(基本)
git stash
または
git stash save "メッセージ"
- 保存した変更を適用する
git stash apply # 最新のstashを適用（stashは保持）
git stash pop # 最新のstashを適用して削除
git stash apply stash@{n} # 特定のstashを適用
- Stashリストの表示
git stash list
- 特定のStashの内容を確認
git stash show stash@{n}
git stash show -p stash@{n} # 詳細な差分を表示
- Stashの削除
git stash drop stash@{n} # 特定のstashを削除
git stash clear # 全てのstashを削除
- 新しいブランチを作成してStashを適用
git stash branch <新しいブランチ名> stash@{n}
- 追跡されていないファイルもStashに含める
git stash -u
- 対話的にStashする(部分的なStash)
git stash -p
- 特定のファイルのみをStashする
git stash push -m "メッセージ" <ファイルパス>
10 最新のStashとの差分を表示
git stash show -p
もっと具体的な使用方法などは、下記のサイトを参考にしています。
6・７月編でのフィードバック
MVPの話
前回の記事で「MVP」について、フィードバックを頂いたので、それを踏まえて、再度まとめ直してみました。
前回の記事を書いた時点で、「逆にデメリットとしては、質より開発からサービスインまでの早さのほうを優先する」と書いたのですが、質ではなく「機能数よりもサービスインまでの早さ」を優先するとのこと。
最小限の機能で早くサービスインすることで、
・実際のユーザー(利用者)からのフィードバックを早い段階で得ることができる
・ユーザー側のニーズを把握し、それに応じてすぐに製品を改善していくことが可能になる
というのが、一番のメリット。
また、必要最小限の機能に開発のリソースを集中させることで、
・不要な機能開発にリソースを消費することを避けることができる
・余ったリソースをバグ修正といったシステムの内部的な質(ここでは不具合が少ないことを指す)を向上することに使うことができる
のも、MVPの利点。
ソフトウェアにおける「質」の話
もう一つ、フィードバックを頂いたので、これについても考えてみようと思います。
前回の記事で「質、質」と強調していましたが、
「ソフトウェアやサービスにおける質とは何か」
というフィードバックをいただきました。「たしかに、言われてみればそうだな」と。
ソフトウェアやサービスにおける「質」の定義は、状況や視点によって大きく変化するので、単に明確な定義もなしに「質」と書くだけでは、抽象的すぎる・具体性に欠けるなと、読み直して感じました。
なので、具体的な例として、どんな定義があるか、エンドユーザーと開発者(とおまけにビジネス側)の視点から、少しですが考察してみました。(それでもまだ抽象的・主観的)
エンドユーザーにとっての「質」
- 使いやすさ
- 基準が分からないから測りにくい
- 安定性
- WebとかだとPageSpeed Insightsとかあるから、指標としてはアリかも
- 速度
- 同上
- 不具合の少なさ
開発者にとっての「質」
- コードの可読性
- Pythonの場合、公式が出しているコーディング規約を指標にするのはアリ？
- それ以外だと、完全に主観的・自己満になってしまうような気がする
- メンテナンス性
- これも主観になってしまいがち。
- 拡張性
- 技術スタックに寄るところが大きいかな。測りにくい
ビジネス側の視点にとっての「質」(ここは弱い)
- コスト効率
- 市場競争力
こうして考えてみると、「質」という言葉一つをとっても、色々な解釈のしようがあって、使用するときは、もっと具体的な文脈や定義を書く必要があるなと思いました。勉強になった。フィードバックありがとうございました。
Discussion