質問に答えられるって嬉しい

今回はただの日記です。

 

プログラマーになって1年以上が経ちますが、わからないことだらけ、教えてもらってばかりの毎日です。

そんな中で、この前、個人宛ではない、汎用性のある技術的な質問に答えることができたので良い日になりました。

「個人宛ではない、汎用性のある技術的な質問」

ここでいう「個人宛ではない」というのは私一人宛ではなく、チャンネルのメンバー全員に広く聞いているもの、ということを指しています。

また、「汎用的」というのは、「そのプロジェクト(案件)固有ではない」ということです。

今までも、例えば「このメソッドってどこで使っているの?」とか「このバグの原因がわからない、、、」という同僚からの質問に対して答えていたことはありました。

ただ、それらは「そのソースの固有事情に対する」解決法でした。

そういう質問に回答するのって勇気がいる

明確に自分が指定されているレビュー依頼や質問で会話するのと違って、こういった(グループ宛に投稿された)質問は「わかる人が答える」という状況になります。

今までも社内の質問チャンネルなどで、「答えられそうかも」みたいな機会はありましたが、「私よりよほど優秀なエンジニアがいるし、、、」「意気揚々と答えて間違っていたらカッコ悪いな、、、」みたいな気持ちでなかなか手が止まってしまうことが多かったです。

答えられた!

今回はRSpecに関する質問がチャンネルに投稿されました。

内容は、「通らないテストがあるが、通らない理由がわからない」というものでした。

貼られているコードを見て、ちょっと心当たりがあったので少し検証して、「これでどうですか?」と改修版のコードを説明して、動かない理由を説明してみました。

(この辺りの具体的な技術の話はQiitaに載せたいです。)

すると、無事解決できたみたいでした。

自分の成長も感じて、嬉しい気持ち

回答にあたって使った知識は、プロジェクトのメンバーが以前Slackで会話しているのを偶然読んでいて、「へー」と思ったことに由来します。

たった1問の質問を答えただけなんですが、技術的な課題に対して、得た知識とテクニックを使い、共有できたこと、今まで身をひいていたところで前に出れたことは、少しだけ成長を感じて充実した気持ちになったという話でした。

(案ずるより産むが易し)自作gemとCircleCIデビューしたら簡単だった

先日、会社の同僚が社内LTで「gemを作ってみたけど簡単だった」と言っていたので、なんだか難しそうと思って敬遠してしまっていたgem作成(ついでにCircleCI導入)をしてみました。

結論から言えば、すごく簡単でした。

gemを作ってみた

gemの作り方は以下の記事がとてもわかりやすかったので、ここでは繰り返しで手順を記載することは避けます。

qiita.com

作ったgemについて

今回は目標が「gemを作ること」だったので、内容は本当に簡単なものです。

私はプロ野球が大好きで、指標を眺めたりするのも好きなので、野球に関する指標を計算してくれるgemにしました。(といってもOPSという指標のみ)

rubygems.org

RubyGemsでの公開も簡単にできました。どれだけ簡単でも、公開されると達成感がありますね。

ちょっと変なことを言うようですが、公開されたという事実よりも、検索フォームで「baseball」と打つとサジェストで「baseball_stats(←私の作ったgemの名前)」と出るのが嬉しかったです。

なんだか認められた感というか、、、

Circle CIを使ってみた

ついでに、業務で使っているものの、設定などしたことがないCircleCIも使ってみました。

circleci.com

CircleCIでこのgemのRSpecを自動化してみました。

公式ドキュメントや記事を見ながら設定ファイルを書いてみましたが、「push時にRSpecのテストを走らせる」というところは達成できました。

最後に

単にQiitaの記事をなぞったりCircleCIの初歩の初歩を試して満足しているだけですが、今までgemやCIツールとの間にあった距離が縮まったのが嬉しかったのでブログに書きました。

「やってみる」って大事だなあと再認識した経験でした。

『情熱プログラマー』を読んで印象的だったことをつらつらと

はじめに

同僚に勧められた、『情熱プログラマー』を読んだので心に残ったことをつらつらと書いていこうと思います。

shop.ohmsha.co.jp

1番の下手くそでいよう

「自分が一番下手くそ」な環境に身を置くことで、周りに引っ張られるように成長できるという話でした。

私が今参加している地域のRubyコミュニティは、周りのレベルが高く自信を失いかけることもありますが、自分が一番下手くそであることに対する恐怖心を捨てて前向きに参加を続けていこうと思えました。

ビジネスを知る

利益を上げる等して会社に貢献することが仕事である以上、エンジニアであってもビジネスの仕組みについて理解することは当然必要である、という話です。

これを見て、ドキッとしました。

今参加しているプロジェクトが準委任契約で入っていることもあり、コーディングに気を取られるあまり、ビジネスへの理解を蔑ろにしてしまっていたことがあるなと思うのでこれをおろそかにしてはいけないですね、、、

アドベンチャーツアーガイド

マネージャーや顧客は往々にして自分が理解できない単語を話し、頭も切れるエンジニアを怖がっているため、安心感を与えることが必要という内容です。

とても共感できる内容として印象に残っています。

自分は元々非エンジニアとして仕事をしていたのもあり、エンジニアを「怖がる」という経験をしたことがあります。

わかる言葉で、顧客の行きたい場所に連れていく、本書でいうツアーガイドのようになりたいと改めて思いました。

ウォーターフォール式のキャリア開発はやめよう

ウォーターフォール式にキャリアを定め、それを目標にして変更することなく突き進むのではなく、自分がやりたいことや社会の需要に合わせてキャリア変更を行っていこうという内容です。

重要だなと思ったのは、「キャリアチェンジに対して柔軟でいること」という点であり、無計画で良い、という点ではないことです。

実際にこの前の章では「自分のロードマップを作る」という章で自分の成長の仕方を考える重要性が書かれています。

最後に

分厚い本でもないのでスラスラ読めますし、自分のキャリアを考える上で色々なヒントが書かれていたと感じます。

『オブジェクト指向設計実践ガイド』は私にはもう一度読む必要がありそうでした

Rubyを扱うプログラマーなら読んでおきたい本としてよく紹介されている『オブジェクト指向設計実践ガイド』を読みました。

gihyo.jp

バイブルとして読み返しが必要

全体的な感想から言うと、私は、これを自分のコーディングに落とし込むには1回読むのでは足りなさそうです。

本書では自転車やそのパーツなどを例にオブジェクト指向で書く方法が展開されていきます。最初はいろいろな問題を抱えたコードで、何度かプロセスを踏んで良い設計になっていきます。

実際に具体例(Ruby)を見ながらテキストに書いてあることを理解していけるのでその点はとても分かりやすかったです。

一方で、コード例が出てこない第4章などはなかなか具体的にコーディングに落とし込むには?を考えたときに、まだまだイメージができていないので力不足だと思いました。

決定を遅らせるという判断

なるほど、と思ったのが、設計を早々に決定すると逆にコストが増大することがあるので、設計の決定を延期するという方法がいくつかの章でとられていたことです。

今後そのアプリケーションのビジネスモデルがどのように変化しているか不確定なときは、最初にガチッとした設計をしてしまうと逆に自分の首を絞めてしまうことがありそうです。

単一責任のクラスにすることで変更しやすい設計となり、後々の設計の決定の判断を先延ばしにできるというのは納得感がありました。

最後に

このほかにも、依存の方向性を意識することや、継承に対する意識などが具体的に書かれており、かなり勉強になったと思います。同時に、今まで書いていたのはなんちゃってオブジェクト指向だったなとも痛感しました。

ただ、冒頭で書いたようにまだコーディングに全て落とし込めるかといったらまだまだなので、また時間を空けて2回目読んでみたいと思います。

抽象的な話を一発で具体に落とし込める人本当にすごいです、、私はコツコツ頑張ろう、、

『エンジニアのための文章術』から得たメソッド

先日、職場の同僚に勧められて『エンジニアのための文章術 再入門講座』を読みました。

honto.jp

 

前職は役所で働いており、メールを書くことが多かったのである程度は身についているものもありましたが、重要だなーと再認識したことや、なるほどと思ったことを紹介したいと思います。

役員と同僚では視点が違う

経営(やプロジェクト)の大局を見て判断する役職にいる役員やリーダーと、自分と同じように1人の開発者としてプロジェクトに関わっている人では、物事に関する関心事項、判断するポイントが異なります。

これを踏まえて、自分の視点からの説明ではなく、必ず相手の立場に立った説明をすることが重要です。

当たり前の話ではあるのですが、ついつい自分視点で書きたいことを書いてしまっていないか、文章を送る相手がどこを気にするかをきちんと考えることを意識する必要があるな、と再認識しました。

断るときは相手が判断をするかたちにし、かつ相手側の大義名分を守る

どうしても時間的、人的リソースが足りず、依頼を断らざるを得ない場面はたくさんあると思いますが、その場合はこの2点を意識すると良いようです。

相手が判断をするかたちにする

「〜なので、お見送りさせていただきます。」といった言い方ではどうしても相手に不満を残してしまいがちなので、きちんと理由を述べた上で、最後は検討してもらうかたちにし、相手が判断をするかたちを取ると相手の不満も抑えることができます。

ただ、ここで私が感じたのは、検討してもらうという方向に意識が向きすぎて対応が難しい理由づけなどを緩めてしまうと、相手が素直に受け取ってしまい、交渉が困難になることも起こりそうだなーということです。したがって、実質逆転が起こらないように理由を明確に書いた上で、かたちだけ検討してもらうという意識が大事かなと思いました。

相手側の大義名分を守る

これは要するに、「こちらがやりたくないのではなくて、あなたにこんなデメリットがあるんです」という伝え方をするべし、という内容です。

あなたがやりたくないだけですよね、と思われると交渉が難しいので、相手の立場に立った上で、起こりうるリスク等を丁寧に説明することで、断る交渉がスムーズに行きやすそうです。

これはかなり納得感があります。確かに「あなたにこんなリスクが発生しますよ」と言われてしまったら、それを覆すのは難しいですよね。

最後に

エンジニアのためとありましたが、ビジネスマン共有で通ずる内容だと思います。面白い内容でした。

 

『良いコード/悪いコードで学ぶ設計入門』を読んだので良い設計への意識を高める

はじめに

書店でもピックアップされ、Twitterでもかなり話題になっていた『良いコード/悪いコードで学ぶ設計入門』を読みました。

gihyo.jp

最近仕事で、設計についてコメントをもらうことが多くあり、動くコードから一歩進んで、良い設計のコードを書きたいなーと思ったためです。

Javaは知らなかったが大丈夫だった

本書はサンプルコードを使いながら解説がされていますが、サンプルコードの言語はJavaです。

私はJavaをやったことがなく、理解できるか不安でしたが、文章中にコードの意味を説明してくれているのと、簡単なサンプルコードなので問題なく読み進められました。

本を読んでこれから気をつけてみようと思った点

以下、本書を読んで気をつけなきゃなーと思った点を今後の自分のチェックリストを兼ねて記載していきます。

第2章 設計の初歩:変数の再代入を避ける

連続する処理をいくつか書いていくと、途中結果を同じ変数を変化させながら使ってしまっていたことがありました。

ただ、途中経過で変数の意味が変わってきたら、その都度別の変数に代入してあげないと後から読みづらくなるので目的ごとに変数を用意することに気を付ける必要があります。

第3章 クラス設計:値の渡し間違いを型で防止する

例えばMoneyクラスのaddメソッドで、Moneyクラスの別のインスタンスのcurrencyを足し算をしたいとなった場合、引数を単に数値にすると、想定外の数値をミスでいれてしまうかもしれません。

しかし、Moneyクラスのインスタンス(moneyとします)を受け取るようにし、メソッドの中でmoney.currencyを足すようにすれば、想定外の引数が渡されることを防ぐことができます。

第8章 密結合:単一責任の原則

私が機能追加をする場合、ついつい使えそうなクラスにメソッドを追加するなどしてしまうのですが、この章を読んで考えを改めようと思いました。

本書内では価格の例を用いて、割引でも1つのクラスにまとめず、割引の種類によってクラスを分けるべきという話が例として出されています。

「クラスが担う責任は1つだけ」になっているかをチェックしながら実装していく必要があります。

第8章 密結合:継承に絡む密結合

継承をするとスーパークラスが共有ロジックの置き場となっていき、結果単一責任が守られず、密結合になっていくリスクがあるという内容が書かれていました。

実装時点では継承で追加コードを省略して書けそうでも、一度止まって考えることが大切になりそうです。

第10章 名前設計:目的駆動名前設計

可能な限り具体的で、意味範囲が狭い、目的に特化した名前を選ぶ

 

『良いコード/悪いコードで学ぶ設計入門』p.211 より

具体的にするというのは意識しなきゃと思っていましたが、目的に特化というのはあまり意識できていなかったです。

本書では単に「商品」といった存在ベースでの命名ではなく、「予約品」「注文品」etcといった目的ベースで命名をすると曖昧にならず混乱を避けられると紹介されています。

最後に

実務経験1年がたって、動くコードだけではなくきちんと設計されたコードを書きたいと思ったので手に取ってみたのですが、とても勉強になりました。

プログラマーの私が『エッセンシャル思考』を実践するにはを考える

『エッセンシャル思考』を読みました。

kanki-pub.co.jp

難しいけど実践したい

なるほどな、良い思考法だなと思いつつ、実践するにはなかなかパワーがいるなと思ったのが正直な感想です。

そこで、プログラマーの私が『エッセンシャル思考』で生きるにはどのような場面で活きるかを考えてみました。

その機能の本質はどこにあるかを考える

機能開発していると、仕様を固めていく上で気づいたらユーザーのニーズには程遠く、開発側の自己満足に近い機能が出来上がっていることがあると思います。

ここで使えるのはこの本の中にもある「本質を見極める」技術で、結局のところ、ユーザーのどんな問題を解決したいのかを明確にし、ただひたすらその解決に突き進むという思考が必要なんだと思いました。

開発の切り白はないか?を点検する

開発をしていると、この機能を開発するには、開発による結果に対して工数がかかりすぎないか?と思うような事態に遭遇します。

今まではその機能は本当にいるのか、といった提案はあまり開発側からしない方が良いのかなと思っていたのですが、よく考えると、より少ない工数で、より本質的な機能の開発に注力する努力を怠っていただけな気がします。

見積もりは自分の考えた「遅れるケース」の更に1.5倍に

見積もりの章の例に出ていた研究の内容がとても面白く、納得感がありました。

学生に卒業論文にかかる時間を見積らせたところ、最大でもこれくらい、と答えた見積もりの時間よりも実際にかかった見積もりの方が多かったというもので、しかもその原因は「人によく見られたい」という説もある、というものです。

確かにこれはやってしまっているなーという自覚があります。

それで想定通りに進まないと焦って細かいチェックを怠ったり、テストケースが雑になったりした経験があるので、これはすぐにでも実践しないとな、と思いました。

まとめ

プログラマーは専門職ゆえにエッセンシャル思考を取り入れやすい職種かなと読んでいて感じました。

一方で、「エッセンシャル思考はノーを言えることだ」というところに関しては、「わかっちゃいるけど難しい」という感想です。なかなかノーという勇気って出ないですね、、

はっきりノーと言わないけど断るメソッドもいくつか紹介されていたのでちょっとずつ実践していきたいです。

いずれにしても、この思考を定着させるには、この本を定期的に読んで自分が非エッセンシャル思考になっていないかを点検する必要がありそうです。