クソコードはエンジニアを貧乏にする｜ミノ駆動
何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。 プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。 クソコードはエンジニアを貧乏にしてしまう。 なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。 本記事の構成■理由①：プロダクトが利益を出せなくなる ■理由②：エンジニアが資産蓄積できなくなる （←ココ重要） ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ 理由①：プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。３項目に分けて説明する。 【クソコードは読みにくい】 どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。 「クソ
設計の「why」を言語化する - Magnolia Tech
設計の「why」を言語化できる人は強いんですよ— magnoliak🍧 (@magnolia_k_) 2022年10月29日 っていうか、驚くくらい「why」が上手く表現できないんですよ、普通は 手順は言えても、なぜ？が言えない— magnoliak🍧 (@magnolia_k_) 2022年10月29日 設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。 また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るとき
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
UMLとかAWS構成図とかを描くツール
UMLとか構成図とかの図を描くの何のツールを使えばいいか迷いませんか？私は迷います。 ですので、最近使っているツールを紹介します。 世の中にツールがイロイロあるのは理解した上で、大量に紹介するとやっぱり迷うので、似たようなツールや個人的に使わないツールはバッサリ省いています。 パワポで描く まずはPowerPointです。 エンジニアや技術系の方は「パワポで図を描くのはちょっと、、、」と思われるかも知れませんが、状況によってありだと思っています。 パワポのメリット パワポは、ビジネスユーザーならほぼ誰でも使える システムを作る時に、お客さん側も含めた関わるメンバー全員がITに詳しいとは限りません。しかしそういう人にもシステムに対する理解は最低限していただく必要があります。システム構成図とか特に興味がない人に説明するときに「新しいツールをいれてください」というのはハードルが高いです。 パワポ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Qiita
