In den verbleibenden 10% machen wir Änderungen. Eine grosse Änderung besteht aus vielen kleinen und kleinsten Änderungen. Die kleinen Änderungen können danebengehen. Je früher wir das merken und korrigieren, desto schneller sind wir mit der grossen Änderung. Tippfehler, Klammerungsfehler, etc. können bereits statisch durch Compilieren oder Prüfen des gerade editierten Files bemerkt werden. Es ist nützlich und praktisch, wenn beim Arbeiten bereits nach einem oder mehreren Tastendrücken eine spezielle Regel make check ausgeführt wird, die schnell und unaufdringlich die Ergebnisse eines Prüfschritts in einer Log-Liste des Editors anzeigt. Wenn Unit Tests vorhanden sind, sollen diese durch make check bei erfolgreicher Compilierung ebenfalls unaufgefordert ausgeführt werden.
Wenn eine Reihe von Micro-Änderungen erfolgreich durchgeführt wurde, will ich als Benutzer einen Build anstossen. Wann genau die Zeit für einen make clean all gekommen ist, kann ich nur selbst bestimmen, das kann mir kein Automat abnehmen: Ich habe selbst den aktuellen Stand der Software während der Arbeit im Bewusstsein und weiss, wann ich meine geplanten Arbeitsschritte alle ausgeführt habe. Allenfalls wäre es bei der Arbeit im Team gut, wenn vor Beendigung der Sitzung automatisch ein make clean all ausgeführt wird, damit die Kollegen auf meinem Stand weiterarbeiten können. Und natürlich sollte der Build die Voraussetzung für das Erzeugen einer neuen Version im Repository sein. Es ist eine sinnvolle Regel, der Versionsverwaltung nur lauffähige Stände zu übergeben. Allerdings sollte ein Build nicht automatisch zu einem Einchecken in die Versionsverwaltung führen.
Zum Build gehören Integrationstest mit einer guten Abdeckung der ganzen Softwarekomponente. Diese können dann ruhig etwas länger dauern (es darf mal eine Laufzeit im zweistelligen Sekundenbereich sein).
Es gibt also auf dem Zeitstrahl zwei Arten von Änderungen: Die ganz kurzlebigen Micro-Änderungen, und dazwischen gelegentlich die Build-Schritte. Schick wäre ein Editor, der diesen Zeitstrahl graphisch darstellt. Man könnte beim Überfahren der Änderungszeitpunkte mit der Maus in einem Kontextfenster die pro Änderung durchgeführten Diffs angezeigt bekommen. Ausserdem sollte es bequem möglich sein, ähnlich dem "Undo", das es in den meisten Editoren mittlerweile gibt (und das auch in die vor dem letzte Sichern zurückliegende Zeit möglich sein sollte), ohne viel Tamtam zu einem beliebigen Zeitpunkt zurückzugehen. Solange die Builds noch nicht in die Versionsverwaltung eingecheckt sind, sollte man auch automatisch zu Zeitpunkten vor einem Build zurückgehen können.
Syntax-Highlighting, Verbergen grosser Kommentarblöcke (etwa der ekligen Copyright-Blöcke am Beginn vieler Sourcefiles), Funktionslisten ergänzen das Programm. Code Completion halte ich persönlich für ein nettes, aber verzichtbares Feature.
Habe ich noch etwas vergessen?