重複排除の原則。 DRY=Don't Repeat Yourselfなんだと。
＃ふりがな、これで合ってる？
エンジニアの39(さんきゅー)ルールを知っていますか？知らないですよね。 昔(と言っても結構最近)僕がプログラミングする時に拘るべき数字があって、それが3と7±2という話をしたら、その時の上司が39の法則と言い出したのが始まり。つまり、完全な造語です。そして、法則よりもルールのほうが適切だと判断して名付けた。 39ルールとは 3について 9について まとめ
読んだ本 統計学入門 1 - 3章 達人プログラマー 1章, 2章9DRY原則まで 良いコード/悪いコードで学ぶ設計入門 徹底攻略 ネットワークスペシャリスト教科書 1 - 3章 仕事とかでやったこと express バックエンドではnestjsを使っていたが、使うメモリの量などを抑えるためにexpressでやることに。 とりあえずローカルで動くものは作った。パフォーマンスやセキュリティ関連は考慮していない。 Apollo(Graph QL) 勉強を始めたばかり。 やってたチュートリアルが古かったらしくて途中で動かなくなったので新しい方を始める。 2月の予定 そろそろ仕事でAWSを本格的に使い…
ミノ駆動本の読書会を社内で行い、そちらを振り返りRailsで活用する目線でどのようなところが活きるポイントかを「章ごと」と「全体を通して」で整理をしてみます。 章ごとに振り返る 1 悪しき構造の弊害を知覚する こちらはイントロダクションの章で、どのようなコードをこの書籍では「悪い」と呼んでいるNGパターンのものがどんなものなのかを説明していく章となっており、後続の個々の説明とつながっていく章となっていると思います。 2 設計の初歩 この章では例示した悪いソースコードをベースに、今後の章で取り上げていくものを当てはめていくとどのように改善されるのかという例示を示すパートです。この章だけでも初歩的…
第１章「悪しき構造の弊害を知覚する」 ・変更に強い構造を知り、ギャップとして悪しき構造を認識できるようになる。 ・悪しき構造：コード読解コストが高い、バグの埋込やすさ、構造劣化の負のスパイラル。 ・技術駆動命名、連番命令の弊害、人間が理解できる意味をコードから外部化したときの同期漏れが混乱を招く、 ・欲しい機能が実装済みであることが把握しずらい弊害。可読性が悪かったり、ネーミングが悪かったり、低凝集だったりが要因。 ・未初期化状態が発生するクラスは生焼けオブジェクトの弊害。 第２章「設計の初歩」 ・ネーミングで対処、再代入はやめて混乱しないように。 ・意味のある単位で区分けする、関係するものは…
コードを作成する機会が増えてきたので，2022年話題になった『良いコード／悪いコードで学ぶ設計入門――保守しやすい 成長し続けるコードの書き方』（仙場 大也，技術評論社，2022年5月12日）を読了。 すでに広く使われ確立している技術や解決法が存在しているにもかかわらず，知らないか，または意図的に無視して，新たに同じようなものをつくり出してしまうことを車輪の再発明と呼びます。（131 ページ） 意図しない車輪の再発明は避けたいところだが，意図して車輪を再発明することで実力をアップにつなげたい。 DRY 原則（Don't Repeat Yourself）と呼ばれる原則があります。直訳すると「繰り…
単一責任原則とは オブジェクト指向のSOLID原則のうちの一つ。色々な説明のされ方がある モジュールを変更する理由はたった一つだけであるべきある。 モジュールはたったひとつのアクターに対して責務を負うべきである 1つのモジュール（クラス）は1つだけの責任を持たなければならない 単一責任はクラスの責務の話として言及されることが多いが、メソッドレベルでも単一責任を意識する必要がある。 単一責任と凝集度、結合度 単一責任を実現するクラスは、責務に沿ったデータとロジックをまとめた凝集性の高いものである必要がある。 逆にいうと、密結合低凝集なクラスを作ると単一責任を阻害することになる。 https://…
おはようございます。 今年最後です。皆様にとって今年はどのような年でしたでしょうか？ 私にとっては公私ともに色々あった年ですが、来年こそ飛躍の年にしたいものです。 さて、今日は、清水亮著「最速の仕事術はプログラマーが知っている」（クロスメディア・パブリッシング）を紹介します。著者の清水氏は、独立行政法人情報処理推進機構から天才プログラマー、スーパークリエイターと認定され、株式会社ユビキタスエンターテイメントのＣＥＯ、経営者でもあります。 スティーブ・ジョブズは「アメリカ人は全員コンピュータのプログラミングを学ぶべきだと思うね。なぜなら、コンピュータ言語を学ぶことによって考え方を学ぶことができる…
年末ということで、私が一年で読んだ技術書を棚卸ししていく。一応ジャンルとしては３パターンに分けられると思ってて、 現場で使う技術 汎用的な技術や設計関連 その他読み物とか色々 の構成で紹介していく。アフィリンクとかは貼らないから安心して欲しい。テキトーに本の書影だけ貼っておくので気になったら適宜探してほしい。 1. 現場で使う技術 オライリー プログラミングTypeScript オライリー Reactハンズオンラーニング オライリー ハンズオンNode.js TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発 2. 汎用的な技術や設計関連 プリンシプル オブ…
こんにちは。「リーダブルコード」を先月読破して、感銘を受けた弁護士の人です。 なにに感銘を受けたかというと、「エンジニアが高級言語を効率的にコーディングするための工夫」は、契約という言語をコーディングするために援用できることがとても多いということです。 例えば、リーダブルコードは「関数には空虚な名前（tmpとかretvalとか）でなく、エンティティの実体に即した名前をつけよう！」と提案しています。 これめっちゃわかります！！！なぜなら、契約言語では当事者というクラスの表現のために「甲」「乙」という定義を未だに使います。そして、甲と乙を逆に書いてしまったままReviewを通過することが実際によく…
言語 Ｃ言語 初級 言語 Ｃ言語 中級 言語 Ｃ言語 上級 技法 言語 UNIX AAA 未分類 分類中 言語 Ｃ言語 初級 除外 言語 Ｃ言語 中級 対象なし 言語 Ｃ言語 上級 エキスパートCプログラミング―知られざるCの深層 (Ascii books)作者:ピーター ヴァン・デ・リンデンアスキーAmazonエキスパートCプログラミング―知られざるCの深層 (Ascii books) σ(^_^) の知る、唯一のＣ言語（上級）本。 相手の机に、 この本が並んでいたら、「 …… こいつ …… やるな …… 」と、思うくらいの本である。 ただし、例えば仕事場の机に置いておいて、必要な時に見る…
こんにちは！Liquidインフラチームの上原です。 この記事では、Terraformのコードリファクタリングについて解説します。 Terraformを使っていて、コードが増えてきて読みにくい…など、同じ悩みを抱えている方の助けになれば幸いです。 導入 Liquidではインフラに AWS を、インフラ管理に Terraform を使用しています。 Terraformは、AWSなどのクラウドインフラサービスの管理ツールです。インフラ構成をコードで記述すると、それに従ってリソースの生成を実行してくれます。 手間のかかる構築作業を自動化できたり、意図しない設定をすぐに検知・修復できたりと、インフラ運用…
pytestについて勉強したのでまとめました。 pytestとは pytestとは、単体テストを支援するPythonのモジュールの一つです。基本的には、 def test_hogehoge(): assert テスト内容 の形でテストケースを書いてテストを行います。 私の場合、pytestとVisual Studio Codeと組み合わせて単体テストを行っています。 テストの実装 pytestを用いて単体テストを行う際によく使うディレクトリ構造があります。それが図1です。 図1：基本のディレクトリ構造 頭にtestとついたファイルを、pytestは単体テスト用のファイルと認識します。 実装 問…
あまり勉強会に参加できてないですが、ときどき帰りの電車で聞き流ししています。 www.youtube.comDRY原則は、単に「コードの重複を許さない」ではなくて 「意図や目的の単位で重複を許さない」ということ なので、目的特化型モデル を設計するただ意図や目的は（命名に影響されて）背後に隠れてしまい認知が困難 『目的駆動 名前設計』 ・目的ベースで名前を設計しよう ・目的ベースで概念を解釈しましょう ⇒ 実はこれが（DDDの）「ユビキタス言語の操り方」 とてもおもしろいお話でした。 あらためて設計っておもしろいよな、って思いました。 ソフトを、システムを、どうやって形あるものとして捉えるか、…
自己紹介 エイチームグループ子会社のエイチームライフデザインで、マネージャーをしています。福田龍(@ryu_f_web)です。 この記事について issue確認やコードレビュー(GitHub: Pull Request, GitLab: Merge Request)を見る際の観点をまとめたもの 業務で直近3ヶ月間、自部署全てのコードレビューを最終確認させてもらっていた上で、よくあったケースのご紹介です 構成 【issue段階】陥りがちな思考の癖2点 【コードレビュー段階】重要度別 観点 【issue段階】陥りがちな思考の癖2点 Howの固定化、Whyの欠如 実装によるデメリット考慮漏れ 開発に…
こんにちは！ スマレジ テックファームのMichiです！ 2022年5月より異業種からWebエンジニアに転職し、10月末でちょうど半年が経ちました。 そこで今回はありきたりですが、エンジニアになってからの半年間を振り返っていきたいと思います。 振り返り 5月（社内研修） 6月（初めての現場） 7月（ﾅﾝﾓﾜｶﾗﾝ） 8月（コロナからの復活） 9月（新プロジェクト開始） 10月（ﾌﾛﾝﾄｴﾝﾄﾞﾅﾝﾓﾜｶﾗﾝ） この半年間で学んだこと・これからの課題 学んだこと これからの課題 所感 振り返り 5月（社内研修） 最初の案件が決まるまでは社内研修。メンターと相談して教材（書籍）を決め、それをひたす…
speakerdeck.com
r7kamura.hatenablog.com
www.infoq.com
yamamotoyama.tumblr.com
qiita.com
asakichy.hatenablog.com
qiita.com
yamamotoyama.tumblr.com
h19e.jugem.jp
