島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

実力を示せるポートフォリオのWEBサービスのコードの作り方

f:id:ms2sato:20180809142937j:plain

はじめに

ms2sato.circlearound.co.jp

こんなのを先日書いたので、その続き的なエントリーです。

「『作ったものがある(最低条件)』とか言っても、何作れば良いんですか?」 的な話です。ゴールとして「出来上がった動くもののソースコードを技術者に見てもらう」切り口で書きます。 これはあくまで「私の場合」なので、異論ある人から「こういうところも見ているぞ!」みたいなツッコミとか超欲しいです。

どういうものを作れば実力が測れるのか

以下、私がRails中心に色々やっている(やらざるを得ない)為に、チョイチョイRailsぽい話になってしまったりしますが、お許しください。個人的には言語とかプラットフォームとかに関して中立な考え方です。

レベルで示していますが、数字が上がると難易度が上がるというよりも「下の方をちゃんとこなしていれば上の方も見ていく」ような感じになる気がします。

【レベル0】 とりあえず見る価値を作る

Scaffoldしただけでできるような「単純すぎるものではない」こと

色々と流派はあるかもしれませんが、単純なCRUD*1を作るのに、多くの人は作業を効率化させる為にScaffoldを利用すると思います。Railsならこれで何が起こるかとか、カスタマイズするのにどうしたら良いかある程度把握しているべきだと思います。

シンプルな掲示板を作ろうとしたりすると、ほぼScaffoldで終わってしまうようなケースがあり「あれ?これってあなたはどこをプログラミングしたの?」というようなことになりかねません。レビューする側も、コマンドいくつか叩いただけのコードでは判断できません。当然ですよね。

ちなみに、このレベルのコードでViewを綺麗に飾るだけしているケースはよくある気がします。もしもHTMLやCSSのスキルやデザインでアピールしたいなら、これもありかもしれません。ですがシステムを扱うプログラマーになりたいのであれば、これでは実力が測れないのです。

というわけで、コードのどこか(適切な場所はありますが、この後に示すようにその場所でなくても構わない場合があります)に頭を使うロジックを入れて置いてください。例えば「どこ頑張ったの?」と聞かれた時に「ここめっちゃ頑張りました!」と言えるようなのがあると良いです。

データベースを利用していること

稀に外部APIを呼び出すだけのものとかがありますが、これはDBの扱いやSQLの理解があるかどうかが見れないです。大抵のシステム開発ではMySQLやPostgreSQLなどのデータベースを扱ってシステムを作るので、この知識があるのかないのか見えないと、やりにくいです。

Scaffoldだと基本のコードがいきなり埋まってしまうので、それにプラスしている場所があると良いでしょう。例えば検索機能があって、入れた情報を絞り込んで出力できたり、LIKEの曖昧検索できたりするなどすると、少しは片鱗が見えます。

またテーブルのリレーションとして

  • 1対多
  • 多対多

などの基本的な情報のまとめかたの方法があります。これらは入れましょう。特に多対多は最初の頃よくわからないこともあるかと思いますが、何か作ればすぐに必要になることなので、やれる方が良いです。

RailsならActiveRecordを使ってアソシエーションを利用するようなコードになるはずで、こういうところのコードの扱いでも一定の実力を測ることができます。

ライブラリは利用しても良いが、骨格は自分でコードを書いていること

OSSで出ているRailsのサービスに何個か機能追加したようなものですと、そのOSSの扱い方を理解しただけなのか、Railsについての理解があるのかがわからず、現場に入りやすいかの判断がしにくい場合があります。あくまでサービスをゼロから作れるかどうかを見たいというような目的感があるので、できればrails new からスタートして作っていて欲しいです。

【レベル1】力技でもやりたい処理を自分で考えて書いているか

「美しいコードでなければ見せる価値はない」と思ってしまう人がいるかもしれませんが、それは誤りです。美しさというのは後で磨くこともできることなので、最低限で考えると美しいかどうかではありません。

大事なのは「考えてコードを書いているのか」とか「困った時に工夫できる機転がきくのか」というようなことです。

なので私の場合「全然勉強の余地はあるけれど、めちゃくちゃ考えたんだろうな」という事が伝わる際には一定の評価をします。ただし「どう考えてそうなったのか」については結構聞き込むはずです。ポイントとしては以下かな?と考えています。

  • 少なくともどこかのコピペコードの筈がない(コピペだとそれっぽいコードが多くなるので「メチャメチャ頑張って工夫」になりにくい)。
  • そのコードについて質問した時に「どう考えたのか」が論理的であるかどうか。

例えばですが「MVCとかよくわかってないです」と言って見せてくれた方のコードでViewにロジックべったりだったことがあります。ただ、聞いてみると彼はシッカリと考えていて、単純にロジックの適切な置き場所がよくわかっていないのだとわかりました。こういうケースは評価できると思います*2

【レベル2】作法に従っているか

レベル1を超えているということは、とりあえず動作を実現した動くコードがあるということになります。ただ、それだとよくありますし「家で独学修行を一年続けました」とかでも到達できる可能性は高いです(私も経験していて、とても価値があることですが自分のやり方に染まり過ぎているかもしれません)。

例えば以下のようなところとかでしょうか。

  • MVCに従うことを知っている。ロジックをモデルへ集めている。
  • アソシエーションを適切に使っている
  • enumやscopeを理解して利用している
  • routesをresources中心で書けている、アクションの追加などもこの作法の中でやっている(collection、member)
  • バリデーションでの失敗の処理がおざなりになっていないか(とりあえず動かそうとすると放置しがち)
  • (もう少し後でもいいか?)N+1 問題への対応

【レベル2】よく使われる外部ライブラリを使っているか

ちょっと調べると出てくるような外部ライブラリを利用できていると、よく調べていることは伝わります。Railsだとこの辺でしょうか。

  • Devise(嫌がる人もいますが、導入されているプロジェクトは多いので知っておく方がいいと思っています)
  • Carrierwave(もう使われなくなるかも)
  • Kaminari

【レベル2】自動テストを書いているか

まず、書く意志があって試みてて欲しいのはあります。RailsではRspecがほとんど使われている様子なので、Rspecで書いてください。

  • モデル
  • コントローラー or リクエスト

くらいで書いてみてて欲しい。最低モデルについて書いていてくれるとありがたい(その為にもモデルにロジックが乗る設計になっていないと難しいですが)。 「素晴らしいテスト」という考え方だと色々と難しくなってしまうと思うので、最初のうちは「意味があると思うものを書きました」くらいでも良いかも。

【レベル3】よくある仕様・画面に対応できているか

現場に入ると最初の頃ちょっと戸惑う「あるある」な仕様があります。これに適切に対応できているかですね。例えば以下のような構成の画面とか。

  • 本の紹介と他人からのレビューコメントが並ぶ画面が適切に作れているか
    • バリデーションしなければどうにかやっていることはあっても、そのあたり含めると怪しくなってくる人は結構いるようです。
  • 本の紹介のために複数の書籍のサムネイルを一つの編集画面で一緒に更新させる。サムネイルの最大数を増やすのはDBの変更をしなくてもできる。
    • これもバリデーション含めると、エラーになると入れたサムネイルが無くなったりしてしまうなどあるので、そのあたりのケア。

この項目は「一度ぶち当たって痛い目を見ると覚える」ような部分でもあるのでプラスアルファだと考えることもありますが、こういうのをシッカリ対応できているなら安心だなとも思います。成長を含めて評価するか、今のその人のできることで評価するかの違いです。

【レベル3】バッチ処理が入っている

普通に教本などをやっていてもあまり出てこないのですが、実際の開発では rails runner や Rakeタスク を使ったcron呼び出しのバッチ処理などが発生することが多いです。また、稼働中のサービスに対してDBの情報を更新かけたりもしたりするので、こういったコマンドでサービスに外から働きかける経験があると、本格的な内容理解がありそうだなと感じたりします。

ロジックの入りやすい仕様について

おそらく「ロジック入るようなのはどういうものか?」という疑問が沸いている人がいそうなので、ちょっと書いておきます。

  • ユーザーが複数の種類いて、それぞれ別の権限を持っている(管理者・コンテンツ作成者・見るだけの人など)
    • 権限判断をすべきところが出てくるので、そこで考えて分岐する必要性などが出てきます。よく実開発で必要になる考え方です。
  • 何かの集計を行なっている
    • 例えば「いいね数」のような概念があって、いいね数の数で検索結果を出したりするなど。複合的に検索できると尚良い。
  • 条件付きで見えるような画面がある
    • 例えば他で設定されたユーザーごとのパスワードを入れて、同じパスワードを入れたら見ることができる、など

今だとクラウドファンディングのサービス作ろうとしたりすると、いい感じに色々な仕様が乗ってきそうな気がしますね。ただ、実力がそこに伴っていないと意味がないので、そうでなければ無理くり目指さずにブログサービスを作るとか、掲示板でもちょっと変わったものを目指すとかでも良いのではないでしょうか。

おしまいに

これってつまり「私が実力を評価する場にいた時に見ること、あると嬉しい情報」なんです。私を攻めるならこういう感じで勝利確率が上がります(笑)

普段WEBプログラミング個別トレーニングの面談でもこうやって今の実力を測らせてもらいますし、弊社の受託で一緒に仕事をするメンバーを見る場合も大抵コード見ながら話をさせてもらいます。 circlearound.co.jp

こうやって結局自社の話に繋げるのは仕様です。もし興味わいたら、明日(8月11日)、25日にトレーニングの説明会やるので来てください。

techdrive.connpass.com techdrive.connpass.com

*1:Create, Read, Update, Delete

*2:もちろん適切なところに書けばもっと評価します