mozilla

Version 67663 von Mozilla Entwicklundsstrategien

  • Adressname der Version: Mozilla_Entwicklundsstrategien
  • Titel der Version: Mozilla Entwicklundsstrategien
  • ID der Version: 67663
  • Erstellt:
  • Autor: ian2ian
  • Aktuelle Version? Nein
  • Kommentar 1733 words added

Inhalt der Version

Einige Strategien, mit denen Entwickler produktiv bleiben.

{{ Outdated("It has not been updated for usage of Mercurial.") }}

Bearbeiten Sie die wichtigsten Bugs erst

Jeder mag einzuchecken, aber bedenken Sie, dass es sich um mehr handelt als nur um die Geschwindigkeit Ihres Checkins. Es ist besser, erst einen Datenverlustbug, einen Crasher oder einen Performancebug oder Vorzugsbug, der wirklich eine Wirkung auf den Benutzer hat, als Grenzfallbugs, die man seltener in geringeren Bugs begegnet, zu lösen.

Nehmen Sie zusätzliche Zeit, um es zum ersten Mal richtig zu schaffen

Es ist besser, ein wirklich solides, gut getestes, gut kommentiertes, sauberes, schlichtes Stück Code zu erreichen, als eine Menge von schnellen Lösungen. Sie (oder jemand anderer) wird wieder in die Code irgendwann zurückkehren. Es ist besser, es das erste Mal richtig zu schaffen, wenn Ihr Verstand in dem Problem ist, als es einmal schnell tun und dann wiederkehren und es dann auf der richtigen Weise befertigen müssen. Das Einzige, was schlimmer als einen fremden Code nicht zu verstehen, ist sein Eigenes nicht zu verstehen.

Testen Sie Ihre Code

QA hat die Aufgabe, die Qualität zu sichern, nicht zu der Qualität hinzufügen. Das ist Ihr Job. Es ist Ihre Verantwortung die Probleme in Ihrer Code vor dem Einchecken zu finden und beheben. Wenn Sie Ihren fehlerfreien Code fertig bearbeitet haben, hat QA die Aufgabe, andere zu versichern, dass sie wirklich Bug-frei ist.


Bitte versichern Sie jene zu schätzen, die einen Bug in Ihrem Code finden. Schätzen Sie sie noch besser, wenn sie ihn finden, bevor Sie den Code veröffentlichen. Sie geben Ihnen eine zweite Chance, es richtig zu schaffen, bevor ein Bug entsteht, dass die Nutzer beeinflussen wird.

Minimieren Sie, wie Sie durch Regressionen betroffen sind

Sofern Sie nicht der Art sind tägliche Regressionen zu bekämpfen, müssen Sie einen Weg finden und nicht lassen, dass sie Sie beinflussen. Sie wollen nicht einen Tree haben, den Sie jeden Morgen, aktualisieren und dann warten müssen bis alle Blocker beseitigt sind.


Sie sollen mehrereTrees haben. Mindestens einer von ihnen sollte täglich aktualisiert werden. Sie werden diese für Regressionen brauchen, die Ihre sofortige Aufmerksamkeit (z.B. für einen neuen Crasher, einen Blocker, oder für ein Problem in Ihrer Region) benötigen. Benützen Sie diesen selben Tree für kleine, schnelle Bugs oder frisch entstandene Regressionen oder Crasher. Aktualisieren Sie nicht so häufig Ihren weiterenTree, wenn Sie wissen, dass der Tree in guter Form ist. Ihre primäre Entwicklung soll in diesemTree sein. Sie müssen aktualisieren, erneut aufbauen, erneut testen und einen Unterschied in dem gegenwärtigen Stamm/trunk des Trees zustande bringen, sobald Sie der Meinung sind, dass Ihre Arbeit da erledigt ist. Doch werden tägliche Regressionen Ihre primäre Entwicklung nicht blockieren.


Soweit es sich darum handelt, den Tree im neuesten Stand zu halten: je länger die Zeit vergeht ohne dem Sie den Tree aktualisieren, desto wahrscheinlicher werden Sie CVS Konflikte haben. Wenn Sie täglich für eine Woche aktualisieren, gibt es vielleicht keine Konflikte, aber wenn Sie nur einmal in der Woche aktualisieren und Sie eine Menge Code geändert habe, wird es höchstwahrscheinlich Konflikte für Sie geben.

Arbeiten Sie an mehreren Bugs im parallel

Sie sollten zuerst die wichtigsten Bugs bearbeiten. Aber diejenigen könnten die schwierigsten Bugs sein (Crashers die schwer zu reproduzieren sind, grosse Umschreibungen der Leistung wegen, usw.), deren Bearbeitung mehrere Tage oder sogar Wochen dauern kann. Dann soll man auch noch Zeit für Bewertungen haben. Während dieser Bearbeitung können Sie in Ihren anderenTrees kleinere, leichtere Bugs bearbeiten. Wählen Sie Bugs, die nicht zu Konflikten mit der Arbeit führen, die Sie in Ihrem primären Tree machen. Suchen Sie solche Bugs aus, die nur ein paar Stunden oder einen Tag, dauern werden um sie lösen. Theoretisch gesagt sollten diese Lösungen für diese Bugs schnell überprüft werden.


Wenn Sie Probleme haben, kleinere, leichtere Bugs zu finden die Sie bearbeiten können, dann suchen Sie doch mal Crashers. Vielleicht kann das Problem in einen Vorteil herumgedreht werden, oder sogar gelöst werden. Sie können Talkback-Abfragen oder Bugzilla-Abfragengebrauchen um Crashers zu finden.


Suchen Sie nach Problemen in der vorhandenen Code. Finden und beheben Sie Probleme die mit dem Benutz von Zeichenketten zu tun haben. Finden und beheben Sie den schlechten Benutz von dem XPCOM Makro Gebrauch. Schalten Sie einen Code an nsCOMPtrs. Suchen Sie für XXX oder TODO in dem Code, verifizieren Sie, dass der Code noch repariert werden muss, und lösen Sie es.

Kleinere Patches werden schneller überprüft

Wenn Sie der Meinung sind, dass Sie eine Menge Zeit damit verbringen, auf Bewertungen zu warten, bedenken Sie, dass Patch Größe nicht in direktem Zusammenhang mit der Dauer der Überprüfung ist. Einen zwanzig-Linien Patch zu bewerten dauert nicht doppelt so lang als einen zehn-Linien Patch zu prüfen, es dauert normalerweise sehr viel länger. Wenn Sie aufteilen können, worin Sie arbeiten, so dass Sie kleinere Stücke zum verarbeiten haben, werden Sie feststellen, dass Sie schnellere Bewertungen erhalten. Natürlich kann alles nicht aufgeteilt werden. Bedenken Sie auch, dass kürzere Lösungen nicht unbedingt besser sind als längere.


Parallele Trees sollte Ihnen ermöglichen, dass Sie auf anderen Elementen arbeiten, während Sie auf Bewertungen warten.

Lassen Sie sich vor statt nach der Arbeit an einem Patch oder Feature beraten

Wenn Sie blockiert oder ratlos sind, woran zu arbeiten, sprechen Sie eher früher als später mit einem Leiter. Höchstwahrscheinlich wird er/sie einen Bug haben, den er/sie Ihnen lassen kann, oder er/sie kann Ihnen helfen, wieder etwas haben, woran Sie arbeiten können. Da er/sie sowieso später Ihre Code überprüfen wird, lassen Sie ihr/ihn zuerst Ihren Plan wissen. Es ist besser, wenn eine Idee abgelehnt wird, als ein großer Patch.

Wenn Sie blockiert sind, aber doch etwas haben, wo es sich lohnt, es einzuchecken, verwenden Sie # ifdef, prefs oder "alternative"-um die Dateien überzuprüfen.

Manchmal bearbeiten Sie etwas, aber Sie können sie nicht beendigen, weil etwas anderes Sie blockiert. Sie können immer noch Ihre Arbeit beendigen (vorausgesetzt, Sie erhalten Bewertungen), wenn der Code nicht standardmäßig aktiviert ist. Dieses macht es auch leichter fürdas Problem Hilfe zu bekommen. Es ist einfacher jemanden zu sagen, dass er eine Pref, oder Vorzug, oder einen kleinen Patch anwenden soll, oder stellen Sie einen # define, als einen riesigen Patch anzuwenden.


Für C + +, verwenden Sie # define, # ifdef, # else und # endif


Wenn Sie an etwas grossem für XUL / JS arbeiten, fügen Sie Ihre neuen Dateien auf den Tree. Dann brauchen Sie bloss nur einen einfachen jar.mn Patch, um es zu aktivieren.


Sie können auch eine eingecheckte Code haben, die aber mit einem pref, oder Vorzug, und standardmäßig deaktiviert kontrolliert ist.

Vergewissern Sie sich, dass Sie das richtige Fix haben, wenn Sie Bewertungen haben wollen

Wenn Sie in Versuchung kommen, in einem ersten Durchlauf Bugs nicht tüchtig zu beheben und die Folgen dann nur später zu reparieren, machen Sie es das erste Mal richtig. Nehmen Sie nicht an, dass Sie später in der Lage sind, einen "Fix it" Bug zu dateien. Wahrscheinlich wird der Kritiker von Ihnen sowieso verlangen, dass Sie die ganze Arbeit fertigstellen.


Wenn es Ihnen weitere fünf Minuten dauert etwas auf der "richtigen" Weise zu lösen, anstatt 20 Minuten mit dem Kritiker zu diskutieren, haben Sie gerade für sich selbst und ihm wertvolle Zeit gespart. Natürlich, wenn es auf der "richtigen" Weise zu machen bedeutet, dass Sie eine große Menge Code wiederkonstruieren, dann ist es besser, inkrementell zu arbeiten; es ist Ihre Wahl wie Sie es tun wollen.

Verlängern Sie nicht Bewertungen durch Kämpfen mit dem Rezensenten in Bugzilla (oder über Email) während Sie sich mit ihm streiten

Wann Sie eine Überprüfung zurückbekommen, plagen Sie den Rezensenten nicht über Punkte die er/sie mit Ihnen bespricht. Wenn die Debatte kompliziert ist, lösen Sie sie in Person, im IRC oder über AIM. Eine Diskussion die 5 Minuten dauert, ist eine Stunde von E-Mails wert.

ÜberprüfenSie die Bewertung der Code gründlich

Wenn Sie die Bewertung der Code von jemand anderem überprüfen, machen Sie es gründlich. Wenn ein anderer Ingenieur in der Code überprüft und Regressionen verursacht oder Bugs hereinführt, werden Sie derjenige sein, der sie später zu beheben muss. Sparen Sie sich (und anderen) später die Zeit, indem Sie eine tüchtige Code-Review machen.

Überprüfen Sie Ihren eigenen Code, bevor Sie für Beiträge bitten

Üben Sie Ihre Fähigkeit der Überprüfung auf Ihrem eigenen Patch, bevor Sie für Beiträge und eine super Nachprüfung bitten. Es ist besser, dass Sie etwas anhalten, als ein Gutachter oder ein Super-Rezensenten es tut. Vielleicht finden Sie ein Problem, oder Sie stellen fest, dass Sie in einige dump () oder printf ()-Anweisungen drinnengelassen haben, oder dass Sie die Leerzeichen verwirrt haben.

Wenn Sie auf einem grossen Stück arbeiten, starten Sie eine Filiale

Wenn Sie an etwas Großem arbeiten, und Sie möchten in der Lage sein, es inkrementell ohne Bewertungen zu überprüfen, erstellen Sie eine Filiale. Aber mit einer Filiale können Sie auch Konflikte haben wenn Sie beendigen. Auch müssen Sie eine lange Zeit auf Bewertungen warten.

 

Quelltext der Version

<p>Einige Strategien, mit denen Entwickler produktiv bleiben.</p>
<p>{{ Outdated("It has not been updated for usage of <a class="external" href="/en/Mercurial" title="https://developer.mozilla.org/editor/fckeditor/core/editor/en/Mercurial">Mercurial</a>.") }}</p>
<h3>Bearbeiten Sie die wichtigsten Bugs erst</h3>
<p>Jeder mag einzuchecken, aber bedenken Sie, dass es sich um mehr handelt als nur um die Geschwindigkeit Ihres Checkins. Es ist besser, erst einen Datenverlustbug, einen Crasher oder einen Performancebug oder Vorzugsbug, der wirklich eine Wirkung auf den Benutzer hat, als Grenzfallbugs, die man seltener in geringeren Bugs begegnet, zu lösen.</p>
<h3>Nehmen Sie zusätzliche Zeit, um es zum ersten Mal richtig zu schaffen</h3>
<p>Es ist besser, ein wirklich solides, gut getestes, gut kommentiertes, sauberes, schlichtes Stück Code zu erreichen, als eine Menge von schnellen Lösungen. Sie (oder jemand anderer) wird wieder in die Code irgendwann zurückkehren. Es ist besser, es das erste Mal richtig zu schaffen, wenn Ihr Verstand in dem Problem ist, als es einmal schnell tun und dann wiederkehren und es dann auf der richtigen Weise befertigen müssen. Das Einzige, was schlimmer als einen fremden Code nicht zu verstehen, ist sein Eigenes nicht zu verstehen.</p>
<h3>Testen Sie Ihre Code</h3>
<p>QA hat die Aufgabe, die Qualität zu sichern, nicht zu der Qualität hinzufügen. Das ist Ihr Job. Es ist Ihre Verantwortung die Probleme in Ihrer Code vor dem Einchecken zu finden und beheben. Wenn Sie Ihren fehlerfreien Code fertig bearbeitet haben, hat QA die Aufgabe, andere zu versichern, dass sie wirklich Bug-frei ist.</p>
<p><br> Bitte versichern Sie jene zu schätzen, die einen Bug in Ihrem Code finden. Schätzen Sie sie noch besser, wenn sie ihn finden, bevor Sie den Code veröffentlichen. Sie geben Ihnen eine zweite Chance, es richtig zu schaffen, bevor ein Bug entsteht, dass die Nutzer beeinflussen wird.</p>
<h3>Minimieren Sie, wie Sie durch Regressionen betroffen sind</h3>
<p>Sofern Sie nicht der Art sind tägliche Regressionen zu bekämpfen, müssen Sie einen Weg finden und nicht lassen, dass sie Sie beinflussen. Sie wollen nicht einen Tree haben, den Sie jeden Morgen, aktualisieren und dann warten müssen bis alle Blocker beseitigt sind.</p>
<p><br> Sie sollen mehrereTrees haben. Mindestens einer von ihnen sollte täglich aktualisiert werden. Sie werden diese für Regressionen brauchen, die Ihre sofortige Aufmerksamkeit (z.B. für einen neuen Crasher, einen Blocker, oder für ein Problem in Ihrer Region) benötigen. Benützen Sie diesen selben Tree für kleine, schnelle Bugs oder frisch entstandene Regressionen oder Crasher. Aktualisieren Sie nicht so häufig Ihren weiterenTree, wenn Sie wissen, dass der Tree in guter Form ist. Ihre primäre Entwicklung soll in diesemTree sein. Sie müssen aktualisieren, erneut aufbauen, erneut testen und einen Unterschied in dem gegenwärtigen Stamm/trunk des Trees zustande bringen, sobald Sie der Meinung sind, dass Ihre Arbeit da erledigt ist. Doch werden tägliche Regressionen Ihre primäre Entwicklung nicht blockieren.</p>
<p><br> Soweit es sich darum handelt, den Tree im neuesten Stand zu halten: je länger die Zeit vergeht ohne dem Sie den Tree aktualisieren, desto wahrscheinlicher werden Sie CVS Konflikte haben. Wenn Sie täglich für eine Woche aktualisieren, gibt es vielleicht keine Konflikte, aber wenn Sie nur einmal in der Woche aktualisieren und Sie eine Menge Code geändert habe, wird es höchstwahrscheinlich Konflikte für Sie geben.</p>
<h3>Arbeiten Sie an mehreren Bugs im parallel</h3>
<p>Sie sollten zuerst die wichtigsten Bugs bearbeiten. Aber diejenigen könnten die schwierigsten Bugs sein (Crashers die schwer zu reproduzieren sind, grosse Umschreibungen der Leistung wegen, usw.), deren Bearbeitung mehrere Tage oder sogar Wochen dauern kann. Dann soll man auch noch Zeit für Bewertungen haben. Während dieser Bearbeitung können Sie in Ihren anderenTrees kleinere, leichtere Bugs bearbeiten. Wählen Sie Bugs, die nicht zu Konflikten mit der Arbeit führen, die Sie in Ihrem primären Tree machen. Suchen Sie solche Bugs aus, die nur ein paar Stunden oder einen Tag, dauern werden um sie lösen. Theoretisch gesagt sollten diese Lösungen für diese Bugs schnell überprüft werden.</p>
<p><br> Wenn Sie Probleme haben, kleinere, leichtere Bugs zu finden die Sie bearbeiten können, dann suchen Sie doch mal Crashers. Vielleicht kann das Problem in einen Vorteil herumgedreht werden, oder sogar gelöst werden. Sie können Talkback-Abfragen oder <a class=" link-https" href="https://bugzilla.mozilla.org/">Bugzilla-Abfragen</a>gebrauchen um Crashers zu finden.</p>
<p><br> Suchen Sie nach Problemen in der vorhandenen Code. Finden und beheben Sie Probleme die mit dem Benutz von Zeichenketten zu tun haben. Finden und beheben Sie den schlechten Benutz von dem XPCOM Makro Gebrauch. Schalten Sie einen Code an nsCOMPtrs. Suchen Sie für XXX oder TODO in dem Code, verifizieren Sie, dass der Code noch repariert werden muss, und lösen Sie es.</p>
<h3>Kleinere Patches werden schneller überprüft</h3>
<p>Wenn Sie der Meinung sind, dass Sie eine Menge Zeit damit verbringen, auf Bewertungen zu warten, bedenken Sie, dass Patch Größe nicht in direktem Zusammenhang mit der Dauer der Überprüfung ist. Einen zwanzig-Linien Patch zu bewerten dauert nicht doppelt so lang als einen zehn-Linien Patch zu prüfen, es dauert normalerweise sehr viel länger. Wenn Sie aufteilen können, worin Sie arbeiten, so dass Sie kleinere Stücke zum verarbeiten haben, werden Sie feststellen, dass Sie schnellere Bewertungen erhalten. Natürlich kann alles nicht aufgeteilt werden. Bedenken Sie auch, dass kürzere Lösungen nicht unbedingt besser sind als längere.</p>
<p><br> Parallele Trees sollte Ihnen ermöglichen, dass Sie auf anderen Elementen arbeiten, während Sie auf Bewertungen warten.</p>
<h3>Lassen Sie sich vor statt nach der Arbeit an einem Patch oder Feature beraten</h3>
<p>Wenn Sie blockiert oder ratlos sind, woran zu arbeiten, sprechen Sie eher früher als später mit einem Leiter. Höchstwahrscheinlich wird er/sie einen Bug haben, den er/sie Ihnen lassen kann, oder er/sie kann Ihnen helfen, wieder etwas haben, woran Sie arbeiten können. Da er/sie sowieso später Ihre Code überprüfen wird, lassen Sie ihr/ihn zuerst Ihren Plan wissen. Es ist besser, wenn eine Idee abgelehnt wird, als ein großer Patch.</p>
<h3>Wenn Sie blockiert sind, aber doch etwas haben, wo es sich lohnt, es einzuchecken, verwenden Sie # ifdef, prefs oder "alternative"-um die Dateien überzuprüfen.</h3>
<p>Manchmal bearbeiten Sie etwas, aber Sie können sie nicht beendigen, weil etwas anderes Sie blockiert. Sie können immer noch Ihre Arbeit beendigen (vorausgesetzt, Sie erhalten Bewertungen), wenn der Code nicht standardmäßig aktiviert ist. Dieses macht es auch leichter fürdas Problem Hilfe zu bekommen. Es ist einfacher jemanden zu sagen, dass er eine Pref, oder Vorzug, oder einen kleinen Patch anwenden soll, oder stellen Sie einen # define, als einen riesigen Patch anzuwenden.</p>
<p><br> Für C + +, verwenden Sie # define, # ifdef, # else und # endif</p>
<p><br> Wenn Sie an etwas grossem für XUL / JS arbeiten, fügen Sie Ihre neuen Dateien auf den Tree. Dann brauchen Sie bloss nur einen einfachen jar.mn Patch, um es zu aktivieren.</p>
<p><br> Sie können auch eine eingecheckte Code haben, die aber mit einem pref, oder Vorzug, und standardmäßig deaktiviert kontrolliert ist.</p>
<h3>Vergewissern Sie sich, dass Sie das richtige Fix haben, wenn Sie Bewertungen haben wollen</h3>
<p>Wenn Sie in Versuchung kommen, in einem ersten Durchlauf Bugs nicht tüchtig zu beheben und die Folgen dann nur später zu reparieren, machen Sie es das erste Mal richtig. Nehmen Sie nicht an, dass Sie später in der Lage sind, einen "Fix it" Bug zu dateien. Wahrscheinlich wird der Kritiker von Ihnen sowieso verlangen, dass Sie die ganze Arbeit fertigstellen.</p>
<p><br> Wenn es Ihnen weitere fünf Minuten dauert etwas auf der "richtigen" Weise zu lösen, anstatt 20 Minuten mit dem Kritiker zu diskutieren, haben Sie gerade für sich selbst und ihm wertvolle Zeit gespart. Natürlich, wenn es auf der "richtigen" Weise zu machen bedeutet, dass Sie eine große Menge Code wiederkonstruieren, dann ist es besser, inkrementell zu arbeiten; es ist Ihre Wahl wie Sie es tun wollen.</p>
<h3>Verlängern Sie nicht Bewertungen durch Kämpfen mit dem Rezensenten in Bugzilla (oder über Email) während Sie sich mit ihm streiten</h3>
<p>Wann Sie eine Überprüfung zurückbekommen, plagen Sie den Rezensenten nicht über Punkte die er/sie mit Ihnen bespricht. Wenn die Debatte kompliziert ist, lösen Sie sie in Person, im IRC oder über AIM. Eine Diskussion die 5 Minuten dauert, ist eine Stunde von E-Mails wert.</p>
<h3>ÜberprüfenSie die Bewertung der Code gründlich</h3>
<p>Wenn Sie die Bewertung der Code von jemand anderem überprüfen, machen Sie es gründlich. Wenn ein anderer Ingenieur in der Code überprüft und Regressionen verursacht oder Bugs hereinführt, werden Sie derjenige sein, der sie später zu beheben muss. Sparen Sie sich (und anderen) später die Zeit, indem Sie eine tüchtige Code-Review machen.</p>
<h3>Überprüfen Sie Ihren eigenen Code, bevor Sie für Beiträge bitten</h3>
<p>Üben Sie Ihre Fähigkeit der Überprüfung auf Ihrem eigenen Patch, bevor Sie für Beiträge und eine super Nachprüfung bitten. Es ist besser, dass Sie etwas anhalten, als ein Gutachter oder ein Super-Rezensenten es tut. Vielleicht finden Sie ein Problem, oder Sie stellen fest, dass Sie in einige dump () oder printf ()-Anweisungen drinnengelassen haben, oder dass Sie die Leerzeichen verwirrt haben.</p>
<h3>Wenn Sie auf einem grossen Stück arbeiten, starten Sie eine Filiale</h3>
<p>Wenn Sie an etwas Großem arbeiten, und Sie möchten in der Lage sein, es inkrementell ohne Bewertungen zu überprüfen, erstellen Sie eine Filiale. Aber mit einer Filiale können Sie auch Konflikte haben wenn Sie beendigen. Auch müssen Sie eine lange Zeit auf Bewertungen warten.</p>
<p> </p>
Zu dieser Version zurücksetzen