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