タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

developmentとProgrammingとdesignに関するch1248のブックマーク (6)

  • コードの寿命・データの寿命・互換性の寿命

    これを記事にしている 2025 年 5 月の二年ほど前 (2023-06-02) に、縁あって明治大学 情報科学科での特別講義 [1] を担当させてもらいました。 身内の評判は悪くなかったのでスライドは公開していたんですが、単に Google Slides を公開状態にしただけだったんですね。 [2] これではあとから参照・引用するのも難しく、ちょっともったいないかと思ったので、いまさらながら記事の形でまとめなおしておくことにしました。 一年も経てば情報が古くなってしまうコの業界です。賞味期限切れの話もあると思いますが、話のネタにでもしてもらえれば幸いです。 講義の対象と目的 この講義、目的は2つあって、まず「最新の情報科学トピックに触れる」こと。 それから、就職活動が始まる3年生がメインの対象者なので、 今後のキャリアプランとか人生指針に関するいろいろな視点を持ってもらうことです。 この

    コードの寿命・データの寿命・互換性の寿命
    ch1248
    ch1248 2025/05/23
    すごく良い教材だ。
  • 「クラス設計の鉄則」執筆ノート - ソフトウェア設計を考える

    『Software Design 5月号』の第2特集「クラス設計の鉄則」を寄稿しました。 gihyo.jp 第2特集の概要と、今回はとりあげなかった、SOLIDGoFデザインパターン、凝集度と結合度について、私がどう捉えているかを説明します。 概要 第2特集のクラス設計の鉄則は3章で構成されています。概要は次の通りです。 第1章:クラス設計再入門 モジュール性・関心の分離・依存関係を意識する 第2章:迷わないクラス設計の指針 アプリケーション開発の実践例から考える現代的な設計方針 第3章:設計の落とし穴対策 コードから問題を検知する着眼点と改善方法 第1章:クラス設計再入門 この章は、クラス設計の基礎として、ソフトウェア設計の三つの視点を紹介しています。 ソフトウェアシステム構築の基課題として「複雑さ」と「変更容易性」に焦点を合わせ、二つの課題に取り組むための考え方として、「モジュール

    「クラス設計の鉄則」執筆ノート - ソフトウェア設計を考える
    ch1248
    ch1248 2025/04/23
    SOLID原則とGoFがこのように言われる日が来て、若干の感銘がある。買ってみるか。
  • データベース中心の設計になってしまう問題と闘う - laiso

    『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

    データベース中心の設計になってしまう問題と闘う - laiso
    ch1248
    ch1248 2024/08/11
    2回実装、なるほど。書籍の方に興味が出た。
  • 今さら聞けないログの基本と設計指針 - Qiita

    ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基的に、外部ログ管理システ

    今さら聞けないログの基本と設計指針 - Qiita
  • コードコンプリートを再読した - $shibayu36->blog;

    以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ

    コードコンプリートを再読した - $shibayu36->blog;
  • デザインパターンよりも、まずリファクタリングを学んだほうがいい - モジログ

    ウィキペディア - デザインパターン (ソフトウェア) http://ja.wikipedia.org/wiki/%E3%83%87 <ソフトウェア開発におけるデザインパターン(型紙(かたがみ)または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである>。 ウィキペディア - リファクタリング http://ja.wikipedia.org/wiki/%E3%83%AA.. <リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、「リファクタリング」の語にも厳

  • 1