xdebug, dbg wichtig oder Nonsens?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • xdebug, dbg wichtig oder Nonsens?

    Hi,
    bei Profi-IDE's wie phpEd, Maguma, Komodo, Zend, usw. sind debugger enthaltn, vor allem xdebug und dbg, wobei dbg sogar das remote-debugging beherrscht.

    Nun verlange ich dzt. als Auftraggeber von freelancern, um die Qualifikation etwas zu steigern, dass sie nicht bloß mit schlichten Editoren wie notepad PHP "programmieren", sondern u.a. auch das debuggen mit dbg, xdebug (neben anderen Dingen) können müssen.

    Nun sagen mir 90%, dass xdebug, dbg ein Nonsens und überflüssig ist, während 10% diesen Standpunkt belächeln.

    Wie ist das nun tatsächlich?

    Warum gibt es denn in high-end IDE's diese xdebug, dbg? Und wie wichtig ist der Umgang damit?

    lg

  • #2
    also ich arbeite seit 2 monaten mit zend studio bzw. zend-server und möchte das nicht mehr missen. du kannst beliebig haltepunkte setzen und so z.b. in schleifen ständig die werte überprüfen und must nicht permanent mit irgendwelchen testausgaben arbeiten. das erleichtertet das auffinden von fehlern ganz ungemein. auch wenn ich vom zend-editor wenig halte.

    gruß
    peter
    Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
    Meine Seite

    Kommentar


    • #3
      Das Debuggen mit Tools sickerte aus anderen Sprachen in die PHP-Welt hinüber. Dort hat man selten so ideale Bedingungen wie mit PHP.

      Als PHP-Entwickler tippt man schnell mal var_dump($foo), Strg+S, Alt+Tab, Strg+R und zack schon hat man eine Variable getestet.
      In kompilierten Sprachen ist nach jeder Änderung des Codes ein Rebuild nötig. Das dauert wesentlich länger.

      Mit PHP hat man fast immer eine Ausgabefläche zur Hand, wo man Testausgaben machen kann (Shell, Browser, Logfile).
      In anderen Sprachen wird z.B. hardwarenah programmiert (Treiber, embedded) oder verteilte Architekturen.

      PHP-Scripte sind vergleichsweise klein. Wieviele LOCs hat eine PHP-Anwendung im Schnitt, im Vergleich zu C++-Anwendungen? Ich habe keine Zahlen, aber der Unterschied dürfte deutlich sein.

      Fazit: PHP-Code kann man auch ohne Tools debuggen. Es geht.
      Man kann aber auch Debugger verwenden. Damit gehts noch besser.


      Ich würde allerdings nicht soweit gehen und sagen, dass ein PHP-Entwickler nur dann wirklich qualifiziert ist, wenn er die bekannten Debugger kennt und bedienen kann.
      Für mich ist es ein Indiz für Professionalität, niemals ein Ausschlußkriterium.
      Schließlich kann man den Umgang mit einem Debugger an einem Tag lernen und dann auch nichts falsch machen. Anders als z.B. Unit Testing.

      Kommentar


      • #4
        Re: xdebug, dbg wichtig oder Nonsens?

        Original geschrieben von silberfisch
        Nun verlange ich dzt. als Auftraggeber von freelancern, um die Qualifikation etwas zu steigern, dass sie nicht bloß mit schlichten Editoren wie notepad PHP "programmieren", sondern u.a. auch das debuggen mit dbg, xdebug (neben anderen Dingen) können müssen.
        Ich würde dich hier gerne darauf hinweisen, dass du ein nicht realitätsnahes Schwarz-Weiß denken an den Tag legst. Zwischen (meiner Meinung nach) überladenen und schwerfälligen Entwicklungsumgebungen (die sicherlich ihre Daseinsberechtigung haben) und Text-Editoren wie Notepad gibt es eine breite Masse an mehr oder weniger effizienten Zwischendingen. Deine Aussage impliziert aber "alles was nicht 'Profi'-IDE ist, ist 'Notepad'".


        Original geschrieben von silberfisch
        Nun sagen mir 90%, dass xdebug, dbg ein Nonsens und überflüssig ist, während 10% diesen Standpunkt belächeln.
        Wo wir hier doch grade von prof. Verhalten reden: Aus der Luft gegriffene Prozentaussagen finde ich immer sehr lustig


        Ich persönlich kann sagen, dass ich PHP mit einem schlichten Editor entwickel. Syntax-Highlighting, Code-Einrückung und Zeilennummern genügen mir. In dem Betrieb, in dem ich arbeite, benutzen alle meine Kollegen Zend-Studio welches für mich schlicht überladen ist, und dennoch stehe ich puncto Programmiereffizienz meinen IDE-Kollegen in nichts nach.

        Um mal einen Vergleich anzustrengen: Ich kenne Leute, die arbeiten nur auf der Kommandozeile. Obwohl es Desktop-Software gibt. Und ich wage hier teilweise sogar zu behaupten, dass diese Leute wesentlich schneller arbeiten, als der Klicki-Bunti-Pendant. Es ist eben, wie so vieles im Leben, in erster Linie Geschmacks- und Einstellungssache
        [FONT="Helvetica"]twitter.com/unset[/FONT]

        Shitstorm Podcast – Wöchentliches Auskotzen

        Kommentar


        • #5
          also den zend-debugger möchte ich, wie schon gesagt, nicht mehr missen. allerdings ist diese form des debuggens für kein qualitätskriterium bei der bewertung eines programmierers. die handhabung ist an einem tag gelernt, wenns denn sein muss.

          gruß
          peter
          Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
          Meine Seite

          Kommentar


          • #6
            o.k. - ist dann "unit testing" ein Indiz für "high-end"-programmers; vielleicht sonst noch was, zbsp uml? Alter über 30 J.?
            mfg

            Kommentar


            • #7
              Um Himmels Willen, so hab ich das nicht gemeint!
              Es ist generell eine schlechte Idee, gute und schlechte PHPler anhand harter Kriterien zu unterscheiden.
              Eine Liste von Fachbegriffen ist sowieso kein Qualifikationstest. Es kann doch jeder DAU einfach alles abnicken ... "kann ich, kann ich auch" usw.

              Wenn du wissen willst, was ein Kandidat auf der Pfanne hat, dann teste ihn. Lass dir seine Referenzen zeigen (nicht nur nennen, sondern erklären oder schau wenn möglich in den Code), frage nach dem Arbeitsumfeld früherer Jobs (Teamarbeit, Controlling, Modularisierung, Versionierung). *ich vermeide hier bewußt die Namen bestimmter Techniken und Tools*
              Kandidaten in der engeren Wahl kann man auch mit kleinen Programmieraufgaben aussieben. Das haben die meisten zwar nicht gern, aber wenn sich der Auftrag lohnt, schlucken sie es.
              Last but not least solltest du auch den theoretischen Background prüfen. Ein Hochschulabschluß sagt dabei allerdings rein gar nichts aus. PHP wird an Hochschulen nicht gelehrt. Frage nach Konzepten wie Normalisierung, Objektorientierung, Komplexitätsberechnung etc.
              Bei dieser Gelegenheit merkst du dann auch, wer schwierige Sachverhalte verständlich erklären kann. Das ist nicht nur wichtig, wenn der Kandidat auf Kunden losgelassen werden soll sondern kommt auch der Kommunikation innerhalb des Projektteams zugute.

              Allerdings sind solche Anforderungen für die meisten 0815-Projekte schon ziemlich oversized. Also immer schön im Rahmen bleiben.

              Kommentar


              • #8
                Um mal auf die Altersfrage einzugehen: Meine Erfahrung ist es, dass "ältere" Programmierer gerne sozusagen träge werden. Sie arbeiten mit den Mitteln, die sie schon seit langem benutzen und sind nur schwer von "neuen" Techniken zu überzeugen. Ausnahmen bestätigen hier sicherlich die Regel, aber das ist meine persönliche Erfahrung.

                Das bedeutet auf der anderen Seite natürlich nicht, dass ein 16-jähriger Jungspund, der von sich behauptet schon dutzende Clanseiten auf Grundlage professionellster Techniken entwickelt zu haben die richtige Wahl ist. Aber "alles unter 30 Jahre" ausschließen halte ich für einen Schnitt ins eigene Fleisch.
                [FONT="Helvetica"]twitter.com/unset[/FONT]

                Shitstorm Podcast – Wöchentliches Auskotzen

                Kommentar


                • #9
                  Meine Erfahrung ist es, dass "ältere" Programmierer gerne sozusagen träge werden.
                  der übliche jugendwahn. imho ist das alles eine frage der einstellung. unser vater (mittlerweile im ruhestand) hat als förster noch mit weit über 50 lenzen sehr schnell gelernt, wie man mit einem mobilen datenerfassungssystem umgeht, während da deutlich jüngere kollegen schon gepaßt haben.
                  und sind nur schwer von "neuen" Techniken zu überzeugen
                  das nennt sich erfahrung. etliche "ältere" semester beobachten erst und entscheiden dann. außerdem können sie mögliche probleme deutlich besser einschätzen. wenn ich nur daran denke, wieviel zeit ich in dinge investiert habe, die sich dann als blindgänger erwiesen habe (z.b. vrml), dann wird mir schlecht.

                  gut, es gibt mit sicherheit bei vielen diese typisch altdeutsche einstellung "das haben wir immer so gemacht - das haben wir noch nie so gemacht - da kann ja jeder kommen", aber das hängt, wie gesagt, von der einstellung und nicht vom alter ab.

                  prüfe das knowhow der leute (wenn du das kannst) und entscheide von fall zu fall. lass die z.b. aufgaben unter zeitdruck lösen. eine sehr gute methode sind auch mathematik- und logikaufgaben, da kannst du deren denkvermögen testen. wer von 10 grundrechenarten nur zwei beherrscht, kann kein guter programmierer sein.

                  gruß
                  peter
                  Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
                  Meine Seite

                  Kommentar


                  • #10
                    OffTopic:
                    Original geschrieben von Kropff
                    wer von 10 grundrechenarten nur zwei beherrscht, kann kein guter programmierer sein.
                    Wer mehr als 4 kennt, ist ein Angeber.

                    Kommentar


                    • #11
                      Original geschrieben von Kropff

                      gut, es gibt mit sicherheit bei vielen diese typisch altdeutsche einstellung "das haben wir immer so gemacht - das haben wir noch nie so gemacht - da kann ja jeder kommen", aber das hängt, wie gesagt, von der einstellung und nicht vom alter ab.
                      Objektiv hab ich nichts anderes behauptet.
                      [FONT="Helvetica"]twitter.com/unset[/FONT]

                      Shitstorm Podcast – Wöchentliches Auskotzen

                      Kommentar


                      • #12
                        Original geschrieben von onemorenerd
                        Es kann doch jeder DAU einfach alles abnicken ... "kann ich, kann ich auch" usw.
                        Stimmt, und es stimmt dies auch für die DAP's, die uns seit 10-12 Monaten Probleme machen. Anfangs ist alles "kein Problem", dann gibts tolle Referenzen (oftmals gefaked, was sich bei Anrufen herausstellte) und schließlich werden angenommene Aufträge (heimlich) "weitergegeben", bis in die Ukraine, was wir nicht tolerieren.

                        Bisher haben wir mit Zend-zertifizierten gute Erfahrungen gemacht, aber die sind ziemlich selten. Daher die Einstellungen, an den eingesetzten tools die Spreu von Weizen zu trennen, wozu auch bugtracker, subversion, etc. gehören, weil es um ein komplexeres Projekt geht, wo man schon den Überblick über >100 Skripte/Dateien finden muß. Gerade Angebote, die beim Std.Aufwand um 600% auseinanderklaffen führen dazu, dass uns der Std.Satz ziemlich egal geworden ist, weil die Spannen bei den Personentagen/Manntagen (6-fache) oft nicht erklärlich sind.

                        mfg
                        p.s. DAP = dümmste anzunehmender ProgrammiererIn
                        Zuletzt geändert von silberfisch; 23.11.2007, 09:44.

                        Kommentar


                        • #13
                          Re: Re: xdebug, dbg wichtig oder Nonsens?

                          Original geschrieben von unset
                          [BUm mal einen Vergleich anzustrengen: Ich kenne Leute, die arbeiten nur auf der Kommandozeile. Obwohl es Desktop-Software gibt. Und ich wage hier teilweise sogar zu behaupten, dass diese Leute wesentlich schneller arbeiten, als der Klicki-Bunti-Pendant. Es ist eben, wie so vieles im Leben, in erster Linie Geschmacks- und Einstellungssache [/B]
                          vi bzw vim steigert (wenn man es erstmal beherrscht) die Produktivität ungemein!

                          http://en.wikipedia.org/wiki/Vi

                          Bin praktisch dazu gezwungen worden, weil wir viel bei Kunden direkt per SSH auf den Servern programmieren. (für kleinere Änderungen etc)
                          Jetzt will ich es aber nicht mehr missen

                          Kommentar


                          • #14
                            Nun kann ich sagen, dass wir Leute, die mit debuggern nicht arbeiten können / noch nicht gearbeitet haben, keine Verträge mehr abschließen, weil wir die nicht als "Programmierer" oder DB-Entwickler ansehen können.

                            Zum Alter nochmals: da ist die Grenze doch noch gekommen: > 30 J.

                            Es gibt massig Leute, die ohne I.D.E. (z.Bsp. mit html-editor und simplen Texteditoren) ihre Dienste als PHP-Programmierer anbieten - die sind nun automatisch auch out.

                            Auch die Gruppe der "Skriptinstallateure", die sich als php-Programmierer ausgeben, können inzw. ganz gut ausgegrenzt werden, was für unsere Projekte eine wahre Wohltat ist.

                            Auch: wer am Mac oder unter IIS php-Projekte entwickelt, ist ebenfalls out.

                            So ist bei uns die anfangs gestellte Frage klar beantwortet:

                            Leute ohne IDE, die einen debugger schon integriert hat oder die den integrierten debugger noch nie nutzten oder für unnötig halten oder nicht nutzen wollen, das sind für uns keine echten Programmierer und daher auch künftig keine Auftragnehmer mehr.

                            Kommentar


                            • #15
                              Also ich arbeite mit Eclipse, selbstgebautem Apache/PHP/MySQL, xdebug, FF2, FF3, Opera, IE6 und IE7. Dennoch passe ich nicht in dein Raster, denn ich arbeite an einem Mac. Findest du das richtig?
                              Immerhin habe ich so auch Safari (nativ!), Camino und sogar IE4Mac.
                              Dank VMWare sind Vista, XP und diverse Linuxe nur einen Klick entfernt.
                              Es gibt wirklich kein Argument gegen Macs.

                              Kommentar

                              Lädt...
                              X