1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Saarländer…

Könnte zu schlampiger Programmieren verleiten.

  1. Thema

Neues Thema


  1. Könnte zu schlampiger Programmieren verleiten.

    Autor: Saardist 17.02.10 - 20:58

    >Pachika soll Programme zur Laufzeit überwachen und Abstürze >feststellen.

    >Läuft das System wieder, soll Pachika den Fehler erkennen und >reparieren.

    Tjaaaaa, aber eben nur, WENN das System wieder läuft. Dann kann es allerdings schon viel zu spät sein. :-D
    Beispiel: Tolle Doktorarbeit in einem namhaften Textverarbeitungsprogramm geschrieben, kurz vor der Fertigstellung einen Tag vor Abgabetermin tritt ein Bug im OS/Textverarbeitungsprogramm auf, welcher zum Absturz des OS/Programms führt -> Dokument futsch, aber Haupsache, das Programm wird hinterher automatisch gepatcht. Das verlorene Dokument aus dem RAM bringt diese Selbstzurechtfrickelaktion jedenfalls nicht zurück.

    Anderes Beispiel: Ein (aufgrund von blindem Vertrauen in die Selbstheilungskräfte) schlampig hergestelltes Programm für eine Herz-Lungen-Maschine. Programm stürzt unvorhergesehen ab und die Maschine schaltet sich in Folge ab. Es erkennt hinterher den Fehler und frickelt seinen Code zurecht, der Patient ist halt leider tot, aber das macht ja nichts. Das nächste Mal/beim nächsten Patienten ist der Fehler ja behoben. ;-)

    Man sollte lieber schon bei der Qualitätskontrolle der Software pingeliger sein als das Programm sich selbst zurechtfrickeln zu lassen.

    Programmierer könnte solch ein System dazu verleiten, nachlässiger ihren Quellcode zusammenzufrickeln und nicht sorgfältig zu programmieren, da ja eh jeder Fehler automatisch behoben wird (oder halt zumindest 17% der Fehler, was dann vermutlich von der Marketingabteilung schon einkalkuliert wird). In Zeiten, in denen die Geschwindigkeit in der Entwicklung von (Software-)Produkten immer mehr forciert wird und die Qualität der Produkte schon heute gravierend leidet, ist das neue System nicht gerade zuträglich (abgesehen vom zusätzlichen Gewinn, der mit Qualitätsmängeln erkauft wird).

    Ich persönlich würde das System eher als eine Art "Modultest" sehen und nicht als ein Allheilmittel gegen schampige Programmierung. Letztenendes kann es auch nicht wirklich viel mehr als abzuchecken, was bei einer Berechnung rauskommen soll und wieviel hinterher tatsächlich herauskommt.

    Logikfehler (diese dürften wohl den Löwenanteil an Programmierfehlern ausmachen) kann Pachika ohnehin nicht beheben.

  2. Re: Könnte zu schlampiger Programmieren verleiten.

    Autor: patchymaster 17.02.10 - 21:05

    Es könnte dazu führen, das man keine Test-Teams nutzt oder das Testen herunterfährt.

    Und wenn man den Debugger laufen lassen muss, kann man auch exceptions einschalten.
    Z.B. das jemand -5 (minus fünf) Waschmaschinen bestellt und von Amazon den Geldbetrag überwiesen kriegt.

    Ein Bauingenieur weiss mehr über ein Haus als ein Boni-Macaroni-Software-Team-Manager über Software.

  3. Re: Könnte zu schlampiger Programmieren verleiten.

    Autor: It's Me 18.02.10 - 14:12

    Saardist schrieb:
    --------------------------------------------------------------------------------
    > Tjaaaaa, aber eben nur, WENN das System wieder läuft. Dann kann es
    > allerdings schon viel zu spät sein. :-D
    > Beispiel: Tolle Doktorarbeit in einem namhaften Textverarbeitungsprogramm
    > geschrieben, kurz vor der Fertigstellung einen Tag vor Abgabetermin tritt
    > ein Bug im OS/Textverarbeitungsprogramm auf, welcher zum Absturz des
    > OS/Programms führt -> Dokument futsch, aber Haupsache, das Programm wird
    > hinterher automatisch gepatcht. Das verlorene Dokument aus dem RAM bringt
    > diese Selbstzurechtfrickelaktion jedenfalls nicht zurück.
    >

    Hätte er mal LaTeX benutzt und Backups gemacht :D

    Schönen Tag noch ;D

    Just Me.
    It_sMe@jabber.org

  4. Re: Könnte zu schlampiger Programmieren verleiten.

    Autor: Weltweites Twittern 18.02.10 - 22:46

    Die Backups sichern die Diplomarbeit. Nicht latex.

    latex+cygwin/vim hat mir nach der Einleitung die Diplomarbeit am ersten Tag vernichtet.
    Das build-script hat dann vor dem triple-latex-lauf ein "cp --update " oder sowas in den backup-ordner gemacht.

    Denkt dran: Bei latex hat man am ende sehr hohe durchlaufzahlen, nur um optische fehler oder Tippfehler zu entfernen. Daher kann man in LaTeX Kapitel abschalten. Bei Einzelhändlern sind das Produkte mit "hoher Rotation" bzw. "hoher Umschlagsgeschwindigkeit".

    Hurd, Amiga, Duke Nukem, LaTeX3(?)... . War nur rhetorisch gefragt. Man könnte ja bei Wikipedia nachsehen.

    Ansonsten noch: Nehmt immer nur das neueste Latex-Buch. Die Bücher-Anleitungen für 2.09 laufen im compatibility-mode und das ist dann langsamer und suckt auch sonst. Das ist als ob man C statt c++ programmiert, obwohl man den c++-compiler benutzt.
    Wobei man heute eh alles online macht... .

    Und ich hätte besser den latex-code gleich in Word mit aller rechtschreibkontrolle getippt (ja. Das geht. Word schockt die Endung nicht und er frisst es trotzdem.). Dann kann man live die roten Schlangen überprüfen. Im Nachhinein ist viel Aufwand und wäre vermeidbar gewesen. Vim braucht man für ein latex-dokument meist nicht wirklich. Texte mit vielen Formeln sind was anderes. Aber da braucht man auch kaum Rechtschreibprüfung.
    Und die freien rechtschreibprüfungen mögen besser sein als früher. Aber word war schon ganz hilfreich. Wenn man alles einschaltet.
    Dann taugt die WorksSuite (nicht Works! sondern WorksSuite)-Lizenz wenigstens mal etwas.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Anwendungsbetreuerin / Anwendungsbetreuer (w/m/d) SAP-Benutzer- und Zugriffsverwaltung
    Berliner Stadtreinigungsbetriebe (BSR), Berlin
  2. Abteilungsleiter Digitalisierungsmanagement (w/m/d)
    Mainova AG, Frankfurt am Main
  3. IT System Engineer für Softwareinstallationen und Systembetreuung (m/w/d)
    PSI Automotive & Industry GmbH, Berlin
  4. Technische*r Projektleiter*in (w/m/d)
    Hensoldt, Ulm

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de