Nummer 1 – Immer dieselbe Technologie

Bei den Technologien wird all zu oft auf altbewährtem gesetzt. In vielen Fällen ist dies eindeutig keine schlechte Wahl, wenn es dabei z.B. um Programmiersprachen geht oder ein Framework, welches man wirklich gut kennt. Aber auch dort sollte man nicht blind. Für manche Lösungen kann auch mal ein Blick um die Ecke gewagt werden, weil diese sich für ein bestimmtes Problem viel besser eignet. So ist es auch bei Datenbanken im .NET Bereich wird typischerweise sehr oft der SQL Server genutzt. Nur ist auch der SQL Server leider nicht für alle Lösungen perfekt. Für viele zwar, aber halt nicht für alle.

Daher bei einem neuen Projekt immer mal sehen, welche Technologien vielleicht auch in Frage kommen können und dann abwägen.

Nummer 2 – Architekturen immer wiederholen

Eine typische Architektur, welche wirklich immer gerne genutzt wird ist wohl die N-Tier Architektur. In vielen Fällen auch eine gute Wahl, aber auch hier keine Lösung für alle Fälle. Nur weil die Architektur für eine Lösung gut funktionierte, muss sie dies für ein komplett anders Problem nicht. Daher sollte man auch in der Welt der Architekturen sich mal Gedanken machen, welche den am besten zu meinem Problem passt. Gute Architekturen stellen meist viel mehr einen bestimmten Ablauf bzw. Prozess da, wo man sich dann denken das N-Tier nicht das Allheilmittel sein kann.

Daher auch hier mal ein Blick um die Ecke wagen.

<

h2>Nummer 3 – Das ganze Programm muss auf den selben basieren

<

h2>

Der dritte Punkt ist für mich so ein Thema, welches ich ein wenig aus den DDD habe. Dort wird oft der Begriff Bounded Context erwähnt. Daher Bereiche, welche unabhängig sind und auch so behandelt werden sollten. Den all zu oft werden die Nummer 1 und 2 gerne für ein ganzes Projekt genutzt. Obwohl bestimmte Teile eines Projektes durch andere Technologien oder Architekturen viel besser wären. Man verkompliziert meist so unnötig eine Menge Dinge, weil man sie dann versucht in das Muster zu bekommen. Teilweise endet es dann, wie bei den Kinderspielzeugen und das Runde würde durchs Eckige gequetscht. Keine wirklich schöne Lösung. Verschiedene Architekturen in einem Projekt sind dabei auch keine schlimme Sache bei der Kommunikation, wenn man die Schnittstellen zwischen einander stabil hat.

Daher immer gucken in welche logischen Einheiten man ein Projekt zerlegen kann. Und sich dann für jede einzelne Gedanken machen.

Fazit

In der Entwicklung wird viel zu oft wiederholt, was gut geklappt hat. Aber oft scheitert dieser Punkt, wenn die Anforderungen ganz andere sind. Daher sollte man mittlerweile auch mal ein wenig mehr aus der Reihe tanzen. Den mittlerweile gibt es so viele Möglichkeiten, welche für ein Problem viel besser sein können.

The post Nicht eines für alles bei der Entwicklung appeared first on CODE IS COOL.

Buzz Words & Basta

Erstmal muss ich sagen die Organisation war wirklich super. Die Location in der Rheingoldhalle ist echt eine super Location für solch eine Veranstaltung. WLan war überall verfügbar und das Essen war einfach genial. Also wirklich richtig gut. Alle 90 Minuten gab es irgendwas zu Essen und davon nicht zu wenig. Hat sich angefühlt wie Weihnachten von dem Bereiche her.

Von den Themen her war es natürlich viel gehyptes dabei, wie Cloud, Cross Plattform, Agil und IoT. Also alles was irgendwie grade Hipp ist. Deswegen ist für mich die Basta wohl auch eher eine Konferenz gewesen, welche Anreize gibt für die Zukunft. Aber so direkt praktisches gab es eher weniger. Die schöne heile Welt halt. Je nach Speaker war es natürlich verschieden von einigen habe ich sehr viel gelernt und von anderen hat man eher eine Werbeshow etwas bekommen für eine Technik oder Technologie.

Aber so ist eine Konferenz halt zumindest hatte man ja immer viel Möglichkeiten zwischen verschiedenen Speaker zu wählen.

Gedanken umstrukturieren

Mein größter Gedanken zum Thema der Softwareentwicklung ist wohl, das man einfach mehr nachdenken sollte beim entwickeln. Man ist einfach nicht nur ein Entwickler, sondern mittlerweile viel mehr. Der Entwickler Job ist für mich nur noch zum kleinen Teil wirklich Programmcode schreiben, sondern sich viel mehr mit dem Thema des gesamten zu beschäftigen. Den nur so können wirklich gute Lösung entstehen, wie Architekturen,…

Dabei sollte man sich auch mal wirklich mehr Gedanken machen, was man den eigentlich entwickelt und für wen. Damit meine ich auch mal in Kontakt mit Kunden richtig zu treten. Nicht immer diese internen Sachen, weil die meist nur ihre persönlichen Interessen vertreten. Das ist kein Entwicklerthema an sich, sondern eins der ganzen Abteilung der Softwareentwicklung. Man muss einfach mal mit seinen alten Gedanken brechen, man liefert eine Software aus und deckt damit die Wünsche schon ab.

Dadurch ensteht auch einfach flexibler zu sein. Es gibt nicht mehr die Plattform in der Entwicklung oder den Prozess in der Entwicklung. Jeder muss seinen Weg dort finden, aber auch ständig evaluieren und anpassen. Diese starten Prozedere sind keine Dinge, welche in der Softwareentwcklung klappen können.

Kürzere Laufzeiten von Software sind dabei einfach letztendlich Schlussfolgerung. Man kann mit den Monolithen von Massen an Features einfach nicht arbeiten, sondern muss sich immer wieder neu orientieren in kurzen Zeiträumen von Wochen. Natürlich kann es Visionen geben, aber man sollte nicht detailiert Monate oder sogar Jahre planen. Die Anforderungen überall können sich dazu viel zu schnell ändern.

Die Basta ist gute für Anreize

Wie man sieht war die Basta für mich weniger eine Entwicklermesse an sich oder gar eine Microsoft bzw. NET Veranstaltung. Ich habe nur wenige Vorträge mit direkten Themen aus .NET gehabt, weil sich dies einfach viel zu schnell ändert bzw. noch gar nicht fertig ist. Diese Grundprinzipien, welche durch die anderen Veranstaltungen entstanden sind, werden wohl etwas länger haltbar sein. Aber auch diese unterliegen wohl einer gewissen Halbwertszeit, wo in 1,2 oder 5 Jahren schon wieder andere Themen aktiv sein können.

Daher man sollte sich wohl nicht so Hypen lassen, aber sich mal grundsätzlich Gedanken machen, was so klappt und was nicht bei sich in der Entwicklung und der Abteilung.

The post Gedanken zur Basta 2015 appeared first on CODE IS COOL.

Die Abnahmetests sind die Endtest, den nun wird überprüft ob es den Ansprüchen, welche der Kunde hatte genügt.

Beispiel

Hierfür gibt es kein Beispiel. Der Kunde entscheidet, was er testet und wie er es nutzt.

Anwendungsfall

Für mich eher ein Projektthema, wenn man es wirklich mit Kunden macht. Ansonsten wäre es weiterhin ein interner Test, wo ein entsprechendes Produktmanagement diesen Tests übernimmt.

Ersteller

Vom erstellen ist für mich hier nicht mehr wirklich die Rede. Den nun sollte doch per Hand getestet werden, zwar sollte man sich einen Plan machen, aber doch händisch vorgehen. Daher ist dies natürlich auch sehr aufwendig, aber dennoch notwendig.

The post Abnahmetest – Test vom Kunden appeared first on CODE IS COOL.

Erläuterung

Die Systemtests kommen den realen System dann schon sehr nah. Man arbeitet mit standardisierten Daten, aber testet das gesamte System in sich. Daher alle Abhängikeiten, auch zu externen Systemen. Solche Tests sind dabei auch sehr aufwendig, da die Tests ja eine Vielzahl von Abläufen abbilden muss. Sinn machen dieses Tests daher erst dann, wenn alle Komponentests und auch Integrationstests erfolgreich sind.

Beispiel

Ein Beispiel wäre viel zu komplex hier aufzuzeigen. Grob wäre es eine Liste von verschiedenen Schritten, welche aber je nach Fall auch sehr lange sein können. Versuchen sollte man jedoch auch dieses Tests möglichst einfach zu halten.

Anwendungsfall

Die Systemstests dienen dem Test des gesamten Systems, daher läuft das Programm auch mit Daten und externen Systemen reibungslos. Daher beginnt vom Login, über Einstellung, verschiedenste Eingaben und deren Auswirkungen. Daraus können wirklich sehr komplexe Testabläufe entstehen, welche aber einmal definiert auch ebenso viel Arbeit abnehmen. Zwar ist meist noch alles mit Demo Daten, um eine entsprechende Wiederherstellbarkeit zu wahren.

Ersteller

Hierfür ist die Mischung aus einem Menschen mit der fachlichen Kompetenz und jemanden der sich mit entsprechenden Tests auskennt. Den Systemtests können z.B. beim Team Foundation Server mit einem speziellen Testmanager erstellt werden.

The post Systemtest – Testen ob alles zusammen funktioniert appeared first on CODE IS COOL.

Pro/Kontra Alleskönner

Erstmal sollte man vielleicht klären, was ein Alleskönner in der IT für mich wäre. Alles Könner könnte jemand sein, welche wirklich alles in der IT macht Hardware, Software, Entwicklung, also wirklich querbeet. Aber ich berufe mich lieber auf die Definition in einem Bereich ein Alleskönner z.B. in der Entwicklung auf verschiedenen Plattformen und Sprachen unterwegs sein.

Als Alleskönner hat man so auf jeden Fall einen Vorteil in eine Menge Projekten aktiv zu sein. Den man kann ja schließlich vieles und kann dieses Wissen auch nutzten. Dadurch kann man wohl auch ganz gut Querverbindungen sehen. Eine Sache ist dort in der Sprache gut gelöst, vielleicht kann man es dorthin mit übernehmen. Lernen ist natürlich auch viel interessanter, weil man überall mal geschnuppert und nicht so eine einseitige Sicht hat.

Aber dieses überall sein hat auf jeden Fall auch einen Nachteil. Man steckt einfach nicht so sehr in einem Thema drin. Man kann halt nur an der Oberfläche kratzen und ein tieferes Verständnis ist einfach nur schwer möglich. Außerdem kann es auch wirklich anstrengend sein in vielen Bereichen sich immer wieder neues anzueignen. Der Verwaltungsaufwand ist halt ein riesiger.

Pro/Kontra Spezialist

Auch den Spezialist will ich vorher etwas definieren. Den für mich wäre ein Spezialist jemand der wirklich sich auf eine Plattform und Sprache fokussiert und dabei wirklich dort 100% gibt für. Die Außenwelt gibt es sozusagen gar nicht.

Als Spezialist wird man natürlich richtig gut in seinem Bereich und dadurch wird man natürlich auch gefragt. Sei es für Aufträge, Konferenzen und andere Sachen, weil man ja schließlich der beste in dem Bereich ist. Außerdem kennt man ziemlich genau auch seine Quellen und Möglichkeiten um noch besser zu werden, weil man genau sein Thema kennt. Weiterbildung ist daher sehr konkret und gezielt möglich.

Blöd ist es natürlich, wenn man sich auf eine absteigende oder zu sehr gehypte Plattform zu sehr spezialisiert hat. Dann kann es auch schnell bergab gehen und man steht vor relativ wenig Aufträgen. Das ist natürlich eins der größten Risiken, eine Spezialisierung sollte man daher immer gut durchdenken. Außerdem fehlt einem oft auch die Sicht auf andere Dinge etwas, weil man halt seine Welt kennt. Gute Ansätze aus anderen Bereichen kennt man so gar nicht und macht vielleicht vieles aufwendige, als es eigentlich sein müsste.

Wie Handhabe ich es?

Für mich war schon immer eine Mischung die beste Lösung. Aber früher habe ich noch sehr stark gemischt. Mittlerweile bin ich für mich auf den Entschluss gekommen nach dem 80/20 Prozent. Zu 80 Prozent konzentriere ich mich auf den .NET Bereich und C# und darin auch nur auf wenige Themen. Daher darauf spezialisierte ich mich aktuell. Aber zu 20 Prozent mache ich dann auch mal einen querbeet Versuch über Ruby, Node.js um sie zumindest auf einem gewissen Niveau zu verstehen und anwenden zu können. Also hängt auch ein wenig Alleskönner in mir.

Fazit

Die Mischung ist für mich daher mit die idealste Lösung. Wie sieht es bei euch aus? Springt ihr ständig hin und her oder seit ihr einer Plattform in der Entwicklung treu?

The post Spezialist oder Alleskönner in der IT appeared first on CODE IS COOL.

Erläuterung

Die Integrationstests sind sozusagen der große Bruder der Komponentests. Man testet nicht nur einezelne Komponete, sondern auch deren Zusammenspiel. Wie z.B. eine Fullname Converter in Kombination mit dem Kundenobjekt. Dabei kann man sagen, nur wenn alle Komponentests erfolgreich sind, dann macht es Sinn die Integrationstests zu starten.

Beispiel

Anwendungsfall

Durch die Integrationstests wird sichergestellt, das verschiedene Komponenten auch untereinander problemlos funktionieren. Ein typisches Beispiel wäre z.B. dabei vom ViewModel bis zur Datenschicht in eins zu prüfen. Daher ob die entsprechende Logik vom obersten Punkt zum untersten Punkt problemlos funktioniert. Empfehlenswert ist es dabei  je nach Fall, nur im eigenen System zu testen und Aufgaben, welche auf andere Systeme wie eine Datenbank zugreifen, noch möglichst gering zu halten.

Ersteller

Dem Schwerpunkt würde ich weiterhin beim Entwickler sehen. Das Zwei-Augen Prinzip ist hier wohl sehr hilfreich, daher zwei Personen, wobei mindestens einer ein Entwickler ist wohl sehr sinnvoll.

The post Integrationstest – Klassen in Kombination testen appeared first on CODE IS COOL.

Alles in einen Pott

Mir selbst ist dies jetzt auch schon einige Male passiert. Vor ein Projekt gesetzt wurden, wo ich meist nur die Hände über den Kopf zusammenschlagen konnte. Meist wurde es gut gestartet, aber dann wurde ein Projekt scheinbar zum schwarzen Loch gewandelt. Quellcode quer verstreut und gefühlt ohne Sinn und Verstand. Dabei natürlich auch alles undokumentiert, damit man gar keinen Startpunkt mehr hat.

Da ich das Projekt meist nicht einfacher neu starten konnte. Habe ich begonnen mich über Thema zu informieren, wie man solche Projekte grade ziehen kann. Wie kann man eigentlich aus Spaghetti Code sauberen Code machen. Dabei bin ich auf ein Buch gestoßen „Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software“ gestoßen und habe damit so eine Art Bibel für mich gefunden.

Mit Rezepten zurück zu den Zutaten

Das Buch „Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software“ erinnert mehr an ein Kochbuch, als an ein normales Fachbuch. Den es beschreibt immer ein typischen Spaghetti Code Fall, welche man häufig findet. Auch dazu typische Gründe, warum man grade den Quellcode nicht cleanen kann z.B. grade keine Zeit. Dazu findet man dann einen entsprechenden Lösungsweg für diesen Fall.

Ein Beispiel dafür wäre z.B. hat man grade nicht viel Zeit, aber eine riesige Methode vor sich, dann kann man sie mit einfachen Refactoring einfach in verschiedene Methoden aufteilen. So werden die einzelnen Schritte übersichtlicher und mit der Zeit hat man viele kleinere logische Einheiten im Code.

Daher ist das Buch ein Nachschlagewerk, welches man direkt neben dem Entwicklerrechner liegen lassen kann. Die Probleme findet man in Spaghetti Code genug. Obwohl man irgendwann bestimmte Lösungen automatisch im Kopf hat.

Man wird nicht zum Meisterkoch von heute auf morgen

Von heute auf morgen wird man Spaghetti Code nicht in sauberen Code wandeln können. Aber über die Jahre kann man doch so einiges grade biegen und spart sich dadurch doch eine Menge Frust.

Das Buch „Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software“ kann dabei eine gute Unterstützung sein um viele typische Fälle leicht zu lösen.

Was macht ihr mit Spaghetti Code?

Wie geht ihr mir Spaghetti Code um? Kennt ihr das Buch vielleicht sogar oder habt ihr sogar noch andere Empfehlungen in dem Bereich? Dann hinterlasst doch einfach mal einen Kommentar.

The post Spaghetti Code in sauberen Code wandeln appeared first on CODE IS COOL.

Teil 1 – Komponententest (Unit Test)

Erläuterung

Begonnen wird heute mit der kleinsten Einheit dem Komponententest oft auch Unit Test genannt. Wie das Wort Komponente im Test schon zeigt, wird eine Komponente getestet z.B. eine Klasse. Am Beispiel eines Hausbaus, wäre es wenn man eine einzelne Schraube für sich testet, ob sie den gewünschten Ansprüchen genügt. Daher sind Komponententest sehr einfach und vor allem schnell, so das sie oft ausgeführt werden können.

Beispiel

Anwendungsfall

Durch die Komponententests wird sichergestellt, dass eine einzelne Komponente für sich den technischen und fachlichen Ansprüchen genügt. Daher zeigt es z.B. nur das eine Klasse dem Test entsprechend funktioniert, aber nicht wie es mit anderen zusammen funktioniert. Den dieses geschieht mit Integrationstests, welche im zweiten Teil folgen.

Ersteller

Ganz klar der Entwickler bei einem normalen Softwareprojekt.

The post Komponententest (Unit Test) – Testen auf der kleinsten Ebene appeared first on CODE IS COOL.

Das Chaos

Die Benennung von Methoden und Variablen sorgt ja meist schon für Diskussionsbedarf in der Muttersprache. Daher wird es meist besonders interessant, wenn nicht die eigene Muttersprache genutzt wird. Englisch ist dabei ja ein Paradebeispiel, welches viele einfach benutzten, aber eine deutlich unterschiedliches Verständnis von bestimmten englischen Wörtern haben. So wird batch, auch mal zu bach, bath, bacth…. Im Sinne von nichts ist unmöglich, der darauf folgende Entwickler versteht dann meist nur noch Bahnhof.

Aus NoNumerics ein NoMummerics machen war wohl vor kurzem eins der Highlights. Lesbarer macht dieses ganze den meist eh schon komplexen Quellcode nicht wirklich.

Ordnung schaffen im Chaos

Für mich stellt sich zuerst immer die Frage. Ist die Nutzung einer anderen Sprache überhaupt sinnvoll. Sind nur Muttersprachler aus Deutschland unterwegs, dann finde ich diese übertriebene Nutzung von Englisch eh sinnlos. Dann doch lieber in der Muttersprache aller.

Andersrum ist manchmal die englische Sprache von Nöten. Durch multikulturelle Teilnehmer an einem Projekt. Aber dann sollten doch zumindest auf ein gemeinsames Glossar einigen. Eine Liste mit den typischen Grundbegriffen, welche jede Person gleich nutzt und somit auch ein gleiches Verständnis haben. Und im Notfall lieber mal nachfragen anstatt einfach irgendetwas rein zu schreiben.

The post Chaos der Sprachen in der Softwareentwicklung appeared first on CODE IS COOL.

Einen Server ist dabei sehr SQL Intensiv und so traten sehr schnell Probleme von Timeouts auf. Kurz nachgedacht und einfach den ConnectionTimeout etwas höher gesetzt und das Problem trat weiterhin auf.

Kurz danach fiel mir auf das auch ein SqlCommand noch einen Timeout besitzt. Hochgesetzt und nun läuft es ohne Probleme.

Was ist jetzt der Unterschied zwischen ConnectionTimeout und CommandTimeout?

Der ConnectionTimeout dient zur Verbindung zum Server selbst. Daher kann ich den Server erreichen und eine Verbindung herstellen. Der CommandTimeout hingegen gibt an, wie lange ein SQLCommand laufen darf, bevor er gekillt wird. Standardmäßig 30 Sekunden, was in den meisten Fällen auch ausreichen sollten.

Falls man also mal Timeout Probleme hat, dann kann es auch an einer zur langen Ausführung eines SQL Befehls liegen.

The post Der Unterschied zwischen Connection und Command Timeout appeared first on CODE IS COOL.