Whiz-zarD

Nein, eben nicht: http://www.focus.de/finanzen/karriere/arbeitsrecht/urteilsspruch-zur-mehrarbeit-klauseln-zu-ueberstunden-sind-oft-unwirksam_aid_976632.html http://karrierebibel.de/ueberstunden/ (Im Abschnitt: "Arbeitsrecht: Sind Überstunden mit dem Gehalt abgegolten?") http://www.finanztip.de/arbeitsvertrag/arbeitsgesetz-ueberstunden/

Das ist rechtlich gar nicht erlaubt. Es ist nur erlaubt, wenn im Vertrag eine explizite Anzahl an Überstunden steht, die damit abgegolten sind. Wenn nicht, ist der Vertrag nicht rechtens.

Mal anders gefragt: Weißt du was Arrays sind?

Weiterbildung muss nicht gleich mit einer Prüfung enden. z.B. ein Pluralsight-Account würde für den Anfang auch schon reichen, um sich weiterbilden zu können. Das ist eine Webcast-Plattform für IT-Berufe, wo Trainer Videos zu bestimmten Themen hochladen und die Videos sind durchweg sehr lehrreich. Selbst da kann man schon sehr viel über neue Techniken lernen. Ich glaub inzwischen bieten sie auch schon diverse Prüfungen an. Auch gibt es diverse Trainer, die man in seine Firma holen kann, die dann für 2 bis 3 Tage die Mitarbeiter schult.

Bei meiner 50 MBit/s-Leitung dauert es 2 Sekunden und dennoch braucht die Webseite beim initialen Aufbau für das erste Byte 12 Sekunden. Da sind die Bilder erst mal irrelevant. Es wird Joomla verwendet. Von daher denke ich schon, dass die Abfragen schon optimiert worden sind.

Ich würde vielleicht mal Strato fragen. Es dauert 12 Sekunden, bis man das erste Byte der Webseite bekommt. Ich kann nicht sagen, wo das Problem liegt. Das müsste man jetzt auf dem Server analyiseren. Das kann sehr viel sein. z.B. Probleme mit der Datenbankverbindung. Eigenartig ist, dass es nur beim initialen Aufbau der Webseite ist. Beim Initialen Aufbau der Webseite sehen so die Zeiten aus: Beim zweiten Aufrufen: Wenn man ein Root-Zugriff und auch schon keine Analysetools hat, dann sollte Strato dies mal anschauen.

Und nun stelle dir mal vor, dass der Rechner, an dem du sitzt, überhaupt kein Excel verfügt, du aber trotzdem eine Excel-Datei erstellen möchtest. Angenommen, du arbeitest an einer Client-Server-Software und der Server soll die Excel-Datei erstellen. Dann muss auf dem Server Excel installiert sein und genau das wird von Microsoft nicht empfohlen, da Excel ein interaktives Tool ist und ggf. Dialoge aufpoppen können, auf die der Server nicht reagiert, da die Reaktion vom Nutzer erwartet wird. Ich habe mal an so einer Architektur gearbeitet (sie stammte nicht von mir). Es sollte eine Excel-Datei geladen und geändert werden, die aber beim Öffnen ein Makro startet, welches ein Willkommensdialog öffnet. Wir mussten also noch über die COM-Schnittstelle ein Entertasten-Druck mitschicken, damit der Dialog geschlossen wird, damit wir die Datei bearbeiten konnten... Also Entweder du ignorierst die Warnung von Microsoft und installierst Excel auf dem Server (und da zeigen schon viele Kunden dir den Vogel) oder die ganze Logik zur Erstellung der Excel-Datei muss im Client implementiert werden. Beides will man aber eigentlich nicht, da man sehr viele Gefahren eingeht und ich spreche aus Erfahrung: Das sind VIELE Gefahren und bei jeder neuen Excel-Version kommen weitere hinzu. Die Software soll also bestmöglich unabhängig von Excel Excel-Dateien erstellen können. Also bleibt dir da nichts anderes übrig, als eine Bibliothek zu verwenden. Das Office Open SDK von Microsoft geht dafür auch, aber ich finde es sehr komplex und nicht gerade Trivial. Excel kann ja weiterhin geöffnet werden, aber erst nachdem die Datei erstellt und tatsächlich Excel installiert wurde. Alles andere ist unklug. Es kann ja auch gut sein, dass der Rechner, vor dem du gerade sitzt nur einen Excel Viewer installiert hat. Excel-Dateien kannst du dir zwar über den Rechner anschauen aber nicht erstellen.

gelöscht

Das ist zu einfach gedacht. Die derzeitige Situation war ein schleichender Prozess, der über Generationen ging und die heutige Generation setzt sogar noch eine Schippe drauf, indem eine Kultur entsteht, die sogar ich mit 32 Jahren sehr besorgniserregend finde. Immer mehr Startup-Unternehmen wollen doch sowas wie eine Gated Community aufbauen. Der Arbeitnehmer soll sich am Arbeitsplatz wohlfühlen, sodass er gar nicht mehr in Erwägung zieht, ein privates Leben zu führen, denn die Arbeit ist sein Leben. So etwas wäre sogar für die alte Generation ein Alptraum. Siehe dir die Hauptzentrale von Facebook an. Das ist eine Kleinstadt nur für die Mitarbeiter. Die Mitarbeiter sollen gar nicht mehr nach Hause fahren. Sie sollen auf der Arbeit leben und wer das Spiel heute nicht mitspielt, kann doch gleich gehen. Siehe Goodgames vs. Betriebsrat. Das ist ein psychologisches Spiel, was hier betrieben wird und die meisten finden es auch noch toll. Wer also in einem jungen Unternehmen arbeitet und es steht ein Raum mit mehreren Tischfußballtischen, kostenlose Softdrinks und Bier, sollte sich mal fragen, wieso der Arbeitgeber so etwas bereitstellt. Eigentlich macht die jüngere Generation auch wieder alles kaputt, was die alte Generation aufgebaut hat. In den 80er Jahren sind Gewerkschaften auf die Straße gegangen und haben für eine 35 Stundenwoche demonstriert und sie haben diese auch bekommen. Heute sind wir doch wieder bei 40+ Stunden pro Woche. Nur so als kleines Beispiel. Auch was Nachhaltigkeit angeht, ist die heutige Generation sehr verschwenderisch. Wieso muss man denn alle zwei Jahre ein neues Smartphone haben? Weil das neue Modell ein Octacore-Prozessor hat? Wieso reicht plötzlich ein Quadcore-Prozessor für "Selfies", Facebook und Twitter nicht mehr aus? Mein Opa hat früher auch die Elektronikgeräte in der Nachbarschaft repariert aber heute? Fernseher ist kaputt? Egal! Kauft man sich halt einen neuen ... Heute kann man die Geräte kaum noch reparieren, ja aber wem ich das Geschuldet? Der Schlankheitswahn bei Elektronikgeräten macht ja auch bei Fernsehern nicht halt. Wozu muss ein Fernseher dünn sein? Als ich vor über 10 Jahren meinen Eizo-Monitor kaufte, sagte jeder: "Der ist aber ganz schön dick." Scheiß drauf, dass er einen guten Schwarzwert hat. Scheiß auf die 10-Bit-LUT, scheiß auf den 98% sRGB-Farbraum. Die Tiefe des Gehäuses ist entscheidend! ... Meine Eltern wollten neulich auch ein noch gutes Sofa ein Sozialkaufhaus schenken. Was war? Sie haben es nicht angenommen, weil das kein Ledersofa war. Also selbst geschenkt war es denen zu teuer. Eine Waschmaschine wollten sie auch nicht, denn die war dreckig und hatte untenrum ein paar Rostpickel, da sie in einem feuchten Keller stand. Da kann man schon sehen, welchen Lebensstandard schon heute die Sozialbedürftigen haben. Das Problem ist, dass man mit einer Altersvorsorgung heute nicht mehr auskommt. Heute muss man breit fächern, um überhaupt später was zu bekommen. Das Zinsniveau ist im Keller und man bekommt kaum was für sein Geld. Wer ein Sparbuch hat, kann das Geld auch gleich in ein Kopfkissen packen, denn dort bekommt er die selben Zinsen. Wer Pech hat, bekommt im Kopfkissen sogar mehr, denn viele Sparbücher haben inzwischen theoretisch Minuszinsen. Nur die wenigen können es sich auch erlauben, ein Haus zu kaufen und gleichzeitig noch andere Sparmaßnahmen zu betreiben, denn man möchte ja auch noch leben können und nicht verhungern, weil man alles für seine Zukunft spart. Ich selber habe mir eine Wohnung nahe Hamburg gekauft, besitze eine betriebliche Altersrente und habe zwei Bausparverträge laufen. Die zwei Bausprarverträge kann ich mir auch nur leisten, weil der Abtrag der Kredite für die Wohnung deutlich niedriger ausfällt, als eine Kaltmiete in dieser Umgebung. Das Geld, was ich da spare, habe ich dann in die Bausparverträge investiert.

Es ist aber die Aufgabe einer Firma, dem Azubi dies klar zu machen, dass er sich ständig weiterbilden muss, denn das ist ein Teil seines Jobs. Auch muss dies von der Firma gefördert werden. Dem Azubi bzw. dem später ausgebildeten Entwickler muss auch die Zeit dafür gegeben werden, dass er sich weiterbilden kann. Wie Kwaiken schon schreibt, nicht jeder kann und will sich privat weiterbilden, weil andere Prioritäten gesetzt werden. Ich bin zwar Single, aber ich komme ca. um 18:30 Uhr von der Arbeit nach Hause. Dann esse ich was, räume die Küche auf und schwupps ist es schon 20 Uhr. Da möchte man auch mal sein Kopf abschalten und zur Ruhe kommen, denn um ca. 23 Uhr gehe ich dann wieder ins Bett. Für Weiterbildungen nach der Arbeit bleibt kaum Zeit. Er arbeitet in einer Firma, die als Hauptsprache C# verwenden. Generics müsste er also schon lange kennen. Wer mit Copy&Paste arbeitet, macht grundsätzlich etwas falsch. Wenn Firmen Bibliotheken für Datenbankabfragen entwickelt haben, sollte die Firma sich sowieso fragen, ob man diese Entwicklung nicht lieber aufgibt und dafür gängige Frameworks verwendet? Das macht den Code schlanker und man kann sich mehr auf die Kernkompetenzen konzentrieren. Abfragen per Hand klöppeln in aller Ehre, aber welche Firma kann sich so etwas noch leisten? Oft wird mit Performance argumentiert, weil ein Framework ja grundsätzlich langsamer ist. Ja, es stimmt aber ich habe die Erfahrung gemacht, dass Performance kaum eine Rolle spielt, da die meisten Firmen gar nicht die Anzahl der gleichzeitigen Nutzer haben, die Performanceprobleme auslösen könnten oder gar nicht jede Millisekunde ausgequetscht werden muss. Wenn eine Berechnung 5 anstatt 3 Sekunden dauert, ist es den meisten Kunden auch egal. Wenn es dann tatsächlich mal Performanceprobleme gab, dann oft wegen einer unzureichenden Implementierung (z.B. wegen zu vielen Einzel-Selects). Solange es keine Performaceprobleme gibt, mache ich mir auch keine Gedanken darüber. Bis dahin versuche ich den Code sauberzuhalten, da Performanceoptimierung oft eine verschlechterung der Code-Struktur mitsichzieht und ich nicht schon von Anfang an die Code-Struktur versauen möchte. "Rückgabe definierter Werte in einem Array" klingt für mich nach PHP-Hacking und das ist für mich auch ein Unding, die hauptsächlich nur in der PHP-Welt vorkommt. Das ist einfach nur schlechter Programmierstil. Wenn eine Funktion mehrere Rückgabewerte zurückliefern soll, dann macht die Funktion zu viel oder das Array wird als Klasse Missbraucht, indem der Name einer Klassen-Eigenschaft als Schüssel verwendet wird. Wenn eine Aufgabe zu kompliziert ist, dann wurde sie nicht genug zerlegt. Jede noch so komplizierte Aufgabe kann so zerlegt werden, sodass sie von fast jedem implementiert werden kann. Es ist aber normal, dass ein Entwickler die Anforderungen, die ein Kunde stellt, nicht gleich versteht, da Kunde und Entwickler oftmals unterschiedliche Sprachen sprechen. Das Fachvokabular des Kundens zu kennen ist auch gar nicht die Aufgabe eines Entwicklers. Der Kunde versteht den Entwickler ja auch nicht. Beide leben in unterschiedlichen Sphären und es gilt, einen gemeinsamen Nenner zu finden. Ich bin Medieninformatiker und arbeite dennoch in der Bankenbranche. Ich versteh das Fachvokabular eines Bänkers oft nicht und das geht vielen Entwicklern bei uns so. Dafür gibt es auch bei uns eine Fachabteilung, die die Fachanforderung der Kunden in eine für uns verständliche Sprache übersetzt. Die Fachabteilung steht auch im ständigen Kontakt mit dem Kunden, sodass wenn wir Fragen haben, die Fachabteilung fragen und wenn sie auch nicht weiter weiß die Frage an den Kunden weiterleiten. Darüber hinaus schreibt der Entwickler noch mal ein White Paper mit den Anforderungen des Kundens und das wird dem Kunde noch mal vorlegt, um eine gemeinsame Sprache zu finden und erst wenn der Kunde sein okay gibt, wird dann die Anforderung umgesetzt. So umgehen wir in vielen Punkten deine Grafik. Seit vielen Jahren ist auch das Buzzword "Domain-driven Design" (DDD) in aller Munde. DDD geht zwar noch viel weiter als wir, aber es ist eben auch eine Methode, damit Kunde und Entwickler die selbe Sprache sprechen und diese Sprache auch im Code abgebildet wird, damit es eben nicht zur besagten Grafik kommt.

Das gilt auch für die FI-Leute. Woher sollen sie auch die Fähigkeiten haben? Ein FIAE lernt nur das, was die Firma macht. Er bekommt keinen Blick über den Tellerrand. Wenn eine Firma nur PHP verwendet, dann lernt er auch nur PHP aber man lernt in der Wirtschaft oft nichts über Clean Code, weil nach Leistung bezahlt wird und der Kunde hat von Clean Code nichts. Also wird der Code oft nur dahingerotzt, um seine Software günstig verkaufen zu können. Auch wissen es die Firmen oftmals nicht besser, weil sie stehengeblieben sind. Gerade ältere Softwareentwickler tragen gerne Scheuklappen und wollen gar nichts mehr neues lernen. Neulich hatte ich mitbekommen, wie ein älterer Entwickler sich wie ein kleines Kind freute, als er herausfand, dass C# ja Generics kann ... Die gibt es in C# schon seit 11 Jahren (ab 2.0) ... Da kann man sehen, dass sein Wissensstand schon seit über 11 Jahren stehengeblieben ist. Die Berufsschule ist da auch wenig hilfreich. Ist zwar schon länger her, als ich mich mal mit einem FIAE-Azubi unterhalten hatte aber damals war es so, dass seine Berufsschule den Azubis zwar Java beibringen wollte, aber die While-Schleife weggelassen hatten, weil die Schule die Erfahrung gemacht hatte, dass diese Art von Schleifen für die meisten Schüler zu kompliziert sei. Man korrigiert also lieber den Standard nach unten. Wie soll man denn bei so einem Vorgehen ein solides Grundverständnis aufbauen, wenn man nicht in der Lage ist, den Azubis die Syntax zu erklären? Also nur weil man einen Abschluss als FIAE hat, heißt es ebenfalls noch lange nicht, dass man gleich der gute Entwickler sei, denn auch hier fehlt die Erfahrung, die man dann erst mal sammeln muss und vor allem muss man sich ständig weiterbilden und am Ball bleiben. Einen Stillstand gibt es in dieser Branche nicht.

Auf meiner damaligen Schule waren die Matrikelnummer aus Einfachheit nur vierstellig. D.h. ab den 9000. Schüler fingen sie wieder bei Nummer 1000 an. Matrikelnummern müssen also nicht auf alle Zeit eindeutig sein. Wozu auch? Nach der Exmatrikulation steht die Nummer wieder zur Verfügung. Eine Matrikelnummer ist etwas fachliches und nicht technisches, wie eine eindeutige ID, die für alle Zeit eindeutig sein muss. Matrikelnummern können in alle Zeit eindeutig sein, ja aber das hat das nicht Geschäftsobjekt zu entscheiden, sondern die Geschäftslogik; Sprich also die Validierung. Gängige O/R-Mapper haben eine integrierte Validierung, die man nach belieben konfigurieren kann. Darunter auch, dass beim Persistieren bestimmte Eigenschaften nicht geändert werden dürfen. Es geht mir in erster Linie darum vor Anfängerfehler zu bewahren, da man z.B. mit der Matrikelnummer eine falsche Vorstellung bekommt, wann readonly angebracht ist und wenn man es einem Anfänger erklärt, warum dann nicht gleich richtig?

Ab C# 6.0 gibt es noch eine elegantere Methode über String Interpolation: Process.Start(command, $"{var1} {var2}");

Kann ich bestätigen. Als ich vor über 10 Jahren meine Ausbildung abgeschlossen hatte, wollte auch keiner die Berichtshefte sehen. Nicht mal auf Nachfrage, ob die IHK/Prüfer die Berichtshefte sehen wollten, wurde verneint. Ich hab also diese Dinger umsonst geschrieben. Ich halte es auch für Zeitverschwendung, wenn die IHK diese doch anschaut, um zu schauen, ob der Betrieb ihre Arbeit gemacht hat, da der Ausbilder die Berichtshefte unterzeichnen muss. Wenn da dann nur drinnensteht, dass der Azubi nur Kaffee gekocht hat, wird der Ausbilder nicht ganz froh sein und fordern, dass der Azubi die Berichte neu schreibt, bis es passt.

Was sollen denn die Betatester testen? Wurden ausgiebig Unittests geschrieben, sodass die Betatester nur den Workflow testen soll oder wurden keine Unttests geschrieben und soll der Tester auch die Logik testen?

Bei Pi und vordefinierte RGB-Farben (RGB-Farben allerdings nur bedingt. Siehe weiter unten) bin ich dabei, dass es Konstanten sind aber Matrikelnummer und Ablauf- und Erstellungsdaten (die mehrzahl von Datum) sind keine Konstanten. Offenbar vermischst du hier final (Java) bzw. readonly (C#) Variablen mit Konstanten, aber da gibt es einen großen Unterschied: Konstanten sind während des Kompilierens bekannt. Beim Kompilieren wird überall, wo die Konstante benutzt wird, gegen den konkreten Wert ausgetauscht. Darum können Konstanten auch nur integrierte Datentypen sein. Es läuft also erst mal ein Präprozessor, der die konkreten Werte ermittelt und diesen dann überall einfügt. Darum sollte man auch etwas vorsichtig mit Konstanten aus Drittbibliotheken sein. Wenn sich eine Konstante in einer Fremd-DLL ändern sollte, bekommt dein Code erst mal davon nichts mit, bis du dein Code neu kompilierst. Aufgrund dieser Schritte besitzt eine Konstante auch keine Variablenadresse. Variablen hingegen werden während der Laufzeit initialisiert und sind zur Kompilierzeit nicht bekannt. Das gilt auch für final bzw. readonly Variablen. Final/Readonly Variablen werden per Initialisierung oder per Konstruktor initialisiert. Ob man jetzt die Matrikelnummer oder Ablauf- und Erstellungsdatum wirklich final/readonly machen möchte, ist vom Design abhängig aber ich würde das eher nicht tun. Man schränkt sich dann doch sehr extrem ein. Man müsste dann diese Werte im Konstruktor reinreichen und das sollte man bei Geschäftsobjekten nicht machen. Die XML-Deserialisierung vom .Net Framework erwartet z.B. einen parameterlosen Konstruktor. Wenn du jetzt die Studenten aus einer XML-Datei lesen möchtest, würdest du dann schon Probleme bekommen, da die Matrikelnummer readonly wäre und somit über den Konstruktor mitgegeben werden muss. Auch gängige O/R-Mapper (wie z.B. (N)Hibernate, Entitiy Framework oder Dapper) erwarten einen parameterlosen Konstruktor. Vielleicht möchte man aber auch einfach mal einen Studenten erzeugen ohne eine Matrikelnummer. Dann wird man wieder Probleme bekommen. Man müsste dann wieder eine Factory-Methode schreiben, die einen Studenten mit einer Dummy-Matrikelnummer zurückgibt. Alles Einschränkungen, die man nicht möchte. Wann sollte man dann also readonly verwenden? Mir würden da spontan zwei Beispiele einfallen: z.B. die o.g. RGB-Farben. Da Konstante nur integrierte Datentypen sein dürfen, müsste man einen ganzzahligen Wert nehmen aber man besitzt vielleicht eine RGBColor-Klasse und man möchte über diese Klasse diverse Farben vordefinieren. Dafür bietet sich dann statische readonly Variablen an. Beispiel: public class RGBColor { public static readonly RGBColor Black = new RGBColor { Red = 0, Green = 0, Blue = 0 }; public static readonly RGBColor White = new RGBColor { Red = 255, Green = 255, Blue = 255 }; public int Red { get; set; } public int Green { get; set; } public int Blue { get; set; } } So hätte man die Farben Schwarz und Weiß als statische readonly Variablen deklariert, die sich per Laufzeit nicht ändern und man kann per RGBColor.Black bzw. RGBColor.White darauf zugreifen. Als zweites Beispiel würde mir die Verwendung von Dependency Injection einfallen. Beispiel: public ClassA { private readonly IDependency dependency; public ClassA(IDependency dependency) { if(dependency == null) throw new ArgumentException(); this.dependency = dependency; } public int DoSomething() { return this.dependency.DoSomething(); } } Ist jetzt zwar ein sehr blödes Beispiel, aber es verdeutlicht, dass ClassA von etwas abhängig ist, was das Interface IDependency implementiert und um sicher zu geben, dass es intern nicht überschrieben wird, wird es als readonly deklariert. Dies ist aber eigentlich auch nur eine Sicherheitsmaßnahme, die nicht not tut, denn in der Regel weiß ich, wie die Klasse tickt, wenn ich sie ändern sollte. Von außen habe ich ja sowieso kein Zugriff. Man sollte sich also im Klaren sein, was man mit dem readonly-Modifizierer erreichen möchte. Die Matrikelnummer sollte zwar nicht änderbar sein, ja aber wir kennen die Domäne nicht, wo diese Klasse verwendet wird und ggf. ist die readonly-Einschränkung zu viel für den Verbraucher, sodass diese Klasse für ihn unbrauchbar wird. Siehe die Deserialisierung oder es kann ja durchaus möglich sein, dass man die Matrikelnummer mal doch ändern möchte und dann müsste man einen hohen Aufwand betreiben um so etwas realisieren zu können, wenn man nicht in der Lage ist, die Klasse ändern zu dürfen, weil sie vielleicht in einer Drittbibliothek steckt.

Die Frage, die ich mir hier stelle, wer will mit wem Daten austauschen? Ihr mit den Kunden oder soll der Austausch nur intern stattfinden? Wenn sie nur intern stattfinden soll und ihr schon eine Windows-Infrastruktur habt, warum dann nicht über eine Dateifreigabe? Wenn die Mitarbeiter auch von Außen darauf zugreifen wollen, dann richtet man ein VPN ein, der dann den Zugriff aufs Intranet ermöglicht. Das hat den Vorteil, dass man Dateifreigaben als Netzlaufwerk einrichten kann. Das ganze lässt sich dann über Active Directory steuern. Wenn ihr mit Kunden Daten austauschen wollt, dann richte ein Filehosting ein. Da wir ebenfalls eine Windows-Infrastruktur verwenden, bot es sich bei uns an, Sharepoint zu verwenden und hier kann man auch HTTPS als Protokoll verwenden. FTP ist eine sehr schlechte Lösung. Vor allem, wenn man Daten mit Kunden austauschen möchten. Viele Kunden sitzen hinter einer Firewall oder hinter einem Proxy und haben keine Möglichkeit vom Firmennetzwerk aus, mit einem FTP-Server außerhalb kommunizieren zu können und für interne Zwecke ist FTP einfach zu nervig. Man muss erstmal den FTP-Client starten und sich dann noch am Server anmelden. Geschweige denn, dass man evtl. noch die Leute dafür Schulen muss. Bei Dateifreigaben kann der Administrator schon die Netzlaufwerke für die Benutzer vorkonfigurieren und sie erscheinen dann beim nächsten Anmelden. Eine Schulung ist somit nicht notwendig. Ein Netzlaufwerk funktioniert dann so wie ein übliches Speichermedium. Also würde es eher so aussehen, dass dein Projekt eher das Einrichten und Administrieren einer Windows-Domäne ist. Mitsamt VPN als Zugriff von Außerhalb und Filehosting für die Kunden.

Für gewöhnlich fängt man bei einer Konsolenanwendung damit an, die Main-Methode selbst zu implementieren aber hast du dir mal die Main-Methode einer WinForms- oder WPF-Anwendung angeschaut? Die besteht nur aus drei Zeilen Code. So sieht sie z.B. bei einer WPF-Anwendung aus: public static void Main() { WpfApplication1.App app = new WpfApplication1.App(); app.InitializeComponent(); app.Run(); } Eine WPF-Applikation wird instanziiert, initialisiert und gestartet. Mehr passiert in der Main-Methode nicht und so sollten bestmöglich auch Konsolenanwendungen aussehen. Wenn du nur etwas ausprobieren möchtest, kannst du gerne so viele statische Methoden benutzen, wie du möchtest. Wenn das Tool aber produktiv genutzt werden soll, dann sollte man schon darauf achten, schon von Anfang an sauber zu entwickeln, denn aus Erfahrung heraus bleibt es nicht bei diesen 50 Zeilen, sondern das Tool wird immer weiter ausgebaut und ehe man sich versieht, wurden aus diesen 50 Zeilen plötzlich 1.000 und mehr Zeilen. Dann hat man nicht nur eine Datenbank, sondern zwei unterschiedliche, die dann zwei Log-Dateien erstellen und die Datei A.csv soll in die erste Datenbank und B.csv in die zweite und vielleicht möchte man dann noch die Logging-Informationen über eine Weboberfläche darstellen, weil der Kunde kein Zugriff auf die Log-Dateien hat, etc, etc, etc... Als weiteren Tipp geben ich dir auf den Weg, dich mit den SOLID-Prinzipien auseinanderzusetzen. Wenn man sie schon einigermaßen versteht und versucht, sich daran zu halten (oft ist es echt schwer, eine Lösung zu finden, die nicht gegen die Prinzipien verstößt), der entwickelt schon automatisch halbwegs vernünftigen Code und bitte: Schreib Unittests. Und wenn er es nicht kann, der Lehrer sollte es können, denn er kennt Java. Microsoft hatte sich damals bei der Entwicklung von C# viel von Java inspirieren lassen und beide Sprachen sind vom Aufbau sehr ähnlich. Ich hab früher auch hauptsächlich mit Java entwickelt. Seit einigen Jahren aber hauptsächlich mit C# und der Übergang von Java nach C# ging fließend.

Na ja, ich arbeite inzwischen seit einigen Jahren als Softwareentwickler und das, was ich schon in einigen Firmen an Code gesehen habe, geht echt unter keine Kuhhaut. Da schreiben selbst Entwickler, die 20+ Jahre Berufserfahrung haben, den allergrößten Mist an Code, den man sich nur vorstellen kann. Da werden Design Patterns auf abstruse Art- und Weisen oder sogar komplett falsch implementiert oder viele haben selbst nach 20 Jahren die Objektorientierung nicht verstanden und schreiben weiterhin spaghetticode wie in alten C-Zeiten. An der Software, wo ich jetzt arbeite, hat man statische Klassen aus Faulheit verwendet. Damit man die Klassen nicht instanziieren braucht, hat man sie statisch gemacht (yeeaah! Man spart sich eine Zeile Code...). Hier wurde Mikro-Optimierung auf die Spitze getrieben und von solchen Klassen gibt es hunderte und diese Klassen sorgen in Unittests immer wieder für Probleme, weil z.B. die Methoden Queries an die Datenbank schicken. Der Unittest ist dann von der Datenbank abhängig. Also testet man im Unittest nicht mehr die Methoden an sich, sondern schon komplexe Programm-Strukturen auf einen Schlag. Das Problem ist nun, dass man von statischen Klassen nicht erben und somit nicht mocken kann. Martin Fowler hatte diesbezüglich mal ein Blog-Eintrag geschrieben. Sein Beispiel ist aber relativ trivial. Stell dir mal vor, du hast im Code hunderte solcher Klassen, die hunderte von Abhängigkeiten besitzen, weil man laufe der Jahren die Klassen immer um weitere Methoden ergänzt hat und die Klassen nun mehrere Tausend Zeilen beinhalten. Ist ja auch so schön einfach, einfach statische Klassen zu erweitern ... Mir persönlich geht es auch eher darum, dass du ein gespürt dafür bekommst, wo die Probleme bei statischen Methoden/Klassen liegen und dass man schon wissen sollte, wann dieses Schlüsselwort angebracht ist und wann nicht. Nur weil man die Syntax versteht, heißt es noch lange nicht, dass man auch sauberen Code schreiben kann und das finde ich viel wichtiger als so manches andere aber das bekommt man von Firmen nicht so richtig beigebracht, weil man lieber aufgrund des Zeitdrucks lieber schmutzigen Code schreibt, der zwar jetzt schnell geschrieben werden kann und somit kostengünstig ist aber spätestens in einem halben Jahr hohe Kosten verursacht, weil der Code unwartbar ist.

Aus eigener Erfahrung gebe ich dir den Rat Die Interop-Schnittstelle nicht zu verwenden! Du handelst dir damit mächtig viele potenzielle Fehler ein. Selbst Microsoft rät von diesem Weg ab. Ein weiteres Problem ist, dass die Architektur ab Excel 2013 sich grundlegend geändert hat, sodass man gar nicht mehr sicher mit der Interop-Schnittstelle arbeiten kann. Früher war es so, dass man immer einen separaten Prozess gestartet hat, über den man arbeiten konnte. Inzwischen wird aber nur ein Prozess gestartet. Führt man also ab Excel 2013 new Excel.Application(); aus, so erhält man intern immer den selben Prozess. Die Properties ActiveSheet oder ActiveWorkbook funktionieren dann nicht mehr korrekt, wenn man nebenbei noch an einer weiteren Excel-Datei arbeitet. Man merkt aber erst beim Speichern, dass da irgendwas schiefgelaufen ist. Darüber hinaus ist auch die Interop-Schnittstelle extrem langsam und während die Excel-Datei erstellt wird, kann man auch die Copy/Paste-Funktion nicht mehr benutzen, weil die Interop-Schnittstelle darüber die Daten nach Excel Transferiert. Wenn du Excel-Dateien erstellen möchtest, dann verwende eine Bibliothek dafür, wie z.B. EPPlus. Das hat auch den Vorteil, dass man von einer Excel-Installation unabhängig ist, da Excel nicht benötigt wird.

Das ist ein sehr schlechtes Beispiel! Das verstößt gegen das Single-Responsibility-Prinzip! Die Mitarbeiter-Klasse hat dann plötzlich zwei Aufgaben: Zum einen repräsentiert es ein Mitarbeiter und zum anderen zählt die Klasse auch noch die Anzahl der Mitarbeiter. Die Mitarbeiter sollten in einem Repository gehalten werden und wir fragen das Repository nach der Anzahl. Schon mal es durchaus vorkommen kann, dass man temporär einen Mitarbeiter erstellen möchte, der aber wiederrum später gelöscht wird. Dadurch kann es zu schlimmen Seiteneffekte kommen, wenn die temporären Mitarbeiter-Klassen gezählt werden. Allgemein sollte man mit static sehr vorsichtig sein. Man sollte wissen, was man da tut. Statische Variablen/Methoden sind schlecht zu mocken, daher sollte man sie zugunsten des Unittests vermeiden. Statische Variablen braucht man echt sehr selten und zwar so selten, dass mir nicht mal ein gescheites Beispiel einfällt. In allen Projekten, die ich inzwischen gesehen habe, wo statische Variablen benutzt worden waren, führten sie irgendwann zu massiven Problemen. Statische Methoden brauche ich eigentlich höchstens nur bei Singletons oder Factory-Methoden. Außerdem gäbe es noch die Möglichkeit Mikro-Optimierungen zu betreiben und zwar wenn ich weiß, wenn eine private Methode unabhängig vom Zustand der Klasse ist, dann deklariere ich sie als private static. Dann wird die Methode nur ein mal im Speicher gehalten. Das Problem mit static ist, wenn sich dahinter Logik verbirgt und ein anderes Ergebnis liefert. Beispiel: DateTime.Now Diese statische Eigenschaft gibt pro Aufruf immer ein neues DateTime zurück. Wenn man nun eine Methode testen möchte, die DateTime.Now aufruft, wird man in Schwierigkeiten kommen, einen gescheiten Unittest zu schreiben, dessen Ergebnis reproduzierbar ist, da DateTime.Now nicht reproduzierbar ist. Man fängt dann also an DateTime irgendwie zu mocken. - Warum sollte sich der Umsatzsteuersatz nie ändern? - Die Matrikelnummer eines Studenten gehört dem Studenten, also darf diese nicht statisch sein! - Eine bestimmte RGB-Farbe wäre eine Konstante. - Pi ist ebenfalls eine Konstante. - Ablauf- und Erstellungsdatum gehören zum Lebensmittel und sind somit nicht statisch! Diese Beispiele sind also allesamt falsch und nicht zur Nachahmung empfohlen!

Hallo, liegen die Daten (mehrzahl von Datum) wirklich als String/(n)varchar in der Datenbank? Das macht doch überhaupt keinen Sinn ... Da die Millisekunden fehlen, wenn sie 0 sind, wenn du ToString() aufrufst, sieht es für mich aus, als würden die Daten in einem spezifischen Date-Format vorliegen. Dann kannst du auch einfach die Methode GetDateTime() aufrufen, was deutlich eleganter ist, da man sich den ganzen String-Kram schenken kann. DateTime zeitstempel = reader.GetDateTime(0); mfg Whiz-zarD PS: Die Zeichen : und . müssen nicht escaped werden.