その通りだと思うけど、上の人が「ドキュメントですべて解決できる」と考えている事と、「チームの最低ラインでの設計」で賄えるシステムは実在しない、という２つの悲劇が避けられない。
認知負荷で脳がバグるのわかるわー。システムの複雑化、マジで無理ゲーだろｗ
その通りと思うけど、ドキュメントも結局人間が理解するし、基本セオリーを理解していない新人レベルのシステムは価値を生まないので、そこには異論あるな。
「分かりやすく」とかで言いがちなコード分割とかモジュール分割の目的をより詳細に言語化してて腑に落ちた
Aボタンを押したらBテキストボックスが表示されBに任意の文字列が入力できてその値によってCラベルの表示が変わるみたいな項目が連動するのをユーザーはやりたがるんだけどバグが起きやすい
書籍ソフトウェアメトリックスの用語を用いた方がいい
アーキテクチャの本質は「計算量の制御」。シンプルな構造にする理由。いつの間にかだれか(自分含む)がやらかす。
脳が壊れるのではなく、理解が及ばなくなる境界線。プログラムのクラッシュのイメージなのか。だがクラッシュするのは思考だ。／「神狩り」で「この文法は人間の脳には使えるはずがない」というネタを思い出した。
いうてOOで3行のクラスを100個導入して、個々はシンプルだぞって言われてもいやでしょ？複雑性や認知負荷は下げるんじゃない、むしろ抽象導入で増える。あくまでも関心毎の視点で整理してるだけ is トレードオフである
だからモジュール化が大事ってことよね……
「シンプル・イズ・ベスト」って言葉が昔からありますよね。
わいは忘れやすいタイプなので、ちょっと離れてると戻るまでのラグがお辛い＼(^o^)／
破綻した設計の妥当な末路/システム全体見渡したらそれでも認知の限界を超えがちだけど、だからこそ一つ一つはシンプルでないと本当に爆発炎上プロジェクトになる。
めちゃくちゃ欲しい情報だった。認知負荷を可能な限り下げたいという自身の思惑にそった記事で、これによって他人の褌で相撲ができるようになりそう
エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム - Qiita
その通りだと思うけど、上の人が「ドキュメントですべて解決できる」と考えている事と、「チームの最低ラインでの設計」で賄えるシステムは実在しない、という２つの悲劇が避けられない。
認知負荷で脳がバグるのわかるわー。システムの複雑化、マジで無理ゲーだろｗ
その通りと思うけど、ドキュメントも結局人間が理解するし、基本セオリーを理解していない新人レベルのシステムは価値を生まないので、そこには異論あるな。
「分かりやすく」とかで言いがちなコード分割とかモジュール分割の目的をより詳細に言語化してて腑に落ちた
Aボタンを押したらBテキストボックスが表示されBに任意の文字列が入力できてその値によってCラベルの表示が変わるみたいな項目が連動するのをユーザーはやりたがるんだけどバグが起きやすい
書籍ソフトウェアメトリックスの用語を用いた方がいい
アーキテクチャの本質は「計算量の制御」。シンプルな構造にする理由。いつの間にかだれか(自分含む)がやらかす。
脳が壊れるのではなく、理解が及ばなくなる境界線。プログラムのクラッシュのイメージなのか。だがクラッシュするのは思考だ。／「神狩り」で「この文法は人間の脳には使えるはずがない」というネタを思い出した。
いうてOOで3行のクラスを100個導入して、個々はシンプルだぞって言われてもいやでしょ？複雑性や認知負荷は下げるんじゃない、むしろ抽象導入で増える。あくまでも関心毎の視点で整理してるだけ is トレードオフである
だからモジュール化が大事ってことよね……
「シンプル・イズ・ベスト」って言葉が昔からありますよね。
わいは忘れやすいタイプなので、ちょっと離れてると戻るまでのラグがお辛い＼(^o^)／
破綻した設計の妥当な末路/システム全体見渡したらそれでも認知の限界を超えがちだけど、だからこそ一つ一つはシンプルでないと本当に爆発炎上プロジェクトになる。
めちゃくちゃ欲しい情報だった。認知負荷を可能な限り下げたいという自身の思惑にそった記事で、これによって他人の褌で相撲ができるようになりそう