Unschöner Code von anderen, was macht ihr damit?
-
Mich würde interessieren was ihr macht, wenn ihr zufällig auf Code stoßt, der verbesserungswürdig ist, also z.B. unsicher oder redundanter Code
- Selbst verbessern und dem Autor nichts sagen (wird er schon mitbekommen)?
- Selbst verbessern und dem Autor darüber informieren?
- Dem Autor nur bescheid sagen, dass man hier und da was verbessern könnte?
- Gar nichts unternehmen, solange es euch nicht betrifft. Schließlich möchte man ja nicht besserwisserisch wirken.Ciao,
2b!=2b
-
2b!=2b schrieb:
Mich würde interessieren was ihr macht, wenn ihr zufällig auf Code stoßt, der verbesserungswürdig ist, also z.B. unsicher oder redundanter Code
Ich muß gestehen, das ich zu den Leuten gehöre, die Anderen auch mal auf den Schlips treten. Auch wenn ich es versuche möglichst nicht negativ rüber zu bringen (Sprich sie auf die Stelle ansprechen, ggf. fragen warum man es so und nicht anders gemacht hat, ihnen [das ist imho das wichtigste] Alternativen nennen...).
Dies kann aber nur gut gehen wenn der Andere bereit ist zuzuhören und nicht sofort gekränkt ist. Das Problem ist, wenn man es stilschweigend ändert, daraus garnichts gewonnen wird. Der Autor wird irgendwann darüber stolpern und ggf. beleidigt sein, und lernen tut auch keiner daraus.Ich weiß das auch ich nicht die absolute Weisheit besitze, und ich lerne daher immer weiter. Ich habe auch kein Problem wenn mich jemand auf etwas hinweist, sofern das was er sagt kein Rückschritt darstellt (Wenn man mir in einem C++ Projekt sagt, das etwas auf C-Art besser sei, werde ich dies erst mit einen Blick Richtung Profiler akzeptieren; Wenn mir aber jemand sagt das dies und jenes mit Sprachmitteln oder anderen Entwurfsansatz besser geht, dann höre ich auch gerne hin).
cu André
-
2b!=2b schrieb:
- Dem Autor nur bescheid sagen, dass man hier und da was verbessern könnte?
so mache ich das. aber auch nur dann, wenn ich glaube, dass der code ursache von irgendwelchen problemen werden könnte. 'unschönen' code akzeptiere ich so, wie er ist.
-
Hi,
das sind meine beiden Vorgehensweisen:
2b!=2b schrieb:
...
- Selbst verbessern und dem Autor nichts sagen (wird er schon mitbekommen)?
...
- Gar nichts unternehmen, ...Ich verbessere nur da, wo ich nennenswerte Änderungen vornehmen muss und mir dadurch die Arbeit erleichtere.
"Verbessern" kann man nämlich immer was
und bezahlt wird vom Kunden aber nur ein fester Betrag.
... Und "den Autor informieren" ist in einer Firma mit 500 Entwicklernm befristeten Stellen und zahllosen (temporären) Externen schöner Traum (bzw. die schöne Ausnahme).Gruß,
Simon2.
-
auf jedenfall nicht hinterruecks code abaendern, vielleicht ueberblickt man nicht immer den ganzen sinn.
wenn einem unternehmen wirklich viel dran liegt, kann es code review vor dem einchecken einfuehren.
-
rapso schrieb:
auf jedenfall nicht hinterruecks code abaendern, vielleicht ueberblickt man nicht immer den ganzen sinn.
Dem stimme ich zu, auch ein Grund warum ich das Gespräch suche.
rapso schrieb:
wenn einem unternehmen wirklich viel dran liegt, kann es code review vor dem einchecken einfuehren.
Dann müssen die, die das Review machen aber mindestens die gleiche Ahnung von der Sprache haben wie der Schreiber. Dies ist in kleinen Unternehmen nicht immer gegeben (anderseits kann dann ein Review auch genutzt werden um neues zu lernen).
cu André
-
Ui ui ui! Sehr schönes Thema! Ich selber versuche Code anderer nicht zu ändern, außer ich muß daran aktiv arbeiten... dann mache ich es gleich mal mit. Aber nur refactoring! Optimieren o.ä. mache ich nicht, weil das auch nach Hinten los gehen kann! (neue Fehler!)
Wenn ich etwas unschönes zufällig sehe, lasse ich es so, wie es ist. Weil da habe ich keine Aktien drin. Und nobody is perfekt! Denn auch ich mag es nicht, wenn jeder zu mir angedackelt kommt, und mich verbessern will. Habe da nämlich so einen Kollegen im Team, der der Meinung ist, das was und wie er es macht, immer am besten ist. Und das geht mir mächtig auf den Zeiger. Wohlgemerkt geht es nicht um Bugs! Sondern eher so nach dem Motto: "ich hätte das so gemacht!"
Wenn ich einen Bug finde, dann ändere ich ihn, weil ich eh an der Stelle zu tun habe, oder ich sage dem Autor bescheid, damit er ihn korrigieren kann.
Die grundlegende Entscheidung, wann ich aktiv werde (bescheid geben oder ändern), hängt davon ab, ob es nur unschön oder ein Bug ist.
-
2b!=2b schrieb:
- Selbst verbessern und dem Autor nichts sagen (wird er schon mitbekommen)?
Geht mal gar nicht, da ist meistens Ärger vorprogrammiert...
Tue entweder auch nichts (wenn das z.B. innerhalb klar definierten Schnittstellen abspielt, isses ja letztlich auch nicht so tragisch, so lange es fehlerfrei läuft) oder halt irgendwie in Kommunikation mit der Person treten.
-
"Die Schönheit liegt im Auge des Betrachters", heißt es. Manch einen stört es z.B. nichtmal, daß ein Projekt mit 1000 Warnings compiliert ...
Wenn es nicht um (potentielle oder existente) Bugs geht, fasse ich nichts an, solange man mich nicht dafür bezahlt und es um einen Kundenauftrag geht. Da ist es in aller Regel so, daß der ursprüngliche Coder sowieso irgendwo anders werkelt, deswegen sitze ich ja dann dran.
Etwas anderes ist es bei OpenSource, wenn man da was nimmt, freuen sich viele, was zurückzubekommen, sofern es kein Pipifax- Genörgel ist.
-
nep schrieb:
...halt irgendwie in Kommunikation mit der Person treten...
Irgendwie geht Ihr anscheinend von "Code-Ownership" aus. Das mag in bestimmten Firmen/Projekten so sein, aber die Codebasis an der wir hier arbeiten, "gehört" niemandem (außer der Firma an sich). Wenn ich ein Codestück in die Finger bekomme, haben da oft über Jahre hinweg viele verschiedene Leute dran gearbeitet. Ich wüsste gar nicht, an wen ich mich da wenden sollte ... und ob der dann überhaupt noch (besser als unser Repository) wüßte, womit das alles zusammenhängt.
Aber es gibt natürlich auch Code, der eher in bestimmten "Fachteams" kursiert und da kann man schonmal den einen oder anderen "Vorarbeiter" kontaktieren; ist bisweilen hilfreich, weil es die Einarbeitung verkürzt - oft genug aber auch nicht.
Wenn ich tatsächlich Code "korrigiere", beachte ich natürlich Schnittstellenkonformität und bevor ich eine Schnittstelle "breche", müsste ich schon mit dem Rücken an der Wand und einem scharfen Messer an der Kehle (einem sehr sehr scharfen!) stehen.
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
... aber wie gesagt: Die Fälle sind eher selten und beschränken sich meistens auf rein komponentenintern Genutztes.OT: Übrigens ein Punkt, den ich bei Java schwer vermisse: Dadurch, dass da immer Referenzen rumgereicht werden (die man leider auch nicht "consten" kann), kann man einer Schnittstelle nicht (compilergeprüft) mitgeben, ob es sich um einen Input- oder einen Updateparameter handelt... eigentlich würde ich mir in C++ auch noch eine Unterscheidung zwischen update (am Besten noch mit Vorbedingungen) und output wünschen - aber nun gut, das ist ein noch weiteres Thema.
Gruß,
Simon2.
-
Simon2 schrieb:
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
das verengt doch nix. man kann die funktion weiterhin mit nicht-const argumenten aufrufen.
-
- Selbst verbessern und dem Autor nichts sagen (wird er schon mitbekommen)?
oder
- Gar nichts unternehmen, ...Alles andere ist bei uns unpraktikabel und sinnlos und das bei einem recht kleinen Team.
Wenn jemand einen Bug in meinem Code gefunden hat und korrigiert hat, dann super. Wenn ich etwas nicht perfekt gemacht habe und jemand die Zeit hatte das schöner zu bauen, perfekt.
Wenn ich irgendwann mal wissen wollen sollte, wer wo rumgebastelt hat, dann kann ich das in der History des VCS nachsehen, z.B. wenn vorher funktionierender Code plötzlich einen Bug enthält.
-
ich änder es für meinen code, aber mache mir selten die mühe den autor darüber zu informieren. warum schon.
-
pointercrash() schrieb:
"Die Schönheit liegt im Auge des Betrachters", heißt es. Manch einen stört es .B. nichtmal, daß ein Projekt mit 1000 Warnings compiliert ...
Kann ich durchaus bestätigen. Ein Kollege baute mal anscheinend mittels eines selbstgeschriebenen Programms eine Bib. mit 500 C++ Klassen der feinsten Sorte. Sorgte für an die 1000 Warnings wenn man diese kompilierte und machte umso mehr Spaß wenn man die Bib. mehrmals einbindete. Natürlich war, als ich das Projekt übernahm, nur noch die vom Programm generierte Bib. vorhanden. Schlechte Namensgebung der Klassen (Prefix + Postfix ala EZAHaus01,EZPHaus02,...), Zugriff auf Array mittels Arrays (a[b[i]]), keine Doku und so vieles mehr sorgte dafür dass man mit dieser Bib. nicht viel anfangen konnte. Und so musste ich in meiner Projektarbeit dem Prof. und Doktoranden erklären dass das Projekt hier schon scheiterte weil das Design schlichtweg scheiße war.
Hätte ich den Autor erwischt, hätte ich ihn wohl oder übel gesteinigt.
Ansonsten lasse ich schlechten Quellcode wie er ist, solange für mich dadurch keine Probleme auftreten. Wenn ich etwas ändern möchte, gehe ich gerne zu dem Kollegen, sofern ich iihn erwische, und erkläre ihm meine Änderungen.
-
asc schrieb:
rapso schrieb:
auf jedenfall nicht hinterruecks code abaendern, vielleicht ueberblickt man nicht immer den ganzen sinn.
Dem stimme ich zu, auch ein Grund warum ich das Gespräch suche.
rapso schrieb:
wenn einem unternehmen wirklich viel dran liegt, kann es code review vor dem einchecken einfuehren.
Dann müssen die, die das Review machen aber mindestens die gleiche Ahnung von der Sprache haben wie der Schreiber. Dies ist in kleinen Unternehmen nicht immer gegeben (anderseits kann dann ein Review auch genutzt werden um neues zu lernen).
cu André
also ich wuerde davon ausgehen, dass leute die produktiv in einem unternehmen arbeiten, echt nicht wegen der sprache nachdenken muessen.
und notfalls macht der vorgesetzter ein review mit, der sollte ahnung haben von dem was abgeht, man solle aber auch erwarten dass sein code nicht dringend ein review benoetigt.
-
~fricky schrieb:
Simon2 schrieb:
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
das verengt doch nix. man kann die funktion weiterhin mit nicht-const argumenten aufrufen.
[/quote]
Natuerlich verengt es die schnittstelle - einfach mal einen schritt weiter denken.
-
rapso schrieb:
also ich wuerde davon ausgehen, dass leute die produktiv in einem unternehmen arbeiten, echt nicht wegen der sprache nachdenken muessen.
Wegen der Sprache nicht unbedingt, aber vielleicht darüber wie ein anderer mit der Sprache umgeht. Ich seh mich noch als Anfänger, aber häufig stolper ich über Code der mit halb so vielen Zeilen sicherer und eleganter gelöst werden kann - was auf der anderen Seite impliziert dass dem Code-ersteller diese alternativen Lösungen nicht bekannt sind.
und notfalls macht der vorgesetzter ein review mit, der sollte ahnung haben von dem was abgeht, man solle aber auch erwarten dass sein code nicht dringend ein review benoetigt.
Der Vorgesetzte eines Entwicklers ist nicht unbedingt selber Entwickler, gerade bei flachen Hierarchien. Ich würde nicht darauf wetten, dass jemand dessen Hauptaufgabe die Organisation der Mitarbeiter ist, alle von denen verwendeten Programmiersprachen ähnlich gut beherrscht wie die Mitarbeiter selbst.
-
~fricky schrieb:
Simon2 schrieb:
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
das verengt doch nix. man kann die funktion weiterhin mit nicht-const argumenten aufrufen.
Eine Schnittstelle hat alt 2 Seiten ... und für den Implementierer wird sie schon enger....
...weswegen ich diese Form der "Verengung" relativ guten Gewissens mache, weil das eigentlich nur dann in Frage kommt, wenn ich die Implementation sowieso anfassen muss.Gruß,
Simon2.
-
Bitte ein Bit schrieb:
...Projektarbeit ... Prof. ... Doktoranden...
Also ich denke, dass gerade an der Uni (vermutlich durch mangelnde Erfahrung, hohe Fluktuation, kaum "maintenance"- und service-level-Anforderungen) besonders viel schlechtes Design zu finden ist. Ist zumindestens nach meiner Erfahrung so.
Dabei will ich mich nicht ausnehmen: Meine Diplomarbeit könnte auch den Titel tragen "Beweis durch Antithese: Warum Scott Meyers doch Recht hatte"....Gruß,
Simon2.
-
rapso schrieb:
...der vorgesetzter ... sollte ahnung haben von dem was abgeht...
In was für einer Welt lebt Ihr denn ? Also wenn hier einer Chef ist, dann meistens nicht, weil er als Programmierer unglaublich viel getaugt hat!
Das finde ich vom Konzept her auch gut: Wer gut programmieren kann, soll programmieren - wer Führungsqualitäten hat, soll führen.
... und sooo viele Leute, die in beiden Gebieten Spitze sind, gibt's nicht.
Und ehrlich gesagt: Unsere Firma leidet ziemlich darunter, dass immer noch zu viele Programmierer in Führungspositionen aufgestiegen sind - die leider ziemliche Managementblinsen sind und sich stattdessen mit ihren (längst veralteten) technischen Vorstellungen in fachliche Arbeit einmischen.Nenene - bloß keinen Programmierer zum Chef haben.
Gruß,
Simon2.