getとfindの使い分け - 日々常々
メソッド名の getXXX と findXXX どっちがいいの？みたいな話になることがある。 この手の話ができるだけでもいい感じだと思います。名前が記号化していないってことなので。 世の中には名前に力を割くのが無駄な文脈もあって、そう言うのに晒されて続けると当然そこに力をかけなくなります。 その文脈では最適解だけど、私は名前が重要だと思っているし、その価値観を土台に他のものを積み上げていきたい。 ということで話を戻す。 「得る」と「探す」のようなものを意図して使い分けるとコードが読みやすくなります。 使い分け方によって読みやすさは変わりはするのですが、「意図して使い分けている」だけでも十分変わります。 その意図に共感できたり汲み取れたりすればさらに読みやすくなりますが、その前段階として意図の有無が重要だと思ってます。 私の基本的な使い分け getHoge(条件): Hoge findHog
個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論
Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは？ Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay
新入社員に向けて私が3年間で読んだ技術書を紹介する - Qiita
はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ？ でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/
テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょう。 users / posts / comments / likes のテーブルが
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広…
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
詳細設計の書き方 - Qiita
はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。 詳細設計の目的やメリット 詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。 開発工程でのバグや遅延を減らすことができる テスト工程での不具
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
書籍「ソフトウェアテスト技法ドリル」ではテスト設計の考えとツールの使い方まで学べちゃいました | DevelopersIO
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？ 本職のテスト
『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』（O'Reilly Media）の全
コード品質向上のテクニック：第9回 来た道を戻れ
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 9 回です。Weekly Report については、第 1 回の記事を参照してください。 来た道を戻れ ネットワークやファイルシステムといった I/O を使う場合、I/O 上のデータ表現とコード上のデータ表現との間で相互に変換する必要があります。その典型例の一つが、インターフェース記述言語 (IDL) やデータベーススキーマなどの外部で定義されたデータと、コード上で定義されたモデルクラスとの相互変換でしょう。このとき、「状態」や「タイプ」を意味する値を使う場合は、コード上の表現として列挙型を使うこともあります。 以下のコードでは、データベースで使われている値と列挙子を相互変換するために Map を使っています。 enum
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
良いコメントが良い設計を導く
要旨 コメントを適切に記述することは、特にインターフェイス（クラスやメソッド）において重要です。これにより、直感性が高まり、抽象化が十分に行われているかを確認する手助けになります。そのため、コメントはソフトウェア設計プロセスの重要な一部と位置づけられます。 2種類のコメントタイプ まず、コメントを2種類に分類します。 1️⃣ コードをより詳細化するコメント(lower-level comment) 2️⃣ コードをより抽象化するコメント(higher-level comment) どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。 1️⃣ コードを詳細化するコメント(lower-level comment) 変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動（仙塲大也） 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア本大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X（@MinoDriven） note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計（以下、DDD）に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人
エンジニアが画面設計（Figma）を担当してみた振り返り
Thinkings株式会社 では sonarATS の開発にあたり、基本的にはデザイナーがFigmaを作成し、それに基づいてエンジニアが開発するというフローを取っています。 そんな中、先日エンジニアサイドで画面設計を行ってみるという実験的な取り組みをしました。 本記事では画面設計を行うことになった経緯と具体的な取り組み内容を振り返り、エンジニアが画面設計をすることのメリットと課題感について考えたことをまとめたいと思います。 エンジニアサイドで画面設計をするきっかけとなった要因 エンジニアサイドで画面設計をすることとなった理由として、大きく分けて以下３つの要因がありました。 デザイナータスク削減の目標 あるマスタ画面を開発したときの課題感 上述の通り、『簡単なマスタ画面の開発』のような共通的な画面設計になる機能については、できるだけデザイナーが介入せずエンジニア主導で開発している → 実際に
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
失敗例から学ぶSOLID原則
