Moderne Softwareentwicklung

[freimatz]

Da gibt es noch Firmen, die meinen mit Objektorientierung sei man modern.
Einige Schlagworte aus meiner Sicht nach Modernität sortiert:
- Maschinencode
- Assembler
- Hochsprache - Delphi
- Strukturierte Programmierung
- Objektorientierte Programmierung
- Unit-Tests
- Testdriven Programming
- Clean Code
- Dependency Injection
- MVVM u.ä.
- Domain Driven Design
- DevOps
Wo seid ihr gerade dran?
In meiner vorigen Firma gab es viele Klassen - nämlich die welche Delphi für jedes Fenster erzeugt hat
Wo ich jetzt bin hat man obige Themen schon alle zumindest mal gehört und auch angewendet.
Ich selber bin gerade dran an Feature Flags die bei DevOps eine grössere Rolle spielen.

[Neutral General]

Alles unter Objektorientierung sind quasi nur "optionale Addons" in meinen Augen.
Nicht alles macht unter allen Umständen Sinn und man sollte nicht einfach blind auf das aufspringen was grad "modern" ist.
Und aus eigener Erfahrung kann ich sagen dass es eine ganze Weile und Aufwand braucht um ein Projekt, dass bis auf die VCL nicht viel mit OOP zu tun hat zu modernisieren bzw. aufzuräumen.
Man muss unten anfangen und sich langsam und mühsam nach oben arbeiten.

[DasWolf]

Zitat von freimatz:

Einige Schlagworte aus meiner Sicht nach Modernität sortiert:

Auf- oder absteigend sortiert?

[Incocnito]

Assembler Funktionen (und auch Assembler-optimierte Funktionen) werden in der Firma hier (nicht nur von mir) "echt geiler Sch**ß" genannt!

Es kommt immer darauf an, was ich wo mache. "Selbst" Assambler kann an den richtigen Stellen "richtig" sein, meinst du nicht?

[hoika]

Hallo,
Dependency Injection mag ich persönlich nicht.

mov ah,4ch
int 21h

[dummzeuch]

Wir sind schon bei AI Blockchain angelangt.

[Stevie]

Einfach mal nach modern software development googlen - und die erste Handvoll Artikel lesen - z.B.
What is modern software development?

Dabei geht es weniger um die Details, ob ich assember oder hochabstrakten funktionalen Code schreibe, sondern den Prozess an sich.
Natürlich ist ein Punkt, ob man technisch noch auf der Höhe ist aber auch, ob man aktuelle und bewährte Methoden anwendet.

Und nicht, weil man ja ach so hip sein will mit agile, scrum und wadd nich alles, sondern, weil man qualitativ hochwertigen Code produzieren und mit geringstmöglichen Aufwand warten und erweitern will. Dazu gehört dann auch die ganze DevOps Geschichte wie CI (inklusive Tests). Aber auch so Dinge wie Versionsverwaltung, Issuetracker, Anforderungsmanagement, Codereviews etc

Man könnte auch sagen, desto mehr von Joels Fragen mit Ja beantwortet werden können, desto moderner ist man - und das ist dann erstmal eine ziemlich zeitlose Aussage, die nix mit aktuell gehypten technischen Dingen zu tun hat.

Um das an einem Extrem zu veranschaulichen, könnte man durchaus bei der Wartung einer Legacy Anwendung von anno tuck moderner sein, als wenn man die neusten Microservices mit AI und ML zusammenklöppelt.

[freimatz]

Hm, The Joel Test - danke gleich mal ausprobieren

1. Do you use source control? Ja
2. Can you make a build in one step? Was ist damit gemeint? Also wenn ich committe und pushe, dann läuft ein build an und sofern so eingeatellt kommt am ende ein setup raus.
3. Do you make daily builds? Nein, builds werden nur gemacht wenn sich auch was geändert hat. Also an dern Werktagen ziemlich sicher
4. Do you have a bug database? Ja
5. Do you fix bugs before writing new code? Nein. Unser Prozess sieht vor, dass man erst die aktuelle Story fertig macht. Dann kommen in der Regel Fehler schon dran. (Fehler die zu einer neuen Story gehören kommen natürlcih schon vorher dran.)
6. Do you have an up-to-date schedule? Keine Ahnung was das ist.
7. Do you have a spec? Ja
8. Do programmers have quiet working conditions? Einer ja, der Rest Nein
9. Do you use the best tools money can buy? Ich schreibe hier in einem Delphi-Forum, also Nein
10. Do you have testers? Ja
11. Do new candidates write code during their interview? Weiss ich nicht.
12. Do you do hallway usability testing? Nein. Und das ist gut so. Wenn mit "you" ich als Entwickler gemeint bin dann ist das nicht mein Job. Dafür gibts Requirement Engeneers.

Ja, selbst Assembler kann an den richtigen Stellen richtig sein. Ich bezweifle jedoch dass irgendjemand hier diese Stellen hat.
AI, Blockchain, gibt es da einen Verwendungszweck den unseren Kunden nutzt?

[Stevie]

Zitat von freimatz:

Do you make daily builds? Nein, builds werden nur gemacht wenn sich auch was geändert hat. Also an dern Werktagen ziemlich sicher

Naja, zu nem Daily Build kann ja noch mehr gehören, als am Ende ein Setup rausplumpsen zu lassen. Das geht von excessiven Integrationstests, die man bei einem adhoc build bei jedem commit evtl nicht laufen lassen möchte bis zu automatisiertem Installieren und UI Testing - so dass sich nicht jemand hinsetzen muss und schauen muss ob das ganze Standardzeugs noch funktioniert. Leider ein noch sehr stiefmütterlich behandeltes Gebiet.

Zitat von freimatz:

Do you do hallway usability testing? Nein. Und das ist gut so. Wenn mit "you" ich als Entwickler gemeint bin dann ist das nicht mein Job. Dafür gibts Requirement Engeneers.

Meiner Meinung nach geht es hier nicht nur um usability testing der Endanwendung oder UI sondern auch um die Verwendung von Code durch andere Entwickler - ich kann aus eigener Erfahrung sagen, dass es nicht selten so ist, dass man denkt man hätte den geilsten Scheiss gebastelt, der den Kollegen das Leben erleichtern wird und denen schauderts jedes mal, wenn sie irgendwas davon benutzen müssen.

[freimatz]

Danke für deine Erklärungen.

Zu "Do you make daily builds?" Immer noch Nein. Das sind bei uns nightlies
Bei Tag lässt man Tests nach Bedarf laufen.

Zu "hallway usability testing": habe ein bischen gegoogelt. Da ging es meistens um Endanwender. Bei uns sind die Anwender eh alle aus dem technischen Gebiet. Trotzdem halte ich unsere Software für die am Besten bedienbare am Markt.
Wegen "Verwendung von Code durch andere Entwickler" - da gibt es halt CodeReviews