Entwerfen von Programmierstandards

[Gast cid0m]

Servus Leute,

ich habe da einmal etwas zu dem Thema Programmierstandards. Eins vorweg ich wusste nicht ob das hier das passende Unterforum für diese Frage ist, jedoch fand ich keins was meiner Meinung nach dazu besser passte. Falls ein Mod vllt. sonst ein passenders weis, wäre es super wenn er es verschieben könnte.

Nun weiter im Text

Ich bin jetzt fast mit meinem ersten Ausbildungsjahr in meiner Firma durch und musste letztens festellen

das wir keine Standards haben, also keine einheitliche Richtlinie wie ein Sourcecode aussehen soll.

Das hat mir nicht nur mir die einarbeitung in das neue Projekt erschwert, sondern erwschwert es auch meinen Kollegen das Programm eines anderen schnell und effizient zu verstehehn und vllt. zu erweitern, bugs fixen und so weiter....

Ich habe meinen Gruppenleiter darauf angesprochen und er meinte das wir leider keine haben obwohl er das sehr gut finden würde.

Also habe ich mir überlegt das ich mir einmal Gedanken um das Thema mache und ein Grundkonzept entwickle, sollte ich das hinbekommen, so das ein schlüssiges Konzept und eine sinnvolle Argumentation dahinter steckt

würde ich das dann meinem Gruppenleiter und eventuell meinem Abteilungsleiter vorstellen.

Meine Frage an euch ist jetzt, habt ihr Ideen und Ratschläge wie ich das ganze richtig angehen ? Ich habe sowas noch nie gemacht und weis natürlich deshalb noch nicht so genau wie der Hase läuft und meint ihr das wäre zu schwer für einen der gerade erst fast im zweiten Jahr ist ?

Ihr könntet euch jetzt sicher fragen, warum tue ich das wenn ich sowas noch nie gemacht habe!

Einfache Antwort, es tut kein anderer und ich persönlich finde so etwas sehr hilfreich. Zudem bilden wir im Moment sehr stark aus,

wir suchen jedes Jahr neue Azubis da das Durchschnittsalter bei ca. 58 bei und liegt, das wäre auch für die neunen Azubis eine große erleichterung, da diese eine einheitliche Struktur zu sehen bekommen.

Der wichtigste Punkt dabei ist, das wir in der Firma mit der iSeries und RPG arbeiten, und vor nicht all zu langer Zeit

kam ein Update für RPG raus was einem jetzt Erlaubt komplett in "free" zu schreiben, vorher musste man noch die Variablen, Proceduren ect. Spaltenorintiert schreiben und der Rest ging in "free", mit dem Update fällt nun auch

die Spaltenorintierung bei den Variablen weg.

Das ist in meinen Augen eine gute Gelegenheit einheitliche Richtlinen festzulegen, keiner bei uns schreibt im neuem "RPG" weil es noch nicht auf unserer iSeries ist, somit können sich alle am Anfang damit gleich auseinandersetzten.

Wie seht ihr das ? Meint ihr ich bürde mir da etwas auf was ich garnicht schaffen kann oder sagt ihr das ist eine gute Idee und ich sollte es ruhig versuchen, meint ihr das ist überhaupt notwendig usw.?

Wie bereits oben schon erwähnt würde ich mich auch über Tipps und Ratschläge freuen, vllt. gibt es ja hier Personen die sowas schon einmal gemacht haben und wissen wie der Hase läuft

Falls noch etwas unklar sein sollte oder ihr fragen habt einfach fragen

Grüße

Dominic

PS : Noch ein paar INfos vllt. zu unserer Abteilung. Wir sind im Moment 20 EDV Menschen in einer ca. 350 Mann/Frau starken Firma. In der Abteilung wird auschließlich für den eigenen Bedarf der Firma entwickelt. Arbeiten

tuen wir hauptsächlich mit RPG und der iSeries, es kommt aber auch ab und an mal vor das wir Java für Webservices nutzen.

Bearbeitet 2. Juni 2014 von cid0m

[carstenj]

Hi,

schau dir mal dieses Buch an, evtl. hilft es dir dabei:

Pragmatisch Programmieren: pragprog

Und es heisst Standard.

[Gast cid0m]

Danke habe es korrigiert, wie das nur passieren konnte :upps

Das Buch sieht schon einmal klasse aus, genau so etwas habe ich gesucht. Das tirfft mein Problem ja auf anhieb^^

[pr0gg3r]

Natürlich ist es sinnvoll, Programmierstandards einzusetzen. Viel problematischer ist dabei aber immer die Politik im Unternehmen. Einerseits braucht man Ressourcen den Standard zu entwerfen und dann aber auch, bereits vorhandenen Code nach diesem Standard anzupassen. Dann gibt es sicherlich auch Libs oder Schnittstellen, die eigene Standards haben, die sich wieder mit anderen oder dem eigenen Standard beißen. Außerdem wird es diejenigen geben, die sich querstellen nach dem Motto: "das haben wir schon immer so gemacht" (der Mensch ist (leider) ein Gewohnheitstier). Letztendlich braucht man dann auch jemanden, der das kontrolliert und Weisungsbefugnisse hat. Auch wenn ich das persönlich befürworte, ist eine Umsetzung nicht ganz so einfach.

[Ulfmann]

Aber je schwerer sich die Umsetzung gestaltet oder auch nur anfühlt, desto notwendiger ist sie wahrscheinlich.

Sich querstellen und Dinge ablehnen einfach aus Gründen der Gewohnheit halte ich für extrem unprofessionell und würde das auch ganz klar so sagen. Früher hat man auch mal Hexen verbrannt (weil man es halt immer so gemacht hat). Sofern aber pragmatische Argumente gegen einzelne Standards sprechen, sieht das wieder anders aus. Aber da muss man unbedingt gemeinsam drüber reden und jedem verschiedene Aspekte verständlich machen. Das finde ich jedenfalls cooler, als wenn jemand kommt und anordnet: "Das machen wir ab heute so! Punkt."

[pr0gg3r]

Aber da muss man unbedingt gemeinsam drüber reden und jedem verschiedene Aspekte verständlich machen. Das finde ich jedenfalls cooler, als wenn jemand kommt und anordnet: "Das machen wir ab heute so! Punkt."

Stimmt, man sollte alle in den Entwicklungsprozess eines Standards einbeziehen. Vor allem ist vieles auch nicht so grundlos wie man manchmal auf den ersten Blick vermutet.

Ich wollte eigentlich auch nicht sagen, dass der TE das bleiben lassen soll (sorry, falls es so rüber kam), sondern, dass es mit dem Entwerfen eines Standards an sich nicht erledigt ist, vielmehr ist es ein langwieriger Prozess, der auch viel an Planung benötigt. Sowas unterschätzt man gerne mal. Zum Beispiel muss definiert werden, welche Geltungsbereiche welche Punkte des Standards wo haben, wann der neue Standard angewendet wird (auch im Bezug auf altem Code). Ich habe da jetzt keine Erfahrung im Bezug auf Standards, aber ich bin mir ziemlich sicher, dass sich das zu einem extrem großen Projekt entwickelt, welches nicht mal geschwind nebenher zu stämmen, ist sondern zu einem Fulltimejob wird. Und dann muss der AG eben auch bereit sein, Ressourcen von anderen Projekten abzuziehen und dafür aufzuwenden. Ich rate deshalb dem TE erheblich dazu, das nicht nebenher anzupacken, egal wie viel Sinn das macht. Wenn er aber die Zeit dafür kriegt (mit der richtigen Argumentation bestimmt machbar, denn die Vorteile überwiegen auf lange Zeit, außer es wird sich von der Leitung her quer gestellt), spricht meiner Meinung nach nichts dagegen. Ich denke, wenn man das auf leichte Schulter nimmt, übernimmt man sich leicht und damit macht sich der TE selbst auch keinen Gefallen...

Wie auch immer: Es ist mit Sicherheit ein interessantes Projekt und mich würde es freuen, bei der Umsetzung auf dem Laufenden zu bleiben.

[Ulfmann]

ich bin mir ziemlich sicher, dass sich das zu einem extrem großen Projekt entwickelt, welches nicht mal geschwind nebenher zu stämmen, ist sondern zu einem Fulltimejob wird. Und dann muss der AG eben auch bereit sein, Ressourcen von anderen Projekten abzuziehen und dafür aufzuwenden.

So ist es. Aber du sagst ja selbst, dass diese Geschichte ein Entwicklungsprozess ist. Da merkt man ggf. auch noch nach Wochen und Montaten, dass hier und da immer mal was optimiert und/oder rausgeworfen werden kann. Das ist so wie mit dem Aufbau einer vernünftigen Testkultur - da ist man im Prinzip nie fertig mit. Man muss halt Arbeitsschritte mit in die Planung einzelner Projekte mit einfließen lassen, die sonst nicht berücksichtigt wurden. Für meinen Geschmack lassen sich solche ongoing "Projekte" wie Testing oder die Implementierung von Standards deutlich besser in den Griff kriegen, als separat, weil es wenn überhaupt nur eine sehr schwammige Definition of Done gibt.

[submain]

Genau das Problem hatten die Analysten, die TrueCrypt anhand des Quellcodes überprüft haben, wie sicher die Verschlüsselung wirklich ist. Die konnten den ganz schwer nachvollziehen und emulieren... Und jetz wo die Programmierer TrueCrypt für quasi tot erklärt haben, ist es fast unmmöglich für andere Entwickler ein Nachfolgeprojekt auf Grundlage der TrueCrypt-Engine zu erstellen.

Somit wäre dein "Projekt" für deine Firma, wo es in Zukunft viele neue Mitarbeiter gibt, ja optimal. So können ja auch Resourcen, die für das einarbeiten in die Software gespart werden, in andere wichtige Projekte fließen.

Und nebenbei zeigst du deinem Chef eine Eigen-Initiative und Unternehmensintegrierung. Für eine spätere Übernahme ist das ja ein sehr gutes Argument. Und solange du nicht den anderen Stoff, der ausbildungsrelevant ist, vernachlässigst, ist das ja auch sicher für dich eine gute Übung Sourcecode zu lesen und zu verstehen.

[submain]

Genau das Problem hatten die Analysten, die TrueCrypt anhand des Quellcodes überprüft haben, wie sicher die Verschlüsselung wirklich ist. Die konnten den ganz schwer nachvollziehen und emulieren... Und jetz wo die Programmierer TrueCrypt für quasi tot erklärt haben, ist es fast unmmöglich für andere Entwickler ein Nachfolgeprojekt auf Grundlage der TrueCrypt-Engine zu erstellen.

Somit wäre dein "Projekt" für deine Firma, wo es in Zukunft viele neue Mitarbeiter gibt, ja optimal. So können ja auch Resourcen, die für das einarbeiten in die Software gespart werden, in andere wichtige Projekte fließen.

Und nebenbei zeigst du deinem Chef eine Eigen-Initiative und Unternehmensintegrierung. Für eine spätere Übernahme ist das ja ein sehr gutes Argument. Und solange du nicht den anderen Stoff, der ausbildungsrelevant ist, vernachlässigst, ist das ja auch sicher für dich eine gute Übung Sourcecode zu lesen und zu verstehen.

Und wie "pr0gg3r" schon schreibt, vielleicht ist das ja dann sogar eine gute Zukunftsbasis für dich in dem Unternehmen, so ein großes Projekt langfristig durchzuführen

[Gast cid0m]

Also das klingt doch schonmal gut Das da eine Menge arbeit auf mich zu kommt ist mir bewusst, das sowas nicht in ein paar Tagen erledigt ist auch.

Aber ich bin der Meinung das die Firma dadruch ein gutes Plus an Leistung erhält, zu Anfang wird das vllt. schlechte rsein, aber sobald der Standard steht und die Mitarbeiter sich daran gewöhnt haben sollte sich das eiegnetlich hoffe ich locker wieder rechnen

Ich werde mir erstmal das Buch was carstenj gepostet hat kaufen und dann habe ich mitte Juni auch wieder BS, da werde ich dann mal mit meinen Lehrern schnacken, die finden sowas auch immer klasse vllt. können die mir dann auch gleich Tipps geben wie ich das ganze anpacken soll.

Das es gemeinsam passieren muss am Ende ist klar, so ein Standard bringt ja nur etwas wenn er befolgt wird, jedoch muss sich ja einer ransetzten und mal die Struktur usw. aufbauen.

Ich bin nur am überlegen ob ich erstmal mit meinem Gruppen bzw. Abteilungsleiter vorher reden soll das ich mir darüber Gedanken mache, oder erst wenn ich was konkrettes vorweisen kann.

[submain]

Is halt die Frage wie du das mit deiner Ausbildung vereinbaren kannst... Da das ja nicht konkret im Lehrplan steht und dementsprechen auch nicht in der Prüfung vorkommt, ist das ja auch mehrarbeit für dich...

Aber wie gesagt, wenn du das meiste von deinem Plan auf die Zeit nach der Ausbildung verschiebst und dein Chef dir auch die dafür genutzten Resourcen zur Verfügung stellt, haste schonma eine Sicherheit für die Zeit nach der Ausbildung. Auf zwei Jahre kommt es ja auch nicht mehr darauf an.

[pr0gg3r]

Vielleicht sollte das auch eher ein erfahrener Entwickler machen? Ich würde mir das jetzt nicht zutrauen, wenn es über die Vorgabe vom Syntax hinaus geht...

[Gast cid0m]

Wie gesagt erst wird ne Menge arbeit und ob ich das richtig hinbekomme steht ja auch noch in den Sternen, ich sehe nur das da für die anderen kein Handlungsbedarf besteht und ich dachte ich könnte das so vllt. ansprechen und ien Konzept erstellen, also wirklich nur ein einfaches Grundgerüst, quasi eine Qliederung, dazu würde ich dann erzählen warum ein Standard meiner Meinung nach Sinnvoll ist usw.

Diesen Standard zu entwicklen wird eine Hutnummer zu groß für mich sein...und wie auch schon geschrieben wurde, sollte der Standard gemeinschaftlich entwickelt werden weil ja alle Entwickler damit leben müssen

[submain]

Höhö, dann versuch mal 58 jährigen Mitarbeitern, klar zu machen das ab sofort ein neuer Standard eingeführt wird. Die werden sich bedanken, Ihre 30 jährige Berufserfahrung jetzt völlig umzukrempeln. Und das auch noch kurz vor Ende Ihres Schaffensdasein...

Warscheinlich ist genau das Problem in deiner Firma... Das die Mitarbeiter jeglichen Neuer- u. Verbesserungen nicht aufgeschlossen genug waren.

[Tempest]

Auch ich sehe das Hauptproblem darin, dass für die meisten deiner Kollegen überhaupt kein Handlungsbedarf besteht. Und auch wenn dein Abteilungsleiter dich ermutigt hat: Ihm kann auch nicht so wichtig sein, wenn er sich jahrelang nicht selber drum gekümmert hat.

In so einem Umfeld kannst die die besten und schönsten Standards entwerfen, es wird dich am Ende doch nur frustrieren, wenn sie keiner befolgen will.

Freiwillig wirds keiner machen, weil der Mensch, wie schon gesagt wurde, ein Gewohnheitstier ist und sich an der jetzigen Situation außer dir niemand stört.

Bleibt also nur "Verordnung von oben". Und oben bist du nicht. Also seh ich da ehrlich gesagt eher schwarz.

[Ulfmann]

Höhö, dann versuch mal 58 jährigen Mitarbeitern, klar zu machen das ab sofort ein neuer Standard eingeführt wird. Die werden sich bedanken, Ihre 30 jährige Berufserfahrung jetzt völlig umzukrempeln.

Es ging nicht darum, ihnen einfach Standards (im Sinne von einem Regelwerk, wie künftig gearbeitet wird) auf den Tisch zu schmeißen und zu sagen "Hier, lies das mal durch. Ab heute machen wir alles anders". Die Idee war mit den Kollegen gemeinsam eine Sammlung von Ideen zusammen zu stellen, wie a) effektiver gearbeitet werden könnte, wie Mitarbeiter schneller eingearbeitet werden können, c) wie man Fehler schneller findet usw. Man versteht Dinge manchmal besser, wenn man darüber redet. Und wenn dann der Großteil der Meinung ist, dass die Umstellung zu hart wird, nicht von der Idee überzeugt sind oder einen anderen Vorschlag haben, dann verwirft man es eben wieder. Darum aber Gespräche. Die Entwickler schreiben den Code und wissen (hoffentlich) selbst am besten, was zu Optimierungen betragen, da muss es keine "Verordnung von oben" geben.

[127.0.0.1]

wichtig ist ja erstmal, dass man damit anfängt! und man muss ja nicht gleich alles umsetzen, was möglich ist...

sinnvoll ist es sicher, wenn es pro woche ne halbe stunde meeting gibt, zu dem alle kommen müssen und dann wird geschaut, was sich bewährt, was überflüssig ist, was geändert werden kann/muss usw. nach und nach wird man dann einen einheitlichen standard haben. und in wie weit alter code angepasst werden muss kann wohl keeiner hier von außen beurteilen. priorität hat sicher der neue code...

und ganz ganz ganz wichtig: versichere dich vorher unbedingt!!!!!!"! der rückendeckung deines chefs bzw des chef der anderen entwickler. du wirst sicher den ein oder anderen kollegen haben, der sich von einem azubi nichts sagen lässt. da genügen schon ganz wenige quertreiber, um das ganze projekt scheitern zu lassen....

(und es empfiehlt sich immer, den größten quertreiber als mentor an bord zu holen. er wird geschmeichelt sein und kann seine eigenen punkte mit einbringen. das senkt den widerstand und er wird zu einer treibenden kraft )

viel erfolg

[Tempest]

Es ging nicht darum, ihnen einfach Standards (im Sinne von einem Regelwerk, wie künftig gearbeitet wird) auf den Tisch zu schmeißen und zu sagen "Hier, lies das mal durch. Ab heute machen wir alles anders". Die Idee war mit den Kollegen gemeinsam eine Sammlung von Ideen zusammen zu stellen, wie a) effektiver gearbeitet werden könnte, wie Mitarbeiter schneller eingearbeitet werden können, c) wie man Fehler schneller findet usw. Man versteht Dinge manchmal besser, wenn man darüber redet.

Und das Ausgangsproblem besteht darin, dass genau dazu kein Interesse besteht. Wenn die Kollegen keinen Handlungsbedarf sehen, sehen sie in der Regel auch keinen Diskussionsbedarf.

Und dann bist du doch wieder bei "von oben verordnen".

[Feron]

Also Code Richtlinien finde ich persönlich eine gute Idee.

Es ist sicher für die älteren Mitarbeiter eine schwierige Umstellung, aber auf Dauer wird es der Firma einen Nutzen bringen.

Man sollte dabei Schrittweise vorgehen.

In allen von Grund auf neuen Projekten hält man sich an den neuen Standard und die alten Projekte lässt man wie sie sind (zu großer Anpassungsaufwand)

Dazu könnte man in Zukunft alle neuen Mitarbeiter gezielt von Anfang an in die neuen Code Richtlinien einarbeiten.

Hier ein paar Prinzipien und Richtlinien die ich persönlich für Sinnvoll halte:

Die Clean Code Developer Initiative:

Roter Grad - Clean Code Developer

Buch: Clean Code von Robert C. Martin

Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe: Amazon.de: Robert C. Martin: Bücher

Falls ihr im .NET Bereich arbeitet:

C# Code Konventionen von Microsoft

Codekonventionen für C# (C#-Programmierhandbuch)

Diese 2 Punkte arbeiten direkt innerhalb von Visual Studio und somit müssen die Kollegen nicht unbedingt selbst an die Einhaltung der Regeln denken:

Im Visual Studio (ich glaube ab 2012) kann man eine Code Analyse durchführen die verschiedene konfigurierbare Regeln prüft und darauf Hinweist, wenn diese nicht eingehalten wurden.

Das Visual Studio Addin "ReSharper" von JetBrains ist empfehlenswert, da es Vorschläge macht wie der Code besser lesbar wird und wie Variablen benannt werden sollten. Es kann noch viel viel mehr...

The Most Intelligent Extension for Visual Studio :: ReSharper - C#, VB.NET, LINQ, ASP.NET, ASP.NET MVC, XAML, XML, JavaScript, HTML, build scripts. Best-of-breed tools for code refactoring, code quality analysis, code cleanup, navigation, code genera

Vielleicht hilft dir ja was davon^^

[carstenj]

Hi,

Und das Ausgangsproblem besteht darin, dass genau dazu kein Interesse besteht

natürlich ist das schwierig, aber wenn man das richtig verkauft, sollten sich Teilaspekte durchaus umsetzen lassen. Ich würde vermutlich erstmal eine List machen mit Dingen, die oft schieflaufen. Z.b. dass Quellcode kreuz und quer verteilt ist, oder Variablen immer unterschiedlich benannt werden. Das dürfte ja nicht nur den TE stören, sondern jeder der Entwickler wird damit ja irgendwann mal zu kämpfen gehabt haben.

Eine Sache die ich immer einführe ist ein Wiki. Das kann ich prima für mich selber alleine nutzen, aber es kann jeder mitmachen. Falls sich dafür keiner interessiert, habe ich zumindest meinen eigenen Wissensspeicher.

[Gast cid0m]

Jo ok also die Idee mit dem Wiki finde ich sehr gut das könnte ich mir auch vorstellen. Dann würde ich das erstmal für mich privat starten, mit Anleitungen und ein Tutorial in RPG für die Neulinge und sobald ich ein wenig was vorzeigen und auch vorweisen kann werde ich dann mal die Standards in Raum werfen.

Der Vorteil ist so denke ich das ich a) schon die Bestätigung habe das mein Chef ein Tutorial für die neuen Azubis gut findet das ich an Punkt A zeigen kann das mir diese Themen wichtig sind und das er sieht das ich mich da auch hinter klemme kann und c) das ich wie carstenj schon schrieb eine vernüftige Liste aufsetzten kann die meine Argumente unterstüzt.

Das sollte denke ich eine ganz sinnvolle Vorgehensweise sein, wie schon geschrieben worden ist kommt es auf ein Jahr oder so auch nicht mehr an und vllt. finden die neuen Azubis dieses Jahr die Punkte ja auch für wichtig, bei mehreren Leute ist man dann ja doch oft bereiter über solche Sachen zu reden.

Ich sage auf jedenfall einmal Danke für die guten Ideen und die Ratschläge solle was neues kommen werde ich euch gerne auf den laufenden halten eventuell kommen ja auch noch von meiner Seite fragen!

[submain]

Musst du als Azubi, in der mündl. Prüfung bei der IHK, nicht auch ein Projekt erstellen was mit deiner Firma zu tun hat...? Da haste ja schonma ein gutes Thema was du vorstellen kannst.

[Gast cid0m]

Mal eine Rückmeldung, habe gestern mit meinem Abteilungsleiter geredet, da mein Gruppenleiter im Urlaub ist.

Er findet, genau wie mein Gruppenleiter, es sehr gut das ich das angesprochen habe, er selber will das wohl auch schon länger in Angriff nehmen, jedoch möchte die Mehrzahl der Kollegen diesen "Aufwand" und es fehlte wohl auch einfach die nötige Zeit.

Ich habe im das mit dem Wiki erzählt und auch das findet er sehr gut! Ich habe dann auch gleich vorgeschlagen das ich da ja meine "Einführungskurse" für die iSeries/RPG/RDI ect., welche ich privat geschrieben habe für neue Azubis und auch für Kollegen die sich mit der "neuen"Technick nicht auseinandersetzten wollen, einpflegen kann, damit es eine zentrale Anlaufstelle gibt.

Lange Rede kurzer Unsinn

Ende Juli wenn ich aus der Berufsschule und aus meinem Urlaub wieder da bin, werde ich meine privaten Texte da einpflegen und Ende Juli/anfang August in der Abteilung vorstellen und dann wird mein Abteilungsleiter auch die Standards ansprechen, und dann sollen nach und nach diese Entwickelt und eingefplegt werden denn er ist der selben Meinung wie ich, viele ältere Leute werden gehen und die neuen Azubis werden es ohen Standart schwerer haben als nötig, zumal das ja auch für die Abteilung an sich auch nur ein Plus sein kann!

Also hier meine Rückmeldung und nochmal ein Danke für eure Ratschläge und Tipps

[pr0gg3r]

Dann hoff ich mal, dass es bei dir besser läuft als bei mir, ich habe auch mal ein Wiki eingeführt. Aber statt, dass sich jeder dran beteidigt, hieß es dann: "trag mal kurz das ein, das fehlt noch, das könnte man noch eintragen, ...". War mir dann irwann zu blöd.

[submain]

Er kann ja dann den neuen Azubis klarmachen, das sich jeder an diesem Wiki zu beteiligen hat... Das sei so üblich ich in der Firma. Den MasterChief hat er ja schonmal hinter sich. :cool: