「奥野さんと社員のリファクタリング部屋」は、リファクタリングに励むトレタの社員と技術顧問の奥野さん ( @okunokentaro ) の間で実際に行われた会話を切り取った開発現場実録コンテンツです。 技術顧問: 奥野さん 三度の飯よりリファクタリングが好き 今回の質問者: 武市さん トレタ在籍2年。沖縄在住のフロントエンジニア 今回の質問 前回に引き続き、Webアプリケーション (Next.js) のプロダクトのリファクタリングを進めている武市さんから、ディレクトリ構造のリファクタリングについての質問です。 tech.toreta.in 前回の指摘も踏まえて、新しいディレクトリ構造とその定義を考えてきました。 ┗ server ┃ ┣ boundary -- 外部システムとのやり取りを行うためのエンドポイント。 ┃ ┃ ┗ mojito ┃ ┃ ┃ ┗ mojitoClient.ts ┃
API シナリオテストツール runn とは 今回は、API シナリオテストツールである runn について紹介します😉✨ runn の主な特徴 runn は Go 言語で実装されているツールで、主な特徴は以下です。 発音は「ラン エヌ」です。 シナリオベースのテストツールとして機能 Go 言語用のテストヘルパーパッケージとして機能 ワークフロー自動化ツールとして機能 以下をサポート： HTTP リクエスト gRPC リクエスト DB クエリ Chrome DevTools Protocol SSH/ローカルコマンド実行 HTTP リクエストテストに OpenAPI 文書に似た構文を使用 単一のバイナリファイル = CI （継続的インテグレーション）に適している 引用: k1LoW/runn: runn is a package/tool for running operations f
はじめに 技術ブログには、プログラミングやインフラ、アーキテクチャといった技術情報はもちろん、マネジメントや開発プロセスなどIT業界で働く皆様のヒントや刺激になる情報が日々蓄積されています。 特にエンジニアの方にとって、有益な情報が非常に多く詰まっています。 そこでこの記事では、エンジニアにおすすめの技術ブログを紹介します。ぜひ参考にしてください。 NRIネットコム まず紹介するのはNRIネットコムの技術ブログです。 Webアプリケーションから、インフラやデザイン、プロダクトマネージャーまで幅広い分野の記事が公開されています。 2024年2月末に公開された「エンジニアは育児に向いているかもしれない」は、TECH PLAYユーザにも人気の記事です。 育休制度についても詳しく記載頂いているので、プレママ・プレパパの皆さんはぜひ読んでみてください！ スマートキャンプ株式会社 次にスマートキャンプ
【技術書】最近読んでよかった本まとめ - Qiita
はじめに エンジニア歴1年目の頃に「新人エンジニアの自分がおすすめする技術書ランキング2022春」という記事を投稿したのですが、エンジニア歴も4年目に入ったということで、改めて最近読んで良かった本を紹介しようと思います。 前回の記事とは違い、ランキングづけはせずにビジネス紹介しようと思います。 ビビッとくるものがあればぜひ手に取ってみてください。 なお今回は紹介しませんが、いまだに1番読んでよかったと思っている技術書はオブジェクト指向設計実践ガイドです。最強です。 プロダクトマネージャーのしごと第二版 感想 仕事でプロダクトマネージャーっぽい動きはするけれど、実際に何したら良くて何をする人がPMなのかさっぱりわからんってなってた時に買いました(同じ状況の人がもしいればおすすめです) PMの仕事の輪郭は多少見えるようになったと思います。有り体な言い方をするのであればPMへの解像度が上がりまし
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や
ソフトウェアの振る舞いは、拡張できるようにすべきである こちらは「オープン・クローズドの原則」に関する記述です。 ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべきである、ということだ。 これこそが、我々がソフトウェアアーキテクチャを学ぶ根本的な理由だ。 ちょっとした拡張のために大量の書き換えが必要になるようなら、そのソフトウェアシステムのアーキテクトは大失敗への道を進んでいることになる。 拡張可能な設計！ 肝に銘じます！ インターフェイスは分離させよ こちらは「インターフェイス分離の原則」に関する記述です。 必要としないモジュールに依存することは一般的に有害とされる。 ソースコードの依存関係においては、再コンパイルや再デプロイを強制されるので明らかに有害であることがわかる。 だが、さらに上位のアーキテクチャレベルにおいても有害なのだ。 この辺りは今どきのフレームワーク
はじめにこの記事は、2024年6月14日に開催されたテックイベント「設計ナイト2024」で筆者が登壇して話した内容をまとめたものです。設計ナイトは、「吉祥寺.pm」というテックイベントを主宰する@magnoliakさんによる個人の勉強会です。個人の勉強会なのに、虎ノ門ヒルズにあるCARTA HOLDINGSさんの素敵なオフィスのイベント会場で開催され、100名もの技術者を集客していました。すごい！ なお本記事は、発表内容のテキスト起こしではなく、当日話し切れなかったことや、他の登壇者の話を聴いて得た気づきなども盛り込んでいます。 発表スライド全体はDocswellで公開しています。 コンポーネントとは何？コンポーネントの定義私たちは日々の開発の営みの中で、「コンポーネント」という言葉をよく使います。ですが、コンポーネントという用語は幅広い意味で使われ、標準的かつ共通的な定義はありません。言
当たり前ではあるが、継続的にプロダクトを開発し続けるためには、継続的にプロダクトを開発し続けられるソフトウェアを維持する必要がある。 なので、継続的にプロダクトを開発し続けられるソフトウェアにするには、どうすればよいのかを理解しておく必要がある。 また、”スピードを優先する”的な発言が多々あると思うが、意図的に優先するためには、優先しない場合を理解し実践できる必要があると思われる。（意図的に負債をためている） 仮に、”優先しない場合を理解し実践できない”状態で”スピードを優先する”を行うと、”とりあえず動くが継続的に開発し続けられない”状態になるスピードも暗黙的に早めていると思われる。（意図せず負債をためている） で、”とりあえず動くが継続的に開発し続けられない”状態になってしまったと仮定して、なんとか”継続的に開発し続けられる”状態に持っていきたい場合を想定する。 その状態に持っていくた
はじめに メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。 11月中旬頃から勉強を初めて、1月中旬に無事UMTP L1~L3まで取得することができたので、その記録を残しておこうと思います。 UMTPに興味を持たれている方のお役に立てれば幸いです。 どんな資格？ 「UMTP/JAPAN 特定非営利活動法人UMLモデリング推進協議会」が主催している、UMLの理解、モデリング能力が問われる試験になっています。 求められるレベルは、それぞれのレベルで異なっており、公式サイトの説明では次のようになっています。 UMTP L1：UMLなどを使ってモデリングを行う最低限の知識を持っている。 UMTP L2：UMLモデルの読み書きが普通にできる。 開発範囲の一部を担当し、モデリングができ、他者のモデルの意味を理解できる。 UMTP L3：実務でモデリングが実施できる ・拡張
概要 GolangでServiceを作る中で感じたunittestおよびClean Architectureという壁についてまとめてみた。 Golangにおけるテストとモック 『Unittestのために、モジュール間参照はインターフェースを使わなければならない』 Golangでunittestを書こうと思ったとき、困るのがモックだ。 例えばJavaであれば、どんなClassもそれを継承したClassを（無理やり）作る事ができるので、対象のコードの中の依存オブジェクトをモックに差し替える事ができる。 例えばPythonやJavaScriptであれば、そもそも型がないので自由にモックに差し替える事ができる。 ところが、Golangでは、
![[golang] 言語仕様から見るunittestとClean Architectue - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed8f6ec10a806a84a04d2ba633f508f484016440/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ29sYW5nJTVEJTIwJUU4JUE4JTgwJUU4JUFBJTlFJUU0JUJCJTk1JUU2JUE3JTk4JUUzJTgxJThCJUUzJTgyJTg5JUU4JUE2JThCJUUzJTgyJThCdW5pdHRlc3QlRTMlODElQThDbGVhbiUyMEFyY2hpdGVjdHVlJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz00ZmVhZjc0MWFiM2E1MmViNGI5OWFiNzc4ZTc1OTRhNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBraXNoaWJhc2hpMyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MGU2ZTdkMGI1ODU3ODZmMjBkNWM4MDQxYzA4ZmEzYjM%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g44Km44Or44K344K544OG44Og44K65qCq5byP5Lya56S-%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Decd099c60d5f0bda39e78dbc4cfb5f16)
自ブログからの引用です。 はじめに GraphQLは非常に高機能なツールである一方、万能が故に本来必要でないケースでも気軽に利用されている印象を受けます。 筆者は同じ組織で同じ目的のために構築されたサーバとクライアントの通信において、GraphQLを採用すべきでないと考えており、本記事ではそのポイントを整理していきます。 なお、本記事ではこのような1対1型のシステムをサーバクライアント型とよびます。 念のために記載しますが、GraphQLは素晴らしい技術であり、本記事はGraphQLを批判するものではありません。 TL;DR (本当の意味で) Code Firstな開発を進めることが難しい サーバクライアント型のシステムでは概念的に両者は一体であるため、両者間の結合を抽象化しない方がよい ドメイン駆動設計を実践するに当たって、ドメインから視点をブラし、モデル駆動開発を阻害する要因となる 開
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
奥野さんと社員のリファクタリング部屋 -ディレクトリの名付け方 - トレタ開発者ブログ
API シナリオテストツール runn で E2E テストを実装する
エンジニアにおすすめしたい技術ブログ10選 - TECH PLAY Magazine
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita
「Clean Architecture（クリーンアーキテクチャ）」の内容をまとめました - Qiita
【設計ナイトトーク】コンポーネント設計って何だろう？｜yonekubo
"The Clean Architecture" から学ぶ "抽象に依存する"
2ヶ月でUMTP L1~L3 を取得したので、その合格体験記 - mongolyyのブログ
[golang] 言語仕様から見るunittestとClean Architectue - Qiita
サーバクライアント型のシステムでGraphQLの採用を避けた方が良いと思う理由 - Qiita