Unverbindlich anfragen
Stelle eine unverbindliche Anfrage zur C# Programmierung: Schnell & einfach, oder detailliert! Nutze das Formular, um mir Dein Projekt näherzubringen – E-Mail, Projektname, Beschreibung & Budget sind Pflichtfelder.
Winforms Entwicklung
Als Urgestein und Experte im Bereich C# Programmierung gehören die Winforms (Windows Forms) unter anderem zu meinen essenziellen Kernkompetenzen. Seit vielen Jahren gehören die Windows Forms zum absoluten Standard der NET Softwareentwicklung.
WPF Entwicklung
Mit dem modernen Stand der Windows-Entwicklung lege ich einen meiner Schwerpunkte auf die Windows Presentation Foundation (kurz WPF). Diese ermöglicht grafisch völlig neue und schöne Anwendungen und stellt den heutigen Standard für neue Applikation dar.
Über mich
Mit über 12 Jahren an Erfahrung im Bereich C# Programmierung bezeichne ich mich als Experte. Ich verwende für meine Software stets gängige Programmier-Praktiken, da Clean Code für mich ein Muss ist.
Meine Expertise konnte ich bereits erfolgreich in verschiedenen Software-Projekten wie:
- Kundenverwaltungen
- Hardware-Steuerungen
- komplexen ERPs
- uvm.
und meinen Unterrichts-Stunden unter Beweis stellen. Dies umfasst meine bisherigen Festanstellungen und auch meine Arbeit als freiberuflicher C# Programmierer.
Je nach Anforderungen, Budget und Deadline füge ich meinen Projekten Kommentare, Tests & eine einfach zu verstehende Dokumentation hinzu. Diese kann sich dann an Anwender, Entwickler und / oder Vorgesetzte richten. Sprich mich hier gerne bei Bedarf an und wir schauen, in welchem Format und Umfang es Dir am besten passt.
Weiter unten findest Du mehr Informationen darüber, wie ich Software umsetze, jedoch wird es dabei allerdings ein wenig technisch. Ich habe versucht, so einfach und verständlich wie möglich zu bleiben, um Dir die Themen näherzubringen.
Häufige Fragen – FAQ
Wenn man erstmal eine tolle Software-Idee, oder einen Geistesblitz hat und dann umsetzen möchte, kommen einem vermutlich erstmal viele Fragen in den Kopf. Im folgenden Abschnitt gehe ich auf viele gängige Fragen ein.
Kurz und bündig
- Kleinere Projekte: Um die 500€
- Mittelgroße Projekt: Um die 1300€
- Große, komplexe Projekte: Mehrere tausend Euro
Ausschlaggebend als Käufer, ist in grober, erster Linie natürlich zuerst einmal der Preis, Welcher durch den potenziellen Verkäufer / Dienstleister aufgerufen wird. Hier kann man einerseits die fixen, stündlichen Kosten und des Weiteren gängige Paket-Preise beachten. Wie bekannt führen – vor allem in der Entwicklung von Software – mehrere Wege nach Rom, daher gibt es auch erhebliche Qualitätsunterschiede zwischen Entwicklern.
Hintergrund
So wie jeder andere Dienstleister, lassen sich auch Software-, bzw. C# Entwickler gängigerweise auf Stundenbasis entlohnen. Hierbei handelt es sich grundsätzlich um die "Stunden-Leistung + Dauer = Lohn"-Formel. Neben den auf Stundenlohn basierenden Preisen gibt es natürlich auch noch die Festpreis-Alternative. Dabei einigen sich Auftraggeber und Auftragnehmer bei einem Projekt, oder einen Bestandteil dessen auf einen festen Preis.
Beides hat Vor- und Nachteile
Beide Vorgehensweise haben – wie so oft im Leben – gewisse Vor- und Nachteile. Bezahle ich jemanden z. B. auf Stundenbasis, bin ich dadurch häufig flexibler und sorgloser, da ich hier schneller wechseln kann, falls notwendig. Ich habe dadurch häufig eine bessere Kostenkontrolle und kann Arbeiten, bzw. Aufgaben besser atomar einteilen.
Verwende ich als Kunde hingegen ein Festpreis-Paket, bin ich so auch erstmal vertraglich gebunden und habe einen festen, längeren Unternehmens-Partner. Hierbei ist auch wichtig, ob ich z. B. möchte, dass der Entwickler sich auf mein Projekt allein konzentriert und ich daher meist mehrere Stunden, Tage, Wochen auf einmal verplane.
Analog zu den erwähnten Arbeitsmodellen gibt es freilich auch noch diverse Misch-Varianten. Dort werden dann verschiedene Bestandteile, bzw. Aspekte aus den Arbeitsmodellen fließend kombiniert. Welche der genannten Vorgehensweisen nachher passen, erarbeitet man häufig gemeinsam, oder ist sich aus Erfahrung bereits über seine Präferenzen bewusst. Ich persönlich variiere die Vorgehensweisen primär anhand der jeweiligen Projekt-Größe.
Das Fazit
Ich selbst verorte mich als C# Entwickler eigentlich eher in einer bestimmten Herangehensweise. Für mich muss Programm-Code sauber geschrieben, bzw. programmiert sein, Software ist leider eben nicht immer gleich Software. Bei Unsicherheit sollte man nach Möglichkeit lieber erstmal mehr Budget einplanen, auch wenn dies vermeintlich weh tut. Damit kann man dann später gängigen Problemen vorbeugen – unerlässlich ist hier natürlich immer die Absprache zwischen Kunde und Programmierer.
Ein gutes, altes Sprichwort findet hier wahre Worte: "Wer billig kauft, kauft zweimal!". Besonders die Software-Branche wird von diversen Billig-Verkäufern geflutet, womit schon dem ein oder anderen "Günstig-Enthusiasten" das Genick gebrochen wurde. Wer sein Haus schließlich auf einem wackeligen Fundament baut, wird feststellen, wie schmerzhaft es ist, alles nochmal abreißen zu müssen, nur um das Fundament zu richten.
Meine Empfehlung
Für Projekte im eher kleineren Rahmen, sollte man mindestens 300-500 € als Budget vorausplanen und eine konkrete Vorstellung in Form von Zeichnungen und Ähnlichem mitgeben. Von Vorteil ist es natürlich auch, wenn man sich an vorherrschende Standards hält. Dabei spreche ich einerseits von geläufigen Oberflächen und andererseits über die Vermeidung von aufwändig animierten, oder komplexen Neu-Entwicklungen.
Große und vor allem komplexe Systeme können selbstverständlich auch an die mehreren tausend Euro kosten. Letztendlich sollte immer der Mehrwert im Fokus stehen: Wenn ich erst einmal Geld in die Hand nehmen muss, aber anschließend ein tolles Produkt habe, oder meiner Firma die Arbeit erleichtere, hat es sich schon gelohnt.
Wenn Du Dich im Zuge Deiner Planung auf die gängigen Fehler vorbereitest, hast Du das Potenzial einer erfolgreichen Umsetzung Deiner Software drastisch erhöht. Schaue Dir hier einige übliche Fehler an und versuche Diese nach Möglichkeit zu vermeiden.
Eine Idee ist erstmal nur das – Punkt!
Angelehnt an den obigen FAQ-Punkt, spielt die Zeit, die Du als Auftraggeber selbst in Deine Idee investierst, fast die größte Rolle. Häufig erlebe ich, dass die Projekte häufig gefühlte Nebensachen waren, was natürlich mehr oder weniger zum Scheitern verurteilt ist. Auch wenn mir dies als C# Entwickler bei erfolgender Entlohnung weniger wichtig sein könnte, entspricht dies nicht meinen Werten.
Wenn Du ein erfolgreiches Projekt umsetzen möchtest, musst Du neben der Erreichbarkeit natürlich auch eine gewisse Planung schon abgeschlossen haben. Gerne unterstütze ich Dich auch bei Deiner Planung in den mir möglichen Formen, falls gewünscht. Ein einfaches "Hau-Drauf" geht aber selten gut aus, daher gehe hier mit Bedacht vor.
"Es gibt doch schon alles"
Ein häufig verbreitetes, negatives Argument, wenn es um "neue" Software geht, ist: "Ach, es gibt doch sowieso schon alles". Auch wenn man vermutlich nicht mal eben den nächsten Facebook-Ableger aus dem Boden stampft, überlege Folgendes: War Facebook das erste soziale Netzwerk? War Tesla die erste Automarke? War Netflix der letzte Streamingdienst – ein ganz großes: Nein!
Die einzige Frage, die für Dich in der Kreativ-Situation relevant ist, ist doch: "Was möchte ich mit meiner Software erreichen / verbessern?". Diese Frage kann sich über viele Teilbereiche, wie z. B. Preisgestaltung, Laufzeiten, Performanz, Funktionalitäten und Co. erstrecken. Manchmal reicht es schon, sich Customer Stories anzuschauen, also was die Kunden an bestehenden Systemen z. B. bemängeln.
Alle noch so klug ausgearbeiteten Funktionen werden Dir natürlich auch nichts bringen, wenn Du einen wirklich essenziellen Punkt namens "Marketing" aus dem Fokus lässt. Hier kann ich Dir, wie Du oben im Formular sehen kannst, ebenfalls zur Seite stehen. Durch die Thematik Marketing kommen wir auch gleich zum nächsten gängigen Fehler.
Entwickler sind automatisch Marketing-Experten
Auch wenn Du in meinem speziellen Fall das Glück hast, auch einen Content-Creator mit Marketing-Erfahrungen an Deiner Seite zu haben, ist dies natürlich nicht der Regelfall. In erster Linie ist der Programmierer eben genau das: ein Programmierer. Klar haben wir aus der Informationstechnik auch diverse Tricks in anderen (Teil-) Bereichen auf Lager, aber dies ist freilich keine zwangsweise vorhandene Kernkompetenz.
Plane also analog zur Größe Deines Projektes alle entsprechend erforderlichen Parteien, bzw. Ressourcen ein. Neben dem in erster Linie relevanten Programmierer, benötigst Du in den meisten Fällen noch: einen rechtskundigen Fachanwalt, einen Steuer-Fachmann und einen Werbe-Experten. Stelle Dir ebenso die (eigentlich freudige) Frage, wer eventuelle Support-Anfragen beantwortet, wenn erste Leute Deine Software verwenden. Welche Arbeits- und Reaktionszeiten erwartest Du von Deinem Programmierer?
Alles wie "von der Stange" aus dem Supermarkt
Hier sprechen wir über einen leider häufig vorkommenden Irrtum von kreativen Köpfen (ohne Software-Erfahrung). Viele "Innovatoren" glauben, dass es alles Mögliche schon irgendwie "ready to use" geben würde. Oft habe ich Sätze wie "Ja das kauft man sich dann einfach ein und zack fertig" gehört.
Sicherlich gibt es mit den vielen verstrichenen Jahren schon einiges, was man fertig verwenden kann, allerdings ist Vorsicht geboten! Diese Werkzeuge sind zuallererst mal meist auf spezielle Systeme (Kontexte, Umgebungen) getrimmt. Es fängt schon bei den verwendeten Technologien, deren Be- und Einschränkungen an und geht weiter über die verschiedenen Hersteller. Eine wichtige Rolle spielt hierbei auch die Performanz, da ein dynamisches und komplexes System eben auch sogenannten "Overhead" mit sich bringt.
Zum Glück gibt es für uns Entwickler und damit auch für die Endkunden die Möglichkeiten, nicht alles von neu bauen zu müssen. Dabei handelt es sich seitens der Programmierung meistens um gewisse Infrastruktur-Tools, allerdings müsste ich zur weiteren Erläuterung zu tief in die Programmierung abtauchen. Die gemeinten Tools erleichtern den Entwicklern das Erstellen der Anwendung in Form von Bestandteilen der Oberflächen, oder einzelnen "Mini-Tools".
Einen einfachen Vergleich kann ich hier schnell anbieten: Denke einfach mal an einen schönen Garten. Du wirst den Rasen vermutlich auch nicht gerade mit der Nagelschere, sondern mit einer erfundenen, erbauten und weiterverkauften Maschine namens Rasenmäher trimmen, oder? Ebenso können auch Entwickler auf bestehende Werkzeuge, die den Tag versüßen, zurückgreifen.
Aus rechtlicher Sicht passt dann alles, oder nicht?
Wir Du hier vermutlich schon am Titel erkennen kannst, soll hier ein wenig Ironie glänzen. Diese bringt es aber meiner Ansicht nach direkt auf den Punkt: Ein Programmierer ist eben kein Anwalt. Welche Software was, wie können darf, oder eben muss, muss geplant und abgesegnet werden. Der Entwickler hilft bei der technischen Umsetzung und berät auf dieser Ebene, allerdings ist er eben kein rechtlicher Fachmann. Sicherlich werden viele Programmierer hier auch Erfahrungen aus der Vergangenheit einbringen können, allerdings bilden Diese sich im Gegensatz zu einem Anwalt diesbezüglich nicht aktiv fort.
Besonders in Zeiten des Datenschutzes und des internationalen Rechts ist hier besondere Vorsicht geboten. Wer hier am falschen Ende spart, endet nachher mit größerem Minus, als die umgesetzte Software tatsächlich eingebracht hat.
Einfach gesagt: Reine Regelungssache!
Grundsätzlich greift auch hier das Urheberrecht, weshalb der Entwickler als Urheber die Rechte erhält. Nicht umsonst habe ich auch diesbezüglich einen Punkt in das Anfrage-Formular aufgenommen, wo Du mir Deine Wünsche diesbezüglich mitteilen kannst. So oder so sollte man diesen Aspekt im Optimalfall schriftlich festhalten.
Wie so häufig muss man auch hier die Sachlage im Verhältnis betrachten, da z. B. das Nutzungsrecht an einer kleinen Hilfs-Anwendung für Deine eigene Firma sicherlich günstiger, als ein zigfach weiterverkaufbares Produkt ist. Dabei darf man dem Entwickler auch nicht zwangsweise eine Art Willkür vorwerfen. Dieser muss schließlich auch eventuelle Lizenzen beachten und je nach Anwendungszweck einkaufen.
Fazit
Letztendlich ist es also erstmal alles eine schriftliche Regelungssache zwischen Entwickler und Auftraggeber. Verschiedene Anwendungszwecke erfordern mehr, oder weniger Klärungs- und Kostenbedarf.
Achtung: Keine Rechtsberatung!
Information ist das A und O
Je mehr Details ich als Entwickler verwerten kann, desto mehr Informationen kann ich auch dementsprechend in die Unterstützung, bzw. Planung fließen lassen. So habe ich dann auch die Möglichkeit, verschiedene Aspekte zu berücksichtigen, Welche andernfalls später eventuell kritische Folgen hätten.
Daher meine Empfehlung
Auch wenn die Verführung groß ist, das obige Anfrage-Formular wirklich nur "schnell schnell" auszufüllen. Ich empfehle Dir dringlich und zu Deiner eigenen Sicherheit alles gewissenhaft auszufüllen. Auch wenn es vermutlich meiner Conversion-Rate nicht guttut, lass' Dir zur Not mehrere Tage Zeit.
Du kannst Dein Projekt so auch selbst noch einmal von unterschiedlichen Aspekten betrachten und mir letztendlich auch meine Arbeit (Dich optimal zu unterstützen) erleichtern. Dies wird auch den Planungs-Prozess beschleunigen und Mehraufwand (zumindest Unnötigen) häufig vermeiden, oder wenigstens reduzieren.
Genaueres
Definiere für Dich die einzelnen Nutzerrollen im (und außerhalb) des Programms. Gibt es neben den aufgeführten Rollen ggf. wesentlich komplexer geschachtelte Berechtigungen? Sollen Diese Berechtigungen verwaltet und zu neuen Rollen erschlossen werden, oder sind Diese fix?
Welche visuellen, Oberflächen soll Dein Programm haben? Wie wird zu diesen Views navigiert: Eine gängige Seitennavigation, oder soll es eher eine Windows 8 ähnliche Kachel-Navigation sein?
Sehr einfach und prompt – so viel wie möglich
Dein Software-Projekt steht und fällt natürlich mit der existierenden Wurzel des Ganzen – Dir! Auch wenn die Umsetzung der Software aus technischer Sicht mein Haupt-Aspekt ist, bist Du natürlich die Wurzel des Ganzen. Testest Du von mir bereitgestellte (und eventuell "geforderte") Tests auch wirklich mit vollem Einsatz? Oder soll ich dies vollständig im Alleingang, alternative auch mit automatisierten Tests erledigen?
Hast Du die Dir relevanten Aspekte klar und deutlich formuliert und auch so an mich weitergetragen? Das sind natürlich Fragen, Welche unter anderem zu einem erfolgreichen Projekt beitragen. Die regelmäßige und vor allem offene Kommunikation zwischen Kunde und Entwickler (-Team) ist essenziell!
Besonders schwierig wird es aus eigener Erfahrung, wenn der Kunde leider kaum Zeit aufbringen kann. Eine kreative Idee, also ein eventuell komplexes System zu erschaffen, bedarf Zeit. Extrem schwierig wird es für mich als Programmierer, wenn ich den Kunden lange nicht erreiche und die Antwortzeiten schlecht sind.
Anders als von vielen Ottonormalverbrauchern gedacht, gibt es in der Software-Welt immense Unterschiede, im Bereich Qualität und Herangehensweisen. Häufig werden "Schnell, schnell"-Aufträge wirklich einfach nur "mal eben" erledigt. In solchen Projekten fehlt es häufig an Weitsicht und richtiger Planung. Besonders schlimm ist es allerdings, wenn die Qualitätsunterschiede im Bereich der Sicherheit liegen, auch dies sah ich zu oft.
Aus der Vergangenheit lernen
Wie oft habe ich es selbst erlebt, dass Kunden "mal eben" haben wollten und – wer bin ich, es Ihnen abzusprechen – nachher auf die Nase fielen. Ich kann hier lediglich meinen Job gewissenhaft erledigen und insoweit erwünscht beraten. Wenn der Kunde es dann z. B. aus Kostengründen ablehnt, bin leider auch ich machtlos.
An dieser Stelle habe ich auch ein konkretes Beispiel: Es gab da z. B. diesen Großkunden, Welcher ein wirklich großes und komplexes System programmiert haben wollte. Trotz meiner Beratung wurden viele Vorschläge und wichtige Hinweise abgelehnt, bzw. ignoriert. Nach 12–14 Wochen durchgehender Arbeit kam dann das böse Erwachen, denn wir sprachen hier von mehreren tausend Nutzern.
Der Kunde hatte weitere Wünsche, Welche im damaligen Stand schlichtweg nicht ohne großen Aufwand umsetzbar waren. Um es grob anzuschneiden, es ging um Berechtigungen, Welche komplex verwaltet werden sollten. Ich betone hier noch einmal das Beispiel mit dem Fundament eines Hauses: Software kann natürlich immer erweitert werden und verändert werden, klar, aber die Kosten, die Zeit und viele andere Dinge spielen dabei unweigerlich eine immense Rolle.
Man kann in der Softwareentwicklung – ob nun bei C# NET, oder bei anderen Programmiersprachen – nicht immer alles von vorne rein bedenken, das stimmt natürlich, aber... Ich habe es schon zu oft erlebt, dass gewisse grundlegende Dinge häufig einfach als "das machen wir später" (trotz Warnung) abgetan wurden. Wer alles immer fleißig nach hinten verlagert, bekommt dies freilich irgendwann auf den Tisch gesetzt.
Durch Verfolgung von diversen Planungs-Tools
Sobald sich die beiden Parteien geeinigt haben und losprogrammiert wird, möchte der Kunde natürlich auch wissen, wo sich das Projekt hier und da befindet. Wie so oft spielt auch hier wieder die Größe des Projekts eine Rolle. Mittelgroße bis große Projekte werden meist mit einem Tool für das Aufgaben-Management begleitet. Dort können die involvierten Parteien hereinschauen und erledigte Aufgaben abhaken.
Ebenfalls dienen solche Programme auch als Anlaufstelle für fehlerbasiertes Reporting, also wenn mal etwas nicht so klappt, wie es soll. Man sollte dabei allerdings kontextuell unterscheiden, ob es sich um etwas Separates, oder um den tatsächlich gemeinten Teil handelt. Ansonsten kann dies schnell zur Verwirrung und zur Verzögerung der einzelnen Aufgaben führen.
Durch Staging-Systeme, etc.
Neben der Verfolgung von Screenshots und der erledigten Aufgaben, gibt es noch Optionen wie "Staging"-Systeme. Diese sind dann spezielle Umgebungen, oder separate Veröffentlichungen der eigentlichen Software, Welche primär zum Anschauen und Testen da sind.
In der Web-Entwicklung hat man dann meistens eine separate Domain, Datenbank, etc. unter "staging.meinsystem.de". Bei der C# Programmierung würde man hier zumindest ähnlich, also mit unterschiedlichen Veröffentlichungen verfahren. Dies geht meist Hand in Hand mit dem Quellcodeverwaltungs-System – hier sind wir bei einem weiteren Punkt.
Lokal auf dem Entwickler-PC
Legen wir zuerst mit der wohl schlechtesten Variante los und wie es dennoch von vielen Entwicklern getan wird. Auch hier werden wir wieder die qualitativ unterschiedlichen Herangehensweisen von diversen Programmierern feststellen.
Einige Programmierer "lagern" den geschriebenen Quellcode trotz moderner Quellcodeverwaltungs-Systeme immer noch auf ihrem PC. Dies ist nicht nur im meist gedachten Fall fatal, also dem Ableben von diverser Hardware. Allgemein ist diese Vorgehensweise völlig veraltet, unflexibel und ein Graus, wenn es um die Arbeit im Team geht.
Was ist z. B., wenn Du als Auftraggeber eventuell noch einen zweiten oder dritten Programmierer beauftragst. Diese sollten sich im Optimalfall natürlich absprechen und gemeinsam am Projekt arbeiten können. Wenn der Quellcode allerdings nur auf einem einzigen PC liegt, wird es mehr als schwierig.
In Quellcodeverwaltungs-Systemen
Hiermit wären wir dann bei der modernen und kontrastreichen Alternative zum obigen Beispiel angelangt. Neben vielen essenziellen Funktionen, wie das gemeinsame Arbeiten an Projekten, bieten diese Systeme mehr. Allerdings würde das natürlich an dieser Stelle den Rahmen sprengen.
Final kann man also festhalten, dass der Quellcode sich im besten – und eigentlich normal-modernen Fall – in einem passenden Verwaltungssystem befinden sollte. Dort kann er zur Not völlig unabhängig vom Entwickler-PC verwaltet und eingesehen werden.
Deine Software
in guten Händen. Greife auf viele Jahre an Erfahrungen zurück und erarbeite Dein Wunsch-Projekt Schritt für Schritt – gemeinsam.
reaktiv
Ein effizienter, kommunikativer Austausch mit Kunden hat höchste Priorität.
erfahren
Mehr als 12 Jahre Erfahrung im Bereich C# Programmierung sprechen für sich.
schnell
Bei der Umsetzungs-Geschwindigkeit habe ich immer ein Ass im Ärmel.
Kundenmeinungen
Hier kannst Du nachlesen, was meine Kunden über mich und meine Arbeit sagen – mehr findest Du in meinem Unternehmensprofil auf Google.
Meine Software ist SOLID
Eine SOLID(e) C# Programmierung
Wenn man in der C# Programmierung, bzw. in der Entwicklung allgemein von SOLID spricht, darf man dies nicht wie im normalen Sprachgebrauch mit einer Art Aggregatzustand verwechseln. Das Akronym SOLID ist in der objektorientierten Programmierung eine Zusammensetzung mehrerer Prinzipien für die Umsetzung von Applikationen. Jeder Buchstabe steht hier letztendlich für ein eigenes Prinzip, Welches man bei der Entwicklung von Software beachten "sollte".
Die Berücksichtigung der angepriesenen Prinzipien sorgt durch verschiedene Aspekte für "saubere(re)" Software. In erster Linie ist das so gesehen nur ein Kontaktpunkt für Entwickler, da ein Endkunde den Code schließlich häufig nicht sieht, bzw. Ihn in den meisten Fällen nicht versteht – wie auch. Ein kleiner, selbstständiger Dachdeckermeister, Welcher für seine Firma beauftragt, wird hier weniger den Code anfassen.
Eine outsourcende große Firma hingegen, wird den Code aller Wahrscheinlichkeit nach ansehen und auch ggf. mit Partnern, oder Mitarbeitern reviewen. Hier spielen –wie man sieht – wieder einmal verschiedene Aspekte, wie z. B. die Unternehmensgröße eine Rolle. Ich würde allerdings sagen, dass 90 % der kleineren Kunden den Code nicht ansehen.
Schnell, schnell abrechnen – nicht gut
Viele Entwickler arbeiten daher auch einfach nach dem Motto: Fertig ist fertig, der Kunde merkt's nicht, Lohn abrechnen. Die fatalen Auswirkungen – besonders bei großen Anwendungen – werden dann später bekannt und äußerst schmerzhaft. Nicht selten wird die Weiterentwicklung ein absoluter Mehraufwand und dadurch ein finanzieller Graus. Verstehe mich allerdings bitte nicht falsch, manchmal gibt es das Budget des Kunden auch schlichtweg nicht her.
Es ist schließlich auch als Softwareentwickler in der Hinsicht nicht anders, als z. B. in jedem anderen Gewerbe. Auch wenn C# Entwickler (in diesem Fall) eigentlich immer bestrebt sind, die möglichst sauberste Software zu liefern, gibt es schlichtweg nicht immer die Möglichkeit dazu. Man muss das gegebene Budget gegen den Aufwand abwägen und manchmal einfach machen. In erster Linie ist man ja auch bestrebt, dem Kunden die best möglichste Leistung zum Preis zu bieten.
Anders als von vielen Ottonormalverbrauchern vielleicht gedacht, kann Software wirklich auf zig Arten hergestellt werden. Dies kommuniziere ich auch standardmäßig in meinen Customer Interviews, wenn es an erste Gespräche geht. Größeren Unternehmen ist dies häufig auch klar, bzw. dort sieht die Budget-Planung anders aus, aber besonders kleine Firmen schnüren häufig jeden Euro.
SOLID: Achtung – jetzt wird es technisch
Bei der sauberen Programmierung von Software gelten die SOLID-Prinzipien als besonders wichtig, bzw. als eine Art Standard unter erfahrenen Softwareentwicklern. Gerne möchte ich kurz die Oberfläche der SOLID-Prinzipien anreißen, um Diese für Dich als potenziellen Kunden verständlich zu machen.
Das Single Responsibility Principle – 'S'
Der erste Bestandteil der SOLID-Prinzipien ist das 'S', also das sogenannte "Single Responsibility"-Prinzip. Man spricht hier wie der Name schon andeutet davon, dass gewisse Werkzeuge (um es einfach auszudrücken) innerhalb der Software nur eine (einzige) Aufgabe haben sollten. Wie Du Dir vorstellen kannst, wird auch Software aus einzelnen Bestandteilen zusammengebaut, Welche teils getrennt geplant, entwickelt und umgesetzt werden.
Wie immer im Leben wird es schwer, wenn eine Person (oder ein Bestandteil der Software in unserem Fall) zu viel auf einmal tut. Man verliert dadurch schnell den Überblick und ist einfach "überlastet". Ebenso fällt es damit auf Applikations-Ebene schwer, die erstellten Funktionalitäten sinnvoll und getrennt zu testen. Nur durch sinnvolle Trennung von anfallenden Aufgaben haben wir aber die Möglichkeit, nachher alles zu einem funktionierenden Großen und Ganzen zusammenzufügen.
Das Open Closed Principle – 'O'
Einfach gesagt ist das Open Closed Principle letztendlich die Aussage, dass Programm-Bestandteile offen für Erweiterung, jedoch geschlossen für Veränderungen sein sollten. Das hilft dabei, dass schon bestehende Bestandteile, Welche bereits erfolgreich getestet wurden, nicht mehr angefasst werden müssen. Somit verhindert man nach Möglichkeit, die bestehenden Teile erneut zu verändern und somit unnötige Fehler zu produzieren.
Neben der potenziellen Fehler-Gefahr, umgeht man so natürlich auch einiges an Mehr-Arbeit. Wirklich einfach erklärt, kannst Du Dir hier ggf. ein Objekt namens "Person" vorstellen, Welche einen Vornamen und einen Nachnamen hat. Ein Chef hat diese sogenannten Eigenschaften ebenfalls, allerdings kann der Chef z. B. Anweisungen erteilen. Das Personen "Objekt" bleibt wie es ist und ein weiteres Chef-Objekt kann dann eben mehr – ohne Vorheriges anzufassen.
Buchstabe 'L' – Das Liskov substitution principle
Das Liskovsches Substitutionsprinzip kann man eigentlich relativ gut anhand eines Vogel-Beispiels erklären, doch sofort mehr dazu. In der Programmierung spricht man häufig von Vererbung, wobei man in diesem Vogel-Beispiel sagen könnte: Es gibt Vögel, bzw. Singular Vogel – Punkt. Eine Ente, könnte durch einen Vogel repräsentiert werden, da eine Ente nun einmal ein Vogel ist. Soweit so gut, allerdings kommt nun der Haken im Liskovschen Substitutionsprinzip.
Es sagt letzten Endes aus, dass ich immer dort, wo ich einen Vogel erwarte (Welcher fliegen kann), auch erwarte, dass davon abstammende "Objekte" fliegen können. Wenn man dann die angesprochene Vererbung seitens des Codes umsetzt, kann man also sagen: Der Strauß ist ein Vogel, also erbt er all das, was ein Vogel nun mal kann. Leider haben wir hier das Problem, dass der Strauß nicht fliegen kann.
Wir erwarten also z. B. Vögel in unserer Software (abstrakt gesprochen) und bekommen einen Strauß, Welcher nicht fliegen kann. Dort gegen rebelliert das 'L' in SOLID. Um noch tiefer zu gehen, müsste ich hier noch tiefer in die Programmierung selbst gehen. Ich denke, das würde hier den Rahmen sprengen.
Der Buchstabe 'I' – Das Interface Segregation Principle
Hierbei handelt es sich um ein Prinzip, Welches sogenannte Schnittstellen (Interfaces in der Entwicklung) auf Ihre Basis reduziert. Das geschieht, um zu große Schnittstellen zu vermeiden und Sie wirklich auf essenzielle, aufteilbare Bereiche zu fokussieren. Man verzichtet auf Dinge, die ein Objekt nicht benötigt, so bleiben die Schnittstellen: einfach, logisch und separiert.
Eine "ILogger"-Schnittstelle sollte somit nur eins können: loggen/protokollieren, nicht aber noch gleichzeitig andere Dinge erledigen. Man könnte ggf. andernfalls in die Versuchung kommen auch "IFileWriter", o. Ä. mit der Logger-Schnittstelle zu vermischen.
Zum Schluss: 'D' – Das Dependency Inversion Principle
Das letzte Prinzip in SOLID, allerdings auf gar keinen Fall das Unwichtigste, ist das Dependency Inversion Principle. Besonders Anfänger in der C# Programmierung erschaffen sogenannte harte Abhängigkeiten zwischen Objekten. Während Sie arbeiten, erstellen Sie (auch hier wieder vereinfacht gesagt) Objekte, Welche feste andere Objekte benötigen.
Nehmen wir als Beispiel unseren Logger aus dem vorherigen Prinzip noch einmal auf. Man könnte als unerfahrener Programmierer in Versuchung kommen, einen Server z. B. so zu programmieren, dass Dieser immer in eine lokale Textdatei loggt. Auch wenn dies funktioniert und schnell fest gebaut ist, ist es nicht die tollste, oder flexibelste Methode.
Wenn wir die grundsätzliche Aussage hier betrachten, fällt uns auf, dass "der" Server (irgend-) einen Logger braucht. Nun können wir die Anwendung so intelligent gestalten, dass dem Server der letztendliche Logger egal ist, Hauptsache ist, dass er überhaupt einen Logger bekommt. Dieser könnte stattdessen auch ein CSV, XML, oder ähnlicher Logger sein. So haben wir die direkte Beziehung zwischen Server und Textdatei-Logger gebrochen und unsere Anwendung flexibel und erweiterbar gestaltet.
Sicherheit
Zu einer tollen visuellen Oberfläche – der sogenannten GUI (graphical user interface) – gehört nicht zuletzt die richtige Steuerung von Aktionen. Nicht jeder sollte schließlich in der Lage sein, Kundendaten einzusehen, Rechnungsdaten bearbeiten, oder gar löschen zu können.
Man sollte diese Aspekte also keinesfalls bei der Planung und Umsetzung der eigenen C# Software aus den Augen lassen. Erfahrene .NET Entwickler sollten hier stets mit Rat und Tat zur Seite stehen und aus vorherigen Projekten gewinnen. Teile mir Deine Fragen, Bedenken und Anregungen also gerne bei Deiner Anfrage mit, dann können wir gemeinsam an der optimalen Lösung für Dich arbeiten.
Schauen wir uns im nächsten Schritt einmal an, welche Bereiche bei einer korrekt ausgeführten Zugriffskontrolle zu tragen kommen. Anders als zumeist gedacht, ist es (leider) nicht nur mit simplen Abfragen, bzw. Anweisungen getan. Grob gesagt treffen wir bei der korrekten Zugriffskontrolle innerhalb einer Software auf 3 verschiedene, gleich folgende Bereiche.
Authentisierung
Der erste Bereich, mit dem wir in Berührung kommen, nennt sich in der Fachsprache "Authentisierung". An sich kennen wir Diesen bereits aus verschiedenen Situationen aus dem Alltag. In dem Moment, als wir z. B. in unserer Jugendzeit unseren Ausweis an der Kasse vorgezeigt haben, haben wir uns damit authentisiert. Wir sagten mit dem Ausweis praktisch aus, wer wir zu sein schienen, wobei hier die Betonung auf "Anschein/schienen" liegt.
Letztendlich können wir ja auch einen Ausweis vorzeigen, Welcher natürlich auch Fehler aufweisen könnte, oder im Extremst-Fall gefälscht ist. Damit kommen wir dann zum gleich nächsten Punkt, Welcher sich mit dem nachfolgenden wichtigen Schritt gleich nach der Authentisierung beschäftigt.
Authentifizierung
Die Authentifizierung prüft im Vergleich zur Authentisierung die Behauptungen des jeweiligen "Ausweises". Wir prüfen den Ausweis also anhand unserer Möglichkeiten auf Echtheit und können so garantieren, dass der Ausweis echt und von der überreichenden Person ist. Dabei könnten wir uns als eine Art Behörde, oder Prüfgerät fühlen, Welches die Echtheit nachweist.
Dies können wir dann in unterschiedlichen Fällen selbstverständlich auch unterschiedlich verarbeiten. Ein Ausweis hat z. B. gewisse Merkmale, Welche auch wir Menschen erkennen. Weitere Merkmale können ggf. nur durch gewisse Maschinen erkannt werden. Noch andere Geräte, wie einen Kartenscanner, können wir nur schwer mit unserem bloßen Auge nachahmen.
Autorisierung
Der letzte und ebenso wichtige Bestandteil der Zugriffskontrolle ist die finale Autorisierung. In diesem Schritt haben wir also schon die Kenntnis über die bestätigte "Person" und können nun entscheiden: Darf diese Person nun passieren, also die Aktion ausführen, oder eben nicht.
Natürlich waren diese Beispiele jetzt sehr rudimentär und es wurden auch keine Themen wie Persistenz (also Speicherung) besprochen, allerdings sollte dies für einen kleinen Einblick reichen. In der heutigen, modernen Zeit, gibt es durch die ständige Weiterentwicklung der Technologien auch unterschiedliche Möglichkeiten, die obigen Schritte durchzuführen. Ich denke allerdings, dass dies den Rahmen sprengen würde, weshalb wir Facebook, Google, OAuth und Co. erstmal auslassen.
Berechtigungen & Rollen
Oben hatte ich schon einmal kurz den Punkt Rollen angesprochen, dort war etwa von z. B. Administratoren, dem Chef oder auch Praktikanten die Rede. In erster Linie ist natürlich schon klar, dass ein Praktikant nicht unbedingt die gleichen Möglichkeiten im Programm haben sollte, wie der Chef. Damit dies funktioniert, muss hier eine Art Autorisierungs-System innerhalb des Programms realisiert werden.
Dieses Sub-System innerhalb der C# Software könnte die Zugriffssteuerung der einzelnen Ansichten (Masken) regeln. Ebenso könnte es für gewisse Knöpfe zuständig sein, Welche nur sichtbar, oder klickbar sein sollten, falls der angemeldete Nutzer über die notwendigen Berechtigung verfügt. Auch hier spielt wieder einmal die Planung der Software eine große Rolle, da eine spätere Umstrukturierung eine immense Kosten-Rakete sein könnte.
