Pull Requests in firmen

[RobertVox]

Hallo,

sagt mir bitte ob ihr in euren Firmen Pull Requests benutzt.
Wie oft stößt man auf Pull Requests in Firmen heutzutage.
Ich meine z.B. Bitbucket configuriert mit Jira.
Ich bin auch sehr gespannt wie oft in euren Firmen die Clean Code Regeln beachtet werden.

Danke im Voraus.

 

[rg88]

Ich kann mit deiner Frage ehrlich gesagt nichts anfangen. Keine Ahnung was du willst


Aber falls dich der grundsätzliche Ablauf bei uns interessiert:
Wir haben Code Conventions. Der Entwickler nimmt sich immer den obersten Punkt mit der höchsten Prio vom Board, entwickelt ihn und commited in den aktuellen Workbranch. Ein zweiter Entwickler macht dafür dann den Review-Task und weißt den Code entsprechend zurück, wenn er nicht schön ist oder sonst was nicht passt z.B. die Logik falsch ist. Gibt der zweite Entwickler sein Ok, dann wird der Code am Ende des Sprints in den Mainbranch gemerged. Daraus wird dann das neue Release gebaut.
Tests laufen parallel im Workbranch ab und am Ende nochmal im Release

 

[cbkoerncb]

Wir verwenden Pull Requests eigentlich immer und ich finde sie auch sehr gut.

Nur mit Jira haben wir sie nicht gekoppelt.
Der gesamte Review Prozess wird damit abgebildet. Wenn alles fertig ist, kommt es in den Dev branch. Wenn wir produktiv gehen, kommt der Dev in den Master.

Hat das was mit Clean Code zu tun?

 

[rg88]

Hat das was mit Clean Code zu tun?

Genau das frage ich mich auch Ich verstehe den Eingangspost einfach nicht. Keinerlei Zusammenhang, irgendwie wirr.

 

[RobertVox]

Danke für die Antworten.
Pull requests haben mit cleancode nix zu tun. Aber das ist egal.
Ich will erfahren, wie oft in eurer Karriere ihr auf pull requests in Projekten gestoßen habt und wie oft clean Code Regeln bei eurer Entwicklung in Teams beachtet wurden.
Ich möchte im allgemeinen erfahren ob Firmen oft oder selten Sie benutzen.
Vor 5 Jahren wurden pullrequests sehr selten benutzt. Wie sieht das heute aus. Hat es sich verbessert? Ich finde pull request wunderbar und clean Code die wichtigste Sache im Projekt. Darum frage ich. Ich hasse in unschönen Code zu wühlen.

 

[rg88]

Die wichtigste Sache im Projekt ist erstmal, dass ein lauffähiges Ergebnis rauskommt
Refactoring kann man später immer noch machen, wenn Zeit dafür ist.
Gezahlt wird nicht nach Schönheit, sondern nach Funktionalität

 

[RobertVox]

Die wichtigste Sache im Projekt ist erstmal, dass ein lauffähiges Ergebnis rauskommt
Refactoring kann man später immer noch machen, wenn Zeit dafür ist.
Gezahlt wird nicht nach Schönheit, sondern nach Funktionalität

Du solltest dich dafür schämen!

Aus meiner 15 jährigen Erfahrung als jee entwickler:

Refactoring später???? = Never!
Clean Code = das schnelle lauffähige robuste Ergebnis!
Cleancode != nur Schönheit
Empfehlung für Dich =
https://www.amazon.de/Clean-Code-Ha...clean+code&dpPl=1&dpID=515iEcDr1GL&ref=plSrch

Bitte antwortet auf meine Frage.

 

[rg88]

Lol, ich denke du überschätzt das CleanCode ein wenig. Das allein ist noch kein Garant für gute Software.
Code Convetions sind das worauf es ankommt.

 

[RobertVox]

Ok

Das allein ist noch kein Garant für gute Software.

Das habe ich nicht gesagt.
Aber echt. Das Buch hat viel bei meiner Entwicklung und denkensweise geändert.

 

[rg88]

Ich kenn das Buch, habs selbst schon gelesen. Aber es ist halt nicht alles in der Praxis immer sinnvoll bzw. machbar was vll. "gut" oder "besser" wäre.
Wir arbeiten recht agil, was zu schnellen Ergebnissen führt mit Sprints von maximal 2 Wochen. Hin und wieder bleibt die Code-Qualität halt dabei auf der Strecke zum Ende hin. Das ist dann immer die Team-Entscheidung ob man das Feature jetzt raushaut und dazu nen refactoring task mit niedriger Prio erstellt, oder ob man auf (wohlgemerkt funktionierende) Funktionalität verzichtet.
Dem Kunden ist der Code egal. Wenn wir jetzt sagen: Mit so einem Code kommt das Feature nicht raus, dann ist das dem Kunden auch egal. Ihn interessiert, was er bekommt. Überarbeiten müssen wir den Code so oder so nochmal. Aber das ist ja das schöne am agilen Arbeiten, dass das eben nicht untergeht, sondern der Task im Backlog landet und das irgendwann gemacht wird, wenn mal Zeit ist, zB wenn im Sprint zuwenig eingeplant war. Man kann ja immer was niedrig priorisiertes nachziehen, weils für refactoring auch kein Refinement braucht.

Ich denke du kommst nicht aus der agilen Entwicklung Robert, korrekt? Sonst wärst du vorhin nicht so in die Luft gegangen Dir fehlt eindeutig das Vertrauen daran, dass es so Sachen wie ne Code-Nachbesserung durchaus auch in der Praxis gibt. Ihr schützt euch vor sowas mit wahrscheinlich hohem Aufwand im Vorfeld, wir arbeiten im Nachgang. Was nun besser ist, das lasse ich mal dahingestellt. Wer schneller etwas abliefert, sollte aber auch klar sein.
Ich sag mal so: Villarriba und Villabajo. Wer hier wer ist musst du entscheiden

 

[G00fY]

Wir nutzen (noch) die Atlassian Palette. Daher also auch Jira, Bitbucket, Bamboo. Grundsätzlich arbeiten wir auch mit PRs. Haben aber auch ohne 100% Abdeckung durch PRs eine sehr einheitliche Codebasis, da wir einen Code-Style-Guide definiert haben und die Zielarchitektur auch im Team bestimmen. Orientieren uns dabei auch sehr eng an Uncle Bob.

Also u.a. Unterteilung in Software Layer um Presentation, Domain und Datalogic zu trennen. SOLID Principles, Dependency Injection, Repository Pattern, MVP bzw. MVVM Pattern um mal ein paar Buzzwords aufzuzählen die bei uns im Mittelpunkt stehen. Bin Java-/Kotlin-Entwickler in einer App Schmiede.

 

[RobertVox]

Ich kenn das Buch, habs selbst schon gelesen.

Die wichtigste Sache im Projekt ist erstmal, dass ein lauffähiges Ergebnis rauskommt
Refactoring kann man später immer noch machen, wenn Zeit dafür ist.
Gezahlt wird nicht nach Schönheit, sondern nach Funktionalität

Nach deinem Post glaube ich dir nicht

Wir arbeiten recht agil, was zu schnellen Ergebnissen führt mit Sprints von maximal 2 Wochen. Hin und wieder ............................

Im Allgemeinen stimme ich zu was du im letzten Post geschrieben hast! Ich habe selbst solche praktische "wirtschaftliche" Einstellung. Ich habe nie behauptet, dass es anders ist.

Man kann ja immer was niedrig priorisiertes nachziehen, weils für refactoring auch kein Refinement braucht.

Wenn man schon erfahren ist, dann schreiben Clean Code nimmt nicht mehr Zeit in Anspruch als nicht-Clean-Code. (Es sei denn, man schreibt keine Tests... aber das ist eine andere Geschichte, die ich unkommentiert lasse.)
Schreiben etwas beim ersten mal richtig nimmt immer weniger Zeit als egal wie und später Refacktoring zu machen.

Ich denke du kommst nicht aus der agilen Entwicklung Robert, korrekt?

Seit 2010 habe ich nur bei verschiedenen agilen Projekten teilgenommen.

Um zu kontrollieren, dass niemand einen Scheiß eingecheckt hat, sind PR unerlässlich.
Meiner Meinung nach: Projekt ohne Clean Code aber mit PR können noch irgendwie funktionieren... ok... aber ohne PR..??
Mangel an PR garantiert, dass ab und zu (regelmäßig) Scheiß eingecheckt wird!

Schade nur das unser Meinungsaustausch mit meiner Frage im Post nichts zu tun hat

 

[character]

Ich bin mir jetzt immer noch nicht sicher, ob hier Pull Requests und Code Reviews gleichgesetzt werden?

Bei uns gibt es Code Reviews, aber keine Pull Requests.

Bzgl. Clean Code wüsste ich nicht wie nachhaltig wirtschaftliche Softwareentwicklung ohne CC funktionieren sollte. Das gehört einfach zum Handwerk dazu und wurde ja auch nicht von Uncle Bob erfunden, sondern "lediglich" gut verständlich zusammengefasst. Auch in deutlich älterer Literatur findet man diese Regeln schon und über Details wie die genaue maximale Länge von Funktionen kann man sicherlich diskutieren.

Unsauberer Code führte in meiner Laufbahn ausnahmslos zu direkt oder indirekt höheren Kosten. Deswegen versuchen wir uns daran so gut es geht zu halten und in aller Regel funktioniert es auch.

 

[Fonce]

Also die Info wie andere Arbeiten ist zwar mal ganz interessant, aber die eine Variante muss nicht zwingend besser oder schlechter sein als die andere.

Bei uns setzen wir aktuell bei alten Projekten auf Subversion. TFS nutzen wir für das Projektmanagement und als Buildsystem. Sinnvolles arbeiten mit mit Pullrequest ist so aktuell von Softwareseite her schwer möglich. Dazu kommt daß man auch eine entsprechende Anzahl an Mitarbeitern braucht um solche Konzepte gescheit umzusetzen. Bei einem Projekt bin ich z.B. der einzige Entwickler. Pullrequests sind da ziemlich nutzlos.

 

[conspectumortis]

Ich kann mit deiner Frage ehrlich gesagt nichts anfangen. Keine Ahnung was du willst


Aber falls dich der grundsätzliche Ablauf bei uns interessiert:
Wir haben Code Conventions. Der Entwickler nimmt sich immer den obersten Punkt mit der höchsten Prio vom Board, entwickelt ihn und commited in den aktuellen Workbranch. Ein zweiter Entwickler macht dafür dann den Review-Task und weißt den Code entsprechend zurück, wenn er nicht schön ist oder sonst was nicht passt z.B. die Logik falsch ist. Gibt der zweite Entwickler sein Ok, dann wird der Code am Ende des Sprints in den Mainbranch gemerged. Daraus wird dann das neue Release gebaut.
Tests laufen parallel im Workbranch ab und am Ende nochmal im Release

Genau so ist es bei uns. Auch wenn wir pair programming machen, schaut noch einer bei der qa drauf. Eigentlich schaut jeder mal kurz auf den code, weil der pull request für alle sichtbar gemacht wird. Anfangs hat das etwas abgeschreckt, aber man lernt so sehr viel.

100% code Abdeckung ist eh dabei. Und immer schön neue Technologien ausprobieren, diverse Programmiersprachen und so bauen wie es am besten passt, solang ein business value rauskommt ist alles bei uns gestattet. Projekte können wir auch selber pitchen. Mega geile Arbeitsstelle eben

Haben schon soviel gut gemacht und für die Firma richtig geile Scheiße gebaut

 

[rg88]

Eigentlich schaut jeder mal kurz auf den code, weil der pull request für alle sichtbar gemacht wird.

Genau das machen wir bewusst nicht. Dadurch besteht die Gefahr, dass sich immer wieder blind auf die anderen verlassen wird, oder eben nicht wirklich intensiv eingestiegen wird, sondern 5 Leute nur oberflächlich drüber schauen

Es ist immer so: Einer macht den Review. Ohne Review wandert nichts zu den Testern.
Es kann natürlich jeder frei entscheiden, ob er zusätzlich noch über den Code schauen will, was oft vorkommt, wenn jemand in einem Bereich entwickelt, bei dem er eher weniger Knowhow hat und derjenige der das Review macht, auch nicht der "Beste" ist. Das ist aber bei uns selbstregelnd. Wenn ich das "Gefühl" habe, dass ich da besser nochmal drüber schauen sollte, dann mach das eben. Desöfteren bringt es dann auch was, weil der Entwickler eben diesen oder jenen Seiteneffekt nicht beachtet hat, weil er es schlicht nicht wusste. Das ist bei größeren Projekten auch nicht anders zu erwarten und dient lediglich der Qualitätssicherung und nicht etwa um andere Kollegen bloß zu stellen.
Das "Bauchgefühl" lässt sich aber leider in keinem mir bekannten Projektmanagmentansatz richtig integrieren

 

[new Account()]

Genau das machen wir bewusst nicht. Dadurch besteht die Gefahr, dass sich immer wieder blind auf die anderen verlassen wird, oder eben nicht wirklich intensiv eingestiegen wird, sondern 5 Leute nur oberflächlich drüber schauen

Es ist immer so: Einer macht den Review. Ohne Review wandert nichts zu den Testern.
Es kann natürlich jeder frei entscheiden, ob er zusätzlich noch über den Code schauen will

So wie er es beschrieben hat^^

 

[conspectumortis]

Genau das machen wir bewusst nicht. Dadurch besteht die Gefahr, dass sich immer wieder blind auf die anderen verlassen wird, oder eben nicht wirklich intensiv eingestiegen wird, sondern 5 Leute nur oberflächlich drüber schauen

Es ist immer so: Einer macht den Review. Ohne Review wandert nichts zu den Testern.
Es kann natürlich jeder frei entscheiden, ob er zusätzlich noch über den Code schauen will, was oft vorkommt, wenn jemand in einem Bereich entwickelt, bei dem er eher weniger Knowhow hat und derjenige der das Review macht, auch nicht der "Beste" ist. Das ist aber bei uns selbstregelnd. Wenn ich das "Gefühl" habe, dass ich da besser nochmal drüber schauen sollte, dann mach das eben. Desöfteren bringt es dann auch was, weil der Entwickler eben diesen oder jenen Seiteneffekt nicht beachtet hat, weil er es schlicht nicht wusste. Das ist bei größeren Projekten auch nicht anders zu erwarten und dient lediglich der Qualitätssicherung und nicht etwa um andere Kollegen bloß zu stellen.
Das "Bauchgefühl" lässt sich aber leider in keinem mir bekannten Projektmanagmentansatz richtig integrieren

So war das nicht gemeint.
Wir machen code QA und ob die Software auch so funktioniert wie sie von der Fachabteilung gebraucht wird etc. Das macht einer oder 2. wenn das Ticket auf "wait for qa" ist und zieht es auf "qa in progress", dann gibt es den deploy, dann nochmal feedback von der Fachabteilung, um eventuelle Probleme aufzuzeigen.
Aber... wir sehen in unserem Teamchat den pullrequest und jeder schaut immer mal drüber und hat Verbesserungen anzubringen oder Ideen. Seiteneffekt: jeder hat fast immer den Überblick über alles.
Dazu gibt es noch "refinements", "technische refinements" usw.

Am Anfang war das nicht so, war viel Arbeit damit die ganze IT so arbeitet.

 

[psYcho-edgE]

Refactoring kann man später immer noch machen, wenn Zeit dafür ist.

Realität in allen KMUs, die nicht mehrere dutzend Entwickler anstellen oder einen externen DL dafür haben:

Refactoring wird auch später nicht gemacht, weil keine Zeit dafür ist, denn

Gezahlt wird nicht nach Schönheit, sondern nach Funktionalität