Programmiersprache Designrules

[Kuddel]

Hallo zusammen,
mal eine Frage an die beruflichen Programmierer unter Euch, die Firmeninterne Software erstellen:
Gibt es bei Euch offizielle Designrules? Also Vorschriften, welche Sprache (C#, Python...) und welcher Code-Editor/Umgebung verwendet wird? Vorschriften für Abläufe, zu Beispiel Qualitätskontrolle, Scrum, ... Wo und wie wird Code dokumentiert (Git, Beschreibung in Word, Funktionsbeschreibung)? Lookalike oder Corporate Vorlagen, wie das Frontend auszusehen hat?
Gibt es Links oder Literatur, wie man sowas einführt?
Danke und Gruß
Kuddel

[Fritzler]

Türlich gibts sowas.
Aber die Designrules sagen nicht welche Sprache oder Editor.
Da gehts allein darum wie der Code geschrieben woll.
zB alle Member Variablen einer C++ Klasse fangen mit "m_" an, Klammersetzungen, sonstwas an Formatierung.
Sowie, dass Funktionskommentare im Doxygenstyle zu schreiben sind.

In Welcher Sprache gecoded wird ist nochmal woanders festgezurrt und in welcher IDE/Editor.
Ein Arbeitsprozess wie neuer Code reviewt und statisch gecheckt werden soll vorm git Merge ist natürlich auch beschrieben.
Sowie eben was an Tests passieren muss bevor eine neue Softwareversion an den Kunden geht.

Links und Lit wie man sowas einführt, ka, sowas wird einem übergestülpt

[zauberkopf]

Kuddel : Das ganze hängt sehr davon ab, in welchem Bereich ihr tätig seit.
z.B. gibts Bereiche wo es Sicherheitskritisch wird, dann auch schnell Anforderungen von 3. Seite...

Ein anderer Punkt wäre der Lebenszyklus einer Software...
ganz krass.. Maschienensteuerung für ein Mulitmilliionen Eur Möller, der 40j oder länger in Betrieb ist...
.. oder ne schöne Konfigurationsapp, für ein billiges überflüssiges Consumer-Device das nach 2 Jahren eh keiner mehr hat.

Da gibts nicht das Allgemeines Goldenes Ei...

[Jannyboy]

Hallo,

Gibt es Links oder Literatur, wie man sowas einführt?

Hier gibt es einen guten Einstieg.
https://dev-docs.kicad.org/en/rules-gui ... index.html

Ich habe ein paar Monate bei Kicad mitgearbeitet und tue es immer noch. Bevor ich einen eigenen Prozess für die Firma entwickelt habe.
Coding-Disziplin ist nachher, das A und O. Also kein schnell schnell mehr nur weil es gerade bequem ist.
Das rächt sich spätesten 6 Monate später mit der doppelten Arbeit, wenn die super wichtige Deadline vor der Tür steht.

Neben den Designrules ist auch noch eine gute Projektplanung notwendig.
Groß im Ablauf: Anforderungsanalyse, Konzept, Zeit- und Ressoucen-Planung, Implementierung / Dokumentation, Verifikation, Testing, Serieneinführung.

Grüße Jan

[manuel]

Design rules. Oh nein !

Man kann schon im Team ein paar Empfehlungen aussprechen. Aber: es kann schnell passieren dass man sich am Ende viel zu sehr damit beschäftigt. Bei schlaumeier Absolventen leider oft der Fall. Da hilft zu erklären: deine Stunde kostet x, wer bezahlts womit ? Sollte zumindest nicht egal sein, mal darüber nachdenken.

Ich empfehle meinem Team mittlerweile nur noch: schreibt die Software doch bitte ungefähr wie im Wiki beschrieben, oder so wie der code im Bestand. Aber nimmt es bitte niemand übel wenn mal was nicht 100% eingehalten wurde. Viel wichtiger: einmal eingecheckt, lasst es so. Bei Änderungen, nur das Wesentliche, nur Dinge die der Kunde als Verbesserung wahrnimmt, keine philosophischen Verbesserung, weil im Zweifelsfall findet diese nur eine Person auf der Welt gut. Bitte, ihr braucht nicht immer und überall beweisen wie toll ihr seit, lieber KISS. Jede Änderung macht ein Berg an Arbeit (auch Jahrzehnte später), also lieber nix (bitte bitte) unnötig ändern.

Was nicht getestet wurde funktioniert nicht. Test driven development empfehle ich gerne. Irgendein Tracking schadet nie. GIT mit CI geht gut. Gibt aber auch anderes taugliches, man nehme was da ist. Solange es flutscht, coverage gut, passt scho.

So wie die anderen programmieren ist immer doof. Ist so, muss man mit leben. Daran sollte man Software nicht messen, sondern an Leistung und Kosten. Zumindest wenn man es gewerblich macht.

Grüße,
Manuel

[zauberkopf]

Ich habe letztens in einem Buch gelesen :
Ein Programmierer, schreibt in erster Linie für einen anderen Menschen, und dann erst für den Computer.
Bei mir ist das so : Ich schreibe, für den zauberkopf der sich das ganze in 6 Monaten noch am anguckt, und sich fragt : Wer hat diesen Kack denn geschrieben ? Und warum ?

Aber noch mal, es schon wichtig, in welchem Bereich man sich bewegt.
Ich habe beim Datenbankprogrammieren, mit unter andere Regeln, als bei Hardwaregeschichten, wo es auch schon mal Sicherheitskritisch wird.
z.B. bei Datenbanken, fange ich beim Design an, möglichst universell zu sein, damit ich später sauber neue Dinge implementieren kann, ich dir mir heute noch nicht vorstellen kann.
Dort Programmiere ich erst, Dokumentiere... vielleicht/hoffentlich... und dann zum nächsten.
Hier helfen schon ein paar "Styles".. und Konvention, um mit den Kollegen zu reden.

Bei meinem jetztigen Projekt, schreibe ich erst die Dokumentation, und erst dann den Code.
Wir reden erst mal über Dokumentation.
Die Arbeit mache ich mir, damit ich überhaupt Einschlafen kann.

Und bei KI wirds noch mal anders..

[Arndt]

Kuddel,
auch wenn es im Ersten Moment "nur" firmeninterne Software (und aktuell vielleicht nur ein Entwickler) ist, lohnt es sich trotzdem die Entwicklungsprozesse und das Regelwerk drumzu vernünftig zu definieren und auch zu leben! Wenn Du die entsprechenden Ressourcen zur Verfügung hast, MACHEN!

Man glaubt gar nicht, wie schnell auch kleine "Helferlein" plötzlich extrem Relevant sind und was für Wellen ein Sicherheitsvorfall im Kritisnetz schlägt...

Ich empfehle als Bettlektüre Clean Code von Uncle Bob und im Bedarfsfall 62443, sowie das BDEW whitepaper (auf letzt beide stehen die Kunden gerade voll drauf zum Glück!)

[Kuddel]

Danke für Eure Tipps und Hinweise.
Werde mal was zusammenschreiben.

[Christian Knüll]

Hallo,

ich denke auch dass es sehr vom Bereich abhängt in dem man tätig ist.
Es gibt ein paar wenige Allgemeinplätze a la "don't repeat yourself" / "sauber und verständlich dokumentieren / kommentieren" und "Benennungsschemen für global genutzte Bezeichner einhalten" die - meistens aber auch nicht immer - passen.
Der Rest ist ein sehr sehr situationsabhängiger Werkzeugkasten aus dem man das passende für die konkrete Situation raussuchen muss.

Im Firmenumfeld dürfte die erste und wichtigste Fragestellung dabei sein "wie müssen wir arbeiten, dass auch wenn Programmierer X vom Bus überfahren wird das Projekt erfolgreich weitergeführt werden kann".
Der Rest ergibt sich daraus und muss sicherlich im Laufe der Zeit auch immer wieder mal nachjustiert werden.

Die 2. Frage im Unternehmensumfeld dürfte sein auf welche Userinterface-, Benennungs- und Arbeitsablaufstandards man sich für die Benutzer einigt.
Die Software dient ja primär dazu den Rest des Betriebes effektiv am flutschen zu halten ohne ständig Mitarbeiter schulen zu müssen oder deren Arbeitsabläufe auszubremsen.
Die Denkweise "normaler Mensch" vs Programmierer unterscheidet sich ja doch oft recht deutlich - schadet nicht bei sowas auch die Betroffenen außerhalb der IT um Rat zu bitten.

Christian

[Marsupilami72]

Witzig...Dazu hat sich gerade vorgestern mein Chef Folgendes von ChatGPT auskotzen lassen. Das passt vielleicht nicht komplett zur Fragestellung, sollte aber ein paar Anknüpfpunkte liefern:

IT-Anwendungs- und Entwicklungsanforderungen
4. September 2024
Du:
Welche Anforderungen an eine professionelle IT-Anwendungs- und Entwicklungsumgebung sollte ein Industrieunternehmen haben?
ChatGPT:
ChatGPT
Eine professionelle IT-Anwendungs- und Entwicklungsumgebung in einem Industrieunternehmen sollte verschiedene Anforderungen erfüllen, um Effizienz, Sicherheit und Skalierbarkeit zu gewährleisten. Die Anforderungen lassen sich in verschiedene Kategorien unterteilen:

1. Sicherheit
Zugriffskontrollen: Strenge Zugriffskontrollen und Authentifizierungsmechanismen (z. B. Multi-Faktor-Authentifizierung) sind erforderlich, um sicherzustellen, dass nur autorisierte Benutzer Zugang haben.
Datenverschlüsselung: Daten sollten sowohl im Ruhezustand als auch während der Übertragung verschlüsselt werden.
Sicherheitsrichtlinien und Compliance: Einhaltung von branchenspezifischen Standards (z. B. ISO 27001, GDPR) und regelmäßige Sicherheitsüberprüfungen.
Patch-Management: Regelmäßige Updates und Sicherheits-Patches für Betriebssysteme und Anwendungen.

2. Skalierbarkeit und Flexibilität
Cloud-Integration: Nutzung von Cloud-Diensten (z. B. AWS, Azure, Google Cloud) für flexible und skalierbare Ressourcenbereitstellung.
Containerisierung: Einsatz von Containern (z. B. Docker) und Orchestrierungstools (z. B. Kubernetes) für eine einfache Skalierbarkeit und Portabilität von Anwendungen.
Microservices-Architektur: Einsatz einer Microservices-Architektur zur Verbesserung der Flexibilität und Wartbarkeit.

3. Entwicklungswerkzeuge und -methoden
Versionskontrollsysteme: Nutzung von Versionskontrollsystemen (z. B. Git) für eine effiziente Verwaltung des Quellcodes.
CI/CD-Pipelines: Implementierung von Continuous Integration und Continuous Deployment (CI/CD) für eine automatisierte und schnelle Bereitstellung von Anwendungen.
Automatisierte Tests: Einbindung von automatisierten Testverfahren (Unit-, Integrations-, und Systemtests), um die Qualität des Codes zu gewährleisten.

4. Performance und Zuverlässigkeit
Monitoring und Logging: Umfassendes Monitoring und Logging für Anwendungen und Systeme, um Performance-Probleme und Fehler frühzeitig zu erkennen.
Hohe Verfügbarkeit und Redundanz: Design für hohe Verfügbarkeit, z. B. durch Load Balancing und Failover-Mechanismen.
Leistungsoptimierung: Einsatz von Tools und Techniken zur Leistungsüberwachung und Optimierung der Anwendungen.

5. Benutzerfreundlichkeit und Zusammenarbeit
Integrierte Entwicklungsumgebungen (IDEs): Bereitstellung von benutzerfreundlichen IDEs mit Funktionen wie Debugging, Code-Vervollständigung und Integration in Versionskontrollsysteme.
Kollaborationsplattformen: Nutzung von Kollaborationswerkzeugen (z. B. Jira, Confluence, Slack) für die Zusammenarbeit und Kommunikation im Team.
Dokumentation: Gute Dokumentation für Anwendungen und Prozesse, um Wissenstransfer und Schulung zu erleichtern.

6. Kostenkontrolle
Lizenzmanagement: Effektives Management von Softwarelizenzen und Abonnements.
Ressourcenoptimierung: Einsatz von Ressourcenmanagement-Tools zur Optimierung der IT-Ressourcen und Kostenüberwachung.
Open-Source-Nutzung: Gezielter Einsatz von Open-Source-Technologien, wo sinnvoll, um Kosten zu senken und Abhängigkeiten zu minimieren.

7. Compliance und Auditierbarkeit
Richtlinien- und Regeltreue: Sicherstellen der Einhaltung von gesetzlichen und regulatorischen Anforderungen.
Audit-Logs und Rückverfolgbarkeit: Protokollierung aller Aktivitäten zur Nachverfolgung und Auditierbarkeit.

8. Anpassbarkeit und Integration
APIs und Schnittstellen: Bereitstellung von APIs und Integrationsmöglichkeiten für eine nahtlose Anbindung an andere Systeme.
Modularität: Modulare Architektur, die es ermöglicht, neue Komponenten einfach zu integrieren oder bestehende zu ersetzen.
Diese Anforderungen helfen dabei, eine robuste, sichere und effiziente IT-Anwendungs- und Entwicklungsumgebung aufzubauen, die den Anforderungen eines modernen Industrieunternehmens gerecht wird.

--------------

Und ich darf mir jetzt anschauen, inwieweit die Microsoft power platform das alles erfüllt...ich koch dann mal Kaffee...

[i_h]

Früher hatten wir festere Regeln, inzwischen bin ich davon abgekommen größere Regelwerke aufzusetzen.

Die Naming Convention ist so halbwegs vorgeschrieben (camelCase/PascalCase/snake_case), je nach Sprache. Wir weichen aber auch nicht wirklich von den etablierten Vorgaben ab, snake_case für C++ und Python, camelCase für Java. _-Prefix für (private) Membervariablen überall und get/set für Java Getter/Setter.

Am Ende sind die Regeln kein Ersatz für den Einsatz von Hirnmasse. Man kann unter Beachtung der Regeln gruseligen Code schreiben den niemand versteht, oder jemand hält sich zwar nicht ganz sauber an die Regeln produziert aber trotzdem guten Code.

Natürlich ist das ein Aspekt der von der Unternehmenskultur und der Anzahl der Mitarbeitenden abhängt. Je mehr Leute desto exakter müssen die Vorgaben üblicherweise ausfallen und um so mehr Aufwand muss man auch reinstecken sie zu kontrollieren.

Noch ein IMHO: Wer den Editor fest vorschreiben muss hat die Kontrolle über seinen Entwicklungsprozess verloren und befindet sich vermutlich bis zum Hals im Vendor-Lock-in.

[Anse]

Die Naming Convention ist so halbwegs vorgeschrieben (camelCase/PascalCase/snake_case), je nach Sprache.

Nur so aus Neugier, warum verschiedene Cases bei unterschiedlichen Sprachen? Von der Syntax sollte alle z.B. CamelCase erlauben. Mittlerweile bin ich vollständig zu CamelCase übergegangen, da es einfach schnell geht. Nur VBA will ja alles wieder anders haben....

Private Members bekommen bei mir immer ein _ davor.

[i_h]

Viele Sprachen bringen ja schon ihre eigene Konvention mit, Python z.B. in der PEP-8 (https://peps.python.org/pep-0008/) oder C++ über die stdlib. Klar kann man sich auch explizit entscheiden dem nicht zu folgen, in der PEP8 steht sogar direkt geschrieben, dass Konsistenz wichtiger ist als sich exakt an die Vorgaben zu halten. Haben wir früher auch so gemacht.

Am Ende fühlt sich der eigene Code im jeweiligen Sprachuniversum aber immer als Fremdkörper an wenn man stark von dem was etabliert ist abweicht. Es bringt auch nichts einen python-only Entwickler der neu hinzustößt auf camelCase zu zwingen, oder einen Java-only Entwickler auf snake_case, nur weil der, der die Regeln gemacht hat, z.B. mehr C++ als Java programmiert.

Außerdem sind die etablierten Konventionen IMHO auch mit den jeweiligen Sprachen und deren Syntax gewachsen und machen dort Sinn.
Java hat z.B. eine ziemlich einfache Syntax die von Methodenaufrufen geprägt ist. Dort erhöht camelCase die Lesbarkeit weil viele Informationen in den Methodennamen selbst codiert sind.
C++ hat eine sehr viel komplexere Syntax die von vielen Sonderzeichen geprägt ist. Dort macht snake_case Sinn weil man die Sonderzeichen dann besser wahrnimmt.
Python hat prinzipiell auch viele komplexe Konstrukte die sich bei snake_case besser erkennen lassen. (Generatoren, Lambdas, type annotations etc.)

Aber das ist nur meine Erfahrung dazu.