私は独学でエンジニア職についた初級者です。私はプログラミングを始めたのが遅かったため、もっとできることを増やしたい、もっとパワフルなエンジニアになりたいと思い、プライベートでも学ぶ時間を取っています。今私が行なっている学び方は、紹介している人が少ないけれどやっている人は多い学び方、つまり暗黙の常識のような学び方みたいなので、私と同じような初級者と共有するために記事を認めました。上級者の方は、何を当たり前な……と思うかもしれませんが、独学初心者はなかなか知らないことなのでお許しください。
学び方
OSSからコードを拝借して自分なりに機能追加、テスト追加などをする。その発展として私個人は、需要はあるのにメンテナンスの停止したOSSを勝手に引き継いで、コンセプトの見直し、テストコード追加、機能変更を行なって公開する、というようなことをしています。(運用はこれから)
注意
この記事は、読者が自分より腕の良いエンジニアのいる組織に所属していることを想定しており、その組織で学んだことをどのようにプライベートで復習するか、に重きをおいているのでご了承ください。
また、新規開発より運用、機能追加、改修、テストなど作ったあとのことに重きをおいています。
前書き
なんらかのプロジェクトにコントリビュートすると成長できる、とよく聞きます。その一方で、自分でプロジェクトを運用すると成長できる、ともよく言われます。どこかで働いているからには、前者は大なり小なり満たしているはずなので、後者、自分でプロジェクトを運用するために学びます。私がこれから話す学び方はその前段をなすものです。自分でなんらかのソフトウェアを運用するにはそのためのソフトウェアが必要だけど、どうやってそのソフトウェアを用意するのか、にフォーカスします。
この学び方にたどり着いたきっかけ
haya14busaさん(だったはず)が2017年のvimconfの発表で、OSSのvimプラグインをフォークしてメンテしていたら、オリジナルの作者から連絡が来て、引き継いで欲しいと頼まれた、的なことをおっしゃってました。この時初めて、github(あるいは他のサイト)のリポジトリを基にして開発をするのは一般的なのだと気付きました。
githubにはfork数の項目がありその数字が多いのだから当たり前といえば当たり前ですが、この時まで意識していませんでした。読むところまではやっていたんですが、そこから先に進むのがなかなか遅れました。
読むのと改修するのは別
一般的初心者からすると、読むのと改修するのは別の行為であるように思います。もちろん改修を加えるためには読む行為が伴いますが、目的意識と重みがただなんとなく読むのとは全然違いました。
自分がコードに手を加える前提でテストを書きながら他人のコードを読むのはなんのとっかかりもないまま読むのに比べて、良い部分悪い部分がはっきり見えます。テストを書きながら読めば設計の良し悪しにも踏み込めます。漫然と読んでいたのが馬鹿らしくなるくらいに真剣にコードを読むきっかけになりました。
新規で作るのともまた違う
私は現状の仕事柄、新規で何かを作る機会はほとんどなく、他人が書いたコードを引き継いで運用、開発することが多いです。一方、前職ではスタートアップで一からコードを書いていました。新規で一から作る行為と、既存のものをより良くする行為は別物です。
初級者から中級者にあがるステップとして、さまざまに経験すべきことはありますが、その多くは既存コードがあるからできることです。個人的には、初級者中級者程度のレベル感だと、新規開発の能力よりも、既存コードありきで何かをする能力のほうが重要であるように感じています。もちろん、キャリア次第ではあります。ただ、運用経験のないエンジニアが書いたコードは技術的負債の塊になりやすい、というのが個人的経験です。
私が実践している方法
極論を言えば、好きなリポジトリをフォークなりクローンなりして、好き勝手に遊べばいいのですが、そう言われても戸惑ってしまう人も多いかと思うので、具体的に私が行った方法を書いていきます。
需要があり、わかりやすく改修の必要性があるのに、放ったらかしにされているリポジトリを探す
需要があることは重要で、直接的にやる気に結びつきます。需要なくてもいい、って人もいるかもですが、私には必須でした。スター数で判断しました。
わかりやすい改修の必要性の例としては、テストがない、バージョンの壁を乗り越えていないなど考えられます。個人的には、テストがないプロジェクトを探すことをおすすめします。テストは必ず必要ですし、テストを書く技術を身につけることは初級者にとって優先度が高いからです。
放ったらかしにされていることは、改修の必要性と結びついています。コミュニティが活発ならわかりやすい問題点なんてすぐにつぶされちゃいますからね。初級者でもわかるレベルの問題が更新され続けているリポジトリにあるとは考えづらいです。
検索ワードはこれだ！
created:>2016-01-01 stars:>200 language:Go license:mit
これを最終更新の古い順に並べて、興味をもったリポジトリをクローンしました。
それぞれ説明しますと、
-
created: あまり古いことを学んでも仕方ないと考え指定 -
stars: 言語のスター数規模と相談しながら適切なものを -
language: 使いたい言語を -
license: クローンして怒られないものを指定。気をつけましょう。 - 最終更新: 好みが別れるところですが、私はオリジナルとは別のリポジトリを作るつもりだったので、更新が止まっているものを選びました。
年末年始の成果物
年末年始はこんな開発をやっていました。
github.com/sourcegraph/thymeというリポジトリを元に改造しました。改造と言ってもまだテストを書いてcron対応しただけですが……
私が何をやっていたかはリポジトリの方を見ていただくとしてまとめにうつります。。
まとめ
先ほどテストがないリポジトリを探すと良いという話をしました。自分でリポジトリを運用するとテストの有り難みが夜９区わかっていいです。改造しようにも影響範囲がわからないと思わぬバグを生むこと多数です。とりあえず一機能削除してみたら案の定バグったから、テストを書いて改造できる状態を整える、という流れになります。
他人のリポジトリを用いて自分でそれなりのサイズのリポジトリを管理するという試みは、程度の差こそあれ初級者にとて大きな学びをもたらします。私自信もまだまだ未熟ですが、正月の間だけでもかなり成長したとかんじています。
ぜひ試してみてはいかがでしょうか？