検索
連載

1つの解決策を永続的な決定とするのは無理がある――曳光弾とプロトタイプ、ユーザーからのフィードバック問題解決力を高めるコツはプログラミングの原則・思考にあり(7)(3/4 ページ)

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。プログラマーは唯一の最終決定解を求める傾向にある。しかし最終決定などというものは幻想で、存在しない。いたるところに常に変化は存在する。今回は「曳光弾」「プロトタイプ」によって早くユーザーからフィードバックを得ることの重要性をお伝えしよう。

Share
Tweet
LINE
Hatena

UNIX思想(15) 最適化の原則

 英語  Rule of Optimization

 What 〜速いコードより正しいコード

 プログラミングにおける最適化とは、パフォーマンス・チューニングを行うことです。動作スピードを上げたり、メモリやディスクスペースなど、マシンリソースの使用を効率化したりします。

 ただし、プログラミングにおいては、コードを最適化する前に、正しく動作するコードを書くようにします。

 十分に動作するものがない段階で、細かいところを磨いていくことには意味がありません。ごくわずかの成果のために、多すぎる時間を注ぎ込むことになります。

 Why 〜早い段階での「速いコード」は設計を破綻させる

 正しく動作する前に最適化に走ることは、コードの設計を台無しにすることです。

 なぜなら、この時点で最適化にこだわると、以下の問題が起こるからです。

  • 透明性や単純性が犠牲になる

 コードが無理なものになったり、コードの内部構造がわかりにくくなったりすると、多くの障害を生み、その障害は莫大な時間を浪費します。そうしてまで得られるものはと言えば、障害のデバッグにかかる時間と比べてはるかに価値の少ない、微々たる高速化や、リソース使用量のわずかな節約に過ぎません。

  • 部分に対する半端な最適化が、全体の最適化の妨げになる

 半端に最適化すると、全体に渡る大きな効果が得られる最適化ができなくなります。その結果、パフォーマンスが低い上に、必要以上に複雑なコードが残ることになります。

 How 〜正しくしてから速くする

 まず動かし、正しくしてから、速くしましょう。この順番でプログラミングすることを肝に銘じてください。

 最適化より前に、最適化されていない「遅くて、リソースを大量に消費するが、正しく動作する実装」をしましょう。少なくともこの時点では、コードの複雑度を上げないようにして、シンプルな状態を保ちます。その後、大きな効果が得られるところを体系的に探し、最適化を行ってください。

 コードが単純であれば、この探索は容易です。

 発展 〜プロトタイプで最適化

 まず動くプロトタイプを作ることは、最適化の観点からも効果的です。

 プロトタイプを使うと、「コードを書かなくて済む機能がわかる」という学習効果があります。コードを書かないことは、パフォーマンスを上げることに貢献します。書いていないコードは、最適化しなくても済むからです。

 「もっとも強力な最適化ツールは、削除キーである」「もっとも生産的な日は、1000行のコードを捨てた日だ」という、皮肉めいた格言もあるほどです。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る