アルゴリズムを考える手順と評価方法について教えてください。 ある課題があり、それを解くアルゴリズムはどのような手順で考えますか? そして良いアルゴリズムを評価する方法を教えてください。 例えば ・フローチャートを紙に書いて考える等。 評価方法は、 「速度」ならベンチマークを計測したり、 「シンプルさ」なら可読性を計測したり、 可読性の計測方法は「コードレビュー」でしょうか。 宜しくお願いします。
>アルゴリズムを考える手順
UMLをかいて考える
UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方平澤 章
うーん、case by case ですね。
業務フローが明らかになっているものであればUMLで考えますが、データ解析であれば方程式をそのままプログラム化したり、フローチャートに起こしたりします。
評価も case by case です。
参照回数の多いアルゴリズムであれば、速度優先で評価します。
参照回数が少ない、とくに例外ケースで参照されるようなアルゴリズムであれば、速度より安定性を重視します。速度的に無駄だとは分かっていても、検算を組み込む場合もあります。
いずれにしても、そのアルゴリズムが対象とすべき全て場合を網羅しているかどうか、耐障害の領域(定義域外)をエラーとして弾くかどうかは最低条件になります。
私の場合、人間ならどのような順番でどのように計算しその問題を解くかを考えます。
そして、そのままプログラムにします。
このとき、まとめてみたり、はしょったりしないよう心がけています。
特に、人間だったらそういう風に考えないだろうというような、いかにもコンピュータ的な考え方をしないのが重要だと思っています。
考え方が人間的であればあるほど評価もし易いです。
スピードが必要なら、それをベースに効率化できるところを検討していきます。
満たすべき条件をまず考えておきます。
速度、開発コスト、信頼性、テストしやすさ、プログラムサイズ、
複雑さ、他の部分との整合性・統一性、拡張性。
その範囲内で、可能な限りシンプルに、可能な限り高速に、
など加減を見ながら、できるだけ沢山の候補の中から
一番よいものを選ぶことになるでしょう。
もちろん開発期間の範囲内で。
その候補の中には、既存のライブラリ(標準API、OSSライブラリなど)
にあるならそれを利用することも、含めておいても良いときもあるでしょう。
ライセンス条件なども当然考慮の上でです。
非常に大きなプログラムの場合、
適当な紙にPADのようなものを書いて頭の中を整理しますが
大抵はプログラムを入力しながらアルゴリズムを考えます。
考えながら書いて行けばフローチャートを作る時間が省けますからね。
評価は、一般にキチガイや馬鹿と呼ばれる人に1日中触ってもらって
問題が起きないかどうかで決めています。
個人的にはアルゴリズムに落とす前のモジュール/クラスの分割統治が厄介
そして、自分でまともなものになったと思っても
他人にとっては納得いかなかったり、後で致命的な失敗に気づいたり...
設計は面白いが、変な設計をするとチームを地獄に叩き落す刃となる