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

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倍に

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

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

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

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

まとめ

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

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

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

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

資格を取るための準備で必要だと思うこと

こんにちは。

私は昨年プログラマーとして転職しましたが、「とにかく知識や技術を身につけたい、対外的に何か形として見せられるものが欲しい」、という気持ちで入社してから以下のペースで資格を取得しました。

一般的に高難度と言われているレベルの試験は応用情報を除いて受けていないのですが、今思うと結構早いペースで取得したなーと思います。

そこで今日は、資格を取る上で私が共通して取り組んでいたことを紹介します。

資格取りたいけど勉強のモチベーションが湧かないなーと思っている方の参考になれば幸いです。

ざっくり難易度を知る

資格試験であれば、資格取得サイトや今まで合格した人のブログ等に、目安の勉強時間や何ヶ月で合格しました、といったことが書いてあることが多いです。

その資格を取得できるまでの目安時間を簡単に把握しましょう。

申し込む(⭐️超オススメ)

私が何よりオススメするのは、申し込んでしまうことです。

特に有効なのは通年で受験できる試験です。

資格勉強あるあるで、「受験代を損しないためにも、日々少しずつ勉強して、合格する力がついたら申し込んで合格したい」というのがあると思いますが、少なくとも私(+私の周りの多くの人)はこのスタンスをとると、勉強しません。

いつでもできるからこそ、いつまでもやらないということです。

したがって、受けようかなーと思ってだいたい難易度と目安勉強時間がわかったら申し込んでしまうのがオススメです。

Tips

試験は日曜の15時ごろがおすすめです。

暗記すれば取れるような分野は勉強の中でストックしておいて、土曜から日曜にかけて暗記してしまうのも一つの手です。

私調べですが、15時頃はちょうど頭が働く時間でもあるそうです。

身になる勉強を...などの考えを捨ててとにかく「合格」を目標にする

これも資格勉強あるあるですが、気づいたら問題演習ばかりで「資格合格のための勉強」になっていることがあると思います。

そういう勉強法は良くないと言われがちですが、私はそれは一旦置いておいて、まずは合格を目指せばいいと考えている派です。

途中で「これ本当に役立ってるのかな」とか考え始めるとモチベーションのダウンにつながりますし、逆に資格対策を離れて勉強すると「これで合格できるのかな」等余計なことを考えてしまうと思います。

資格対策に専念するというのは本当の意味でBESTではないのかもしれないですが、モチベーションの維持などを考慮すると、少なくとも悪いことではなく、多くの人はそれほど理想な勉強をできるとも思えないので、割り切って一心不乱に合格を取りにいくのが良いんじゃないかなあと思っています。

資格対策に特化した勉強をしても無意味なんてことは絶対にないですし!

合格したときのご褒美を決めておき、宣言する

私は資格勉強をする前に、合格した時の自分へのご褒美を決めて、宣言をしていました。例えば私の場合はキーボードを買う、などでした。

単純にご褒美を楽しみに頑張る、という効果もありますし、人に言ったからには合格しないと、という気持ちも働きます。

最後に

以上が大体私が行ったことでした。共通して言えるのは、「いかに勝手に自分が勉強する仕組みを作れるか」ということかなと思います。

資格勉強はやりたいけどなかなかそちらにパワーが向かない、、、という方の参考になれば幸いです。

『パーフェクトRuby on Rails【増補改訂版】』を今読んで良かった

ずっと気になっていたものの、量が多くて躊躇っていた『パーフェクト Ruby on Rails【増補改訂版】』を読みました。

gihyo.jp

読んだ感想

  • Railsチュートリアルの延長線くらいのものかと思ったら違った
  • 自分がもしこの本から初めてRailsを勉強していたら挫折してそう
  • 実務も少し経験した今読むと知らないこともたくさん知れてかなり面白かった

構成

この本は全体的に、つまみ食いできるような形で各章が別々の機能説明となっています。

Part1でRailsの基礎知識を学習し、Part2でRailsの周辺知識を学習します。この2つで276ページまで到達するので、かなり手厚く書いてあると思います。

そしてPart3やPart4ではPart1やPart2で使った知識を使いながらサンプルアプリを1つ作りながら学習していきます。

そして最後のPart5は発展的な内容として、サンプルアプリからは離れて、複雑なロジックの場合の対応方法について学習します。

各パートの感想と良かったところ

たくさんありますが、大まかに書くと以下です。

Part1, Part2

不勉強だった以下のような点についても書かれていたり、知らなかった多くの知識をインプットできました。

細かいところだと、scopeとクラスメソッドでクエリインターフェイスを定義する時の違いも知りませんでした。

(例えば find_by を使う場合、クラスメソッド内で使ってレコードがなかった場合はnilを返すが、scope内で使ってレコードがない場合だとScopeの検索条件を除外した結果を返す。)

それぞれサンプルコードで動かしてイメージできるようになっている点も理解しやすくて良かったです。

Part3, Part4

ここではイベント開催して、他ユーザーが参加表明などをできるアプリを作成します。

OAuthを利用してGitHubログイン機能を作るのは自分で実装したことがなかったので勉強になりました。

ただ、アプリ全体の機能については結構基礎的なものだったかなと思います。

Railsチュートリアルで作るアプリの方がその点では発展的な内容を含むかなと思います。

Part5

要すればより良い設計でRailsを書くことについて色々と紹介されている章です。

サービスオブジェクト、フォームオブジェクト、プレゼンターなど、実務で触ったことがある分野もありましたが、Concernや値オブジェクトなど、なんとなく存在は知っていてもどういうものか知らなかったところについても使う場面、使い方から解説されていてありがたかったです。

初学者の1冊目としては完走できるか怪しい?

上記のように発展的な内容もあり、別々の機能の解説がそれぞれの章でされているので、これからエンジニアを目指すような方が最初の入り口としてこの本を選ぶと頭がパンクする人も多そうな気がしました。

本書の対象読者にも以下のように書かれています。

・普段Ruby on Railsを使っていて、一歩先の「レール」に乗りたい人

Ruby on Railsの学習を始め、これから本格的に使っていきたい人

・他のMVCフレームワークを扱ったことがあり、これからRuby on Railsを始める人

 

出典:『パーフェクトRuby on Rails【増補改訂版】』| すがわらまさのり 前島真一 橋立友宏 後藤優一 五十嵐邦明

まさに、という感じです。少なくとも基礎知識を持っていることは前提にしてるようです。

さいごに

実務経験を少し積んで、割とRailsできるようになってきたかな?と思っていた矢先、まだまだ知らないことが大量にあることをこの本を読んで気づけて良かったです。

Railsチュートリアルとの差分もかなりあるので、もし未経験の方などでこの本をやるか考えている方がいるなら、個人的にはやはり最初はRailsチュートリアルを勉強し、理解が進んだらこの本を取り組むくらいがちょうど良いのかなと思いました。

『SOFT SKILLS(第2版)』を読んだので感想と始めたこと

こんにちは。

先日、伊藤淳一さんの以下の記事を見て、私も『SOFT SKILLS(第2版)』を読みました。

blog.jnito.com

今日はその感想と、読んで始めたことを書いていきます。

第1部:キャリア

言われてみれば間違い無いな、と思ったのが専門特化の必要性の章です。

なんとなく今まで、「あれも知ってる、これもある程度できる」という状態になりたいなーと考えていましたが、考え方が少し変わりました。

確かに色々できると求人の選択肢は増えますが、とある分野を突き詰めていると、その分野に関する求人があった場合に必要とされる確率が格段にUPするというのは間違いなさそうです。

もちろんこれからも色々な技術に触れていきたいですが、私はまずRuby, Railsエンジニアなので、そちらをきちんともう一度勉強しようと思いました。

ということでこの章を踏まえて、『Perfect Rails』を読んで学習中です。

gihyo.jp

その次は、一度読んであまり理解できなかった『メタプログラミングRuby』にリベンジしたいです。

www.oreilly.co.jp

第2部:セルフマーケティング

まさにこのブログはこのパートを読んで始めました。

ブログはやってみたいなという気持ちがありつつも踏み出せないでいたのですが、このパートを読んでいるとむしろやらねば!という気持ちになって始めることができました。

また、Fukuoka.rbに積極的に参加するようになったのもこの影響です。これからエンジニアとして生きていく上で、近い領域にいる方々と少しでも交流を持っておきたいと考えて始めることができました。

第3部:学習

このパートで、教えることが最高の学習方法になる、とありました。

ちょうど今の会社で、新入社員のメンターになっています。自分の技術力に自信がなく、あまり技術の話ができていなかったのですが、この本を読んで、自分が実務の中で勉強になったことなどを新入社員の方と話すようにしました

その中で疑問が出てくることもあって、調べて会話などをしているとより良く理解できることも実感しているので続けていこうと思います。

第4部:生産性

ここは実践できていることは少ないのですが、内容はとても共感できるものでした。

ポモドーロテクニックは今まで何度かやっているものの、気づいたらやらなくなってしまっています。効果は十分に感じているのですが、習慣化する前に忘れてしまうという感じなので、これからも忘れては思い出してやって、を繰り返していずれ習慣化できればという気持ちです。

他にも、このパートを読んで以下はやらないとと認識しましたが、なかなか誘惑を断ち切ったり、着手することが正直できていない領域です。

  • YouTubeを見ないようにする
  • 並行作業をしない(どうしてもSlackをこまめに返そうとしてしまうが、1時間おきとかでも良いと思う)
  • スケジューリング

第5部:資産形成

ここはこの本の感想で多く言われている通り、色々と感想が分かれそうですが、少なくとも私は資産形成に関する知識が少ないので、まずは書かれている通り知識を身に付けないと話にならないなと感じました。

今は会社員としてプログラミングしているのが楽しいですが、今後のことを考えても選択肢を増やす方法を取らない理由はないので、勉強しないといけないという気持ちです。

伊藤淳一さんがお金に関する本を読んだブログを上げていたので、その中から選んで読んでみようと思います。

blog.jnito.com

第6部:フィットネス

運動不足の私にとっては、読むのが辛い章でした。笑

20代というのでかまけているといずれ大後悔が待っていそうなので少しずつでも運動せねば、、という気持ちです。

とりあえずこの本を家で読むときは家の中で立って読んだりしてみました。

第7部:マインドセット

自分でコントロールできないことに振り回されるな、といった趣旨の話が出てくるのですが、私が大学生の頃に大流行したアドラー心理学をもとにして書かれている『嫌われる勇気』を思い出しました。

www.diamond.co.jp

当時も共感してずっと意識するようにしているのですが、それがまだ体に落とし込まれていないので、これからも意識し続けていきたいですね。

感想

この本をきっかけにいくつか始めることができたことや考えることができたこともあったのでとてもよかったです。

個人的には、こうすれば全てうまくいくよ、といった論調ではなく、ハードワークも人生の中で絶対にしないとダメだよ、などのパートもあり、現実主義な内容だったのが気に入りました。