Strukturregeln. Lernen, wie man Programme strukturiert, Erforschung von Möglichkeiten, Fehlern, Lösungen usw. - Seite 4
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Und was passiert mit Ihrer klaren Struktur, wenn sich der Kunde in der Mitte oder sogar gegen Ende des Projekts plötzlich ändert?
Dies ist ein guter Test dafür, wie bereit und belastbar Ihr Projekt gegenüber Veränderungen ist.
Das ist das Problem, weshalb ich in diesem Thread bin.
Ich möchte eine Antwort darauf finden, wie man einen solchen Rahmen gestalten kann (oder wie man den Kunden in einen solchen Rahmen zwängt), so dass sowohl seine Wünsche erfüllt werden als auch das Projekt nicht kaputt geht.
SZY, weil die Münze hat zwei Seiten, mit einem können Sie das Projekt zu ändern, mit einem anderen können Sie sagen: "Nein, wie ein Teil dieses Projekts nicht tun können," die Wahrheit liegt irgendwo in der Mitte.
Am besten ist es, die Entwicklung so zu gestalten, dass die meisten der wesentlichen Kundenwünsche realisierbar sind.
Heutzutage zeichnet kein normaler Programmierer mehr Flussdiagramme. All dies ist theoretischer Unsinn, der für den Unterricht in der Schule gedacht ist, aber nicht für die Arbeit in realen Projekten.
Es hängt alles davon ab, was man zu Papier bringt.
Ich bin nicht für das Schreiben, aber manchmal muss man eine allgemeine Struktur auf dem Papier entwerfen. Es ist bequem und schnell, es ist wie eine Skizze für einen Juwelier, das Gesamtbild sollte klar sein.
Vielleicht gibt es deshalb so viele nicht-normale Programmierer, weil sie keine Flussdiagramme zeichnen.
Heutzutage zeichnet kein normaler Programmierer mehr Flussdiagramme. All dies ist theoretischer Unsinn, der dazu dient, Schulkindern etwas beizubringen, aber nicht, um in realen Projekten zu arbeiten.
Heutzutage zeichnet kein normaler Programmierer mehr ein Flussdiagramm.
Ich schätze, dass es deshalb so viele abnormale Programmierer gibt, weil sie keine Flussdiagramme zeichnen.
Ich würde es nicht so scharf als "theoretischen Unsinn" bezeichnen. Das Zeichnen von "Quadraten mit Pfeilen" auf Papier ist in der Programmierung weit verbreitet. Nehmen Sie zum Beispiel UML - voll von "Pfeilen mit Quadraten". :) So können auch Blockdiagramme in der Anfangsphase nützlich sein...
Ich habe versucht, mit UML zu entwerfen, es ist Unsinn (IMHO).
All diese Quadrate und Pfeile kann ich perfekt in meinem Kopf behalten, aber Abstraktionen passen nicht in meinen Kopf, also skizziere ich sie.
HI Wenn man tiefer gräbt, ist das menschliche Gehirn gut geeignet, um sich Bilder, Landkarten und Verhaltensmuster zu merken, aber nicht, um Abstraktionen zu bilden; Abstraktion ist das Schwierigste, was ein Mensch tun kann.
Die Menschheit hat also immer versucht, die Abstraktion in etwas Vertrauteres zu formalisieren.
Das menschliche Gehirn ist gut geeignet, um sich Bilder, Landkarten und Verhaltensmuster zu merken, aber nicht, um Abstraktionen zu bilden; Abstraktionen sind die schwierigste Aufgabe für einen Menschen.
ZZZI Deshalb strebt die Menschheit immer danach, die Abstraktion in etwas Vertrauteres zu formalisieren.
Ich stimme zu.
Ich habe meine eigenen Methoden, um mein eigenes Gehirn in diesem Bereich neu zu verdrahten, ich habe sogar eine Software entwickelt (die ich bei Gelegenheit weitergeben kann), aber die Entwicklung ist sehr langsam (wenn auch im Nachhinein spürbar).
--
In gewissem Sinne ist jede Art von Programmierung Abstraktionsarbeit, aber es gibt große Unterschiede in Bezug auf das Niveau und die Fertigkeiten im praktischen Umgang mit abstrakten Konzepten.
Ich stimme zu.
Ich habe meine eigenen Methoden, um mein eigenes Gehirn in diesem Bereich zu schärfen, ich habe sogar Software entwickelt (ich kann sie bei Gelegenheit weitergeben), aber die Entwicklung war sehr langsam (obwohl das im Nachhinein auffällt).
--
In gewissem Sinne ist jede Art von Programmierung Arbeit mit Abstraktionen, aber es gibt einen großen Unterschied im Niveau und in der Fähigkeit der praktischen Anwendung von Abstraktionen.
Wir sind nicht an Abstraktion um der Abstraktion willen interessiert, nicht wahr?
Ich denke, da wir evolutionär nicht optimal an die Abstraktion angepasst sind ?! (fraglich, zumindest besser als die anderen Bewohner dieses Planeten), sollten wir versuchen, Krücken zu bauen.
Man hat zum Beispiel eine Technik wie das Brainstorming erfunden.
Es fällt mir oft schwer, eine Entität zu benennen, ihr einen prägnanten Namen zu geben, der sowohl verständlich genug als auch extrem kurz ist. Wenn das gelingt, ist die Abstraktion leicht zu assimilieren.
Tut mir leid, ich kann jetzt nicht viel schreiben (es ist nicht bequem, es von einem Handy aus zu tun), ich werde keine Zeit haben, es zu tun, wenn ich dort bin. Ich kann jetzt nicht viel schreiben (am Telefon ist es unpraktisch), und ich werde keine Zeit dafür haben.
Tut mir leid, dass ich jetzt nicht viel schreiben kann (von meinem Handy aus ist es nicht bequem), ich werde keine Zeit haben, wenn ich dort bin. Besser morgen.