小説活動にプルリクエスト駆動が必要になってきた
小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。
【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。
GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索
小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること
【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。
小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。
【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。
本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。
そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。
【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。
トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。
プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。
【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。
akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter
加速!#DevSumi #devsumiB pic.twitter.com/d8nFXH4bjc
— 門屋浩文@redmineエバンジェリストの会主宰 (@MadoWindahead) February 15, 2019
門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter
デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter
過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。
GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。
そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。
そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。
| 固定リンク
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント