かざいむ日誌

IT関係で知ったことなどを記事としてあげていきます。内容に不備や質問などあればぜひコメントをよせてください。

ちょっとだけプログラミングのプロセスの改善をした。

ここ数日慣れないPythonでグラフを出力するコードを書いてたけど詰まりながらも途中で軌道修正できたので、その中で気づいたことを書いておく。

f:id:name_untitled:20200517003341p:plain

Pythonで出力したグラフ

言いたいことは大体こんな感じ。

  • 制約をベースに手段を考える
  • 具体化は出来るだけ遅らせる
  • ドキュメントから関連するものを漁る
  • 実現方法は何パターンか考える
  • おもちゃを用意してこねくりまわす
  • 機能分割は無意識にやりがちなので気をつける
  • コードではなく思考プロセスを振り返る

昨日久しぶりにやや手探りでPythonでグラフを書いたけど、前回はまったので注意しようと思った。前にも数回Pythonでちょっとしたコードをかいたことがあるけど、毎度毎度けっこう引っ掛かってはまってしまう。この時の考え方に癖やはまるポイントがあると感じたので、投稿。

 

背景として書こうとしたコードの説明をする。模擬試験を受けられるサイトがあり、試験結果をCSVファイルでダウンロードできる。これが、1問1行で学習日、分野、正誤のデータを持っている。この過去の試験の正答率の推移を折れ線グラフでプロットしようとした。

自分の持っている地図が合っているか確認する=公式ドキュメントをあさる

プログラミングが少し分かると自分の手持ちでやろうとしてしまう。今回もそこから手順を考えてしまっていた。C#の経験が長く、C#でもうっすらLINQまでで最近の文法はあまり追っていないので、C#をベースに考えそうになった。前回もやりたいことのキーワードをいくつかググってごちゃごちゃ組み合わせたが、けっこう無駄が多かったように思う。

問題となるのは、現在持っている言語の知識が今取り組んでいる言語やフレームワークに適合するか分からないことだ。ググるスキルが上がってピンポイントで調べて、一歩先に進むのが早くても、違う言語なら地図も違うはずで、頑張った末に行き止まりになってしまうこともある。逆に方向性が合っていれば、一発解決の可能性もある。

 

この問題には今回以下の考え方で進めた。グラフに出す場合はどのように呼び出すかでデータの形が決まるので、そこが制約になる。固い制約があれば、そこはぶれないのでロスは少ない。

また、取り組んでいる途中で前にやった機械学習のコースをちょっと思い出した。その動画では講師が何度も公式サイトのドキュメントやサンプルを紹介していたように思う。これは多分意図的で、公式ドキュメントでその言語やフレームワークでのキーワード群を押さえるとググるキーワードがその言語向けに良くなる気がする。まずはキーワード+ライブラリで検索をかけて、ライブラリの公式ドキュメントで関連する部分を探す。そこからブログなどを探すとまずまず良かった。

この問題に長期的に取り組むにはよく言われている毎年1つ新しい言語を学ぶことなのだと思う。ToDoアプリを作ると一通り新しい言語が分かると聞く。ToDoアプリを目的にすると、上のようなその言語やライブラリの特徴を逃しそうな気がする。その言語らしく書くにはどうすればいいかはもう少し調べた方が良さそう。 

機能分割は無意識にやりがちなので気をつける、実現方法は何パターンか考える、具体化は出来るだけ遅らせる

手段を考えるときに思いだしたのが、国際協力の分野での問題解決手法。ゴールを決めて、そのために必要な状態を書くのだけど、ポイントは具体的なアクションではなく、実現したときの状態を書くというもの。

最終ゴール:グラフ表示

サブゴール1:ファイル読み込み

サブゴール2:データを1つずつ読んで、XXXする

ではなく、

最終ゴール:グラフ表示

サブゴール1:ファイルの内容が取得されている

サブゴール2:データがXXXな状態になっている

これは、単に表現の問題のように思うかもしれないが、下の形で考えておくと、1つの手段で詰まった時に代替案を考えやすくなる。 

これに関連して、具体策を探すのは、出来るだけ遅らせるか、すぐに結果が出せるようにするのがいい。あまり詳しくないものを時間をかけて調べると結果が出づらい気がする。これは、下のおもちゃの話に関係する。

おもちゃを用意してこねくりまわす

『アプレンティスシップ・パターン: 徒弟制度に学ぶ熟練技術者の技と心得』では壊していいおもちゃ、すぐに取り換えのきくサンプルコードを用意する。いきなりファイルを読み込んで表構造のデータを作成するじゃなく、ベタうちの表構造データを数件用意するとかがいい。あとは、おもちゃとおもちゃは分ける。検証したい処理が3つあったら、それぞれ別々に簡単に動かせるコードを用意して、動作を確認してから、組み込む。そうすると、一つが使えなかったらすぐにべつの実現方法に切り替えることができる。

コードではなく思考プロセスを振り返る

問題解決手法の中では解決した状態をゴールとして、〇〇が実行されるとはしない。これは手段の目的化を避けるため。目的から手段を考えると、いろんなオプションが考えられる。
こういうプロセスをふりかえるのが大事で、考えはすぐに消えてしまうのでやる前や詰まったときにメモを取ると良さそう。こういうプロセスの改善がパフォーマンスに大きく影響するように思っていて、プログラミングではライブコーディング(練習なしの)やペアプロ、モブプロがそれにあたると思う。ライブコーディングはYoutubeとかを探しても良さそう。