周りをフル利用して成長するための考え方

概要

今の会社には、「10分でわからなかったら質問しよう」という文化があります。
私のような駆け出しエンジニアにとってそう言っていただけることは非常にありがたく、研修中から考え方に詰まったら聞くようにしていました。

しかしながら、いざプロジェクトに入って開発をするようになると、なかなかそれをスムーズに実行することができませんでした。
そこには

• 前職での「自分で調べ尽くしてから質問をしろ」という文化がまだ残っていた
• 質問をする時には常に「やりたいことは〇〇で、今コードは△△になっていて、それに対してXXを試して〜〜〜」みたいなことをキッチリ書くべきだと考えていた
  

のような、自分で勝手に質問のハードルを上げていたことが理由としてあったような気がします。

その結果、昨年一度タスクを抱え込んで痛い目を見たことがありました。
その時に教えていただいた、周りを頼って成長するための考え方を参考に、それ以降は気掛かったことがあればすぐに相談して、タスクを進めることができたので、メモとして残してみます。

自分の成長がチームのためになる

まず社長の技術力・開発スピードが、今後1〜2ヶ月で著しく向上することは考えづらい。
しかし貴方はビギナーなので、倍になることも割と現実的。
自分の成長に力を使ってくれる方が、チームにとっても助かる

だいたい氷山の一角

自分で調べる、粘ることに制限時間を設けるというやり方は聞いたことがあるかもしれない。
とはいえ、「あとこの部分が分かれば誰かの手を煩わせることなく解決できそう！」ということもあるでしょう。
しかし経験則的に、それで分かったことは実は氷山の一角であったり、その後に新しい課題が見つかったりすることが多い。
だから自分だけで対処しようとするのには時間で制限をかけるべき

先行投資

自分が調べたら何日か要するかもしれないことでも、先輩はかかっても数時間で説明できる。
もしかしたら、その先輩も過去に何日もかけて調べたのかもしれない。
そこに気を遣ってしまうこともあるかもしれない。
しかし、そこは「せっかくその人が先行投資をしたのだからそれを享受しよう」と考えるべき。

自分が調べたらもっと時間がかかるところが数時間で済んで、浮いた時間で別のタスクをこなすこともできる。結果チーム全体で先に進むことができる。

数質問すれば、質問も上達する

そのままだが、誰かをメンションして聞いた方が良いのか、誰かが気づいたらで良いかもとつぶやき程度にSlackに書いておくのか等、確かに質問を多めにするようになってからそこまで経ってはいないけれども気づきがあったように感じる。

あとは自分がごちゃごちゃ考えるよりも聞いてしまった方が圧倒的に解決が早いし、先輩にとってはさもない質問で、手を煩わせているという感じもそこまで無いということが分かって、質問へのハードルも下がってきているようにも思います。

まとめ

今回自分の行動を変えることができたのは、質問を躊躇うことの弊害、また質問によって得られるメリットを、
言葉で理解することができたことが大きな一つの要因だと考えています。
自分ではそこを言語化できなかったので、「質問したら〇〇思われるかも」「質問せず解決した方が良いかも」といったような、特に根拠のない感情寄りの行動でデメリットを生んでいたのではないかと思います。
今後も0秒思考等々活用して、どんどん自分の思うことを言語化して整理できるように練習していきたいです。

IdPとは

今度アサインを受けたプロジェクトで認証周りの知識が必要になったので、調べてまとめてみました。

参考

• IdPとは？　役割や機能、SPとの違いをわかりやすく解説！

• IdPとは？実現できることや必要性などを解説します！

• 多要素認証とは？導入するメリットから認証の種類まで広く解説します
• IdPとは
• IDaaSとは？（2）IDaaSで何ができるの？

IdPとは

Identify Providerの略称で、クラウドサービスやアプリへのアクセスを試みるユーザーの認証情報を保存・管理するサービスのこと。
SAML認証において、認証情報の提供役を担う（SAML認証は別途調べることにします）

IdPがもたらすメリット

• ユーザー情報の一元管理
• シングルサインオン
• 多要素認証

の3つが挙げられる。

ユーザー情報の一元管理

ユーザーIDやアクセス権限などの認証情報を一元管理できる。
そのため社員退社時の、各サービスのユーザーIDやアクセス権限を削除するなどの煩雑な作業が一括で対応可能に。

従来からActive Directoryなどを活用した社内でのユーザーID一元管理は可能だったが、それらはあくまでも社内システムやサービスが対象で、企業でのクラウドサービス活用が拡大するなかで、それだけでは不十分になってきている。

IdPはユーザー認証情報をクラウド上で管理を行うので、社員の入社・退社による増減にも柔軟な対応が可能。
社員の部署移動による属性情報の更新も簡単に管理者側でできるだけでなく、アクセス権の範囲も自動更新できるなど便利。

シングルサインオン

IdP利用の最大のメリット。シングルサインの実現により業務効率向上とセキュリティ強化が同時に実現。

シングルサインオンは、単一のID/パスワードでクラウドサービスやアプリにログインできる仕組み。
他のサービスで一度でもログインに成功すれば、認証情報を信頼して他のサービスにも適用するため、覚えるものが最初のログイン時に入力するマスターパスワードだけでよくなる。

IdPを利用することでSAML認証によるシングルサインオンを実現できるため、ログインにかかる工数を大幅に減らし、業務の効率化が期待できます。

またシングルサイン未導入の企業では、複数サービスで同一のパスワードを使い回したり、サービスごとに異なるパスワードをメモしてデスクに張るなど、社員が不正アクセスのリスクを高める行動をとってしまう傾向があるとのこと。

しかし強度の高いパスワードを設定してIdPで連携しておけば、ユーザーは一つのパスワードを覚えておくだけで良いし、セキュリティを強化することもできる。

多要素認証

クラウドサービス利用時に、複数の要素によって本人確認をする認証行為のこと。
スマートフォンのSMS機能を活用したワンタイムパスワードや顔認証や指紋認証を活用した生体認証などを求めることで、精度の高い本人認証を実現できる。

クラウドアプリケーションごとに多要素認証を有効化するのはユーザーや管理者にとって負荷が高く、また多要素認証が利用できないサービスも存在するため、一元的に多要素認証を管理・有効化することで、全体の認証強度向上および管理コスト削減が可能

『Webを支える技術』読みました

Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus

エンジニアとして成長していくにあたって、RESTの考え方に習熟していきたいと思った時に、「そもそもWebとは」みたいなことへの知識もあると、より理解が深まるよと上司に紹介していただきました。
特に自分は学生時代もあまりPCに触れたことがなく知識がほぼ0であったため、何か新しいことが得られればと思い読んでみました。

構成

1章 Webとは何か
2章 Webの歴史
3章 REST Webのアーキテクチャスタイル 4章 URIの仕様
5章 URIの設計
6章 HTTPの基本
7章 HTTPメソッド
8章 ステータスコード
9章 HTTPヘッダ
10章 HTML
11章 microformats
12章 Atom
13章 Atom Publishing Protocol
14章 JSON
15章 読み取り専用のWebサービスの設計
16章 書き込み可能なWebサービスの設計
17章 リソースの設計

メモ

アーキテクチャスタイル

別名「（マクロ）アーキテクチャパターン」とも言い、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉で、例えばMVCやパイプ&フィルタ、イベントシステムなどがある。
パターンという言葉からデザインパターンが想像されることもあるが、いわゆるデザインパターンは別名「マイクロアーキテクチャパターン」とも言い、アーキテクチャスタイルよりも粒度の小さいクラスなどの設計様式を指す。

REST

RESTは数あるアーキテクチャスタイルの中でも、特にネットワークシステムのアーキテクチャスタイルである。ネットワークシステムのアーキテクチャスタイルで最も有名なのはクライアント/サーバであり、そしてWebはクライアント/サーバでもある。（RESTはクライアント/サーバから派生したものでもある。）

RESTとはつまり以下6つを組み合わせたアーキテクチャスタイル

• クライアント/サーバ
  • ユーザインタフェースと処理を分離する
• ステートレスサーバ
  • サーバ側でアプリケーション状態を持たない
• キャッシュ
  • クライアントとサーバの通信回数と量を減らす
• 統一インタフェース
  • インタフェースを固定する
• 階層化システム
  • システムを階層に分離する
• コードオンデマンド
  • プログラムをクライアントにダウンロードして実行する

アドレス可能性

RESTfulなWebサービスの性質として最も重要なもの。
これは「URIさえあればリソースを一位に指し示すことができる」と言う性質であり、URIのこの性質がなければ接続性と統一インタフェースを実現できない。

接続性

リソースをリンクで接続することで1つのアプリケーションを構成するという考え方。
RESTの基幹をなす思想。

統一インタフェース

URIで指し示したリソースに対する操作を、統一した限定的なインタフェースで行うアーキテクチャスタイルのこと。
例えばHTTP1.1ではGEtやPOSTなど8個のメソッドだけが定義されており、通常はこれ以上増えない。
インタフェースの柔軟性に制限を加えることで全体のアーキテクチャがシンプルになり、またインタフェースを統一することでクライアントとサーバの実装の独立性が向上する。

URI

http:yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10
このURIは以下のように分けられる

• URIスキーム：http
• ユーザ情報：yohei:pass
• ホスト名：blog.example.com
• ポート番号：8000
• パス：/search
• クエリパラメータ：q=test&debug=true
• URIフラグメント：#n10

変わらないURIこそが最上のURI

1998年当時、URIが変更になることは日常茶飯事であった。
しかしながらこれはWebの根幹を揺るがす問題で、Webとはそれぞれのリソースに他のリソースへのリンクが埋め込まれたハイパーメディアシステムである中で、リンクが切れてしまうことはそれが機能しないことを意味するからだ。

URIを変わりにくくするためには

• プログラミング言語に依存した拡張子やパスを含めない
  • 言語を変えたら使えなくなる
• メソッド名やセッションIDを含めない
  • メソッド名が変わった瞬間、またログインし直すたびに使えなくなってしまう
• URIはリソースを表現する名詞にする
  • URIとHTTPメソッドは、名詞と動詞の関係にある。URIは全体として名詞になる様に設計すべき

HTTP

名前こそハイパーテキストの転送用プロトコルだが、実際にはHTMLやXMLなどのハイパーテキストだけでなく、静止画・音声・動画・JavaScriptプログラム・PDFや各種オフィスドキュメントファイルなど、コンピュータで扱えるデータであれば何でも転送できる。
HTTPはRESTの重要な特徴である統一インタフェース、ステートレスサーバ、キャッシュなどを実現している、Webの基盤となるプロトコルである。

べき等性と安全性

HTTPメソッドはその性質によって以下の様に分類できる。

メソッド	性質
GET、HEAD	べき等かつ安全
PUT、DELETE	べき等だが安全でない
POST	べき等でも安全でもない

べき等とは

「ある操作を何回行っても結果が同じこと」を意味する数学用語。
例えばPUTやDELETEを同じリソースに何回発行しても、必ず同じ結果（リソースの内容が更新されている、リソースが削除されている）が得られる。

安全とは

「操作対象のリソースの状態を変化させないこと」を意味する。
リソースの状態に変化を与えることを「副作用」と言うので、安全は「操作対象のリソースに副作用がないこと」とも言う。
例えばGETには副作用がないので、GETを同じリソースに何度発行しても、リソースの状態は変化しない。

ステータスコードの意味と分類

• 1xx：処理中
  • 処理が継続していることを示す。クライアントはそのままリクエストを継続するか、サーバの指示に従ってプロトコルをアップデートし再送信する。
• 2xx：成功
  • リクエスト成功を示す。
• 3xx：リダイレクト
  • 他のリソースへのリダイレクトを示す。クライアントはこのステータスコードを受け取った時、レスポンスメッセージのlocationヘッダを見て新しいリソースへ接続する。
• 4xx：クライアントエラー
  • 原因はクライアントのリクエストにある。エラーを解消しない限り正常な結果が得られないので、同じリクエストをそのまま再送信することはできない。
• 5xx：サーバエラー
  • 原因はサーバ側にある。サーバ側の原因が解決すれば、同一リクエストを再送信して正常な結果が得られる可能性がある。

キャッシュ

HTTPの重要な機能の一つ。
サーバから取得したリソースをローカルストレージ（ハードディスクなど）に蓄積し、再利用する手法のこと。
ローカルストレージにキャッシュしたデータそのもののこともキャッシュと呼ぶことがある。
クライアントが蓄積したキャッシュは、そのキャッシュが有効な間、クライアントが再度そのリソースにアクセスしようとした時に再利用する。

HTML

Hypertext Markup Lnaguageの略。
マークアップ言語とは、タグで文書の構造を表現するコンピュータ言語である。また、マークアップ言語でマークアップした構造を持った文書のことを「構造化文書」と呼ぶ。

Atom

タイトル・著者・更新日時といった基本的なメタデータを備えたリソース表現のためのフォーマット。
Atomは多様なアプリケーション用の拡張が用意されたフォーマットでもある。
例えば、ポッドキャストによる音楽配信や、写真管理、検索エンジンなどのアプリケーションは、XMLの名前空間の仕組みを使ってAtomに独自の要素を追加している。

JSON

JavaScript Object Notationの略で、データ記述言語である。
その名の通りJavaScriptの記法でデータを記述できる点が最大の特徴で、記法はJava Scriptだが、そのシンプルさから多くの言語がライブラリを用意しているため、プログラミング言語間でデータを受け渡すことができる。

Webサービスでは、ブラウザがJavaScriptを実行できるために相性が良い、XMLと比べてデータ表現の冗長性が低いなどのメリットから、Ajax通信におけるデータフォーマットとして活用されている。

Webサービス設計において大切な考え方

• なるべくシンプルに保つ
  • 設計が複雑になったり機能が無駄に増えてきたら、１段階メタな視点で全体を考え直す。
    やり方を変えることで削除できる箇所があるかもしれない。
    全体をシンプルに保つことは、設計バランスを考える上で最も重要。
• 困ったらリソースに戻って考える
  • HTTPメソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。
    検索機能を実現するSEARCHメソッドをHTTPに追加するのではなく、「検索結果リソース」をGETする、と考えることが重要。
• 本当に必要ならPOSTで何でもできる
  • 更新にはPUTを用いるべきだとしても、例えばバッチ処理の様に複数リソースが対象となった時点で、PUTを使うのは諦めてPOSTを用いる方が賢明である。

まとめ

プログラミング学習を始めた頃から、Railsに触れ始めた頃からRESTという言葉やリソースを大切にする考え方に触れることは多くありましたが、そもそもそれはWebの成り立ちにも起因することで、Webが発展してきた経緯があったということを知りました。

自分がこれまで学んできたことは、どちらかといえば表層の方にすぎず、より根底に近いHTTP、URIなど開発の基礎とも言える箇所を新たな角度から学ぶことができたのではないかと感じています。

自分のコードが初めて世に出ました

コードが初めて世に出た

ついに自分がコードを書き、リリースされる経験をしました。 正直そこまで実感はないというのが率直な感想です。

そう感じる主な理由は、新規サービスなどではなく、既に走っているサービスの一部改修であったために「リリースされた！」という印象が強くないことかと思います。
いつも通り作業をして、コミットしてPRを出して、レビューをいただいてクライアントにも確認いただいて、main のブランチへ push をする。を淡々とこなしたという感覚です。

CTOは、「バグや障害対応の業務が発生し始めると、自分の携わったコードが世に出ている感覚も強くなったりするよ」と仰っていたので、また新しい感想を持つタイミングがきたら、このブログを読みながら気持ちの違いを記録に残してもみたいなと思っております。

プロジェクトに入った話

先月の頭、銀行を退職してからちょうど1年のタイミングに実案件にアサインしていただきました。

既存のアプリケーションに対して、新機能を追加実装する受託案件で、
「規模もそこまで大きくないので、勉強する気持ちでたくさんのことを吸収して成長してほしい」
と最初に言って頂いていたので、知らないこと全てに触れていく気持ちで臨みました。

開始当初の作戦会議mtgで実装方針を定めて設計をし、やるべき課題に対して issue を立ててタスクの割り振りをし、スケジュールを確認しながら作り上げ、引っかかることがあれば方向修正しながらより良いものに仕上げていく。という様な進め方で日々の業務に取り組んでいきました。

間も無くテストも終えてリリースを迎えることになりますが、初プロジェクトで

• 案件の一連の流れや立ち回り方
• 設計
• クライアントとのmtgやコミュニケーションの雰囲気
• 当然ながらコーディングの知識

等々、それなりに多くのことを経験できたのではないかと思っています。

多くの先輩に良質なアドバイスを頂ける職場で、設計からコーディングから結合テストまでをこんなに早い段階で経験することができ、自分は非常に恵まれていると再認識しております。
プログラミングスクールを使っての勉強から転職活動、研修を経てついにエンジニアとしての仕事ができるようになって非常に感慨深い思いです。

一方で先輩方の凄さと自分の未熟具合も感じて、自分も時間が経過したときに同じ様になれているだろうかと不安を覚える、そんな日々でもありました。

まとめ

自分は自分のペースで、できる努力を地道に積み重ねて、日々昨日の自分を超え続けられる様に進んでいきたい所存です。🔥
明日からも頑張ろう

Rubyプログラム実行時に、コマンドライン引数を取得できるようオプションを作成

先日カレンダープログラムの作成に取り組みました。 その中でオプション設定や、それに係るエラーメッセージの表示を初めて行ったので、メモとして残すものです。

最終的に作ったコード

require 'optparse'

option = {}

OptionParser.new do |opt|
  begin
    opt.banner = "Usage: calender [options]"
    opt.on('-y year') {|v| option[:year] = v}
    opt.on('-m month') {|v| option[:month] = v}

    opt.parse!(ARGV)
  rescue OptionParser::InvalidOption => e
    puts "calender.rb:\s#{e.reason=('illegal option')}\s#{e.args.join(' ')}"
    puts opt.help
    exit
  rescue OptionParser::MissingArgument => e
    puts "option requires an argument\s#{e.args.join(' ')}"
    puts opt.help
    exit
  end
end

ひとつひとつ振り返る

rescue等の例外補足は置いておいて、オプションを使うためのコードはこの辺り

require 'optparse'

option = {}

OptionParser.new do |opt|
  opt.banner = "Usage: calender [options]"
  opt.on('-y year') {|v| option[:year] = v}
  opt.on('-m month') {|v| option[:month] = v}

  opt.parse!(ARGV)
end

例えば以下のようにすれば出力することで、コマンドライン引数を取得できていることがわかります。

p option[:year]
p option[:month]

% ruby test.rb -y 2021 -m 9

"2021"
"9"

オプションを作成

  opt.on('-y year') {|v| option[:year] = v}
  opt.on('-m month') {|v| option[:month] = v}

ここで-yと-mのオプションを取り扱えるようにしています。（onメソッドリファレンス）
今回はカレンダーのプログラムで年と月を扱いたかったので、最初にハッシュを作っておいて、それぞれyear・monthのキーの値にするようにしました。

また、このonメソッドの箇所では引数に関する設定が可能。

• 引数を取らない場合

# コマンドラインにオプションを入力した場合は、 true を引数としてブロックを評価する。
on("-x"){|boolean| ...}

• 引数を取る場合（本件の書き方）

# 'year'の部分は任意の文字列
on("-x year"){|val| ...}

• 引数が必須ではない場合（上の書き方は必須）

# [ ] をつける
on("-x [year]"){|val| ...}

その他

opt.parse!(ARGV)

opt.parse!(ARGV)

Optionparser#parseは与えられたargvからオプションを取り除いたものを返す。
（parseメソッドリファレンス）

試してみたところ、これを書いていないと引数だけでなくオプション自体も要素として入っておりました。
今回は、オプション指定時に引数を入力し忘れた場合に例外を補足したい（OptionParser::MissingArgument）と考えており、オプションが入ってしまうと例補足することができなかったので、記述しました。

# 引数を入力し忘れた時
# parse!した場合
% ruby 02.calendar/calender.rb -y 

irb(main):001:0> ARGV
=> [] 


# parse!しなかった場合
% ruby 02.calendar/calender.rb -y 

irb(main):001:0> ARGV
=> ["-y"]

opt.banner = str

opt.banner = "Usage: calender [options]"

banner=メソッドは、--helpオプションを指定した時に表示されるサマリの最初に表示する文字列を指定することができます。 今回は例外補足時にUsage: calender [options]と表示したかったのでここで記述して、rescue節のputs opt.helpで出力するようにしておりました。

感想

カレンダー全体のプログラムについても、振り返ってまとめてみたい。

『リーダブルコード』読みました

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

読んだきっかけ

研修としてのアプリケーション開発で沢山のコードレビューを頂くなかで、

「この書き方の方がぱっと見で何がしたいかわかりやすい」
「この変数名だと誤解を招く恐れがある」

といったアドバイスをたくさん頂きました。
「機能的に要件通り動作するかどうか」にしか未だ考えが及んでいなかった私は、よりコードのクオリティへの考えが必要だと感じ、ベースとなる知識を得るために本書を手に取りました。

構成

1章 理解しやすいコード
2章 名前に情報を詰め込む
3章 誤解されない名前
4章 美しさ
5章 コメントすべきことを知る
6章 コメントは正確で簡潔に
7章 制御フローを読みやすくする
8章 巨大な式を分割する
9章 変数と読みやすさ
10章 無関係の下位問題を抽出する
11章 一度に1つのことを
12章 コードに思いを込める
13章 短いコードを書く
14章 テストと読みやすさ
15章 「分/時間カウンタ」を設計・実装する

メモ

命名で相手に意図を伝える

最善の名前とは誤解されない名前である。
命名においては明確な単語を使い（Getではなく状況に応じてFetchやDownloadを使うなど）、読み手が自分の意図を正しく理解できるかどうかを重視する。

コメントで意図を伝える

コードを読めばすぐにわかることをコメントで説明しない。
コードを読んだ人が「質問しよう」と思うところを予想してコメントをつける。

自分も開発の中で以下の様にコメントで補足してみました。
（動作確認用データを作る単純なrakeタスクですが、、、）

task tasks: :environment do
  puts "\n== 動作確認用のタスクを100件作成しています =="
  # seedで作った最初のユーザーと紐付けて作成する
  user = User.first
  raise "\n-- seedでユーザーデータを作成してから実行してください--" unless user

  # 適当に100件
  100.times do |n|
    user.tasks.create!(
      name: "タスク#{n}",
      created_at: Time.current + n.days,
      due_on: Time.zone.today + n.days,
      status: Task.statuses.keys.sample,
      priority: Task.priorities.keys.sample
    )
  end
  puts "\n== 動作確認用データ100件の作成が完了しました =="
end

制御フローを読みやすくする

行数を短くするよりも、他者が理解するのにかかる時間を短くする
こちらも自分の開発の中で取り入れてみました。
とても実効の流れが追いやすく、戻り値もわかりやすくなると感じました。

# 修正前
def current_user
  @current_user ||= User.find_by(id: session[:user_id]) if session[:user_id]
end

# 修正後
def current_user
  return unless session[:user_id]

  @current_user ||= User.find(session[:user_id])
end

オブジェクト思考プログラミング

データと操作をクラスという単位にグルーピングし、クラスに対応するオブジェクトと呼ばれるものを生成して利用するもの。

テストを整理する

整理するための指針

• 新しいテストを簡単に追加できる様にする
• 既存のテストをシンプルで理解しやすい状態に保つ
• テストを見返す度、内容の把握に頭を悩ませずに済む様にする

良いコードを書いて保守しやすいテストを作るための武器

• スペースの入れ方
• 適切な命名
• 重複の排除

テストを整理しておくことで得られる効果

• バグの起きている箇所を特定しやすくなる
• テストのパターンを見つけやすくなる
• 漏れているテストケースを見つけやすくなる

助けになる2つの考え方

• テスト対処を絞り分離すること。一度に多くの内容をテストしようとしないこと
• にているテストをコンテキストによってまとめ、頭を使わずとも理解できる様にしておくこと

モックとは

自動テストで、実際のオブジェクトを置き換えて使うダミーのオブジェクトのこと。

常に本物のオブジェクトを使ってテストすれば良いのでは？？

それは正しい考えで、本物を使えば本番と違う動作をしたりしないし、コードも読みやすく、今書いてある通りに動くため、テストのために特別な準備も必要ない。
しかし実体を呼び出すことが問題となる場合もあり（ユニットテストからの外部サービス呼び出しが高コストだったり遅かったりするケース etc）、モックを導入してオブジェクトを外から操作したり監視したりできる様にしておくと、テストのための設定や準備を柔軟に、また強力に行える様になる効果がある。

TDD（テスト駆動開発）

プロダクションコードの追加より前にテストを書くというプラクティス。

TDDのステップ

1. 失敗するテストを書く
2. テストを成功させる
3. リファクタリングする

TDDの利点

• オーバーエンジニアリングを防ぐ
  • 最初に失敗するテストを書いて、必要性が示された時のみプロがクションコードを追加するため、過剰な作り込みを防止できる
• 設計が改善され、テストされたコードになりやすい
  • 最初か設計とテストについて考えることになるため、保守しやすいシンプルさを保ち、読みやすいコードを生み出せる様になる
• 複雑な内容を扱いやすい
  • 新しいプロジェクトや機能に取り組み始めたばかりの時は、確認すべきことやうまくいかないことが多く、疲弊することも多々ある。TDDでは一度に1つのテストだけに集中するため、問題を単純化し、目の前の課題にフォーカスできる。

新機能の追加時やバグを修正する時、実際に作業をする前に「何が成功なのか？」を常に考えることで、成功の定義が明確になり、スコープが限定され、本当に重要なことに集中できる。

まとめ

「読みやすいコードを書くこと」は機能的に優れたコードを作る。

本書では、より良いコードを書くための具体的な手法がいくつも示されていましたが、それに加えてその手段を使うための考え方が非常に勉強になったと感じました。

コードの可読性を上げることは、アプリケーションの機能とはそれ程深い関係がなく、+αのクオリティの様な問題だと思っていました。
しかし、

• 読みやすいということは、レビューもしやすくなる。
  
• 理解するまでの時間が短ければ、その後開発を進める上でも「ここはどうなってるんだっけ」の時間を減らすことができる。
  

といった様に、開発コストを削減できることを知りました。

加えて設計やテストのしやすさにも繋がって、最終的にはバグも少なく、機能的に優れたコードが出来上がるということを学びました。

どの階層・どのオブジェクトにこの仕事をやってもらい、この情報を知っている状況を作るのかということを鑑みた命名や設計ができる様、今後も勉強していきます。

RubySilver受験記

先日Ruby技術者認定試験(Silver)に合格しました。
自分もいくつかの合格記を参考に学習をしたので、記録も兼ねて残してみたいと思います。 どなたかの参考になりましたら幸いです。

前提（スキルレベル）

• 2020年9月に前職を退職し、6ヶ月のプログラミング学習を経て2021年5月にWeb系受託開発企業へ転職
• ポートフォリオ開発でRailsは少し触れていましたが、生Rubyの使用経験はわずか
• 以前に『ゼロからわかるRuby超入門』を一周で体系的に学習
• 後述するRExの模試の最初の結果は44点でした

学習に使用したもの

• RubyExamination（REx）
• ［改訂2版］Ruby技術者認定試験合格教本（Silver/Gold対応）Ruby公式資格教科書
• 模擬問題集PDF(Silver試験用)
• Rubyがミニツク

学習時間・やったこと

総学習時間は約4週間、30時間程度でした。

RubyExamination（REx）

毎回問題が変わる、解説付きの問題集です。（GitHubアカウントの連携が必要） 主にここで学習をしていました。コンスタントに70点以上を取れた時に、どういう間違い方を狙われているか等、大体の出題傾向や学習すべきことがわかってきた気がします。

［改訂2版］Ruby技術者認定試験合格教本（Silver/Gold対応）Ruby公式資格教科書

[改訂2版]Ruby技術者認定試験合格教本(Silver/Gold対応) Ruby公式資格教科書

公式テキストです。主に巻末の問題集（練習問題30問、模試1回分）を使用しました。

模擬問題集PDF(Silver試験用)

PDFと書いてありますが、GithubGistのページへ移行しています。 RExとは違う問題を解きたくて使用しました。

Rubyがミニツク

問題が幅広く、解説も充実しているので理解が深まります。 試験1週間前くらいに取り組見ましたが、もっと早く手をつければよかったと感じました。

試験結果

スコアは84点（合格ライン:75点）でした。50問中、確信を持った解答ができなかったのが10問程度ありましたが、ある程度選択肢を絞り込むことはできるので、いくつか拾えていたのではないかと思います。

まとめ

模擬試験は30分程度で解いていましたが、本番では何度も見直しをして結局60分ぐらい使ったと思います。
特に

• いくつ選択する問題なのか？
• 出力結果として問われているのはメソッドの返り値なのか？
  • 破壊的・非破壊的を判断する必要の有無が変わる

は見直しでカバー可能なポイントだったと感じています。