1.はじめに
・経緯：学習サイト"Recursion"でチーム開発を始めた。
・期限：2023年9月23日〜10月８日 の２週間
・課題：オンラインチャットサービスの作成
・書く目的：何も知らない段階で学んだものの記録し、見直すため
・言語：Python3
・チームGitHub:https://github.com/Recursion-BackendNovice-TeamA/TeamDev-OnlineChatMessenger
2.自己紹介
・2023年6月から、プログラミング＆コンピューターサイエンスを始めた
・始めた段階のスペック： ソケット通信についてさらっとみた程度 ほぼ分からないくらい
・目指すスペック： 通信の原理説明できる程度の理解＆コードも書ける
・終わった段階のスペック： 下に記載
3.テーマ詳細
・期限までにステージ２まで完成させること、余裕があればステージ３を作る。
・ステージ１：クライアントがUDPを用いてサーバに接続する。この段階では、基本的なCLIを使い、サーバーに送信したメッセージが他のすべてのクライアントに中継される。
・ステージ２：それぞれのCLIクライアントが自分専用のチャットルームが作成する機能が追加される。他のCLIクライアントは、このチャットルームに参加してコミュニケーションが取れる。
・ステージ３：GUIを持つデスクトップクライアント、モバイルクライアント、そして共有メモリを持つマルチプロセスチャットルームなどが追加される。
・学習目的
メイン目標：クライアントとサーバーの操作を構築する段階で、サーバーの操作の基本を身につけること。
サブ目標：TCP/UDPの内部構造についての理解やプロトコルの基本概念を把握し、独自の低レベルネットワーキングをアプリケーションに実装する能力を高めること。
要約？：自分自身で実装することで、ネットワーキングの基礎を身につけ、サーバサイドのアプリケーション開発のスキルを向上させることができる。
4.開発ログ
9/23
・課題を聞いてとりあえずの目標を明日までにステージ１の内容を満たしたものを各々作ることにした。
・TCP/UDPのプロトコルを意識しながらコードの模写に専念した。
9/24
・作成が間に合わなかった。
・打ち合わせの結果：ステージ１を満たしているか怪しかった。通信の理解を深めるために９/27までにインプットに専念することにした。
・ステージ１が出来ている人のコードを見て必要な情報を収集することにした。
9/25
非同期処理async/awaitとthreadingの違いを調べた。
ステージ１の課題内容の理解が浅いので機能要件と非機能要件について調べる。
・async/awaitとthreadingの違い （チャットGPTで違いを検索した）
共通点:非同期処理を扱うためのツール
async/await:
非同期プログラミングをサポートする。
特定のイベントが発生するまで待機せずに他のタスクを実行する。
非同期処理は通常、I/O操作や待機が必要な操作に対して実行され、CPUの待機時間を抑えるのが目的。
threading:
マルチスレッドプログラミングをサポートする。
複数のスレッドを実行してプログラムを並行実行することができる。
各スレッドは独立して実行され、CPUのコアを利用する。
CPUバウンドのタスクには、threading
I/Oバウンドのタスクには、async/awaitが適している。
今回では、async/awaitが適していると思う。
9/26
ライブラリasyncioについて調べていた。
・イベントループ
・async/await
・CPUの消費を抑えつつ結果の出力も早い
・普段の処理と異なる処理だから触りだけでも理解するのに時間がかかった。
・後ほどこれについての記事を書く
9/27
・asyncioについて調べていたが今回のプロジェクトで使わないことにした。
プロジェクトが終わったら調べてまとめてみる。
9/28
・9/27にやる予定だった打ち合わせを行った。
・使うライブラリは、通信：socket 並列処理系：threading
・メインの雛型はこちら
・コードの理解のためにthreadingのライブラリも確認する。
9/29
・UML図を描いていないので描くことにした。
10/1
・体調崩して9/30は休んだ
・UML図のユースケース図とクラス図をGitHubにpushした。
10/2
・UML図のシーケンス図をGitHubにpushした。
・通信のプロトコルを作成されていなかったので作成することにした。
10/3
・ステージ１のプロトコルはできた。
・ステージ２のチャットルームのプロトコルの作成を始めた。
10/4
・ステージ２のプロトコルを概要を作成しサーバークライアント間で動作の確認をする。
10/5
・作ったプロトコルに沿って入力してみたらsocketモジュールのsend() recv()の捉え方を勘違いしていたことに気づき修正
10/6
・socket.sendall() に対応するrecv()をheaderのバイト量を元に受け取るようにしました。
10/7
・TCPの通信処理の整頓をした。
10/8
・動作確認してみたらTCP周りにエラーが発生したので他の人の処理を主に利用することになった。
・締日なので、提出
5.やってみた感想、変化
5.1.課題をする前とした後の比較
| 前後比 | 通信 | UML図 | チーム開発 | 並行処理 |
|---|---|---|---|---|
| 前 | TCP・UDPを知った程度 | 概要だけ聞いた程度 | 初めて | 聞いた程度 |
| 後 | 通信時の動きの処理や動作を知れた | クラス図・ユースケース図・シーケンス図作った | UML図を用いて認識のすり合わせや担当決めをしっかりと決めないと一から組み直さないいけない状態になる 別欄で記載 | 処理周りでわからない部分があったので学んでみる |
5.2.感想
5.2.1.全体
締切に追われながらのチーム開発は、技術的負債が発生する可能性がありながらも妥協して完成させることができた。個人的には、より良い設計をできるだろうなと不完全燃焼感がある。それを解決するために具体的な学ぼうという目標もできた。
5.2.2.詳細
- チーム開発について
各人毎に役割を大雑把に決めて開発していたので、作り直しが後半に発生するなどの問題が発生した。
コードを書いてからの作り直しのコストが大きいので、時間コストが少ないUML図を最初に作成して役割分担をすればいいなと思った。 - UML図について
ユースケース図、クラス図、シーケンス図を描いてみると一連の動作や機能要件の理解をしやすかった。
描く前は、一連の動作が分からなかったので描いてみて正解だった。
クラス図の書き方には改良点があると思った。 - 通信について
TCP/UDPの処理をやってみて思ったのは、全然役割が異なると実感した。
TCP通信：確実に情報を受け取りたい、大容量の情報を受け取りたい。ただし、通信の手間が多い。
UDP通信：早く情報が欲しい、通信の手間が少ない。ただし、情報の正確性が保証できない。
socket通信：通信の動きをコントロールする奴。 - 並行処理
asyncioやthreadingなどのライブラリがあるが処理の理解が浅いので後で確認する - サーバクライアントモデル
送受信の処理を再現するのに扱いやすいので通信の実験する際はこれを用いてみようと思う
ex.今後の方針
- 方針：オンボーディングスピードを上げるために基礎力を作る
基礎力 ＝[基本的なプログラミング, OOP, デザインパターン, データベース, オペレーティングシステム]
基礎力[0]:Pythonならチュートリアル終わらすくらい。
基礎力[1]:継承、カプセル化、ポリモーフィズムをテーマに記事の作成をする。
基礎力[2]:各パターンをテーマにしたコードの作成を記事にする。
基礎力[3]:データベースの一連の操作をサーバクライアントモデルで遠隔操作してみる
基礎力[4]:プロセス、スレッド、シェル、カーネルなどの仕組みをテーマに記事を作る。 - 他ににやること
・チーム開発後にシステムを改善させるための仕組みを調べる。
・プロセスやスレッドなどの最小単位の動きを調べる。
・仕組みを理解するために、車輪の再開発をテーマにする。
・標準入力・出力を調べてみる。
・並行処理、並列処理についても調べてみる。
・公式ドキュメントの内容を試してみて記事にしてみる。