codekata04: Data Munging
概要
下記の3つの作業をそれぞれ個別に行う. (後に行う作業を考慮して、前の作業を行わない)
- 天気のデータを読み込んで、整形して出力する.
- サッカーリーグのデータを読み込んで、整形して出力する.
- 上記の2つのプログラムから重複する部分をできるだけ排除して、共通機能としてまとめる.
上記の作業を行った後に、いくつかの質問に対しての考察を行う形。
実装
codekata/04 at master · kitabatake/codekata · GitHub
天気データの整形プログラム
必要な機能をリストアップ
- テキストファイルを読み込んで, 各行のデータを個別に格納する.
- ヘッダー部分などの不要な行のデータを削除する.
- 各行内のデータをスペースで分割して、項目ごとに分ける.
- 指定されたフォーマットで出力する.
サッカーリーグのデータ整形プログラム
ほぼ上記と同じ。 削除する行の条件と、出力する形式が違うので、コピペ後に違う部分だけ変更した。
重複部分の排除
共通部分
- テキストファイルを読み込んで, 各行のデータを個別に格納する.
- ヘッダー部分などの不要な行のデータを削除する.
まとめた機能
ファイルを指定して、必要な行の条件を定義すると、各行のデータを取得できるような機能にまとめた。
出力部分は必要な項目が異なっているので、共通化せずにそれぞれ別々の状態のままで残した。
Kata Questions
1 . 元のプログラムを書く際に、どの程度設計を行うと、後の共通部分を取り除く作業が楽になるか？ もしくは難しくなるか？
この規模のプログラムで「設計」をどう解釈するかは難しいが、細かな機能ごとをメソッド等で整理しておけば、後の作業が楽にはなりそう。
どの部分をまとめるかの判断のしやすくなったり、メソッドごとそのまま使えることもある。
2 . 2つめのプログラムを書く際に、1つめのプログラムを書いた作業の影響はあったか？
あった。
ほとんど似たような構成のプログラムなので、1つめと何処が違って、どの部分を変更すればいいか？という感じで考えた。
3 . 共通部分をできる限り取り除くことは、普遍的に良いことと言えるか？ このことで、読みにくさの部分で苦労することはないか？ また、メンテナンスのしやすさはどうか？
共通部分をまとめるということは、多くの場合で良いことだと言えると思う。
理由としては、今後同じ構成のプログラムを書く際に使えたり、 共通部分をコンポーネントとして纏めることで、コンポーネントのクライアントに残るコードはクライアントがやりたいことの本質に近いものだと言えると思うので、可読性も上がり、メンテナンスしやすいコードになり得ると思う。
ただ、「共通部分をできる限り取り除く」ことを目的とした場合は危険なケースがありそう。
やみくもに、できる限り重複部分を排除してしまうと、共通化した部分が複雑になってしまったり、 本来クライアント部分に残しておいた方が良いものも強引に共通化させたりしてしまうと、クライアントのコードを見たときに、何をやっているのかが解り難くなってしまいそう。
目的を「共通機能をコンポーネントに整理して、可読性の高い、メンテナンスのしやすいコードを書く」とすれば、どの部分をどうコンポーネント化して、どういった名前付けをするかなどに気を使うことになるので、これは良いことだと言えると思う。
考察
「良いコードを書く」ということを目的として、可読性やメンテナンスのしやすさを考えると解り難くなる。
目的はあくまで「メンテナンスのしやすさ」（開発段階での仕様、設計の調整もメンテナスに含む）とすると解りやすい。
そもそもメンテナンスのする予定のない、小規模のコードなどは1ファイルに全部ずらーと書いてしまった方が、別ファイルに機能を整理するより可読性が高いこともありそう。
例えば今回の テキストデータの整形でも、
- 同じようなデータ形式の、異なるデータソースを整形するプログラムが今後大量に依頼される
- 同じデータソース内で様々な出力形式が依頼される
- 今後特になにも依頼されない
などのケースによって、「良いコード」は何か？は変わってくると思う。
