読者です 読者をやめる 読者になる 読者になる

大学プロジェクトメンバーに残す「今後やってほしいこと」

雑記

2年の頃からアルバイトとして大学でいろいろなWebシステムの開発を行っていましたが、卒業が近づくにつれ終わりが近づきつつあります。

自分は居なくなりますが、後輩は(おそらく)今後も各種システムの開発を引き継ぐことになると思います。

せっかくなので、自分がやろうと思ってできなかったことや、絶対にやっておいたほうが良いと思ったことなどをまとめてみました。

といっても私が思ったことでしかないので、特に従わなければだめとか、従ってないと悲しいとか、そういうことは全くないです。

というか、あの現場にいるよりもっと成長できる現場に行けるのであればやめてしまっても全く問題ないとすら思っています。

デザインパターンの習得

共同でコーディングを行う上で、デザインパターンの習得は非常に重要だと考えています。

というのも、デザインパターンは知っている人たちからすれば「共通の設計方針」になるからです。

例えばこのシステムにおけるモデルはActiveRecordパターンを使う、などというだけで、設計方針を 明確に伝えることができるようになります。

メンバー全員が共通の認識を持つことで、チグハグな実装になる可能性を排除することができます。

例えば、アレにおけるmakeUserメソッドはFactoryパターンです。採用理由はコンストラクタで例外を投げないようにするためです。

関数型言語(の考え方)の習得

関数型言語といえば数学的というイメージがあり、圏論、ラムダ計算、(Haskellの)モナドなど、難しいイメージがあるのではないかと思います。

私もそうですが、今後この仕事でご飯を食べていくためにもしっかり圏論から学ばなければならないなと薄々感づいています。

ただ、別にそこまで理解しなくとも関数型言語のエッセンスを理解することは従来通りの手続き型OOPをする上でも十分に活用できると思っています。

というのも、最近は何気なく書いているSQLJavaScriptには既に関数型のエッセンスが散りばめられているからです。

高階関数、イミュータブル(不変)性のメリットなどについて調べることで、データの加工処理においてよりスマートなコードが書けるようになると思います。

例えば、アレのUI生成ではJavaScriptのmapメソッドを用いていますが、あれも関数型の考え方に近いものがあると思っています。

環境の改善

ただただ仕事としてやるだけじゃなく、コードを書く上で効率的な手法やモダン(近頃流行っている)な手法について自ら調べ試してみることで 例えそれがうまくいかなくとも良い経験になると考えています。

個人的にCI(継続的インテグレーション)とかしっかりしたユニットテストやりたかった。

普段何気なく使っているGitLabですが、せっかく多機能なシステムなのに殆どの機能を活用できていません。

また、いちいちテストサーバにデプロイする作業も無駄です。Hookなどの機能を活用してテストサーバに自動的にデプロイされる環境を作ったほうが良いでしょう。

例えば、アレは比較的大規模なシステムなのにもかかわらず、ユニットテストがしっかりと組まれておらずテストの自動化ができていません。テストが自動化できないことでデグレード(改善したつもりがバグになる)が発生する危険性が増し、「触らぬ神に祟りなし」状態となってコードのリファクタリングもしにくい状況です。

スケジュールとメンバー次第ですが、テストドリブン(機能実装より先にテストコードを書く)な開発を行っても良いと考えています。

「書いたら書きっぱなし」をやめる

環境の改善と重複しますが、一度書いたコードは問題が起きるまでいじらない、という考え方はやめたほうが良いと考えています。

といっても状況によるのですが、コーディング規約を無視してとりあえず動くようなコードを書いて、それを「問題がないから」と放置するのはその後の保守を考えると絶対にやめたほうが良いでしょう。

自分の書いたコードは他の開発メンバーが読む、ということを常に意識してコードを書くよう心がけ、例え荒削りなコードを書いたとしても後々しっかりリファクタリングすることで、その後の開発が随分楽になるのではないかと思います、

ちなみに就活をしていた時の経験として、コードを書くときに面接官の方はそういったところをかなり注目して見ています。

仕事においては複数人での開発が当たり前になるので、他人が読むことを考慮したコードを書くことはとても重要です。何せ自分たちは頭キレキレでバリバリなコードを書く理系大学生ではないのですから、そういう部分でアドバンテージを発揮するしかないように思います。

例えば、アレについて私は問題ない部分や変数の初期化方法など本当にどうでもいい部分を結構変更したりしていましたが、コードの統一性を図り後々メンテナンスする時に楽になればいいな、と考えていたためです。(とはいえテストがしっかり組まれていないのでかなり危険な橋を渡っていたことは否定できない)

検索スキルをつける

何か問題にぶち当たったらとにかく検索しましょう。自分がぶち当たった壁は99%くらいの確率で他の誰かも経験しています。

あと、英語で検索してみるのも良いかもしれません。どうせこの分野での英語なんて大して難しい言葉は使われていませんし、最悪Web翻訳をかけて読むことだってできます。

例えば、55円事件のアレでは英語で検索したことで本番環境での不具合の原因がSAMBAのバグであることを特定することができました。

最後に

グダグダと書いてきましたが、とにかく興味を持つことを忘れないのが大事だと思います。好奇心を大切にしてください。 自分からいろいろな情報を集めて試してみるのは良いことです。少なくとも、学生なら少しくらい失敗しても大丈夫です。

あと、偉そうなこと言ってますが、私は仲間とともにもっともっといろいろ磨いていきたいなと考えているだけの本当に大したことのない人間です。あんまり当てにしないほうが良いと思いますし、もっと立派な人はいます。

っていうか、大体の場合において、こういうことをグダグダ言っている人は無能です。本当に有能な人は黙々と自分の道を進んでいます。そういう人から学べる環境に行きたいなと常々思います。