はじめに
この度株式会社Works Human Intelligenceにエンジニアとして新卒入社しました。
新卒社員研修の一環としてQiitaの記事を投稿させていただきます。
本記事の内容
自分が初めてチャレンジした「英語技術書による学習」に関して、役立った考えやコツのようなものをいくつか共有させていただきます。
今回は技術書を読み進めながらDBMSを実装しました。学習に使った本は「Database Design and Implementation: Second Edition」というものです。自作DBMSに関するコンテンツは日本語のものもいくつか存在するようですが、
- 自分が現在学習しているJavaで解説されている
- 実装部分だけでなくDBMSやDB全般の基礎的な知識を解説している
という観点から、英語で書かれているというデメリットをメリットが上回ると考え、この書籍を選定しました。
(他の参考書など ニッチ？な分野であり、そもそもあまり存在しなそうでした)
Rustで実装するもの
Goで実装するもの
注意点
- タイトルに「自作DBMS」とありますが、本の内容に関する話にはそこまで言及せず、初学者が英語の技術書にチャレンジした際に役立ったことという点にフォーカスして記事を書いています
- 全体として内容が「ソースコードの記載がある技術書」に寄った内容となっている点をご了承ください
- 筆者はあまり英語が得意ではないので、その点をご了承いただきたいです。英語が苦手だが日本語で良い本が見つからないという方に向けた記事となっているため、英語が得意な方やそもそも英語自体を学習したい方には向かない内容かもしれません
学習前にインプットした内容
前提の知識量について共有するため、この項を設けさせていただきます
学習前の筆者自身はDB周りの知識に疎かった(正直SQLもほとんど書いたことがない)ため、基礎知識を得るために以下のコンテンツをインプットしてから書籍を読みました。
筑波大学の講義
データベース実践入門
上記2つのコンテンツは「DBの設計」や「SQLの理解」などに関して言えば非常に優良なものだと思いました。しかし、後から分かったことではありますが、今回取り組んだDBMSの作成に対してはそこまで有用なコンテンツではありませんでした。
つまり、あまりしっかりとした前提知識を持たないまま実際に書籍の学習や作成に取り掛かったという背景になります。
本題
前置きが長くなりましたが本題に移り、役立ったことを以下に記述していきます。
その0: 翻訳ツールは使い倒す
英語のコンテンツをどう学ぶかという記事でこれを書いていいのか躊躇いましたが、その0として書かせていただきます。
実は筆者自身、書籍の読み始めのうちは「英語のまま読み進めるぞ」と意気込んでいましたが2~3週間くらいで普通に挫折しました。学生時代に英語の論文を読んでいた読まされていた経験はありますが、ページ数が多く(400ページくらいで図も少ない)、前提知識が足りていないという今回の条件下ではとても無理そうだと感じて諦めました。
ですので、自分と同じく英語が特別得意でない方は素直に翻訳ツールを使いましょう。恥ずかしいことはありません。その分大きなアウトプットを生み出せば良いのです。
翻訳ツールとしては、kindleアプリ備え付けのBing AIによる翻訳機能が役立ちました。Androidは不明ですが、iPadやiPhoneであれば該当部分を選択するだけで勝手に翻訳文が出現してくれます。英文を読むときにありがちな困る点として、読むのに時間がかかって前の文との繋がりが捉えにくくなるということが挙げられるんじゃないかと思いますので、積極的に翻訳ツールを使うことで読むスピードを上げて前後の文脈の繋がりを捉えやすくすることが有効だと感じます。
(kindleの翻訳機能)
その1: 疑問ドリブンで読み進める
疑問ドリブンという言葉が存在するかは分かりませんが、ここでは「文章・コードを読む前もしくは読んでいる最中に疑問を列挙しておき、その後読み進める中でその疑問を解決していく学び方」という意味で言葉を使わせていただきます。
筆者は「DBMSは単なるファイルのシステムと比較して何が凄い」とか「クエリを解読して実際にデータを取ってくる仕組みはどうなっている」といった疑問を抱えていたので、本の該当の章を読む前にそういった類の疑問を書き出しました(もう少し細かい粒度の疑問だと解決がスムーズにいきやすいと思いますが)。また当然ながら本を読み進める最中にも疑問は生じるわけで、新しい単語が出てきたときに「〇〇の役割は？」とか「□□とは何が違う？」などといった疑問を付け加えていくことで、学習の方向性が定めやすくなります。
どうしても英語の教材だと、翻訳ツールを使っていたとしても知りたいことが書いてあるページを探すのに時間がかかってしまい、知識同士を結び付けることが難しくなると感じます。そのような問題を解消するために疑問と解答のリストを自分で作成しておくと後々の自分の役に立つと思います。
(疑問とそれに関する自分なりの回答)
単純に学んだことをメモしていくよりも自分にとっては効果的だと感じたので紹介させていただきました。
その2: 写経は正義
ソースコードがネット上に公開されているような技術書の場合、ダウンロードまたはコピペして内容を読むだけ、としてしまう方がいらっしゃるかもしれません。筆者もそのうちの一人だったのですが、単なるコピペで終わらせず自分の手でコードを打つ「写経」のメリットを感じることができたので共有したいと思います。
自分として、写経は「コードを書いている最中にコードの内容や意味が頭に流れ込んでくる」みたいなイメージがありました。しかしシングルタスク人間の自分はコードを書くという作業にリソースを使ってしまい意味を同時に理解できないという経験を過去にしてきていたため、あまり写経を実施していませんでした。
しかしながら今回、なかなかコードの理解が進まなかったことから試しに写経を実施したところ、写経のメリットを自分なりに理解できました。以下2つの通りです。
- コード中のクラスやメソッドなどの役割や関係を 空間的/構造的 に理解できる
- 自分が理解しやすいスピードでコードに向き合える
1点目については各コードのクラスやメソッドを手打ちし、コードの量を実感できるようになることで、それらが担う役割の大きさのコントラストを認識できるようになるといった意味合いです。コードを眺めるだけだとどのクラスやメソッドも平坦に見えてしまい、構造を理解しにくかったから理解がしにくかったのだなと学びました。
2点目については、自分のタイピング速度が良い意味でボトルネックとなり、理解のスピードが制御されるといった意味合いです。読み飛ばしも少なくなると思います。
短いコードであれば写経のメリットはそこまで無いかもしれないと思いますが、ターゲットが大きくなるほど一つ一つのコードの意味に加えてコード間の関係性を掴むことが重要になるため、写経が威力を発揮するのではないかと思いました。
その3: 自分用のソースコードは積極的に汚すべき
コードの可読性を高めることについては散々その重要性が主張されていると思いますが、自分だけが読む学習用のソースコードに関しては自分が理解しやすいようにカスタマイズしまくるべきだと思います。業務ではJavadocやdocstringなどの活用が求められるかもしれませんが、自分用のコードであればそのような「お作法」に縛られる必要はないと思います。
自分はNotionを使って疑問やメモを書き残しており、それは学習内容の全体像を把握するのに役立っています。しかしソースコード自体にも疑問やメモを書き残しておくと、よりミクロな視点での理解が促進され、とても心強いです。英文中の重要な記述を日本語で書き直してメモしておくことも有効な活用法だと感じました。ソースコードはもう一つのメモ帳、くらいの感覚で色々書いています。
終わりに
ありきたりな内容も多くなってしまったかもしれないと思いましたが、自分と同じように「何から手を付けたらいいか分からない」という思いを持った方々の助けに少しでもなればいいと考えております。
最後まで読んでいただきありがとうございました。