はじめに
「世界に通用する強い技術者になりたい」
を目標に、日々奮闘中の方も多いのではないでしょうか。
自分もその一人で、技術や知識より大事なものについて、
自戒の念を込めて、思うがままに書いてみることに。
考える力って?
問題解決に向けた、切り口や発想、お作法などでしょうか。
モノづくりの哲学みたいな独自の信念も含まれているような。
運よくOracle ACE(日本に数名?)のAさんと仕事ご一緒したことあります。
OSやカーネルなど精通し、その技術力はいろいろ学べるものがありました。
ただし、技術や知識より感銘を受けたのは、課題解決における考える力。
Aさんと仕事した中で感じたものを思い起こし、羅列してみます。
難題にぶつかったら、三つ以上案を出してみる
思いつく案を、とにかく三つ以上書いてみる。
そして、それぞれのメリット・デメリットを分析/比較。
| 案 | 内容 | メリット | デメリット |
|---|---|---|---|
| 1 | XXX | ... | ... |
| 2 | YYY | ... | ... |
| 3 | ZZZ | ... | ... |
| ... ... |
単純比較なら二つの案でも物足りる気がしますが、
二者択一では、ベスト案を見逃す可能性が高いとか。
ソースコードは、美しさを追究する
Aさんのソースコードを読んでいると、アート作品に見えてきます。
ロジックのみならず、コードの簡潔さやコメント1つもとことん追究する。
わかりやすい、
無駄がない、
読んでいて気持ちいい、
その故、バグを生みにくい。
基本を大切にする
コーディング上の疑問は、公式ドキュメントや書籍を読み返し、徹底的に理解する。
例えば、通信プロトコルを使用する場合、RFC定義を注意深く理解し、根拠とする。
作業効率を追究する
世に存在する部品は作らない(車輪の再発明をしない)。
自ら作成した新機能は、再利用できるように部品化しておく。
手動テストをしない、自動化するかテストツールを駆使する。
テストツールがなかったら、時間をかけても自前作成する(将来的にコストダウンにつながる)
設計は、デザインパターンを意識する
Wikipediaからデザインパターンとは
- ソフトウェア開発におけるデザインパターンまたは設計パターン(design pattern)
- パターン(pattern)とは、型紙（かたがみ）やひな形を意味する
- 過去のソフトウェア設計者が発見し編み出した設計ノウハウ
- 蓄積したノウハウに名前をつけ、再利用しやすいように特定の規約に従ってカタログ化されたもの
製品リリースに含める機能は、欲張らない
プロジェクトによっては、お客様からさまざまな機能を要求される。
開発者自身が、気に入った機能を付けたくなる場合もあります。
ただし、ここは欲張らず、コア機能に徹すること(特に初版リリースは)。
痛くも痒くもない機能を詰め込むと、肝心な基本機能が疎かになってしまうので。
OSS(オープンソースソフトウェア)からヒントをもらう
GitHubなど公開されているOSSは、プログラミングの教材でもあります(例えば、Python自体のCコード)。
Aさんも、OSSに着目し、そこからいいヒントをもらっていました。
もちろん、Aさん自身もGitHubに有益な成果物を発表していました(それがOracle ACE推薦につながったとか)。
おわりに
Aさんとの雑談で、週末は趣味で何かされましたか、と聞きました。
答えは、いいアイディア浮かんだのでプログラム一本書いたよ、と。
趣味を仕事にでき、コードを書くことが楽しくてたまらない、
これこそ、最強で幸せなエンジニア人生と感じた瞬間でした。