blog.kur.jp

バイオリンと山、自転車をこよなく愛するkurのチラシの裏。たまには技術的なことを書いたりするかも知れません。

身も蓋もないが本当に有効な「コードの書き方」

インターネットをぶらぶらしていたら,こんなエントリを見つけました.

身も蓋もないが本当に有効な「企画書の書き方」

身も蓋もないが本当に有効な「論文の書き方」

これって実は,どんな業界にも通じるところがあって,それはたとえばプログラマでも例外ではないと思うのです.なので,良いプログラムを書くために大事なことって何なんだろうって考えながら,私も真似して書いてみます.

前例を重視する

アルゴリズムについて

ソフトウェアの機能には独自性を求められますが,その機能を実現するためのアルゴリズムには独自性を求められません.むしろ、独自性が高いアルゴリズムばかを採用し,前例にしたがっていないプログラムはダメなプログラムであるとみなされる傾向にあります.

たとえば,セキュリティを向上させるために独自の方式を実装しましたとか,データをソートするために独自アルゴリズムを実装しましたとか,自慢気に話してくれる人がよく居るのですがこれはナンセンスです.セキュリティを重視したいなら用途に応じてAESとかRSAとかを素直に使ってくれたほうが安全です.なぜなら世界中の世界中の数学者・暗号学者がAESの脆弱性を探すことを仕事にしているにも関わらず,決定的な解読方法が見つかっていないからです.独自暗号の安全性の根拠はどこにあるのですか?ソートにしたって,素直にクイックソートでも使ってくれたほうが,思いつきで実装してくれたソートよりも早いことが多いです.もちろん,データの性質にもよるので,一概には言えないのですけれど.

なので,プログラムを書くときは似たようなアルゴリズムが存在しないかを探し,どういったアルゴリズムを自分で開発する必要があるかを見極めることが重要です.

ユーザーインターフェースについて

ときたま,とんでもないインターフェースを実装する人がいたりします.

ワードでもエクセルでも多くの画像編集ソフトでも,何らかのデータをコピーしたいときは,ctrlキーを押しながら,cキーを押すことでショートカットが使えます.でも,実装の仕方によっては,ctrl+vでコピーctrl+cでペーストの機能を実装することもできます.でも,こういった部分はなるべく前例を重視しましょう.ユーザを戸惑わせるだけだからです.

ユーザインタフェースのボタンにしても,スクロールバーやプルダウンメニューや,チェックボックスや,ラジオボックスなど,できるだけ既存の,広くつかわれているものを流用すべきです.奇抜なインターフェースが本当に使いやすい場合ってのもあるんですが,滅多に無いと思っていいと思います.スクロールバーやプルダウンメニューの使い方に戸惑うユーザって,そんなんいませんよね.

既存のプログラムを間接的に評価するようなことは書かない

新しいプログラムを書くのですから,何らかの目的があると思います.でも,その際に,既存のプログラムを批判するのはやめたほうが良いです.

何故かというと,コンピュータの世界は日進月歩です.既存のプログラムが書かれた時代と現在では,時代背景や環境が根本的に異なる場合があります.

高速なCPU,大容量・高速メモリ,大容量記録装置,高速ネットワークが珍しくなった昨今,ソフトウェアで実現できる可能性は桁違いです.既存のプログラムが書かれた際の環境を理解しましょう.

また,ターゲットを限定し,機能を削減すればプログラムが高速化するのは当たり前だと考えてください.何の自慢にもなりません.

ユーザの流行をとらえる

たとえば最近の流行だと,AjaxなWebアプリ,iPhone等向けのケータイアプリだとかでしょうか.

ソフトウェアを使うために,Windowsにインストールしなければいけないというだけで躊躇するユーザはかなり多いと考えましょう.また,多くの人には信じられないことかもしれませんが,最近は情報工学の学生であってzipやlzhといったファイルの解凍方法を知らないユーザが多く居ます.

じゃぁ,インストールせずにアクセスするだけで利用できるWebアプリなら良いのかというとそういうわけでもありません.いまどき静的なHTMLのみで構成されたWebアプリも,ユーザによっては古いと感じられてしまうかもしれません.

そして当然ですがコマンドラインアプリなんて開発して公開したところで,誰にも見向きされない可能性が高いです.

長く書く

プログラムを長く書くことは大事です.

開発期間的な意味

バグのないプログラムを最初から作り上げるのは一般的に不可能です.また,長期間にわたってプログラムを開発することによってユーザが増え,ユーザからのフィードバックを得ることができます.

これによってユーザの求める機能が見えてきますし,自分自身のモチベーションにもつながります.

可読性的な意味

プログラムの容量を減らすために,1byteに命をかける人たちが居るのは事実です.

しかしながら多くのそのようなプログラムは,可読性的な意味でマイナスであることが多いです.

他人が書いても容易に理解できるプログラムを書くように心がけましょう.三日後の自分は他人です.

経験的な意味

一般に,プログラマの技術はある程度経験に比例する気がします.多くの良質なプログラムを書くことで,一流のプログラマに成長できる可能性があるかもしれません.そういう意味では,私はまだまだです.

さいごに

と,ここまで書いてみたわけですが,実はこれ,半分ぐらい私自身への戒めのつもりで書いています.

プログラムを書く上で注意しなければいけない点は多いのですが,ついつい「俺Sugeeeeee!」状態になってしまって,他のことが見えなくなってしまいます.

常にまわりを見ながら,よいプログラムを書けるようになりたいもんです.