構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。 - ページ 4

[Mykola Demko]

C-4:

また、プロジェクトの途中、あるいは終了間際に、顧客が突然変わってしまった場合、明確な構造はどうなるのでしょうか。

• 当初の要求の5％。
• 当初の要求の10％。
• 当初の要求の25％。

これは、プロジェクトが変化に対してどれだけ準備ができているか、どれだけ回復力があるかを試すのに良いテストです。

これが問題で、このスレッドにいるわけです。

お客様の要望を満たし、かつプロジェクトが壊れないような設計（あるいはそのようなフレームワークへの詰め込み方）の答えを見つけたいのです。

SZY コインには2つの面があり、1つはプロジェクトを変更することができ、もう1つは「このプロジェクトの一部として行うことはできません」と言うことができるので、真実は中間のどこかにあるのです。

一番良いのは、お客様の本質的な欲求のほとんどが実現できるような開発設計をすることです。

[Alexandr Bryzgalov]

C-4:
今どきフローチャートを描く普通のプログラマーはいない。これらはすべて、小学生に教えるための机上の空論であり、実際のプロジェクトで使うためのものではありません。

すべては、何を紙に書くかによるのです。

私は書くことに賛成しているわけではありませんが、時には紙の上に大まかな構造を描くことも必要です。便利で早い、宝石商のスケッチのようなもので、全体像がはっきりしていることが大切です。

フローチャートを描かないからこそ、非正規のプログラマーが多いのかもしれませんね。

[Vladimir Gomonov]

C-4:
今どき、普通のプログラマーがフローチャートを描くことはない。これらはすべて、小学生に教えるための机上の空論であり、実際のプロジェクトでは通用しない。

まあ、「机上の空論」とまでは言いませんが、「四角に矢」を紙に描くことは、プログラミングの世界では広く行われています。 少なくとも、同じUMLでも、「四角に矢」だらけですからね。だから、初期 段階でのブロック図も有効なのですが......。

[TheXpert]

C-4:
今どき、普通のプログラマーがフローチャートを描くことはない。

ブロック図はありません。やはり建築を描かなければならない。

[Vladimir Gomonov]

sanyooooook:

フローチャートを描かないから、異常なプログラマーが多いんでしょうね。

;)

[Mykola Demko]

MetaDriver:
プログラミングの世界では、紙の上に「矢印付き四角形」を描くことは広く行われており、例えばUMLは「矢印付き四角形」で埋め尽くされています。だから、初期 段階でのブロック図も有効なのですが......。

UMLで設計して みたが、ナンセンスだ（IMHO）。

四角や矢印は頭の中に完璧に収まるのですが、抽象的なものは頭に入らないので、スケッチしています。

HI もっと掘り下げると、人間の脳は絵や地図、行動パターンを記憶するのには適しているが、抽象的なものを構築するのには適していない。抽象化は人間ができることの中で最も難しいことなのだ。

だから、人類は常に抽象的なものをより身近なものに形式化しようと試みてきた。

[Vladimir Gomonov]

Urain:

人間の脳は、絵や地図、行動パターンを記憶することには適しているが、抽象的なものを構築することには適していない。抽象的なものは、人間にとって最も難しい課題である。

ZZZI だからこそ、人類は常に抽象的なものをより身近なものに形式化しようと努力するのです。

私もそう思います。

この分野では自分なりに脳を研ぎ澄ます方法があり、ソフト開発までしている（たまに共有できる）のですが、開発は非常に遅いです（後から見ると顕著ですが）。

--

ある意味、あらゆるプログラミングは抽象化作業なのですが、抽象的な概念を実際に扱うレベルやスキルは千差万別なのです。

[Mykola Demko]

MetaDriver:

私もそう思います。

この分野では自分なりに脳を研ぎ澄ます方法があり、ソフトウエアの開発までしている（たまに共有できる）のですが、開発は非常に遅れています（今思えば顕著なのですが）。

--

ある意味、すべてのプログラミングは抽象化されたものを使う仕事ですが、抽象化を実用化するレベルやスキルに大きな差があります。

私たちは、抽象化のための抽象化には興味がないんですね。

私たちは進化上、抽象的な表現に最も適しているわけではありませんから。(議論の余地はあるが、少なくともこの惑星の他の住人よりはましだ)、松葉杖を作ろうとするはずだ。

例えば、ブレーンストーミングという手法が考案されました。

私はよく、実体の命名に悩みます。十分に理解でき、かつ極端に短い簡潔な名前をつけるのです。それが成功すると、抽象化されたものが簡単に同化してしまうのです。

すみません、今はあまり書けません（携帯からだと不便です）、現地に行くと時間がありません。今はあまり書けない（スマホだと不便）。 時間がないだろうから。

[Rustamzhan Salidzhanov]

私はToRを読み、構造という形での解決策が思い浮かばない場合、他のプロジェクトに 取り組みますが、通常、初日に実装を開始することはありません。プログラムがICLやXMLでない場合、私は読み、実装のバリエーション、構造タイプ、クラスを計算します。頭の中に共通の絵が浮かんだら、ブロックを切ったり、基本モジュールを書き始めたりします。 何かうまくいかないと、テトリスのようなおもちゃを持ってソファに倒れこみ、完全に解決するまで、あるいは飽きるまで遊びます :)

[Vladimir Gomonov]

Urain:

今、あまり書けなくてすみません（携帯からだと不便です）、現地に行くと時間がありません。より良い明日を。

問題ありません。私も今日は嫌なことがありました。 枝の常設化（「バグ、バグ、質問」など）を大いに期待します。 議論の形式が徐々に建設的な流れに落ち着けばいいんですけどね。