Top Category

2024年の振り返り

はじめに今年も気がつけばあっという間の一年でした。バックナンバー 2021 年の振り返り 2022 年の振り返り 2023 年の振り返り 2024/01 仕事前職の同僚に誘ってもらい、新しい環境で副業を始めました。新規案件でかつ、バックエンドの技術選定から参画することになりました。なるべく少人数でかつ、言語経験者が少ない中でスピード感をもって開発できるようにしたいという要望を踏まえて、自分の中で最良のアーキテクチャを考えるのがすごく楽しかったのを覚えています。プライベート Auth 屋さんの本を読みました。社のドキュメント読むために、Auth屋さんの本で改めて勉強してみて、雰囲気わかるからだいぶ整理できましたhttps://t.co/gyIbYnT4Gz — reo (@_uhzz_) January 11, 2024 2024/02 仕事たしかこの時期はスキーマ変更の多い機能を開発していました。いつか使うときが来ると確信した、令和はこれでいくhttps://t.co/350E4A8El3 — reo (@_uhzz_) February 13, 2024 大学以下の科目習得試験を受験しました。論理回路微分積分 1 昨年の分をここで取り返しました。プライベート初めて確定申告をしました。初回だいぶ苦戦を強いられたのですが、もう第二回が近づいてきてると思うと少し憂鬱です。月に一度は通うくらいお気に入りですが、しばらく投稿をサボっていました確定申告を完了させた開放感から、朝サウナをキメることにしましたアロマロウリュのあるサウナと迷い... (＠多摩境天然温泉森乃彩 in 東京都, 町田市) https://t.co/PF36kygWA8 — reo (@_uhzz_) February 29, 2024 また、この時期に初めて北海道に行きました。雪まつり直後だったのですが、自分の身長より高く積もった雪の中滑る道路を歩けたのは、南国生まれとして感慨深かったです。初めて見たこのオブジェに感動したので写真を撮っていました。(砂箱というらしいです) 2024/03 仕事転職しました。経緯については入社エントリに書きましたのでぜひ一読ください。【入社エントリ】Finatext に入社して９ヶ月経ちましたプライベート PostgreSQL で全文検索するためのpg_bigmについて調べていました調べるほど沼ってたけど、この資料で腹落ちできた(特にfastupdateがイメージ図が助かりました)https://t.co/DS6GyUnrzv — reo (@_uhzz_) March 16, 2024 2024/04 仕事 Go Conference 2024 の LT が採択されて、2024 年上半期で一番アガりました。

Tuesday, December 31, 2024 Read

Go Conference 2024参加レポ

はじめに先日、オフラインで開催された Go Conference 2024 に参加してきました。 https://gocon.jp/2024/ Go Conference で登壇デビューできた感想と、リアタイできた発表のレポートをしていきます。発表レポ(というか感想)は、リアタイできた発表をご参照ください。(しばらくポエムになります) 発表緊張した… 当日の発表スライドはこちらです https://gocon.jp/2024/sessions/21/ まずは、発表のためにフィードバックをいただいた皆さんほんとにありがとうございました！！また、激励してくれた同僚＆元同僚にもほんとに感謝です 🙏 どうしても発表は緊張するものなのですが、スライドはみんなに見てもらって恥ずかしくないものを持ってきた、というのが心の支えになりました。おかげで、当日は気持ちよく発表することができました。会場からの反応もいただくことができて、発表後のエゴサが止まりませんでした笑こちらもありがとうございます👋 足向けて寝られないぐらいお世話になってる oapi-codegen#gocon — RADISH (@ruby_engineer) June 8, 2024 oapi-codegenの生成コードを使うと、endpointごとに個別のミドルウェアを差し込めない課題がある。わかる！そうだよそこだよ！ #gocon — 鹿 (@mizushika1) June 8, 2024 oapi-codegenメインで使ってるから助かる#gocon — パンダム/rymiyamoto (@rymiyamoto129) June 8, 2024 ちょうど oapi-codegen で chi のサーバーボイラープレートを試してたけど、パスごとのカスタムミドルウェア周り課題あるなあというのを思ってた #gocon

Tuesday, June 11, 2024 Read

2023年の振り返り

はじめに今年はここ数年でも特に怒涛の 1 年でした。公私共に変化が激しくて、心が折れそうになりながらもなんとか乗り切った感があります。いつも通り(?)需要の有無に関わらず振り返っていきたいと思います。バックナンバー 2021 年の振り返り 2022 年の振り返り 2023/01 仕事新年明けてすぐ、所属チームを異動することになりました。入社してから n 年後には、そのチームでチャレンジしたいと思っていたのですごくワクワクしました。プライベート週 1 で ROOFTOP サウナに行ってました。 #サウナ今年のサウナ初めでした。こちらに来るのは４，５回目です。２時間で4セット回しましたがあっという間でした。今日のアロマは木？の香りで、ロウリュ直後... (＠ ROOFTOP in 東京都, 杉並区) https://t.co/pavDmbYmWE — reo (@_uhzz_) January 6, 2023 2023/02 仕事チームを異動してすぐに、翌月のリリースに向けた機能開発が始まりました。都度リードエンジニアに設計方針を確認しながら、のびのび開発できました。コミット量はこんなかんじ副業前職で副業を始めました。正社員時代と同じチームに参加させていただくことができ、業務内容もバックエンド開発がメインです。大学以下の科目習得試験を受験しました。 Web アプリケーション離散数学 Web 技術基礎特に離散数学で扱うグラフ理論は、入学してから一番 Computer Science してるなと実感しました。プライベート高校からの友人に結婚のご祝儀を渡しました。祝儀袋を買って、お金を包むイベントは初めてだったので、とても感慨深かったです。 2023/03 仕事 2 月に開発していた機能をリリースしました。詳細はこの後で触れるのですが、チームを異動して初めてのリリースでした。プライベート軽井沢観光に行きました。長野出身の同僚に教えてもらって、旧軽井沢銀座通りやミカド珈琲を巡りました。個人的には、白糸の滝に行けたのが１つ思い出になりました。筆者撮影桜が綺麗ですね 🌸

Sunday, December 24, 2023 Read

2022年の振り返り

はじめに１年経つのは早いですね。今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。バックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます 2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました初のオンライン合宿開催！開発合宿についてご紹介！ Gatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。このとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり😌 2022/03 とくに話すことはありませんでした。 2022/04 ふらっと Kyash のイベントを見にいきました。 Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。このイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。またプライベートな話題としては、通信大学に入学しました【通信教育課程】帝京大学理工学部情報科学科に編入学しました入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。この振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。 2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです。今も継続して週に 2 回くらいは走りに行ってます。走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。 2022/06 とくに話すことはありませんでした。 2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。内心なにかしら交流があるかも😌、とそわそわしていましたが、杞憂に終わりました。 2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑 2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。社会学新版 (New Liberal Arts Selection)

Saturday, December 31, 2022 Read

履修科目一覧をNotionでつくりました

ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）近況元気にやっています👋 備考表紙イラスト：Loose Drawing

Sunday, September 4, 2022 Read

【通信教育課程】帝京大学理工学部情報科学科に編入学しました

はじめに表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。きっかけ大学進学について通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。ただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しいとりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。キャリアについて考えるようになったそんな中、昨年末に以下の記事を拝見しました。生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡 IC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。これまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略) 1 つは「毎日楽しく開発したい」ということ。(中略) もう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略) この「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。ここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。帝京大学に決めたのはそこまで時間がかからなかったフルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。また、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる帝京大学の通信教育課程の学生やってます @gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。入るまでの手続きなど詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について今回 2 年次編入で出願することができました。というのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。そして入学しました出願から約 2 ヶ月後、晴れて入学式を迎えることができました。

Tuesday, May 31, 2022 Read

2021年の振り返り

はじめに今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。しばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！ 2021/01 とくに話すトピックはありませんでした。読んでた本改訂 2 版みんなの Go 言語 Go プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る 2021/02 とくに話すトピックはありませんでした。読んでた本達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。 2021/04 転職しました。社会人４年目にして３社目になります。前職と同じくサーバーサイドのポジションです。前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。はじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。読んでた本プロを目指す人のための Ruby 入門言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ) パーフェクト Ruby on Rails 【増補改訂版】 (Perfect series) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

Friday, December 31, 2021 Read

達人プログラマーとは

はじめにエンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています達人の哲学ソフトウェアのエントロピーの話は心当たりがありすぎたエントロピーとは、物理学の用語で「ある系における無秩序の度合い」のことで、時間が経つたびにエントロピーは増大していくソフトウェアも同様に、時間が経つたびに無秩序になっていくこれを割れ窓理論というメカニズムで説明していたのもわかりやすかった窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが植え付けられて、最終的には建物全体が破壊されていくソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、放置しておくと潜在的なバグを生み出すことになりかねないこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを残すといった何らかのアクションをしてくださいと言った主張だった茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じたあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話要するに、いつもメタ認知を意識して行動しようということこれは仕事に限らずしていきたい達人のアプローチ章前半のDRY 原則については膝を叩いて同意できるといった実感があったまた、曳光弾の考え方については目からウロコだった複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法シンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン毎回トピックの初めに、名言があってモチベーションが上がるプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方やコミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い基本的なツール「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」ということを知るのはつらいものだ - ソフォクレスデバッグの最初の心構え → 「パニクるな」妄想の達人契約プログラミング(DbC) は素晴らしい仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをするトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる Go のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、柳に雪折れなし列車の衝突事故を例にして依存をわかりやすく説明している１つのメソッドであまりにも多くのことをやろうとすると、連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける例)割引料金を算出するメソッドの中で、これらの操作を行う。顧客の注文履歴を参照する注文履歴から特定の注文オブジェクトを取得する注文オブジェクトの総額を返す総額から割引した値をオブジェクトにセットする次のような考え方がある照会せずに依頼する TDA(Tell, Don’t Ask)

Friday, March 5, 2021 Read

OAuth について

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 OAuth とはひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。こちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。ただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。そして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。メリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。 OAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可) 特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが) また、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。 (Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです) さらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。 OAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。これによって実装しやすいものになりましたがセキュリティが気になるところです。 OAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。 (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

Tuesday, January 5, 2021 Read

システム設計-part1-

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。設計パターン値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。値オブジェクトクラスはこんなかんじ class Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value < MIN) { throw new IllegalArgumentException("不正" + MIN + "未満"); } if (value > MAX) { throw new IllegalArgumentException("不正" + MAX + "超"); } this.value = value; } } そして参照はこんなかんじ Quantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。

Saturday, December 5, 2020 Read

システム設計-part2-

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。設計パターン早期リターン複雑になりがちな場合分けのロジックの見通しをよくしようというものです。ありがちなif-elseをつなげた(例 1) Yen fee() { Yen result; if (isChild()) { result = chidFee(); } else if (isSenior()) { result = seniorFee(); } else { result = adultFee(); } return result; } さっきのコードからローカル変数を抜いて結果をすぐにreturnするようにした(例 2) Yen fee() { if (isChild()) { return chidFee(); } else if (isSenior()) { return seniorFee(); } else { return adultFee(); } } このように、値が決まるとすぐにreturnするやり方を早期リターンと言います。ガード節上記の例 2 からelseを抜いた(例 3) Yen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。

Saturday, December 5, 2020 Read

システム設計-part3-

はじめにバックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。業務ロジックメソッドをロジックの置き場所にする現場で役立つシステム設計の原則では、“従来"という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。その名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。この手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。なぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。解決としては、Java 本来のクラスの使い方を踏襲することです。データとロジックを 1 つのクラスに閉じてしまおうという考え方です。 class PersonName { private String firstName; private String lastName; String fullName() { return String.format("%s %s", firstName, lastName); } } データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。こうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。また、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。クラスが肥大化したら小さく分けるこれもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。それを防ぐために、大きくなってしまったクラスを次のルールで細分化します。インスタンス変数とメソッドを対応付けるメソッドが全てのインスタンス変数を使うようになる細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。こうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。まとめ時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。備考現場で役立つシステム設計の原則表紙イラスト：Loose Drawing

Saturday, December 5, 2020 Read