写経と言っても、仏教の経文を手で書き写すことではありません。それに似た行為ですが、本に書かれたソースコードなどを、コピペではなく、手で入力し、動かす行為を指します。
習作は、アプリを作るのが目的というよりは、新しい言語やライブラリに慣れるためにコードを書く行為です。
これらはプログラミングの練習としては大切なことです。
写経は人によっては無意味に感じるかもしれませんが、意義のあるものです。
どんな分野でも上達するためには1万時間が必要だという説が提唱されています。皆さんもおそらくこれに類似した話を聞いたことがあるでしょう。
元ネタの論文1では、1万時間はあくまで目安というか平均値に過ぎないこと、ただぼーっと1万時間を過ごしても意味が無いこと、そもそもこの論文で示してる領域までたどり着く必要があるとも限らないことは気をつけなければいけません。
さて、1万時間の真否はさておいて、プログラミングにおいても、ある程度はソースコードを書かないと上達のしようがないことは確実でしょう。
写経は、まだソースコードを書き足りない人が、実際にソースコードを書くことで体で覚えるという側面があります。
上級者においても、慣れてない言語などでは意義があることです。
写経は単に書いて動かすだけではなく、書いて動かしたものを改造して、それがどういう意味合いのものなのかを掘り下げる起点として使えます。
パラメータを変えたらどうなるのか?処理を削ったらどうなるのか?処理を追加すればどうなるのか?
プログラミングにおいては、あるインターフェースが提供する機能について、もっともミニマムなところを理解すべきです。それができていない人は、ソースコードを書けば書くほど、そこに余分な技術的負債が積み重なり続けるからです。
習作するときは、すでに過去に自分が作ったことがあるものを題材にすることを強くおすすめします。
なぜなら、新しい言語やライブラリにチャレンジすることが目的なのに、新しいものを作り上げようとすると、同時に2つ以上の課題にチャレンジすることになり、習作という行為そのものの質を大きく下げるからです。
あなたが人類史上稀に見る天才でもなければ、同時に複数のことをすべきではありません。
常日頃から習作に向いた題材を用意しておくと、新しい言語やライブラリ、環境に慣れる足がかりになります。
チャットアプリや掲示板アプリ、chat botなどはそういった題材に向いているかもしれません。人によってはもっと違う自分向きのものもあるでしょう。
cyber-dojo2は、さまざまな言語やテスティングフレームワークで、用意されたお題にチャレンジできるサイトです。
I'm on my own
を選び、
create a new session
を選び、
言語、テスティングフレームワークと、お題を選びます。
この例では、C言語でFizzBuzzを解くというものです。
基本的には、このCyberDojoではTDDによりお題にチャレンジするサイトですし、プログラミング上級者を目指すのであれば、TDDによって適切な設計、関数分割などを行えるべきですが、TDDに慣れていなければ、そうする必要はありません。
プログラムは、ただ書けば良いというものではありません。 仕様や要件を満たすプログラムを開発することはもちろんですが、ここで重要となるのが非機能要件です。
非機能要件とは、機能要件を除く全般の機能のことを言います。 たとえば、次の項目があります。
- 性能
- 信頼性
- 拡張性
- 運用性
- セキュリティ
- ...etc
この中で、とくに日々のプログラミングにおいて意識したほうが良いのは、パフォーマンス(性能)とセキュリティです。
競技プログラミングとは、プログラムを記述して時間内に問題を解く競技です。 代表的なサービスに、TopcoderやAtCoderがあります。
- Topcoder: https://www.topcoder.com/
- AtCoder: https://atcoder.jp/
- AIZU ONLINE JUDGE:: http://judge.u-aizu.ac.jp/
競技プログラミングでは、メモリーの使用量やプログラムの実行時間に一定の制約があります。 たとえばAtCoderでは、実行時間制限2secといった制約が、問題ごとに課されています。
ABC087B - Coins
実行時間制限: 2 sec / メモリ制限: 256 MB
問題文
あなたは、500円玉を A 枚、100 円玉を B 枚、50 円玉を C 枚持っています。 これらの硬貨の中から何枚かを選び、合計金額をちょうど X 円にする方法は何通りありますか。
https://atcoder.jp/contests/abs/tasks/abc087_b より
パフォーマンスを考えずに記述すると、実行時間制限をオーバーしてしまうこともあるため、競技プログラミングでは必然的にパフォーマンスが重要となります。
動作の遅いアプリやWEBサイトでは、利用者のストレスとなってしまい、離脱率も上昇してしまいます。 パフォーマンスを意識することは、非機能要件を満たすプログラムを目指す一歩となります。
筆者は「プログラミングコンテスト攻略のためのアルゴリズムとデータ構造」という書籍で、競技プログラミングの学習をしています。 ここでは学習の過程で、ソートや探索といった基本アルゴリズムを学ぶことができます。
- バブルソート
- 選択ソート
- 線形探索
- 二分探索
- ...etc
アルゴリズムについて、情報工学や情報基礎といった学問的なイメージを持たれている方も多いかもしれません。 しかし進化の早いIT業界では、時代に流れされない息の長い根本的な知識を身に着けておくことは、とても大切です。
ISUCONとは、"Iikanji Speed Up Contest"の略称です。
お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。 http://isucon.net/ より
競技プログラミングは、C++などのプログラムを提出する形式のコンテストですが、isuconではWEBサービス全体が対象となります。 つまりサーバーやデータベースも含めた、全体最適化を目指すのがISUCONです。
ISUCONは個人で練習することもできますが、チーム戦なので会社でチームを組んで参加することもオススメです。
SECCONとは、情報セキュリティをテーマに多様な競技を開催する情報セキュリティコンテストイベントです。
情報セキュリティをテーマに多様な競技を開催する情報セキュリティコンテストイベントです。
実践的情報セキュリティ人材の発掘・ 育成、技術の実践の場の提供を目的として設立されました。 https://www.seccon.jp/ より
どんなに使いやすいアプリケーションや早いプログラムであったとしても、セキュリティを満たしていないと脆いプログラムになってしまいます。
まずは最低限のセキュリティ知識を身に着けましょう。 これにはIPA(情報処理推進機構)の安全なウェブサイトの作り方といった資料が参考になります。
- 「安全なウェブサイトの作り方」
- https://www.ipa.go.jp/security/vuln/websecurity.html
ソフトウェア世界の一部の人たちには「車輪の再発明をするな」という信仰があります。
何かのゲームに自信がある人でも、Twitterで「オレは最強の○○ゲープレイヤーだ」とツイートするなんてことはできません。世界大会で優勝するようなチャンピオン3でもなければそのようなツイートをしても、失笑を買う、反感を買う、クソリプが付く、スルーされる、生暖かく見守られるなどという寂しいことになります。
Twitterを見ると、ゲームプレイで飯を食ってるプロもいれば、超絶技巧をYoutubeにアップロードする音楽関連の人もいますし、大学教授や、さまざまなジャンルのスゴイ人ばかりです。
SNSが流行るより前ならば、「オレは最強だぜ!(店のトップ)」「オレは最強だぜ!(学校のゲーム大会の優勝者)」くらいの人は星の数ほどいました。
ソフトウェア開発でもまったく同様です。狭い範囲でなら少しでも自信を持てたのに、今の時代GitHubやQiitaその他、自分の実力と、世界最高峰の実力の差が分かる機会が増えてしまいました。
筆者はこれはあまり良くない側面があると思っています。
何かを上達する為には、猪突猛進で「オレTUEEEEEEE」くらいの気持ちを抱いている方がよい時もあります。その後で鼻っ柱を折られて、そこからまた立ち上がるようなこともあるでしょう。
今のインターネットは、あまりにも最高峰が可視化されすぎていて、「これから」という人の意欲をそぎすぎています。
車輪の再発明は、ソフトウェア開発シーンで特に非難されるものです。
「広く受け入れられ確立されている技術や解決法を知らずに(または意図的に無視して)、同様のものを再び一から作ること」を意味する。新たな付加価値が何もないものを作成するのにコストをかけることから、皮肉的なニュアンスで用いられる。再発明を行ってしまう理由としては、「既存のものの存在を知らない」「既存のものの意味を誤解している」といったことが挙げられる。主にIT業界、とくにSEやプログラマの間で良く用いられる。 たとえば、論文を書くとき、マーケティングで新商品を開発するときには、既存のリサーチは必須であり、新規性は何か、勝負を仕掛けられる根拠、そういったものが必要になります。
ところが、万事全てそれでいいかというとそうではありません。
どんなに世界でスゴイ人がスゴイことをしていても、車輪の再発明を恐れて、既存のものには手を付けない、せいぜい改良に手を出すというだけでは、ソフトウェア開発は停滞するでしょう。
筆者も貴方もまだ世界の最高峰には勝てないかもしれませんが、ソフトウェア開発なんてまだ発展途上のものです。一昔前の常識が覆るということが毎年さまざまなところで生じています。
少しだけ鈍感になってもいいと思うのです。HRT(謙虚・尊敬・信頼)は忘れずに、でも世界最高峰や日本最高峰、あるいは日本のスゴイ人たちのことを忘れて、本当に自分がしたいこと、できそうなことをやってみるべきです。
ちなみに車輪の再発明には利点があります。再発明する前よりも、車輪、つまり再発明する対象について、詳しくなれることです。
再発明をしてない、机上の空論のスゴイ人よりも、詳しいというと、ものすごく大きな利点があると思えませんか?
今の時代はあらゆるジャンルで強い人、スゴイ人、そういった人が可視化されすぎています。これは人々の成長を妨げるものでもあります。
再発明を恐れないことで少しでも成長してみませんか?
「車輪の再発明をするな」なんて小賢しいことをいう人たちの言葉なんて忘れましょう。SNSのスゴイ人たちを見過ぎて車輪の再発明を恐れたりしないようにしましょう。
車輪の再発明には、その対象について詳しくなれるという大きな利点があります。
ソフトウェア開発のスゴイ人のスゴイ度は、たとえば格ゲーチャンピオンたちよりほどのスゴイ度ではないかもしれません。一部の人を除けば、スゴイ人として認識されている人にも、勝てる方法はいくらでもあるかもしれません。
今の時代、少しくらい鈍感になる方がいいでしょう。下手に日本や世界のスゴイ人たちばかりを見ていると、成長のチャンスを失います。猪突猛進で再発明をする人の方が、成長できる時代です。
もちろん、プロダクトコードで、車輪の再発明をする場合、注意深くなるべきです。せっかく既存の素晴らしいもの(大抵の場合はOSS)があるのに、わざわざ車輪の再発明をすると、メンテナンスリソースの分散が生じるからです。
とはいえど、既存の素晴らしいものには、既存の面倒なしがらみがあることもしばしばです。OSSの良さは、気に入らなければ自由にforkできることです。これはOSSの寿命を事実上無限にすることもできるものです。
アプリケーション開発においては、最低限の非機能要件を満たすことが必須となります。 これらは普段の開発で意識的に取り組むほか、競技プログラミングやコンテストの参加によっても、鍛錬できます。
習作することによって非機能要件を高めるという選択肢、ぜひ挑戦してみてはいかがでしょうか?
Footnotes
-
https://royalsocietypublishing.org/doi/10.1098/rsos.190327 ↩
-
世界大会で優勝するような人でも最強を名乗るかというとそうでもないでしょう。次の大会で最強のままいられるか?というと大変です。 ↩