An der Stelle möchte ich Dich einfach einmal auf
https://clean-code-developer.de/ hinweisen. Da finden sich viele interessante Punkte, so man sich für Software Entwicklung interessiert und über die ersten Anfänge hinaus gekommen ist.
Und ein wichtiger Punkte ist da halt recht schnell schon
Mit dem roten Grad beginnt der Weg des Clean Code Developers. Ab hier gilt es, einen ersten Teil der Clean Code Developer Bausteine in die tägliche Arbeit einzubringen und immer wieder zu üben. Der rote Grad ist so gestaltet, dass jeder Entwickler hier mit minimalem Aufwand einsteigen kann...
clean-code-developer.de
Das Wort Optimierungen ist aber genau zu definieren, denn Software Entwickler optimieren ständig Code (hoffentlich)!
Es ist zu unterscheiden zwischen Optimierungen bezüglich Laufzeit und Refactorings. Man optimiert den Code auf Lesbarkeit. Da ist dann auch die Signatur von
@mrBrown wichtig mit dem Zitat von Kent Beck: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand.". Und das ist ein Bereich, in dem viele wirklich in die gleiche Kerbe schlagen. Uncle Bob (Robert C. Martin) bringt z.B. eine Regel, nach der jeder Checkin den Code lesbarer machen muss.
Aber Laufzeitoptimierungen werden nicht durchgeführt! Und wenn das doch notwendig ist, dann wird erst analysiert und dann entschieden, was wie optimiert werden kann. Das sind in der Regel keine kleinen Umstellungen. Die sind einfach nicht ausschlaggebend. Was bringt es, einen Faktor x zu optimieren? Selbst wenn es doppelt so schnell wird, wird es weiterhin Probleme haben. Denn es geht ja um Algorithmen, die generell ausgetauscht werden. Wenn Du etwas hast, das z.B. in O(n²) läuft, dann bringt eine Optimierung um einen konstanten Faktor nichts. Da muss man dann überlegen, was man optimieren kann. Dann klappt evtl. ein Zugriff in O(n)...
Was man aber auch von Optimierungen unterscheiden sollte:
Best Practices. Es gibt ein paar Dinge, die man als Best Practice ansehen kann. "Effective Java" wäre da ein Buch, das viele einzelne Punkte aufgreift und erläutert.
Und wenn ich z.B. eine List sehe, bei der auf beliebige Elemente zugegriffen wird, dann ändere ich die ggf. verwendete LinkedList zu einer ArrayList. Das ist eine Form der Optimierung. Das ist schwer, abzugrenzen. Das könnte man bezeichnen als: Behebung eines Fehlers. Aber ein wirklicher Fehler war es ja nicht, denn die Tests liefen durch. Und ich habe auch keinen Test hinzugefügt, der fehl geschlagen ist und den ich dann mit der Änderung zum laufen gebracht habe ...
Die Regel, keine Optimierungen zu machen, ist somit relativ schwer abzugrenzen. Aber es ist eine wichtige Regel, die man immer im Hinterkopf haben sollte.
Und man sollte immer geeignete Datentypen verwenden. Wenn das bei einem Datum ein String sein soll: Sei es drum. Aber das ist hoffentlich gekapselt in einer Klasse a.la. StringBasedDate oder so. Aber mit einem Datum rechnet man in der Regel doch regelmäßig, daher ist die geeignete Form eben nicht String. Gerade in der Datenbank möchte ich doch einiges machen können. Ich limitiere die Möglichkeiten, die ich in einer Datenbank nutzen kann.
In den C#-Foren hieße es schnell, daß bei den Gigabytes an Speicher und Gigahertz an Geschwindigkeit, die ein Rechner heutzutage hat, es keine Rolle spielt welchen Datentyp man für ein Datum verwendet und wie rum das ganze schneller verarbeitet wird.
Gerade das wundert mich etwas, denn C# war ja Windows basiert und da war der SQL Server führend. Und der bietet ja - was Datum/Zeit angeht - extrem viel. Die Aussage ist natürlich jetzt nicht 1:1 kopiert und auch der Context fehlt, aber das kann durchaus schlicht der Punkt sein: "Keine Optimierungen".
Generell stimme ich dem zu, aber man sollte die zur Verfügung stehenden Dinge kennen und diese dann auch einsetzen. Also sich überlegen: Was will ich überhaupt haben und machen?