Q&A
細かい誤字ですが、”自身”喪失だと事件ですよ。
最近は、コードリーディングが遅いと感じていて、自信喪失しています。そこで思いついたのが、クラスの設計やコードのデザインパターンを見抜ければ、全体を把握するのが早くなり、コードリーディングが早くなるのではないかと思いました。
例えば、以下のリポジトリのコードの全体像を把握したいです。どのデザインパターンに当てはまると思いますか？
また、どのように全体像を把握していけばよいのですか？どのように勉強してきましたか？クラス設計の理解の助けにある教材やツールを何かご存知でしょうか？
皆さまの意見のtipsから以下のようなロジックで理解していければと思っています。
このクラスは、こんな役割で全体としてこのようなモジュールの役割をしていて、このパッケージはこのためにあり、このパターンはだいたい、こんな感じで書かれる → すでに発掘されている〇〇デザインパターンに当てはまる。→ そのデザインパターンを学ぶにはこの教材がいい。このツールを使うと作りやすい。
コードリーディング対象のリポジトリ
https://github.com/dpgaspar/Flask-AppBuilder/tree/master/flask_appbuilder
すでに、以下の教材はさっと目を通しましたが、どんなときに使えるのか理解できていません、正直、「へーそうなんだ」で終わっています。
https://github.com/faif/python-patterns
Effective Pythonもざっと目を通しましたが、コード設計の全体像を読み取る能力向上には、あまり役立たないように思えます。
そもそも質問者さんは「このデザインパターンだ」とわかれば何とかなるくらいの技術・知識をお持ちなのでしょうか？それで何とかなるならデザインパターンはそもそも基本形なので、全体を見ればどのパターンか見当つきそうなものですが。
回答4件
0
Pythonは畑違いなので具体的な内容には触れられないのですが、ちょっと思ったことを。
逆じゃないですか？
デザインパターンをはじめとした様々な「手法」は、いろんな物作りの過程を繰り返す中で、パターン化されたものを体系的に整理してモデルにしたものです。作る人も、
- 何かを作ろうとする
- 作り方を検討する
- 過去に使ったあのケースに類似してる
- 適用してみる……うまくいった。これでいこう
という流れでパターンを組み込んでいると思います。まずはその流れをあなた自身が追うという経験を何度繰り返し、パターンに当てはまる場合、当てはまらない場合、どういう場合にどのケースが使えるかといったことを経験して初めて、「この場合はこういうケースが使える」ということが読めるようになるかと。それを何度もやっていくと、本来そのソースがやりたかったことを汲んだ上で「こういう場合はこのパターンが使えるけど……あ、やっぱりね。やってるね」みたいな感じで使っているデザインパターンや手法を読み取れるようになるんじゃないでしょうか。
世の中のプログラムはすべていずれかのデザインパターンでできているわけではありません。特定の場合、条件を満たす場合に、いつものやり方が採用できる、というだけで、実際は全くそういうものを使っていなかったり、部分的に使ったり、アレンジしたバージョンだったり様々です。
なのではなから「どのパターンですか？」という見方でソースを読もうとすると、そもそもそのソースがやりたいことを見ずに、パターンにマッチする部分を探す「もしかしたら正解がないかも知れないパズルゲーム」になってしまいます。結果、時間がかかる……。そんな風になってませんか？
冒頭に書いたように、物作りを繰り返す中で何度も出てくるケースをまとめたモノがデザインパターンですから、デザインパターン本を何度読み返しても、「はぁ、まぁ、そうだよね」としかなりません。いわば建築手法の本、柱や木の削り方、組み合わせ方だけを学んで、「で、これってどこで使うの？」となっているようなもの。
実際に作る経験をもっと積んで、そのデザインパターンや手法がいかに便利で、筋の通っているモノであるかを実体験することを繰り返された方が良いように思います。
見当外れの回答かもしれませんが参考になれば。
投稿2019/01/29 01:00
総合スコア534
おっしゃる通りです、本来なら帰納的に学習するべきですが、演繹的にばっと当てはめることもできないのも理解しています。ただ、本当にそういうものなのか、という部分に自信がもてず、投稿しました。ありがとうございます。
0
まず、「最初からコードを読むもんじゃない」「他人の書いたコードは所詮他人が書いたコード」というのがtipsの筆頭になります。あとは私がどの様に対象のリポジトリを見ていったのかをちょっとだけ記載します。
URLを開く
まず以下の画面で私は「多い」と思って中を見てみようという気が失せました。
READMEに移る
READMEを見るとちゃんとドキュメントへのリンクがあったので少し安心しました。
Documentationを開く
ドキュメントを眺めるとIntroductionやInstallationに加えてexampleやDemoも準備されているので、そこら辺は最低でも読んである程度理解しておかないとコードなんて読めたもんじゃないだろうなと感じました。
投稿2019/01/29 01:03
総合スコア6142
0
ベストアンサー
ほぼほぼ、backyardさんが言いたいこと書いてますので端的に。
ソースリーディングが遅いのは、自身の問題以外にソースそのものに問題があるケースもあります。
※当該リンクのソースは見ていない
デザインパターンを見抜ければ、全体を把握するのが早くなり
そんなことありません。
このクラスは、こんな役割で全体としてこのようなモジュールの役割をしていて、このパッケージはこのためにあり、このパターンはだいたい、こんな感じで書かれる → すでに発掘されている〇〇デザインパターンに当てはまる。→ そのデザインパターンを学ぶにはこの教材がいい。このツールを使うと作りやすい。
backyardさんの指摘の通り逆じゃないですか？
デザインパターン自体は、GoF以外にもいっぱいありますし、知らないだけで使ってるパターンもいくつもあります。
ただ、その用途（問題と解決）について理解してつかってない人もたくさんいます。
デザインパターンを学ぶならソースよりも、デザインパターン本を読むのがいいです。
で、ソースリーディングするにあたってクラス図のリバースが理解を早めることになると思います。
Python専門外ですが、Epydoc、Pyreverseなどのツールがあるようです。
投稿2019/01/29 01:49
総合スコア4820
momon-gaさんの意見がまさに確認したいことでした。ありがとうございます。
> で、ソースリーディングするにあたってクラス図のリバースが理解を早めることになると思います。
Python専門外ですが、Epydoc、Pyreverseなどのツールがあるようです。
これが特に知りたかったことでした。
0
「以下のリポジトリのコードの全体像を把握したいです。」のあとに「どのデザインパターンに当てはまると思いますか？」と書いてある時点で破綻してると思いますが、、、リポジトリ丸ごとに当てはめるようなものでしょうか、デザインパターンって。
「わからないところがわからない」状況なら、まずはどこでつっかえているのかをちゃんと明らかにしましょう。
投稿2019/01/29 01:29
総合スコア30933
> 「以下のリポジトリのコードの全体像を把握したいです。」のあとに「どのデザインパターンに当てはまると思いますか？」と書いてある時点で破綻してると思いますが、、、リポジトリ丸ごとに当てはめるようなものでしょうか、デザインパターンって。
とてもいい指摘ありがとうございます！モジュールの依存関係の把握とコード設計の理解の二つの問題が私の頭の中でごちゃごちゃになっていたのだなときづきました。それらがコードリーディングに影響するのだと理解しました。
あなたの回答
tips
プレビュー
