「DDD」を含む日記 RSS

はてなキーワード: DDDとは

2021-11-17

GoMockテスト辛い問題とかDDDって何それうまいの?とか

GoMockってのはGo言語ライブラリで、依存するinterfaceテストモックに置き換えてくれる。

それで、テスト中のモックの期待される振る舞い等を簡単定義できるのだ。

期待される振る舞いってのは、モックメソッド呼び出しやその引数とかだな。

期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。

他に、メソッド戻り値副作用記述できる。

非同期処理のテストだとよく、wg.Done()をモックにさせたりする。

正直、これまで書けなかったテストがモリモリ書けて楽しい

けれどそのうち辛くなってくる。

まり、たくさんのinterface依存するサービスオブジェクトメソッドテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。

モックメソッド戻り値によってサービスオブジェクトメソッド内の挙動が変わる。

すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。

依存interfaceが増えるとこの場合けが指数関数的に増える。

当然だ。

Go言語にはテーブルリブテストっていう、テストケースは配列簡単にまとめられると良い、という慣習・哲学がある。

しかし俺のサービスオブジェクトテストケースが肥大化複雑化しすぎてしまったようだ。

モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。

やりたくない。

どうしてこうなった

どうしてこうなったかは明らかだ。

サービスオブジェクトが巨大すぎるのだ。

ノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。

そうだなモノシリックは辛い。DDDかにすればいいんだろ?

やったよ(見様見真似で)。

モックでこれまでできなかったテストが書けるのはいいね

でもじつはここはまだ山麓だったのです。

サービスオブジェクトが巨大なモノリス化してしまったのです。

分け入っても分け入っても青い山。

おれはどこに行けばいいのだ。

参考文献

https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month

あとどこかにDDD100本ノックとかないかな。

2021-10-04

ある書籍要約系サイトの想い出

ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作エッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリー存在した。2010 年代のことであるGoFデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちラクになるような気がしたのだった。

その後、わたしアラサーになるころには、そこで紹介されていた大部分の原著書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したもの秀和システム書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこ書籍化に伴って、はてダも閉鎖されてしまった。もっと新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。

図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的DDD

なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。

2021-09-26

触れてはいけないIT用語一覧

Twitterブログで触れても何の得にもならない単語を並べる

2021-09-14

新しい概念本質を忘れてる奴ら

DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか

https://www.pospome.work/entry/20161023/1477206615

2021-08-05

一次ソースにあたれ

情報一次ソースに当たることは昨今の情報社会において当然のことのように思うが、情報が氾濫している以上そうしなくても満足してしまうこともしばしば。

アプリケーション開発においても全くその通りで、QiitaGitHubで拾ってきたサンプルコードベストプラクティスと思い込んでしまう人がいる。

DDDだ、クリーンアーキテクチャーだ言い始める前に、エリックエヴァンスアンクルボブの本を手に取ろう。

そして会社プロジェクト情報の入手へ投資を惜しまないようにしよう。本を買おう。

本を読んだ人はまずチームメイトに共有しよう。議論してあなた会社・チームにとってのベストプラクティスを見つけていこう。

2021-07-18

anond:20210718033304

奈須きのこ先生文章月姫FateDDDと徐々に読みやすくなっていったけど

空の境界商業一作目でそれほど読者の事も考えていない作品って事もあってか本当に読みづらくて困る

2021-05-03

DDDリポジトリってファットにならない?

リポジトリは集約ルートのみ返す。1つの集約にはリポジトリは1つ。リポジトリの中でのみRDBへ問い合わせる。」って書いてあるけど、集約内の関連テーブルへの問い合わせをすべてリポジトリ書くからリポジトリが巨大にならない?

DDD実装例を見ているんだけど、参照はリポジトリ以外からも呼んでいてクソワロタ

https://qiita.com/haazime/items/5776e4e25b6527b682e7

ActiveRecordのassosociationとRepositoryの相性って良くない気がする。(Repositoryのセオリーに完全に従うとassosociationが使えなくなるのでは?)

2021-04-26

anond:20210425022947

RailsやLaravelみたいな(Web)MVCフレームワークで開発する場合、無理にDDD文脈アーキテクチャレイヤードアーキテクチャ/クリーンアーキテクチャ/オニオンアーキテクチャ)を採用すべきではないと言う主張に読めた。そういうことな同意できる。

MVCフレームワークはそれらのアーキテクチャのために作られたものじゃないもんな。


Web開発で主流のMVCフレームワークレイヤードアーキテクチャなんかは一見共存できそうに見えるが、実際は噛み合わない部分がある。

一例を挙げると、MVCフレームワーク採用されることが多いActiveRecordはDomain層とinfrastructure層を分離させるという考え方と相性が良くない。

仮に、ドメインモデルの導入とともにActiveRecordあくまデータの入れ物(DAO)としての使用限定すれば、形だけはDDD文脈アーキテクチャに合わせることはできるが、フレームワーク全体のエコシステムActiveRecord(に基づく各フレームワーク固有のModelクラス)前提で作られてたりするとどこかで破綻する。

Userモデルを前提とした認証処理なんかで引っかかることが多い)

その上、いくら設計方針としてActiveRecordをDAOとして扱っても、可用性はActiveRecordのままなので、そこが設計一貫性を保つ上でのセキュリティーホールになり得る。

そういう部分をテクニカル設計コードレビューで頑張って回避するコストと、MVCデメリットによって発生するコストのどっちがマシなのかは慎重に検討すべきと思う。

個人的には大体において後者のほうがマシだと思うが)


なので、理想を言えば、追記にもあったようにDDDためのフレームワークが普及するのが一番だと思う。

実際hanamiとかが出てきてるので、DDD推進派の皆様はRailsDDDとか中途半端なことをせずに、新興フレームワークをどんどんキャッチアップして知見を広めて頂ければと思う。

2021-04-25

anond:20210425022947

日本のアホだけど偉い人名言集に加えておけ

?「よし、AIだ」

?「よし、ディープラーニングだ」

?「よし、ブロックチェーンだ」

?「よし、DXだ」

?「よし、マイクロサービスだ」

?「よし、DDDだ」

共通して言えるのはアーキテクト不在の技術ゼロ企業ほど、この傾向が強い

でも増田の言う通り、要所要所適度な加減で取り入れるのは賛成。ユビキタス言語とか、日本語使う我々が、更にSIerでもなければ何の意味もない。

過度な抽象というのは自分DDDに対する理解と異なるな。どこまでを抽象化するかは触れていないはず。ユースケース層は必ずしも最上レイヤーのみで収まる話ではないから、どこまでが抽象化の対象となるかはアプリケーションによる。

anond:20210425022947

言おうとしていることはわかる。言語仕様にもよるが、例えばGo適用してDDD概念がそのままディレクトリー名になるとか、まじでありえない

DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。

※追記あり。最後の追記は 2021/04/25 21:40頃※

タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。

この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく(易しく、ではない)ご指摘願いたい。

※この記事では Web Application を前提とした話になっている。

DDDとは?

https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88

DDD、ここがイケてる
  • ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。
  • 俗に言う「ビジネスサイド」の人間との共通言語を整備するべきだ、という提言。
  • ドメインモデルの構成要素のうち「エンティティ」「値オブジェクト」あたりの概念は、俗に言うビジネスサイドの人間も持たなくちゃいけない。DDDはその学びの道標として非常に優れている。
DDD、ここがイケてない
  • 共通言語たるドメインモデルを、そのままコードと1対1対応しなければならない、という思い込みや風潮。
    • 既存のWAF(Web Application Framework) の利点を潰してどうする…
  • ドメインモデルの構成要素のうち「リポジトリ」等はソフトウェアの中に閉じた世界の話であって、俗に言うビジネスサイドの人間との共通言語には登場しなくて良いことが圧倒的に多い。設計を遅延させる原因になっている。
    • 名前から考えれば、DDDの効用の範囲は「共通言語の整備」と「共通言語の会話から設計に落とし込む際のベストプラクティス」あたりであって欲しいのに、余計なお世話。
  • 過度な抽象化
じゃあ、どうすんの?
  • エンティティやその周辺のドメインモデルの話は、いわゆるビジネスサイドの人間との共通言語として、噛み砕いて共有したい(既に進行中)
  • ソフトウェアの設計としては、3月にバズってた記事 Only My Rails Way のような方針でありたい。欲を言えば静的型付け言語に乗り換えたいが、それは叶わぬ望み……。。。

短く言うならば「DDDの理念は取り入れるが実装は取り入れない」

(参考) 筆者のポジションと近況
  • データベーススペシャリストの立場で、また俗に言う「テックリード」の立場で、情報システムやWebサービスの設計と実装に従事。
  • 技術的な上司はチーム外。チーム内では筆者が一番上。
  • 社内のよそのチームが「DDDいいぞ」と言って布教しようとしてきてて、つらいお年頃。
追記@2021/04/25 21:40頃

夜中に投稿したのに多くの方に読んでもらえて嬉しく思います。コメントなどなどありがとうございます。以下、補足です。

  • 筆者にとっても普段はWAFという語は Web Application Firewall を指します。わざわざWAFの正式スペルを文中に書いたのは、通常と異なる言葉遣いであるから、です。
  • 「既存のWAFの利点を潰してどうする」が言うところの利点の主たる部分は、junior developer 職の人を新たにチームに招き入れる際に、当該言語やWAF(frameworkの方)、そして基本情報レベルのセキュリティや通信の知識さえあれば容易に参画可能であるという利点です。seniorならまだしも、juniorを迎え入れるときにDDDの知識を持ってる人を必須にしたり on boarding の時点でDDDの話をしなくちゃいけないのは、コストに見合わないと判断しています。

あと、素晴らしい引用に感謝したいのですけれども、

「一般的に言えることだが、使っているフレームワークとは争わないこと。 フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、 詳細は捨て去る方法を模索すること。」エヴァンス本 p157

https://b.hatena.ne.jp/entry/4701728015809111618/comment/sonota88

例えば、アプリケーションのディレクトリ構造をDDDの用語に合わせたものにするという行為は、ここで言うところの「対立」に相当すると考えています。「基本」すなわち理念だけ存分に私たちのアプリケーションに取り込みたいものです。

少し違う角度の話をすると、初っ端からDDD前提のWAF(frameworkの方)を、できれば静的型付け言語で(←個人的な趣味)、新しく開発してそれを普及させることによって、当該WAFを学んだ人は自然とDDDも身に付いているという文化を作ることには熱い賛同の言葉を贈りたいと思っています。

2021-04-24

DDDユースケース層でのエラーハンドリング言語化している情報ってありませんか?

ユースケース層ってドメインからエラーを受け取って翻訳して、呼び出し側へハンドルやすいようにエラーを投げるじゃん。もしくは、想定のエラーだったら握りつぶすみたいな役割あるじゃん

そのユースケース層のあるべき振る舞いの情報源って経験的でしかなくて、識者から情報が欲しい。

ドメイン駆動設計 モデリング実装ガイドって本にはサラッとしか書いていなかった。

2021-04-10

F通のDDDとかって

ドメインしか無くって

アプリケーション層無いんだよな

多分無知馬鹿なんだろうな

2021-04-08

大金持ちになったらやりたいこと

なんとか有限会社ノーツ債権を集めて最大債権者の力で

奈須きのこに『まほよ』の残り2部と『DDD』の残りを書かさせたい

あと『空の境界』の映画6章を原作準拠リメイクさせたい

2021-04-02

ソシャゲ一回始めたら金かかるのはネックだよなぁ

ウマ娘は今10課金した

アズレンはこれまで15万ぐらいの課金

プリコネ12万?15万ぐらい

クリユニが25万

あとタイトル忘れたが15万

他は買い切りアプリで3千ぐらい

PS4は月1万ぐらい何かしら買ってるが積んでる

FGOは初期のシナリオでのグダグダでやらなくてそっから追っかけるのもシャクだからやってないな

どうしてもfateソシャゲってイメージあんまり乗り気になれないし

ソシャゲするよりDDD三巻と月姫2を出して欲しい感が強い

月姫リメイクメルブラ出るそうだがそろそろDDD続きでてくれねえかな

というところで皆さんおはようございます😃

ソシャゲ一回始めたら金かかるのはネックだよなぁ

ウマ娘は今10課金した

アズレンはこれまで15万ぐらいの課金

プリコネ12万?15万ぐらい

クリユニが25万

あとタイトル忘れたが15万

他は買い切りアプリで3千ぐらい

FGOは初期のシナリオでのグダグダでやらなくてそっから追っかけるのもシャクだからやってないな

どうしてもfateソシャゲってイメージあんまり乗り気になれないし

ソシャゲするよりDDD三巻と月姫2を出して欲しい感が強い

月姫リメイクメルブラ出るそうだがそろそろDDD続きでてくれねえかな

というところで皆さんおはようございます😃

2021-03-13

"aaa: bbb: ccc; ddd"をドラッグドロップ編集すると"_bbb_ ccc"になるのなんで

やり方

aaa: bbb: ccc; ddd

上記1行をコピーしま

一度適当テキスト入力欄に貼り付けます

もう一度、1行ぶん範囲選択しま

Chrome適当空っぽ入力欄に移動させます

なんで?

2021-01-02

[]2020年12月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

272あとで/1803users この本がスゴい!2020: わたしが知らないスゴ本は、きっとあなたが読んでいる

257あとで/1367users 鹿児島中央駅から新函館北斗駅まで新幹線の全駅に下車してきたので全力で紹介する_PR【駅メモ!】 | SPOT

247あとで/2110users ぼんくらITエンジニアでもYouTubeとスタサプでTOEIC 900点突破できたので勉強法をまとめていく - だいたいよくわからないブログ

235あとで/1299users 「イラストでわかるDockerKubernetes」は完全に良書 - Cloud Penguins

222あとで/1463users 売れるアプリにするコツ100個書きます(吐血) - Crieit

203あとで/1011users JavaScriptの基礎知識GIFアニメで分かりやす解説 -総まとめ | コリス

192あとで/1373users もしあなたが急にAndroidアプリ業務で作るはめになった場合選択肢(2021年初頭版) - Qiita

190あとで/959users OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife

183あとで/1146users 一人前のプロマネってどんな人? プロジェクトマネジメントスキルセットとは-誰も教えてくれないプロマネのコツ | Mammoth Project

180あとで/1008users Python仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball

173あとで/1647users 【練習内容公開】イラストを100日練習しました|都路 燕禅|note

170あとで/2469users 僕のしょうもない人生を紹介します - いまトピ

170あとで/1019users 「フリーランス副業向けサービス カオスマップ2020年完全版」が公開 - Digital Shift Times(デジタル シフト タイムズ) その変革に勇気希望

163あとで/1186users 9割の人が知らない再現性危機 - 本しゃぶり

157あとで/1019users Mac を買ったら必ずやっておきたい初期設定を、全て自動化してみた | ulwlu | Zenn

154あとで/751users CTOの頭の中:技術投資最適化する|Shin Takeuchi|note

152あとで/1503users 僕らはいつまでUSB Type-Cケーブルを選ぶのに迷うのだろう…もう間違えないための覚え書き - Magnolia Tech

148あとで/2347users 全財産を使って外車買ったら、えらいことになった|岸田 奈美

141あとで/1040users 英語発音について概説する - Amosapientiam

135あとで/648users 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

131あとで/2088users Amazonで「鬼滅の刃」のコミックを買ってしまったのに、どうしても読み始める気になれない。 | Books&Apps

131あとで/1089users ステーキをおいしく焼く理論料理家・樋口直哉が教える、肉の焼き方「新常識」【保存版】 - ソレドコ

129あとで/855users Webディレクタースキルリー - NMY

129あとで/915users Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog

126あとで/745users Web制作の時短に!2020年の便利オンラインツールベスト100選 - PhotoshopVIP

121あとで/880users 【総まとめ】2020年公開のすごいPhotoshopチュートリアル、作り方厳選まとめ - PhotoshopVIP

121あとで/613users ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

121あとで/864users 家で筋トレを続けるための簡単な「仕掛け」を取り入れてみたら、筋トレが楽しくなって習慣化した話 | Fun Pay! | あたらしい自分、はじめよう。楽天カード

120あとで/614users Micro Frontends Architecture Patterns | okmttdhr | Zenn

120あとで/679users 3ヶ月くらいフロントエンドやったのでやったこと一旦まとめ - Stimulator

相変わらず英語ネタが人気。

ステーキの焼き方記事好き。

2020-11-16

anond:20201115125745

俺の場合は、愚直に書いたほうがいいよ、巨大アプリリファクタリングの話とか鵜呑みにしないほうがいいよ、社内では評判わるくてもプレゼンだけうまかったりプロジェクト破綻するまえに転職するヤツ多いから、とか言っても全く無視される。DDDとか○○アーキテクチャとかだどーのこーのとか。。。

煽るのを仕事にしてるヤツと煽られて載せられてチームを破綻させるひとと、それでもどーにかプロジェクトを完成させなきゃならん責任感に振り回されている。

2020-11-15

anond:20201115125745

仕事にしてしばらく経ったら大して好きでもなかったな」と「○○歳定年説」は、ベクトルが違う。

昔は、やりたいのにやらせてもらえない。そんな時代だった。

キャリアアップと言えば、手を動かす → 人を使う、の一択しかなかったから。

今は良い時代だ。

正直、アジャイルとかテストファーストとかDDDとか、どうでも良いと思ってる。

大事なのは、「名前」がついたこと。

名前がつくことで、大義名分にできる。

正直、真似事ですら、できるやつはあまりいない(定年説を唱えている界隈では)。

効率だ、品質だ、に、ふんづまったところで、大義名分は、ポンコツを除外できる とても良い言い訳になる。

少数で、歳は食ってるけど、その分、経験はあるやつと、経験は少なくても、知識貪欲でパワーのあるやつだけでチームが構成できると、とても楽チン。

Wizard みたいなのじゃなくても、コード書いて楽しんで生活できてるのは、一定数は居ると思うけど。

もうじき40代かばを迎えるプログラマー遺言(少し追記)(もうちょっと追記)(さらにもうちょっと追記)

世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。

世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる(ブラック的な意味ではなく)。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説しか映らないだろう。

だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。

だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。

まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたくなくなる。というか、そもそも一生プログラミング仕事にしたいと思う最初の頃は好きだと思っていたが、仕事にしてしばらく経ったら大して好きでもなかったな、と思うようになる。

大して好きでもないことを仕事にし続ける体力はやはり年とともになくなり、体力がなくなった分「自分本質的にしたいと思うこと」が見えてくる。そしてそれはプログラミングではないため、ギャップがきつくなっていく。

おそらく、この辺が35歳くらいのあたりに来るのではないだろうか。35歳定年説と言ったら35歳ピッタリしか想像できないのが離散数学世界で生きているプログラマらしいといえばらしいが。

そんな感じでやってても、20年もやればそれなりにスキルも身につく。さすがにGoogleの一線で働くような大天才たちと渡り合うことはできないが、もしかしたらGoogleの片隅で働ける程度のスキルはあるかもしれないが、正直もういいっす、っていう気持ちのほうが大きくなる。

次に、自分がどうにか身につけてきた知見というものがなかなか広まらない。コンセンサスが取れない、という状況にも苦しくなってくる。

自分がやってきたプロジェクトでこういうことをやったらうまく働いた、というような知見は共有するが、なかなか価値観が共有できないことに気がつく。若いうちは「だったら俺が全部やりますわ」くらいの気合を見せられたものだが、年を取ってくると「あ、そうですか・・・」となってしまう。純粋に体力も気力もなくなっていく。

プログラミングをやっているだけありみんな論理的思考が大変上手だ。「皆さんホント論理的でいはりますなぁ」と言いたくなるわけだが、悲しいことに自分たちの振りかざす論理が、単なる正論、飛躍、極論、屁理屈、と言ったものであることに気づけない人も結構多い。こういうのを各個撃破するのも疲れる。

これからプログラミング仕事にする人たちに言っておきたいことがある。もしこの世界で長く働きたい、定年までコード書いていたい、と思うなら、常に勉強をしなくてはならない。もしあなたFラン出ているなら、他の人の倍努力しなくてはならない。できないならそこそこで転職したほうがいい。この世界にいるといか若いうちの勉強大事だったかを日々痛感する。

実務の上での俺の感じていることを書く。DDDだとかクリーンアーキテクチャだとかも大事だがもっとそれ以前に俺が根源的に重要だと考えているポイントだ。この辺をないがしろにしたらDDDクリーンアーキテクチャ絶対崩壊する。

コードを書くとき重要ポイント

まず、心得てほしいのはどんなにすごいプログラマでも意図の通じないコードは本当の意味で直せないということだ。

まず、引数チェック、状態チェックは必ずやれ。コードが語る、というようなことを言ってやらないやつが昔は多かったが、今もいるんだろうか。悲惨バグメンテナンス性の低下はそういった自分意図の表明を横着したコードから起こり始める。「俺はこれをやる、だからこの機能を呼び出すならこういう状態にした上でこういう情報を渡せ、じゃないならやらない」とはっきり言え。もしこの辺を冗長だと考える同僚がいるならもう辞めたほうがいい。

引数チェックや状態チェックのコードで画面の半分が埋まったならそのコード設計おかしい。一旦手を止めてよく考えろ。一つの機能を動かすのにそんなに引数がいるのか、そんなにチェックする状態が多いのか、そしてそれらは本当に必要検討しろ

テストコード絶対に書け。テストコードが書けない技術絶対に使うな。意味のあるテストが書けないならやめたほうがいいという輩もいるが、とにかく意味があろうとなかろうと書け。引数にこれを入れたらこうなる、こういう状態でこういう事したらこうなる、というお前の意図はとにかく示せるだけ示せ。

だいたいこの辺を横着したやつは翌年酷く後悔するか、そこのメンテ担当した同僚を攻撃している。

就職活動するとき重要ポイント

コードが書けなくても大丈夫、という会社は、コードが書けたほうが有利な会社ではなく、本当にコードを書かない会社だというこは肝に銘じておけ。身につくスキルEXCEL方眼紙を最低限の手数で作れるようになることか、本気でやればビジネス理解できるかもしれないが、お前の技術者としてのキャリアはそこで止まる。

仮に憧れのスーパーハッカーがいる会社を目指しているとして、彼らがそこでどう働いているか、なにが泥臭いのかを想像できない、聞くことができないならやめておけ。浮かれ過ぎだ。

仮にGithubURLを教えろという会社を目指しているとして、そこのリポジトリを飾り立てようと考えたならやめておけ、そういう会社Githubアウトプットすることを日常的な趣味として苦ではなくやり続けられる人を求めている。

年収をその会社選択基準にしているならそこはおまえには分不相応会社からやめておけ。仮に入れたとしても馴染めることはまず無い。これは年収が低くても同じだ。

人間関係重要ポイント

嫌いな人がいるならその会社はやめていい

少しだけ追記

コメントを観てこの「最小且つ単一論理でなにか否定できた気になる」という輩への対処が一番疲れる

もうちょっと追記

一晩立ってみたらこんなにブクマついててびっくりした。気になったブコメもあったのでちょっと追記しておく。

いきなり視点ミクロに、と言うやつなんだが、結局若いうちにこういうのできてないやつはあとで苦労するが、最初のうちは体力でカバーできている。体力でカバーできなくなったときに本当の意味でつけを払う羽目になるという意味で言ったり、あとオレみたいなおっさんが大変つらい思いをする、という意味でも言っている。

Fラン関係なくねっていうやつだが、昭和世代ステレオタイプかもしれない、ごめん。勉強する習慣もなければ大してやってきてもいないやつはこの業界だと倍苦労する羽目になるというふうに言いたかったと思う。どんな業界でもそうだとは思うが。

返す刀で結論づけしたがる人々がやっぱり現れるな、君たちはそう思わない人なんだろうし議論する気もないが何かしら言いたい人なんだろう。別にそれはそれでいいよ。お仕事頑張ってね。

「俺は大して辛くないけどなー」っていう人もやっぱり現れるな。辛くないんだったらいいことだと思う、お仕事頑張ってね。

4Kモニターものすごく細かい文字を読んでいる若者を見た、という人、俺も同意する。もう見ていられないんだよね。

関白宣言っぽいな、というのは俺も思った。

結局の所、プログラマ35歳定年説は俺も打ち破りたいと思っていた口なんだが、打ち破れる人とそうでない人がいる、ということで、俺は後者だった、ということだ。当然50過ぎてもプログラマやっている人は見かけるので、数学的な真理というわけではなく、統計的な傾向なんだろうと思っている。

若いうちから、いい環境で働かないと、気持ちのほうがどこかで先にギブアップする。いくら大好きで転職だと思う仕事だとしても、体力や若さで捻じ曲げていることはなかなか気づかない。色んな本を読んで客観的指標判断したほうがいい。

遺言とか言って書いておいて追記したら俺はソンビか亡霊なんだろうか?

さらにもうちょっと追記

びっくりした。こんなおっさん愚痴みたいなエントリーがこんなにブクマされるとは思ってなかった。いくつか気になったブコメがあったのでやはり書いてみたくなったので書く。

まず、この遺言最後にいなくなるのかという話だが、おそらくいなくなる。ゾンビで居続ける体力ももはやない。

次の準備はすでにしている。それは俺が本質的にやりたかたことに近いことだと思うのをピックアップしている。

本質的にやりたかたことって何かという話なんだが、まず俺が感じるプログラマーという仕事は「良き作り手であり続けること」が根本的なモラルだと思っている。若手で右も左もわからないような状態でも、それこそやっとフィズバズが理解できたような状況でも今持っているレベルで最大限にできうる一番いいもの模索し続ける仕事だと思っている。初心者にはチェックコード書け、意図はできるだけ込めろというのはそういう意味でもある。これを真正から受け止めてくれる職場を探したほうがいいというのは追加しておきたい。

プログラム論とかそういう話がしたいんじゃないということだけは言っておく。

俺も体力があるうちは良きつくり手を目指していたのだが、本質的にやりたいこと、もうちょっと言うなら、俺のモラルの軸は作ることにではなく使うことにあった。プログラミングというアクティティを挟んでこっちにつくり手がいてあっちに使い手がいる。仕組みを理解して作るのがプログラマーなら、作ったプログラム理解してよりよい日常模索するのが使い手、と言ってもいいかもしれない。いいフィードバックループのあっちとこっち、と言ってもいいかもしれない。俺は「良き作りてが使ったものを使う良き使い手でいたい」ということに気づいたので、遺言を書くことにした。少なくともこれに気づいた時点でプログラマーとしての俺は死んだ。

まだ直感的なものしか無いので、うまく言語化できていないのは申し訳ないんだが、今後10年位はそれを模索していくのではないだろうか。

2020-11-10

仕 事 が で き な い !!!!!!!!!!!!!!!!!!

マジで意味わかんねえ、他の会社でもそうなのか

作業に関するマニュアル情報が一切ねえ

みんなやってる作業なのに何の情報も一切ない

全部誰かがやってるメールのやりとりを見て汲み取るだけ

この作業はどのようなことをするのか、どの部分を自分担当するのか、どこに気をつけるのか、どのような部分を確認するのか、最終ゴールは何、そもそもこれは何

報連相大事だ、何もわかりませんと言いたい。これは異常だと言いたい。

からないことが多すぎる、正解は常に一つだけど、不正解無限にある。

じゃあ最初から正解を上げておけば、不正解は正解に近いけど正解じゃない物だけになる。確認と訂正が楽になる。

から情報の共有、ひいてはマニュアル存在重要になる。

大体みんながやる作業なんだったら、定型化してるはずだろ、ならマニュアルにできるだろ、なんでないんだよクソがクソクソ

作業をやった、死ぬほど確認相談をした。俺が相談した人は聖人だった。80%ぐらい答えてくれたし、怒らなかった。

無視したり、逆ギレする奴もいるし、俺に対して「無能」のレッテルを貼って逃げようとする奴もいるからな、すごい怖いけど聞いてよかったよ

本当に助かった

でもここで何で俺が遜らなきゃダメなんだ???答えてくれた人はすごいありがたい。でも何で、そもそも俺が質問しなきゃいけないんだ??

最初から情報が共有されてたら、いちいち答えてもらう必要も頭下げる必要もないんだが???

おかしいだろ、何で俺が胃をきゅっとさせながら申し訳なさそうに聞かなきゃならんのだ、業務の怠慢を末端に押し付けんなよ、部署ちゃん仕事のやり方ぐらい残しておけよ

報連相をしたら、「やり方が悪い」なんて言われるだろう。

なんせ正解がどこにも書いてない問題について、正答を出そうとしたら沢山の疑問と答えが必要になるからな、yes/noクイズだよこれは。答える方からしたらしんどい

つーかしんどいって思うんならマニュアル作れよ、yes/noクイズは1発で正解すんのか??しないだろバカだろ正解を渡せよバカ


俺が悪い以前に、俺に振る奴が悪い、やり方が悪い。

何で情報がないまま仕事を振るんだ???

AはBBという仕事です。OOOやXXXをVVVするためにKKK連携してCCCDDDなどのチェックを行い、BB完了させます

とか具体的に言えばいいだろう??言ったところでそこに書いてない部分の疑問は増えるからな、クソみたいなやりとり無限にしなきゃならんけどな

5W1Hとか、新人がめっっっっちゃくちゃ教えられてるが、できてないのは上司の方だったりしないか???

上司は、毎年教えられるのか???5W1H新人以降に意識したことあるのか??????

マジでわかんねえ、何も知らされてねえ、何も共有されてねえ

「知らない」こと自体は数えられない。

「ここが分からない」になってようやく、知らないことを自覚して数えることができるんだわ

努力ベースの「個人が注意して」行う作業無駄なんだわ、認識してなきゃ注意できないんだわ

今お前は「ハワイの気温は?」って聞かれる前に「ハワイの気温」について考えてたかちゃんと注意できてたか

できないだろバカが、仕方がないんだよこれは、意識してる奴が「今からハワイの気温について聞くから」とか事前に共有することで、

ハワイの気温について調べたり把握したりする作業ができるんだわ

クソが

何も仕事ができねえ

全て確認し終えて、作業が終わって、次の奴に仕事を振ったら、本来不要な部分の確認作業もさせようとしてたわ

不要なら不要って先に言えや!!!!!!!!!!!

2020-11-08

DDDのSpecificationパターンって破綻してるだろ

仕様に関わる判定処理とかを一元管理したいんだろうけど、sqlのwhere句に書いちゃだめとか終わってるだろ

無理があるよ 誰だよこんな破綻してるのをパターンとか言っちゃって提唱してる頭悪いやつ ちゃん検証してねぇだろ

普通に考えてwhere句にも判定処理を書くんだから、判定処理は分散するよ この理想郷はあり得ない

2020-10-22

anond:20201022074405

DDDとかクリーンアーキテクチャとかってのは車輪の再開発みたいなもの

こういう概念1980年代からあって普通に利用されてた

頭悪い無知識な奴がさも新しいことと思っているだけ

ログイン ユーザー登録
ようこそ ゲスト さん