| Lautsprecher |
Transkript |
| Aurora Tiffany-Davis |
Hallo, ich bin Aurora Tiffany-Davis. Ich bin Softwareentwicklerin im JMP Live-Team. Heute möchte ich Ihnen erzählen, wie wir im JMP Live-Team Software entwickeln. |
| |
Stellen Sie sich zunächst vor, wie das Erstellen von Software aussieht. Wenn Sie selbst kein Entwickler sind, ist Ihr Bild wahrscheinlich von Fernsehsendungen und Filmen geprägt, die Sie gesehen haben. |
| |
Sie stellen sich vielleicht jemanden vor, der allein arbeitet, jemanden, der wirklich schlau ist, vielleicht sogar ein Genie, und dessen Vorgehensweise ganz einfach ist. |
| |
Sie denken über ein Problem nach, schreiben Code und stellen dann sicher, dass er funktioniert. Und das tut er wahrscheinlich auch, denn schließlich sind sie Genies. |
| |
Wären wir alle JMP Live-Experten, würde dieser einfache Prozess funktionieren. Aber das sind wir nicht, und wir leben in der realen Welt. Deshalb brauchen wir etwas mehr. |
| |
Erstens arbeiten wir nicht allein, sondern in enger Zusammenarbeit. Unser Prozess umfasst mehrere Schritte, die sicherstellen sollen, dass wir nicht nur irgendeine Software, sondern qualitativ hochwertige Software produzieren. |
| |
Ich möchte darauf hinweisen, dass es keinen einheitlichen Weg zur Softwareentwicklung gibt. Er kann von Unternehmen zu Unternehmen oder sogar innerhalb von Unternehmen unterschiedlich sein, aber ich werde Sie durch unseren Prozess führen. |
| |
indem ich Ihnen erzähle, was ich tun würde, wenn ich eine neue Funktion in JMP Live entwickeln würde. |
| |
Bevor ich mich hinsetze und Code schreibe, muss ich zunächst einmal ein gewisses Bedürfnis dazu verspüren. |
| |
Es muss da draußen einen echten Benutzer mit einem echten Problem geben, etwas, das er in JMP Lives identifiziert hat, das nicht funktioniert ... das nicht so funktioniert, wie er denkt, dass es funktionieren sollte, |
| |
Das ist eine nette Art zu sagen, dass sie einen Fehler oder eine von ihnen angeforderte Funktion gefunden haben. |
| |
Wir erfassen diese Anfragen intern in einem System. Als Erstes suche ich mir dort ein Problem mit hoher Priorität, das zu meinen Fähigkeiten passt, und beginne mit der Bearbeitung. |
| |
Als Nächstes muss ich den Bedarf besser verstehen. Ich werde mit Leuten sprechen und versuchen herauszufinden, welche Art von Nutzern diese Funktion benötigt. Wie werden sie sie nutzen? |
| |
Und dann werde ich JMP Live auf meinem Rechner ausführen und mir ansehen, wie diese Funktion in das heutige JMP Live passen könnte. |
| |
Oder ich öffne den Code und schaue, wo der neue Code in unsere vorhandene Codebasis passen könnte. |
| |
Sobald ich die Anforderungen einigermaßen verstanden habe, beginne ich mit der Designarbeit. Auch hier spreche ich mit den Leuten im Team und frage: „Haben Sie schon einmal an einer ähnlichen Funktion gearbeitet? Haben Sie schon einmal an diesem Teil des Codes gearbeitet?“ |
| |
Und ich werde mit den User-Experience-Experten sprechen, die wir bei JMP haben. |
| |
Ich werde versuchen, das Rad nicht neu zu erfinden. Es gibt also einen Aspekt der Funktion, der sehr häufig vorkommt und nicht spezifisch für JMP Live ist, beispielsweise das Protokollieren von Informationen in einer Datei. |
| |
Das Problem ist gelöst, Tausende von Menschen hatten es bereits. Möglicherweise gibt es eine gute Open-Source-Lösung dafür. |
| |
Und wenn ja, würde ich es möglicherweise verwenden, nachdem ich es sorgfältig geprüft habe, um sicherzustellen, dass es sicher in der Anwendung ist. |
| |
Es bleibt noch viel zu tun, viel JMP Live-spezifischer Code muss geschrieben werden. Deshalb werde ich Artikel und Diagramme schreiben und |
| |
Ich beschreibe meinen Vorschlag und stelle sicher, dass alle im Team mit der Richtung, die ich mit dem Design einschlage, einverstanden sind. Dann setze ich mich hin und schreibe den Code. |
| |
Dazu verwende ich eine integrierte Entwicklungsumgebung, ein Tool zum Schreiben von Code mit vielen Extras, die Ihnen dabei helfen, Ihre Arbeit effizienter zu erledigen. |
| |
Ich habe Code geschrieben. Bevor ich ihn einchecke, möchte ich die darin enthaltenen Probleme finden. Ich bin auch nur ein Mensch, daher ist die Wahrscheinlichkeit, dass ich beim ersten Versuch 100 % fehlerfreien Code geschrieben habe, ziemlich gering. |
| |
Ich werde zunächst nach sehr offensichtlichen Problemen suchen und dafür eine statische Analyse verwenden. |
| |
Die statische Analyse betrachtet meinen Code nicht während der Ausführung, sondern so, als wäre er gerade auf einer Seite niedergeschrieben. Eine Analogie wäre die Rechtschreibprüfung in Microsoft Word. |
| |
Die Rechtschreibprüfung kann Ihnen zwar nicht sagen, ob Sie einen fesselnden Roman geschrieben haben, aber sie kann Ihnen sagen, ob Sie irgendwo ein Komma vergessen haben. Die statische Analyse erledigt das für Code. |
| |
Sobald ich solche offensichtlichen Probleme gefunden und behoben habe, konzentriere ich mich auf die Suche nach weniger offensichtlichen Problemen. Dafür verwenden wir eine automatisierte Testsuite. |
| |
Dies unterscheidet sich von der statischen Analyse, da der Code tatsächlich ausgeführt wird. Es führt einen Teil des Codes mit einer bestimmten Eingabe aus und erwartet eine bestimmte Ausgabe. Wir haben eine breite Palette von Tests für unseren Code geschrieben. |
| |
Und ich werde mich hinsetzen und Tests für die Funktion schreiben, an der ich arbeite. |
| |
Das ist wirklich nützlich, denn wenn ich mich hinsetze und die Tests schreibe, muss ich mir klarmachen, wie der Code genau funktionieren soll. Außerdem schützt es davor, dass jemand anderes die Funktion in Zukunft versehentlich beschädigt. So lassen sich Probleme frühzeitig erkennen. |
| |
Fahren wir nun mit den manuellen Tests fort. Ich werde JMP Live auf meinem Rechner ausführen, die neue Funktion testen und sicherstellen, dass sie wie gewünscht funktioniert. |
| |
Ich könnte sogar in der Datenbank herumstöbern, die hinter JMP Live liegt und die Datensätze, Beiträge, Gruppen, Benutzer und Kommentare verfolgt, um sicherzustellen, dass alle diese Datensätze so geschrieben werden, wie ich es für richtig halte. |
| |
Jetzt bin ich vorsichtig optimistisch, guten Code geschrieben zu haben, und der nächste Schritt ist die Peer-Review. Ich möchte, dass meine Kollegen mir helfen, den Code zu überprüfen und alles zu finden, was ich möglicherweise übersehen habe. |
| |
Vielleicht habe ich etwas übersehen, weil ich einfach nur Scheuklappen habe oder weil jemand in meinem Team einfach über Kenntnisse verfügt, die mir fehlen. Dieser Schritt ist oft auch für den Prüfer sehr hilfreich, da er dadurch neue Techniken kennenlernen kann. |
| |
Nachdem der Code das Peer-Review durchlaufen hat, sind wir bereit, ihn tatsächlich festzuschreiben oder in ein Quellcode-Repository einzuchecken. |
| |
Wir haben auf unseren Servern ein kontinuierliches Build-System, das darauf achtet, dass wir Code einchecken. Und wenn wir das tun, macht es eine Menge Sachen mit diesem Code. |
| |
Stellen Sie beispielsweise sicher, dass die richtigen Dateien am richtigen Ort vorhanden sind, die richtigen Namen haben usw. Außerdem werden unsere Stapelanalyse und unsere gesamte automatisierte Testsuite erneut ausgeführt. |
| |
Das ist nützlich, denn wir sind schließlich nur Menschen. Jemand könnte vergessen haben, diese Dinge früher im Prozess zu tun, oder es könnte sich etwas geändert haben, seit er es das letzte Mal getan hat. |
| |
Sobald der Code den Continuous Build durchlaufen hat, steht er auch Personen außerhalb der Entwicklungsgruppe zur Verfügung. Die ersten, die dies bemerken, sind unsere Testexperten bei JMP. |
| |
Sie werden alles durchgehen und möglicherweise unsere automatisierte Testsuite ergänzen. Möglicherweise führen sie auch einige manuelle Tests durch. |
| |
Sie schauen sich beispielsweise an, wie die Software auf verschiedenen Betriebssystemen, in verschiedenen Browsern usw. funktioniert. Sie denken sich verrückte Dinge aus, die der Benutzer tun könnte, und schauen, was passiert und wie die Software reagiert. |
| |
Sie sind ein wirklich entscheidender Teil unseres Prozesses. Sie denken wirklich kreativ, wenn es darum geht, Probleme in unserem Produkt zu finden. |
| |
Sobald die Freigabe erfolgt ist, steht die Software für die nächste Version bereit. Ich zeige Ihnen nun das Produkt und den gesamten Prozess. |
| |
Und es sind viele Schritte. Das ist eine Menge Zeug. Machen wir das wirklich für unseren gesamten Code? |
| |
Ob Sie es glauben oder nicht, dieser Prozess ist enorm skalierbar. Für einen wirklich einfachen, offensichtlichen Fehler werden wir diesen Prozess daher ziemlich schnell durchgehen. |
| |
Aber für eine sehr komplexe neue Funktion werden wir bei jedem Schritt dieses Prozesses langsamer vorgehen, uns Zeit lassen und sehr sorgfältig vorgehen, um sicherzustellen, dass wir es wirklich richtig machen. |
| |
Alles, was Zeit kostet, kostet ein Unternehmen Geld. Warum ist JMP also bereit, dieses Geld in Softwarequalität zu investieren? |
| |
Ein Grund ist ganz einfach: Wir sind stolz auf unsere Arbeit und möchten ein gutes Produkt herstellen. |
| |
Der zweite Grund ist etwas weniger idealistisch. Wir wissen: Wenn unser Produkt Probleme hat und wir diese nicht finden, werden es unsere Kunden tun. Das ist nicht gut fürs Geschäft. Deshalb möchten wir diese Probleme minimieren. |
| |
Ich möchte darauf hinweisen, dass JMP zwar Zeit und Geld in die Softwarequalität investiert, |
| |
Wir investieren nicht so viel Geld wie beispielsweise eine Organisation wie die NASA, daher können wir keine Perfektion versprechen. Wie bei jeder Software auf dem Markt, |
| |
Möglicherweise finden Sie in JMP Live etwas, das nicht so funktioniert, wie Sie es sich vorstellen. Wenn Sie einen Vorschlag finden, |
| |
Wir möchten Sie einladen, www.jmp.com/support zu besuchen und uns mitzuteilen, ob es etwas gibt, das Ihrer Meinung nach anders funktionieren sollte, oder ob Sie sich Funktionen für die Zukunft wünschen. |
| |
Dieses Feedback von echten Nutzern ist für uns unglaublich wertvoll und wir freuen uns sehr darüber. Das ist alles, was ich heute für Sie habe. Ich hoffe, Sie genießen den Rest von Discovery. Vielen Dank. |
