zackey推し

IT系のこと書くぞい

「Design It! プログラマーのためのアーキテクティング入門」の咀嚼 第1章 ソフトウェアアーキテクトになる

近々、プロダクトの近い位置で仕事する機会が増えます。

今までの、
SES・Slerといった顧客の要件を元に開発するスタイルから、
自分たちで最適解の機能・アーキテクチャを開発するスタイルへと変わります。

言語やフレームワークといった開発も大事ですが、
これまでとは異なるスキル(視点や行動など)が必要となってくると感じています。

プロダクトやビジネスサイドとどう付き合って、エンジニアとして動いていけば良いか、
体系的な知識を身につけるため、「Design It! プログラマーのためのアーキテクティング入門」を
購入しました。

www.oreilly.co.jp

scrummasudar.hatenablog.com

tech-blog.cloud-config.jp

これから続けられる限り、
本書から咀嚼した内容を記事化していきたいと思います。

  • 1章「ソフトウェアアーキテクトになる」に書いてあること
    • アーキテクトの役割
    • ソフトウェアアーキテクトとは
    • アーキテクチャは肩書きがなくても取り組めるし、誰もがアーキテクトである
    • プログラマーからアーキテクトになるには
    • 素晴らしいプロダクト・ソフトウェアを作るためには
  • 終わりや所感
続きを読む

Object-Oriented Conference 2020 ( OOC ) の当日スタッフ参加させていただいたときの学びなど #ooc_2020

2020/02/16(日)に行われた、
Object-Oriented Conference 2020 ( 以降OOC ) に当日スタッフとして
参加させていただきました。

ooc.dev

ooc.connpass.com

当日の映像はYoutube Liveで配信されており、以下から視聴することも可能です。

www.youtube.com

この記事では、

  • 参加したきっかけ
  • 当日の雰囲気
  • 当日スタッフとして得られたこと
  • 感想・所感

を自分のメモ用に書いておきます。

続きを読む

Clean Architecture 第11章「DIP: 依存関係逆転の原則」の読書メモ

現在、自分がいるコミュニティにて、クリーンアーキテクチャの輪読会が行われています。

自分が第10章〜第11章となり、以下についての資料をまとめました。

この記事では、第11章「DIP: 依存関係逆転の原則」の理解を深めるために、
ブログ等の文献を読み漁り、咀嚼した内容をメモしておきたいと思います。

咀嚼した内容

以下のリポジトリディレクトリ内でお試しコードを打ちながら咀嚼しました。

github.com

序章

  • DIPが伝えたいこと
    • 具象ではなく抽象だけを参照しているもの
  • 柔軟なシステム=抽象を参照しているもの
    • 柔軟ではないシステム=具象を参照しているもの
  • 具象(モジュール)の定義
    • 本では、関数が実装されているものを指す
  • 適応範囲
    • すべてに適応するのは現実的ではない
      • String等、OSやプラットフォーム周りについては許容してもOK
    • 適応範囲は、システム内の変化しやすい具象要素
      • 今現在開発しているモジュール
      • 変更が入るモジュール

安定した抽象

  • 優れたソフトウェア設計者は...
  • コーディングレベルでの説明
    • 変化しやすい具象クラスを参照しない
      • 抽象インタフェースを参照する
        • 言語関係なし
      • AbstractFactoryパターンを用いるとよい
        • というか、それしかないらしい
    • 変化しやすい具象クラスを継承しない
      • 静的型付言語の継承は協力かつ幻覚なもののため、十分に注意すること
        • おそらく、意図しない動きをさせる危険性があるためと思われる
    • 具象関数をオーバーライドしない
      • オーバーライドしたい場合は、元の関数を抽象関数にして、パターン毎の実装をすべき
    • 変化しやすい具象を名指しで参照しない
      • DIPの言い換え

Factory

安定した抽象に従うと、具象オブジェクトを生成する際に特別な処理が必要。

事実上、すべての言語において、オブジェクトの具象定義を含むソースコードの依存は避けられない。

そのため、大半のオブジェクト指向言語ではAbstractFactoryを用いて、依存性を管理する。

Abstract Factoryについて

まとめ

咀嚼した結果、

  • Abstract FactoryのcreateFactoryあたりは、もっとスマート(依存しないような形)で実装できたら良さそう
    • Railsconstantizeのように、文字列からクラス名を生成する仕組みがあると便利かも
  • DIPは原則(規則)、DIやAbstract Factoryはそれに準拠するための手法

のようなイメージでインプットしました。

もし、気になる点等ありましたら、FBいただけると助かります。🙇‍♂️

じぶん Release Notes ver 0.30.3

f:id:kic-yuuki:20200202082051p:plain

2020/01の取り組みの成果を書いていきます。

先月分はこちら -> じぶん Release Notes ver 0.30.2 - zackey推し

  • 開発・技術
  • 勉強会・コミュニティ
    • 勉強会
    • コミュニティ
  • プライベート
    • 記事(じぶんリリースノートを除く)
    • PV数
  • Challenge Every Month
    • 2020/01の結果
      • ⭕️プロを目指す人のためのRuby入門の読破
      • ❎プロを目指す人のためのRuby入門の記事を書く
    • 2020/02の目標
      • DesignIt!を読破する
      • すぐ分かる音楽理論#7 まで完了する
  • おわりと所感
    • ギター
    • 仕事とか
続きを読む

GitHub Actionsを使って、MarkdownファイルからPDF(職務経歴書)を生成する

この記事では、以下のことを記載します。

  • はじめに(職務経歴書Markdownで記述、GitHubで管理する)
  • GitHub ActionsでPDFを生成する
    • md-to-pdfでMarkdown→PDF出力
    • 手順
      • 1. README.mdに職務経歴書を記述する
      • 2. md-to-pdfをインストール、PDF出力するスクリプトを作成する
      • 3. ワークフローを記述する
      • 4. git pushでワークフローを実行、PDFがダウンロードできるか確認する
  • おわり
    • 参考文献
続きを読む