Menü
Avatar von cdonat
  • cdonat

mehr als 1000 Beiträge seit 21.10.2002

Re: Nobody ever got fired for using Jira.

Bitschnipser schrieb am 18.02.2019 19:18:

cdonat schrieb am 18.02.2019 10:49:

Das fängt ja schon bei so elementaren Dingen an, wie ein Single Sign on in der Standard Installation. Bei Attalassian Tools muss ich mich immer in jedem Tool noch mal neu einloggen.

Hm. Ich hab das Login im Browser, da merk ich das nicht so :-)
Bzw. SSO soll ja auch mit den ganzen Intranet-Websites funktionieren, da ist es relativ egal, ob die Atlassian-Tools einzelne Logins brauchen - die müssen sowieso alle ans gemeinsame SSO angebunden werden.

Bei uns besteht das Intranet in erster Linie aus Atlassian-Tools. Da wäre es doch angenehm, wenn diese gleich mit einer Art SSO kommen, oder gar einfach so weit integriert sind, dass es aus Sicht der User gar keine drei getrennten Tools sein müssen.

Genau das ist auch das Schlimme an den GUI-Inkonsistenzen der Atlassian-Tools.
Andererseits: Wenn ich einen PR absetze, brauche ich sowieso einen diff.

Wenn ich den PR absetze brauche ich keinen diff. Auch nicht in Bitbucket. Was soll ich auch damit? Wenn ich einen PR reviewe, dann brauch ich diff, ja.

Ich mach den Review selbstverständlich als Teil meines PR-Ablaufs.

Also ich reviewe nur den Code meiner Kollegen, nicht meinen eigenen. Meinen Code reviewen die Kollegen. Sonst wäre ja auch der Nutzen eines Code-Reviews dahin.

Ich will meine Änderungen schließlich so zu Commits zusammenfassen, dass sie für Dritte nachvollziehbar sind.

Das ist kein Code Review. Bei einem Code-Review schauen andere Leute als der Autor sich den Code an, weisen auf Fehler, mögliche Schwachstellen, schlecht lesbaren Code, etc. hin. Wenn du selber deinen eigenen Code anschaust, dann schaust du dir deinen Code an, aber das ist dann kein Code-Review.

Wie dem auch sei, wir beide haben wirklich sehr verschiedene Arbeitsweisen.

Bei uns läuft das so: Ich mach den Commit auf dem Feature Branch dann, wenn ich einen Schritt abgeschlossen habe. Erst dann gehe ich an den nächsten Schritt. So sind meine Commits automatisch immer passend zusammengefasst. Wenn der letzte Schritt für ein Feature fertig ist, wird auch der auf den Feature Branch commitet und dann für den Feature Branch der PR erstellt. Den Reviewen dann meine Kollegen. Ich arbeite ihr Feedback in den Code ein und wenn alle damit zufrieden sind, wir der Feature Branch in den Develop-Branch gemerget.

Auf die Idee, mehrere Schritt zu machen und dann daraus einzelne Commits nachträglich zu extrahieren, bin ich ehrlich noch nie gekommen. Was ist denn der Vorteil von deiner Herangehensweise? Der Nachteil liegt meiner Meinung nach auf der Hand: man muss nachträglich die verschiedenen Änderungen auseinanderzuppeln, um sinnvolle Commits machen zu können.

Ich verwende dafür spezielle Diff-Tools, wie z.B. meld, oder kompare, die ich natürlich von der CLI aus starte. Die können das eine, was sie können im Zweifel meistens besser als ein Eierlegendewollmichsautool, wie eine IDE.

Kann ich nicht bestätigen. meld ist nicht halb so gut wie das diff in, sagen wir, IntelliJ.

Was konkret macht denn IntelliJ besser? Ich hab hier als IDE CLion aufgedrängt bekommen, aber bisher steht mir das Ding in jeder Hinsicht mehr im Weg, als dass es nützlich wäre. Meistens wechsle ich dann doch lieber in die Konsole, wo ich mich nicht erst durch hunderte von Einstellungsdialogen wühlen muss, um z.B. in einem anderen Verzeichnis als sonst mit anderen cmake-Parametern einen Build anzustossen.

Ansonsten, so schreckliches Gebastel ist ein "vim -d" als reine CLI-Lösung jetzt auch wieder nicht. Ich bin mir sicher, dass es für emacs was ähnliches gibt.

Sorry, sowohl vi als auch emacs sind schreckliches Gebastel :-)

Seit ich mir mal das Gebastel mit dem Namen "Eclipse* auch von innen angeschaut habe, würde ich einen an einem Tag zusammengehackten Minimaleditor aus eigener Feder, der in Malbolge geschrieben ist und mit INTERCAL konfiguriert werden kann vorziehen. :-)

Bisher habe ich mit Jira nur begrenzte Erfahrungen gesammelt, aber das hat mich jetzt nicht so vom Hocker gehauen, dass ich es unbedingt jedem als das beste Tool aller Zeiten empfehlen würde, wie es der eine, oder andere hier manchmal tut. Da hätte bei mir bisher Phabricator schon bessere Chancen. Das hat mir wirklich sehr gut gefallen.

Aber natürlich kenne ich nicht alles und hab auch nicht die Weisheit mit Löffeln gefressen. Wenn du mir erläutern kannst, was es den ist, was Jira so gut macht, dann erkenne ich vielleicht endlich den Vorteil und kann es auch bei meiner Arbeit besser einsetzen.

Plus: Es erkennt Issue-IDs und setzt sie automatisch in Links um.

Meinst du so, wie das selbst Trac schon seit Ewigkeiten macht?

Eh. Ich wollte hier keinen Schwanzvergleich starten.

Naja, ich habe nach Vorteilen von Jira gefragt und als Antwort kam von dir eine Liste von Sachen, die so ziemlich alle Konkurrenzprodukte genau so gut können. Dann sind das keine Vorteile, sondern einfach Features, die man von einer solchen Software erwarten kann.

Das kann also entweder bedeuten, dass Jira keine Vorteile hat, oder dass die Vorteile von Jira nicht Teil deiner Liste sind. Darum hab ich zu jedem deiner genannten "Vorteile" ausgeführt, warum ich das nicht als spezifischen Jira-Vorteil sehen kann. Gibt es da noch echte Vorteile, oder ist Jira gleich so schlecht, dass es eigentlich doch keine echten Vorteile gibt? Wenn es keine echten Vorteile gibt, warum will man so was dann einsetzen?

Bewerten
- +
Anzeige