プログラミングを10年以上やってきて役に立ってると思うもの

278, 2020-01-16

目次

プログラミングを初めて14年

プログラミングを初めて実に14年が経った。
私がC言語の勉強を始めたのが20歳ごろだったから、それから数えると今年でプログラミングを始めて14年が経つことになる。
HTML/CSSを考えれば20年以上、コーディングしていることになる。

プログラミングは多種多様な知識が必要とされる。
基本的な、メモリやCPUなどのコンピューターの知識。
それからプログラミング技法の知識。アーキテクチャやデザインパターンなど。
そしてデータ構造とアルゴリズムの知識。
あとはサーバーサイド、シェルやDBサーバーやWebサーバーの知識。
数え上げたらきりがない。

プログラミングの学習は一本の木に例えられる。
始まりはなんてことのない「Hello, World!」だが、それを根にして長く太い幹、そして縦横無尽に分かれていく枝の数々。
こずえ(枝の先)にはプロフェッショナルと言われる人たちがひざ組みをして腰を掛けている。
最終的にはみんなそこを目指しているのだろうと思う。

私はスキルというものは大体10年ぐらいでその人に根を下ろすものだと思っている。
つまり、石の上にも10年。

確かに、初心者のころに比べれば出来ることは増えたが、それでも出来ないことは沢山ある。
しかし、出来ることは出来るようになっている。
その中で、私が勉強して役に立ったと思うことを記事にしてみたいと思う。

役に立たなかったことがあるのか? と問われると、みんな多かれ少なかれ身になっていると答える。
だから今回の『役に立った』というのは『とりわけ役に立った』という意味だ。

まず最初はデータ構造とアルゴリズムだ。

データ構造とアルゴリズム

私は最初にC言語を学んだあとに、やることがなかった。
基本的な文法を覚えて、小さい基礎的な制御文を使ったヒヨコみたいなプログラムを作ってはいたが、特に作りたいものもなかったため、ぼーっと過ごしていた。

言語さえ覚えれば、色んなアプリを作れるようになると思っていたのだが、それは間違いだった。
実際にアプリを作るには、理想や情熱が必要だ。
ほとんどの人はそれらを持っていない。私もその一人だった。
そのため、作りたいアプリも無く、基本的な文法の復習しかしていなかった。

しかし、基本的な文法ばかり書いていても、プログラミングのスキルは上達しない。
じっさいに、上達しているという実感に乏しかった。

そんなときに目にしたのが『データ構造とアルゴリズム』というワードだった。
これは、どこで知ったのかは覚えていない。
ただ、プログラミングについて調べていると、わりとよく見かけるワードだった。

データ構造とアルゴリズムは、汎用化されたデータの構造とアルゴリズムについての知識だ。
計算機科学の歴史は浅いが、その密度は高く、先人たちがさまざまなデータ構造とアルゴリズムを開発した。
これらを使うと、プログラミングにおける問題を効率よく解くことが出来るようになる。
データ構造とアルゴリズムを学ぶということは、そういった先人たちの残した資産を学ぶということになる。

たとえばデータ構造なら配列、スタック、キュー、リスト、グラフ構造、木構造などがそれにあたる。
ソフトウェアの多くは、これらの基本的なデータ構造を使って作られていることが多い。
つまり、これらの構造はそれほど汎用的だということになる。

アルゴリズムはクイックソート、二分探索、ダイクストラ法などがあげられる。
アルゴリズムはある問題を効率よく解決するための手順だ。
たとえばみんな大好き二分探索は、配列から効率よく目的の値を探すことが出来る。

このデータ構造とアルゴリズムは、私がプログラミングをしていく中で、かなり頻繁に利用することが多い。
アプリの設計を考えるときは、アーキテクチャの次にデータ構造からの流用を考えるし、機能を実装しようとするときは使えそうなアルゴリズムは無いか考える。
じっさい、このデータ構造とアルゴリズムを基本的な文法の学習の次に学んで、私は良かったなーと思っている。

もし読者の方が基本的な文法の次に、なにを学べばいいかわからない時は、アルゴリズムとデータ構造を学べばいいだろう。
これは汎用的だし、身に付ければ、アプリ開発の基本的な思考回路になる。

アーキテクチャ

じっさいのアプリ開発はデータ構造とアルゴリズムだけでは構築できないことが多い。
特に規模の大きなアプリは、例外なくそうだと言える。
そういったときに役に立つのが、『アーキテクチャ』の知識だ。

アーキテクチャとは、アプリの設計における土台となるものを指す。
アプリ開発では、このアーキテクチャの上に様々な建造物を建てていくことになる。

有名なアーキテクチャがMVC(エムブイシー)と呼ばれるアーキテクチャだ。
もっともこれは、アーキテクチャではなくてデザイン・パターンだとする意見もある。

MVCModel, View, Controllerという3層構造にアプリを分割し、ビジネスロジック(アプリの核となる仕事)をModelに、見た目の挙動をViewに、ModelViewの連携にControllerを使う。
こうすることでアプリの開発が楽になり、目的に合った処理がそれぞれの層に整理されていくことになる。

MVCGUIアプリケーションでよく利用されるアーキテクチャだ。

たとえばWebフレームワーク、これなどはそれぞれアーキテクチャを持っている。
たとえばRailsはアーキテクチャにMVCを採用しているし、DjangoMVTというMVCの亜種をアーキテクチャに採用している。
つまり、Webフレームワークをどれか一つ学べば、勝手にアーキテクチャの知識が付くことになる。

いわずもがな、Webフレームワークは巨大なツールだ。何十人というプロのプログラマーが何年もかけて育てている。
そのフレームワークの土台となるのがアーキテクチャである。

基本となるのはMVCだ。これを最初に学ぶと良いだろう。MVCの亜種となるアーキテクチャは多いので融通も利く。
HTTPサーバーやクライアントを作りたい場合はクライアントサーバーモデル、CUIアプリケーションを作りたい場合はパイプとフィルターについて調べると良いだろう。
また、Webアプリを作る場合は3層モデルが有用と言える。

分割統治

分割統治という概念は、プログラミングに限らず日常生活のありとあらゆる問題に適用できる、万能な概念だ。
これは、大きな問題を小さな問題に砕いて、各個撃破していくという考えである。

プログラミングでは人間が扱えない規模の大きな問題を扱うことが多い。
普通に開発していても、コード行数が1万行を超えてくると設計上のストレスが多発するようになる。
そういったとき、すべての問題をまとめて解決しようとすると高い確率で失敗する。
そこで分割統治の出番だ。
問題を小さく分割して(どのぐらい小さくするのかというと、個人が解決できる大きさまで小さくする)、そしてひとつずつ丁寧に解決していく。こうするとことで気が付くと、すべての小さな問題が片付き、結果として大きな問題を片付けることが出来るということになる。

この概念はプログラミングでは必須と言っていい。特にアプリ開発では無くてはならない考え方だ。
ぜひとも習得したい。

抽象化

角の出っ張った鋭いギザギザを持つ石ころを、鏡面反射するほどツルツルな丸石に磨き上げるのが抽象化という考え方だ。
先ほどの分割統治と関連が深い概念である。

人間が理解しやすい機能ほど、抽象化のレベルが高く、逆に人間が理解しづらいほど抽象化のレベルが低くなる。
たとえば

  • 家を出る
  • コンビニに向かう
  • 牛乳を買う

という処理は

  • コンビニで牛乳を買う

という一行に抽象化することができる。
具体的であればあるほど、処理という物は把握しづらくなり、抽象化のレベルが下がる。
これはプログラミングでも同様だ。
そこで処理を把握しやすくするために抽象化を行う。
これによって機能のメンテナンス性が上がり、最適化するとモジュール化まで出来るようになる。

しかし、抽象化は失敗しやすいアプローチだ。
そのため、効率の良い抽象化にはプログラマーの経験と勘が求められる。
AIでプログラミングを自動化するなら、この抽象化が高い壁となるだろう。もっとも、AIのプログラミングには抽象化など必要ないかもしれないが……。
要するに、人間の専売特許である。個々人のスキルの差が如実に表れるので、腕の見せ所と言っても良い。

ひとつやっかいなことに、極限まで抽象化された機能というのは、逆に使いづらくなることがある。
これは不思議な話で、いわゆる抽象化には「丁度いい」レベルがあると私は思うのだが、この辺は人によるのかもしれない。

テスト

アプリケーションの開発を助けるのがテストだ。
これを知ってて行うプログラマーと、行わないプログラマーとでは、作れるアプリケーションも違ってくる。
それほど、テストというのは開発を飛躍的に補強できる。

日本ではテストを行う開発者はテスターと呼ばれ、立場を低く見られる傾向があるようだ。
しかし海外ではテストエンジニアは専門職として確立されているらしい。

私は日本もその内、テストエンジニアを重視する傾向になっていくと思う。
テストはアプリケーションのおまけではなく、アプリケーションの一部だ。それほど重要なものだと言える。

なぜこんなことが言えるのかと言うと、私は独自プログラミング言語の開発をしていたことがある。
Capというアプリケーションにテンプレート言語を実装していた。

最初はテストを行わない開発をしていた。そのためか、進捗があまり良くなく、頓挫を繰り返していた。
しかしテストを導入すると、開発が圧倒的に楽になり、もはやテスト無くして開発は出来ないという感触を得るまでに至ったのである。
この経験から私は、テストは開発の一部であるという認識になった。

複雑なアプリケーションを作る場合は、ぜひともテストを導入しよう。
まぁ、GUIアプリのテストはしんどいけど。

リファクタリング

アプリケーションの健康状態を維持するのがリファクタリングである。
リファクタリングは、テストと関連が深いテクニックだ。
出力結果を変えずに、中身を整えて綺麗にするのがリファクタリングである。人間でいうデトックスだ。

規模の大きなアプリケーションでは必須と言えるテクニックである。
これをやらないと、高い確率でアプリケーションが破綻する。

リファクタリングを行う場合は、テストをしっかり書かなくてはならない。
なぜならテストは出力結果を保証するからだ。
テストを書くことで、安心してリファクタリングを行うことが出来る。

さしずめリファクタリングを行うプログラマーは、外科医か内科医かメンテナーか。
アプリの健康状態が気になる、または、アプリがよく破綻するという人は、リファクタリングを導入してみよう。

おわりに

振り返ってみると、この10何年で生き残ったノウハウはそれほど多くない。
しかし、ここまで書いてきたものはどれも重要だ。
プログラミング初心者の方は、やることが無かったら、これらのことを勉強してみるといいだろう。

目指せスーパーハカー

おしまい

Webアプリケーションの制作ならNARUPORT

Webアプリケーションの制作ならNARUPORTにお任せください。
Webアプリの他にもGUIアプリやChromeExtension, スクリプトの制作など可能です。
以下のお問い合わせフォームからご依頼ください!

投稿者名です。64字以内で入力してください。

必要な場合はEメールアドレスを入力してください(全体に公開されます)。

投稿する内容です。

スポンサーリンク

スポンサーリンク

スポンサーリンク

スポンサーリンク