Unschöner Code von anderen, was macht ihr damit?
-
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.
-
Simon2 schrieb:
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 ...
Das ist prinzipiell richtig, aber dann hat ja trotzdem immer wieder einer den Code "übernommen", also hat sozusagen das "Code-Ownership" über diesen historisch gewachsenen Code. So war zumindest meine Erfahrung bis jetzt. Aber variiert wohl.
-
pumuckl schrieb:
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.
minimalismus ist halt nicht immer das ziel, manchmal will man schnellen code haben, manchmal lesbaren (in dem implizite dinge nicht uebersehen werden).
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.
ich spreche natuerlich von der technischen seite, der lead programmer sollte dazu faehig sein. ich erwarte natuerlich nicht dass der producer irgendwelchen code vom technical director pruefen muss.
-
Simon2 schrieb:
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.ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
... 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.da haben die vorherigen vorgesetzten wohl versagt beim verteilen der leitpositionen, aber ich glaube das hat nicht wirklich viel mit dem topic hier zu tun. ich stimme dir zu, aber naja... darueber aufregen bringt wohl nichts.
-
rapso schrieb:
ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
Dazu muss es so eine Hierarchie erstmal geben.
-
Simon2 schrieb:
~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....
das stimmt natürlich. z.b. wenn von der schnittstelle, der du ein so freimütig 'const' verpasst hast, andere funktionen aufgerufen werden, die 'nicht-const' sind, musst du die auch anpassen usw. und schon hast du den berüchtigten 'const is a virus'-effekt. für den implementierer kann's in der tat ziemlich eng werden.
Shade Of Mine schrieb:
Natuerlich verengt es die schnittstelle - einfach mal einen schritt weiter denken.
na, wenigsten hast du mich nicht zum mitdenken aufgefordert. damit hättest du mich schwer beleidigt.
-
Bashar schrieb:
rapso schrieb:
ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
Dazu muss es so eine Hierarchie erstmal geben.
das klaert deinen postcount, capt obvious