今日のＤＡ 【デジタルアライアンス ハ タ ケ ヤ マ】
イケジマさん、組み立て家具って面倒ですよね・・・わかります。
私も苦手で、先日娘の勉強机用の椅子の組み立て家具を買ったのですが、
簡単な組み立てにもかかわらずかなり苦戦して何とか組み立てました。
難しい案件だなんてとんでもないです。技術の事は色々至らないところがあり、
イケジマさんにも助けて頂きました。今後ともよろしくお願い致します。
今日は、AI活用とセキュアプログラミングについて紹介したいと思います。
実は記事をAI（Copilot）に依頼して書いてもらいました。
今日のＤＡ 【デジタルアライアンス ハタケヤマ】
ヨシナガさん、バトンありがとうございます。
頼ってもらっても大丈夫なよう精進します・・・^^;)
最近オブジェクト指向プログラミング（以降OOP）について、学びなおしをしたのでそれで感じた所感を紹介したいと思います。
オブジェクト指向は昨今ではフレームワークやライブラリ等々で採用されているケースが多く、
ソフトウェア開発する際は避けて通れないものになっているかと思います。
とあるプロジェクトでなんちゃってDDDを実践していますが、より価値の高いしなやかな設計を目指すには
まずはOOPの基礎を抑えるひつようがあると思い、学びなおしを致しました。
何を元に勉強をしたか、勉強を通して何を感じたかを述べたいと思います。
まずはデザインパターンです。
上記書籍は良書として改版しながら販売継続されており、2020年に第３版が出版されておりました。
最新の第３版を購入して勉強しました。
説明がとても分かりやすく、具体的なコードパターンの実装が示されていて、流石は評判の良い良書だと思いました。
委譲、ポリモーフィズム、開放閉鎖の原則、リスコフの置換原則、DI、自己文書化、低結合な実装や、
抽象に依存する事の重要さ等々、OOPの設計・実装の重要なエッセンスを学ぶことが出来ました。
一方で、パターン自体はなかなか実戦で使えそうなものは少なそうな印象を持ちました。
言語やフレームワークレベルで、同じことをもっと簡単に出来るように備えられているものがあったりもします。
この辺りは、Gofのデザインパターンがが出た当初はデザインパターンの活用どころがあったのかもしれないのですが、
その後時間が経過して便利なライブラリやフレームワークが進化した結果なのかもしれません。
WEB+DB PRESS Vol.132に、衝撃的なコラムがあったので紹介です。
表紙タイトルに書いていますが、「オブジェクト指向神話からの脱却」です。
このコラムには、オブジェクト指向言語が出てきた歴史から、その機能面の解説。そして、
ざっくりとした概要としては良い設計・実装をするにはOOPが必須という誤解・幻想を捨てましょうという
内容となっています。オブジェクト指向言語の機能であるポリモーフィズム、継承による差分プログラミング
や、部分型等々といった機能ベースで深い考察が書かれていました。
また、OOPでなくても保守性の高い実装手段はあるし、よりシンプルに実装出来たりもするという
実装例もありました。
また、継承は１回限りしか使えないカードなのと、基底クラスと子クラスの結合度が密接になって
しまう事から、昨今のOOPでは継承を使わない方が良いという意見があり、その事についても
触れられていました。昨今流行りのGoやRustといった言語には、継承がありません。これも、
こうした継承の問題点をくみ取った流れなのかもしれません。
OOPが出来ればいい設計・実装が出来るという神話や思い込みは捨てて、OOPの機能を
有効活用したり、OOPの機能でなくてもより良い設計・実装の追及は出来るという気づきを
頂きました。ただ、私としてはOOPの設計・実装スタイルは好みなのと、保守性・変更容易性の高い
設計・プログラミングの重要な鍵になるという考えは持っております。有効活用していけるよう、
よりスキルを磨いていけたらと思っています。また、オブジェクト指向は要らないという事は無いと思います。
先述の通り、多くのフレームワークやライブラリでオブジェクト指向言語が取り入れられており避けては
通れません。そして、オブジェクト指向は、プログラミングを高度に抽象化する機能を持ち合わせた技術
である事は間違いありません。そのエッセンスを学ぶことは、プログラミングスキルの向上に必要だと
考えています。OOPに触れることなくプログラミングするより、OOPを学んでその上で必要なものを適切に
活用しながらプログラミングするのが理想かと思います。
マーチン・ファウラーのリファクタリングの本が良書という話を聞きつけて、読んでみました。
具体的に、そしてとても細かくリファクタリングの手順やテクニックが書かれていました。
また、第１版では元々Javaで書かれていたのを、第２版では最近流行のJavaScriptベースで書き直し
されている点も好感を持てました。細かすぎてこのテクニックを現場で使えるかが自信がありませんが、
一つ印象に残っているのは継承についてです。継承で問題点が出たら、委譲にリファクタリングすればいい
というテクニックです。継承はやめたほうがいいという昨今の論評がありますが、この本はそのことを否定
していました。継承は便利なので使えばいい。ただ、問題が出たら委譲にリファクタリングすればいいだけと。
なので、今後も躊躇なく継承を使っていこうと思いました。リファクタリングのリスクはあるんですけどね・・・
ただ、DDDではリファクタリングは通常の開発活動の一部とせよとうたわれています。リスクが高く
リファクタリングしにくいという事情がある場合、リファクタリング出来る開発環境・ツールを整えたら
問題解決できます。スタンダードな解決方法としては、UnitTestの自動テスト実装でしょうか。
以上がOOPについて勉強した事の所感となります。
明日は、同じ部屋の大先輩のMさんです。
今日のＤＡ 【デジタルアライアンス ソリューション事業部 ハタケヤマ】
マツダさんバトンありがとうございます。スーパーエンジニアだなんてとんでもありません・・・
マツダさんに質問される際は大体私の知らない事ばかりなので、質問される際はびくびくしております。
なかなか都合が合わず参加出来ていませんが、都合が合えば是非釣りまた行きたいです。
さて、本日題材にしたいのは、Qiitaで既に記事にした二番煎じネタですが、
Laravelで同じ実装をDDDとMVCで比較した事について紹介したいと思います。
今日のＤＡ 【デジタルアライアンス ハタケヤマ】
木附さん、バトンパス有難うございます。
娘の成長の速さに驚いて、近頃私も時の流れの速さを実感しています。
漫画といえば私が見ているのはアニメだけですが、ベタですが最近は私も鬼滅の刃にはまっています。
もしかすると漫画にも手を出すかも・・・現在検討中です。
さて、今回はPHPのLaravelフレームワークで、ドメイン駆動開発（以下ddd）を検討した話についてご紹介したいと思います。検討するに当たり、書籍「エリック・エヴァンスのドメイン駆動設計」(以下dddの書籍と呼称)だったり、Laravelでdddを検討した方がGitHubにアップされたサンプルプロジェクト等を参考に致しました。
今日のＤＡ 【デジタルアライアンス ソリューション事業部 ハタケヤマ】
昨今コンテナ技術が普及し、どんどん運用で使われています。また、その進化もめまぐるしいと感じています。最近特に注目して勉強したのがkubernetesです。
既に運用で巨大なクラスタが稼働しているケースも見聞きしていて、技術的には実運用は十分行われていて、それをどんどん発展・応用していく段階にきているように感じています。
そこで、kubernetesを勉強する意味でも、またインフラの勉強をする意味でも、ここはやってみないと思いまして、実際に社内で個人の開発環境として使える環境を作ってみました。
使用する環境要件は以下となります。
【環境要件】
◆OS
・Windows10 Pro(x64)
◆ソフトウェア
・Docker for Windows
・Ubuntu 18.04 LTS
◆設定ファイル一式
Github
※設定ファイルが多いためGithubへアップしました。社内の情報は公開できないので、社内の設定等は仮の値に置き換えました。sslの鍵もブランクのファイルに置き換えているため、この鍵では正常に動作しません。使用される場合は個人の環境で適切なものを入れてください。
