Wenn Entwickler Komponententests in ihrer Entwicklungsumgebung durchführen, bevor sie in die Quellcodeverwaltung einchecken, sollte diese Umgebung (einschließlich Testfehlern) gemeinsam genutzt werden?Sollten Entwickler in Sandboxes arbeiten?
Sollen alle Builds öffentlich sein?
Ich denke, in einer Sandbox arbeiten ist eine gute Idee. Es hat mich ein paar Mal gerettet. Normalerweise habe ich ein paar verschiedene virtuelle Maschinen im Umlauf, die ich für die Entwicklung nutze, und wenn ich es wirklich kaputt mache, muss ich nicht darauf warten, dass meine Maschine neu aufgebaut wird.
Ich glaube nicht, dass alle Testergebnisse von einfachen Entwickler-Builds veröffentlicht werden sollten. Ich mache mir nicht wirklich Sorgen darum, jemandes Gefühle zu verletzen, indem ich all seine Misserfolge öffentlich mache, aber ich mache mir Sorgen, dass die Informationen, die sie liefern, nicht nützlich sind.
Es wäre interessant, eine Art von System zu untersuchen, bei dem der Entwickler die Testergebnisse beim Einchecken einreichen muss, aber ich denke, selbst das würde die Dinge vorantreiben. Dies kann sich nachteilig auf die Produktivität auswirken. Entwickler haben bereits genug nicht-kodierende Sachen zu tun.
Ich denke, es ist unpraktisch, Entwickler Builds öffentlich zu machen. Sie möchten Ihre Teammitglieder nicht bei jedem Buildfehler (Komponententestfehler) belästigen, dem Sie begegnen.
Sie sind immer dabei, eine Lösung für ein Problem zu erstellen, und die Chancen stehen gut, dass Sie es beim ersten Mal nicht richtig machen, so dass Fehlertests häufig auftreten. Vor allem, wenn Sie einen testgetriebenen Ansatz zur Entwicklung Ihres Codes verfolgen: Schreiben Sie zuerst Ihren Komponententest und implementieren Sie die Funktionalität, damit sie nicht mehr fehlschlägt.
Ja, Entwickler sollten möglichst in Sandboxes arbeiten. Keine Builds sollten nicht standardmäßig alle öffentlich sein. TDD wird zu mehreren Fehlern und Verfeinerungen sowohl bei Tests als auch bei Code führen. Das öffentliche Teilen von Builds mag zwar lästig sein, aber sicherlich sollten andere Entwickler sehen können, was jemand macht, wenn sie sich genug kümmern, um nachzusehen. Sie sollten veröffentlicht werden, wenn sie dazu aufgefordert werden. Wenn Sie nach dem Beweis fragen, dass sie etwas getestet haben, sollte die Ausführung der Tests nach der Überprüfung des Codes ausreichend sein.
Entwicklern die Umgebung, Werkzeuge und Freiheit zum Testen von Änderungen geben liberaly verbessert die Stabilität und Qualität Ihrer Software. Das Testen von Theorien und die Fehlersuche erfordern oft kleine inkrementelle Builds. Wenn die Sandbox teuer ist, sollte sie Zeit für die Nutzung der Sandbox reservieren. Wenn Sie jedem Entwickler eine private Sandbox geben, kann dies dazu führen, dass sich der Code für längere Zeit verzweigt. Was ist deine Motivation dies zu fragen? Wenn der Entwickler versucht, etwas zu verbergen, dann gehe zur Ursache des Problems. Wenn Sie versuchen, Kosten zu kontrollieren, dann berücksichtigen Sie das Reservierungsmodell.
Welchen Vorteil sehen Sie darin? Insbesondere bedeutet dies, dass jeder über jeden Picayune-Testfehler von jedem Entwickler informiert wird.
Dies dient lediglich dazu, alle abzulenken.
Vermeiden Sie die Versuchung, etwas zu tun, nur weil es möglich ist; Lassen Sie Ihre Anforderungen Ihren Prozess vorantreiben. Erstellen Sie keinen neuen Prozess, nur weil Sie es können.
Kinder sollten in Sandboxes spielen;), Softwareentwickler sollten auf ihrem eigenen PC spielen und ihren Code committen, wann immer sie das Gefühl haben, dass sie ein bestimmtes Qualitätsniveau erreichen. Wenn jeder regelmäßig kleine und getestete Codeabschnitte festlegt und aktualisiert, dann ist meine Erfahrung, dass keine ernsthaften Probleme auftreten, nur konstruktive Rückmeldungen und manchmal jemand etwas schreit. Die Veröffentlichung der Software für die Öffentlichkeit/Kunden ist eine andere Geschichte.Das erfordert umfangreiche Tests, Schreiben von Release-Notes, Aktualisierung von Handbüchern, Marketing usw.