Whiz-zarD

Es wird ein Zeitplan auf Stundenebene erwartet und das spricht gegen die agile Entwicklung. Diese Zeitangaben ist auch eine einzige Mogelpackung, denn wer kontrolliert es und wer kann sich daran halten?

TDD heißt nicht gleich, dass Agil gearbeitet wird. Agile Softwareentwicklung ist noch was anderes. Schaut man sich das "Agile Manifesto" an, so findet man folgende Leitsätze (kopiert aus Wikipedia): Menschen und Interaktionen stehen über Prozessen und Werkzeugen Funktionierende Software steht über einer umfassenden Dokumentation Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung Reagieren auf Veränderung steht über dem Befolgen eines Plans Und das widerspricht so allem, was die IHK von der Abschlussprüfung erwartet. Aber gut, da rege ich mich schon seit über 10 Jahren auf. Als ich damals meine Mechatroniker-Ausbildung absolviert hatte, musste ich sogar noch auf die Uhrzeit genau angeben, was ich mache ... Da ist es schon ein großer Fortschritt, dass man nur noch die Stunden angeben muss. Kanban muss aber auch nicht unbedingt agil sein. wenn z.B. bei Kanban nicht mit dem Kunden geredet wird, sondern stur die Aufgaben von "Bereit" bis "Fertig" abgearbeitet werden, haben wir hier ebenfalls ein Wasserfallmodell.

Eine kleine Anekdote aus meinem Berufsleben: In der Software, an der ich arbeite, wurde damals in der Designphase (das war weit vor meiner Zeit) einen gravierenden Fehler gemacht und zwar hat man die Geschäftsobjekte direkt mit der Persistenzschicht verdrahtet. D.h. um ein Geschäftsobjekt erzeugen zu können, brauchst du zwingend eine Datenbankverbindung. Bei so einer Architektur im nachhinein Unittests zu schreiben ist unmöglich, da man anfangen müsste, die Datenbank zu mocken. Desweiteren wurde der Fehler gemacht, Geschäftslogik in die UI zu verlegen, weil das so schön einfach ist. Unter Visual Studio einfach ein Doppelklick auf dem Button im Designer und los gehts ... Schreibe aber mal dafür einen Unittest. Viel Spaß. Mit TDD umgeht man diese ganzen Probleme, weil man schon vornherein gezwungen wird, den Code so zu schreiben, sodass er auch Testbar ist. Ein weiteres Problem ist, wenn man die Unittests danach schreibt, dass man eigentlich nur noch die Schnittstellen nach außen testet und das reicht oft für ein Test nicht aus. Man sieht dann zwar, dass sich ein Ergebnis ändert hat, aber wo der neue Wert herkommt, sieht man nicht. Bei TDD geht es also darum, testbaren Code zu schreiben. Unittests Teste deine Klassen und die Methoden. Informiere dich mal über den Begriff "Testpyramide". Manuelle Tests gilt es zu vermeiden, weil die sehr zeitaufwendig sind und Zeit ist Geld. Hier in der Firma besteht der Regressionstest hauptsächlich aus manuellen Tests (die gründe stehen weiter oben) und der Test wird pro Major-Release mit 200 - 300 PT veranschlagt. Das ist enorm. Bei uns steht die Testpyramide auch auf dem Kopf und das ist das Worst-Case-Szenario. Manuelle Tests sind eigentlich nur noch UI-Tests und die testen nur noch den Workflow. Also dass z.B. wenn man auf Button X klickt auch Dialog Y auftaucht und dass Eingabefehler abgefangen wird aber auch diese Tests lassen sich automatisieren. Da gibt es genug Tools. Tests sollten immer durchgeführt werden, bevor es zum Kunden geht. Ansonsten hast du eine Bananen-Software: Reift beim Kunden. Aber ich persönlich sehe viele Probleme bei der Abschlussprüfung, wie die IHK es sich vorstellt. Das sind veraltete Methoden, die man heute nicht mehr anwenden sollte. Heutzutage versucht man den Kunden mit in die Entwicklung zu integrieren, sodass er für Fragen und Antworten bereitsteht und so kann man auch viel schneller auf Anpassungen reagieren (sprich agil arbeiten).

Hast du auf dem Server alle Fehlermeldungen aktiviert? Vielleicht tritt dort ein Fehler auf und du siehst es nur nicht. Aber noch ein Hinweis: Vermeide SELECT *, denn das gibt zu viele Informationen zurück und kann auch zu Problemen führen, wenn man weitere Tabellen gejoint hat, die wiederum Spalten besitzen, die den selben Namen haben. Gib immer explizit an, welche Spalten du haben willst. In diesem Fall hast du sogar zwei Tabellen gejoint, also gibt dir die Abfrage die Spalten von drei Tabellen zurück. Je nach Anzahl der Recordsets kann es durchaus zu Performanceproblemen kommen.

Unittests im Nachhinein zu entwickeln klappt meist auch nicht, da der Code dann der Code nicht testbar ist. TDD ist zwar anstrengend aber es ist durchaus hilfreich, denn TDD führt dich nicht in die Versuchung, den Code irgendwie hinzuhacken. Der Code bleibt dann immer testbar. Wenn man die Unittests erst hinterher schreiben will, hat man dann oft ein Code, der nur sehr schwer testbar ist. Dann testet man nur die Schnittstellen nach außen. Wenn aber dann ein Fehler auftauchen sollte, ist man da erst mal mit dem Suchen beschäftigt, wo der Fehler überhaupt herkommt und je nach Komplexität kann es sehr Zeitaufwendig sein. Ich kenne es auch eigener Erfahrung, dass man die Entwicklungskosten gerne niedrig halten möchte und daher gerne auf Unittests verzichtet werden, weil Unittests Geld kosten und von Unittests hat der Kunde nichts aber das Geld, was man hier investiert, spart man später bei der Pflege des Codes. Ich selber arbeite an einem unwartbaren Monstrum, wo die Entwickler an vielen Stellen im Code sich nicht rantrauen, weil sie nicht wissen, welche Seiteneffekte entstehen könnten, wenn sie was am Code ändern sollten. Der Analyseaufwand steigt somit ins unermessliche. Wenn aber schon vornherein dafür gesorgt wurde, dass vernünftige Unittests geschrieben worden sind, kann man bei Änderungen sehr schnell herausfinden, ob noch alles so läuft, wie vorher. Zeitdruck herrscht immer, denn Zeit ist Geld. Geld, was der Kunde nicht ausgeben will und ich weiß, dass es schwer sein kann, den Chef davon zu überzeugen, aber das ist einfach eine Milchmädchenrechnung, wenn man meint, dass man beim Sparen an Unittests grundsätzlich Geld spart, nur weil das Produkt schneller zum Kunden kommt. Die ganzen Bugs, die der Kunde meldet und der enorme Zeitanstieg bei der Beseitigung der Bugs oder bei der Implementierung von Weiterentwicklungen, sieht oft der Chef nicht. Also muss man ihn dies vor Augen führen, welche Folgekosten so etwas hat.

Das hast du so gut wie in jedem Beruf und dennoch spricht man nicht gerade von einem "kaufmännischen Teil". Ein Kaufmann ist schon ein bisschen mehr, als Kosten- und Nutzen abzuwiegen.

Such dir was aus und du hast deine Antwort... Also ist man sich eigentlich gar nicht im Klaren, was ein Anwendungsentwickler ist? Ich selber habe eine schulische Ausbildung zum "Assitent für Medieninformatik" und vor 16 Jahren eine Mechatroniker-Ausbildung absolviert und in beiden Berufen habe ich nichts über einen Kaufmann gelernt,

Was muss man denn als FIAEler für einen kaufmännischen Teil lernen? Was hat ein Entwickler mit einem Kaufmann zu tun? Außerdem das e-book vom Rheinwerk Verlag würde ich nicht unbedingt empfehlen. Es ist komplett veraltet und die Programmierbeispiele sind oft abschreckende Beispiele, wie man es nicht machen sollte.

So, wie ich das verstanden habe, will er das auch machen. Seine Frage ist wohl nur, ob und wie er es verkauft bekommen kann, irgendwas in Richtung "Medizin" zu machen, obwohl sein Arbeitgeber im Bereich "Musik" tätig ist.

Selbst dann nicht mal wirklich. Sie sollten über Interfaces kommunizieren.

Sowas ist schlechter Programmierstil, da du hier HTML und JavaScript miteinander vermischst. Auf der Webseite von Fancybox ist doch ein Beispiel, wie das funktioniert. (Die "Inline"-Beispiele) Was genau ist denn dein Problem? Wieso kannst du es denn nicht so umsetzen, wie im Beispiel?

Hallo, Ich persönlich würde auch die Finger von lassen, denn offenbar ist der Belegschaft nicht klar, welche Probleme herrschen. Wenn schon die Entwicklungsabteilung nicht mosert, dann ist da irgendwas im Busch. Da würde ich mich fragen, ob überhaupt das Know-how da ist, um geine neue Softwaregeneration einzuleiten? Wenn der Wille und das Know-how fehlt, dann bringt es auch nichts als Geschäftsführer auf den Tisch zu hauen, denn man stößt auf taube Ohren und dann wird das Schiff erst recht untergehen.

Das tatsächliche Einfügen ist weniger das Problem, wobei hier die Festplatte der Flaschenhals ist, wenn es sich nicht um eine In-Memory-Datenbank handelt. Das eigentliche Problem wird gerne viel vielen Übersehen: Das Parsen. Es ist zwar für uns nur ein String, aber für ein DBMS harte Arbeit. Das Statement muss geparst werden, damit das DBMS weiß was der Nutzer überhaupt will. Danach wird ein Ablaufplan erstellt, wie man das Statement am performantesten abarbeiten kann. Dabei werden dann u.a. Statistiken der Tabellen und Indizes gelesen und dann wird der Plan abgearbeitet. Bis es zu er tatsächlichen Abarbeitung kommt, wird sehr viel Zeit verbraten und jetzt stelle dir mal vor, das muss das DBMS bei jedem der Tausend Insert-Befehle ausführen. Da wird Tausend Mal immer das selbe gemacht. Gängige DBMS-Systeme können dieses Problem ein wenig kompensieren, indem sie ein Query-Cache implementiert haben, mit dem überprüft werden kann, ob die Query, die gerade geparst werden soll, nicht schon vorher geparst wurde. Das klappt mal mehr, mal weniger gut. Man sollte sich also im Klaren sein, dass ein DBMS auch kein Hexenwerk ist und nicht alles in Echtzeit schafft. Man sollte sich schon damit befassen, wie ein DBMS arbeitet und was man vermeiden sollte. Ein DBMS würde ich auch nicht selbstentwickeln. Erst mal fehlt mir dazu einfach das nötige Know-How und zweitens wozu auch? Es haben sich schon sehr viele andere den Kopf darüber zerbrochen. Ich habe schon Firmen erlebt, die meinten, sie wären Schlauer als Oracle und haben Datenbank-Funktionalität nachprogrammiert. Haben Zehntausende Euro verbraten und was kam raus? Eine instabile Lösung, die jegliche Form von Weiterentwicklung ausbremste.

Ein Hinweis: Ein Insert-Befehl pro Datensatz ist extrem inperformant. Bei 10 Datensätzen ist es noch kein Problem, aber wenn es über 1.000 sind, dann kann es schon einige Zeit dauern, bis alles in die Tabelle geladen wurde. Das ist auch einer der Gründe, warum sich Microsofts O/R-Mapper Entity Framework sich nie richtig durchsetzen konnte, denn dort wurde tatsächlich jeder Insert einzeln ausgeführt. Inzwischen hat Microsoft das Entity Framework komplett neu entwickelt, um diese Fehler zu korrigieren. Je nach dem wie groß das Projekt wird, würde ich ein O/R-Mapper empfehlen, der das dann übernimmt. Dann erzeugt man per Java-Code lediglich nur eine Liste von den Geschäftsobjekten aus der CSV-Datei (Deserialisierung) und sagt dann dem O/R-Mapper, er solle die Liste in die Datenbank einspielen. In Java dominiert der O/R-Mapper Hibernate. Selber SQL-Statements generieren würde ich eigentlich nicht, da man dann sich abhängig von der Datenbank macht und vielleicht möchte man sie irgendwann wechseln. Jede Datenbank hat so seine Eigenheiten und ein O/R-Mapper kapselt diese Eigenheiten, sodass man sich darüber kaum Gedanken mehr machen muss. Aber ich weiß nicht, was du vorhast oder welchen Wissensstand du besitzt aber wenn für dich der O/R-Mapper zu viel Overhead bedeutet, dann generiere doch einfach per Code ein Insert-Statement und schicke es zur Datenbank. Eine CSV-Datei auslesen ist ja nicht schwer.

Was verstehst du denn unter "Konventionen"? Eine Konvention ist ja eine Vereinbarung. Darunter versteht man in der Softwareentwicklung eher sowas wie Namensgebung, Einrückungen, etc. Es gibt zwar empfohlende Konventionen aber das kann sich auch von Firma zu Firma unterscheiden. Keiner muss sich daran halten. Das, was du wohl meinst, sind wohl so etwas wie Design Patterns. Zum Thema Design Patterns kann man noch das gleichnamige Buch von Erich Gamma erwähnen, was eigentlich so zur Pflichtlektüre gehört. Ich kenne das Buch "Code Complete" nicht aber ich denke, das meiste, was man dort findet, findet man auch im Buch "Clean Code". Zumindest liest sich die Agenda sehr ähnlich. Man darf auch nicht vergessen, dass Robert C. Martin als einer Erfinder des Begriffs "SOLID" gilt, was die Welt der objektorientierten Programmierung der letzten 10 Jahren sehr geprägt hat. Ansonsten könnte man noch Begriffe wie Test-driven Development (TDD) und Design-driven Design (DDD) in den Ring werfen. Dazu gibt es dann auch noch haufenweise Bücher aber das sind Praktiken, die man Anwenden kann, wenn man schon mehr Erfahrungen gesammelt hat.

In Japan gilt eigentlich per Gesetz die 40-Stunden-Woche. Einigen Unternehmen ist es auch gestattet, dies auf 44 Stunden auszuweiten. Darunter zählen z.B. Einzelhandelsgeschäfte oder Kinos. Das Bild des Arbeitswütigen Japaners stammt aus den 80ern und noch in die 90er hinein. Damals gabs Todesfälle wegen Überarbeitung aber dies wurde von denen gar nicht verlangt. 1997 hat man dann die 40-Stunden-Woche per Gesetz verabschiedet um der Arbeitswut Einhalt zu gebieten und so viel ist von der Arbeitswut auch gar nicht mehr übrig. Sie ist zwar immer noch recht hoch, aber inzwischen wollen die Japaner auch mehr Zeit für sich und ihrer Familie haben. Viele Firmen bieten sogar inzwischen eine 4-Tages-Woche an. Auch sind die Japaner sehr sozial eingestellt. So übernehmen viele Firmen auch inzwischen die Kita-Kosten, geben einen Mietzuschuss oder bezahlen Kindergeld. Davon können wir hier nur Träumen. Auch wenn man eine sehr lange Zeit Krank ist, bekommt man oft sein Gehalt sechs Monate ausgezahlt. Hier sind es nur 6 Wochen. Danach gibt es hier nur das Geld der Krankenkasse. Es bleiben also nichts weiter als Klischees übrig.

Ja, das Buch ist zu empfehlen und eines der Pflichtlektüre, wenn es um Clean Code geht. Es ist aber ein Irrglaube, wenn du denkst, dass Clean Code gleichzeitig auch eine bessere Performance bietet. Clean Code ist einfacher zu lesen und zu warten aber das hat nichts mit Performance zu tun. Um Performance würde ich mir auch erst mal keine Gedanken machen, sondern es geht erst mal darum, sein Code sauberzuhalten. Wie Einrückungen gemacht werden ist Geschmackssache und auch von Sprache zu Sprache unterschiedlich. Java und C# haben eine nahezu identische Syntax und dennoch sind die empfohlenden Namenskonventionen von Klassen/Methoden unterschiedlich. Während in z.B. Java empfohlen wird, eine Methode so zu schreiben: public void method() { // mach was } Wird sie in C# so empfohlen: public void Method() { // mach was } Und Python definiert die Blöcke nicht mit geschweiften Klammern, sondern mit Tabs. Da wird man also gezwungen, sauer einzurücken. Man muss aber auch darauf achten, dass hier Java gemeint ist, denn in der C#-Welt wird dies ebenfalls nicht empfohlen. In der C#-Welt ist es üblich, dass Interfaces mit einem großen I anfangen und für den eigentlichen Namen nimmt man ein Adjektiv (z.B. IDisposable) oder ein Nomen (z.B. IList). In C# endet auch die konkrete Implementierung nicht mit Imp oder Impl. Das braucht man auch nicht, da schon durch das große I erkennbar ist, was ein Interface und was eine Klasse ist. (z.B. die Klasse List implementiert das Interface IList).

Warum nicht? Ob ich jetzt mehrere Threads auf einer Maschine oder mehrere Prozesse auf mehreren Maschinen starte, spielt für die Parallelität keine Rolle. Fakt ist, es wird parallel etwas verarbeitet.

Anstatt einen Monolithen zu bauen wird heutzutage die Microservice-Architektur bevorzugt. Man startet also nicht einzelne Threads, sondern ganze Prozesse, die untereinander mit einem Messagebroker kommunizieren. Die Microservice-Architektur lässt sich auch einfacher skalieren, da die Microservices auf unterschiedliche Server gehostet werden können und für jeden Microservice kann dann eine geeignete Persistenzschicht gewählt werden. Weil das vielfach einfach nicht nötig tut und over-engineering wäre. So lange es auch auf andere Wege funktioniert, die einfacher zu händeln sind, würde ich nicht auf eine Parallisierung setzen. Nicht überall ist eine Parallisierung schneller, da eine Parallisierung auch mehr Overhead bedeutet. In einigen Fällen ist eine Parallisierung sogar auch langsamer als eine sequentielle Abarbeitung. Besonders wenn die Threads miteinander kommunizieren und aufeinander warten müssen.

Nicht immer ist eine Parallelisierung sinnvoll. Eine Parallelisierung ist nur dann sinnvoll, wenn man auch wirklich eine Berechnung parallelisieren kann und diese auch von der Parallelisierung profitiert. Etwas zu parallelisieren, nur damit die Berechnung 2 Sekunden dauert, anstatt 5, ist einfach unnütz. Du wirst selbst heute noch sehr wenig mit Parallisierung zu tun haben. Eher mit Nebenläufigkeiten, um Daten asychron zu berechnen/zu laden. Parallelisierung wird oftmals erst zum Thema, wenn es Performanceprobleme gibt. Ehrlich gesagt, würde ich mich schon freuen, wenn ich sogar von Entwicklern mit mehrjähriger Erfahrung kein Spaghetticode mehr ansehen muss. Es ist einfach traurig, dass selbst viele Freiberufler und Consulting Agenturen noch nie etwas von Clean Code oder SOLID gehört haben. Aber zum Thema: Warum sollte man es nicht erwähnen, dass man sich mit Themen wie Nebenläufigkeit schon mal auseinandergesetzt hat? Man erwartet ja kaum in Vorstellungsgesprächen, dass er alles ins Detail kennt. Selbst die Stichworte, die der TE aufgeschrieben hat, ist mehr als so manch ein Diplominformatiker weiß. Beim Vorstellungsgespräch kann man ja mit offenen Karten spielen und sagen, dass man sich bis jetzt nur in der Theorie damit auseinandergesetzt hat. Wenn ich einen Azubi einstellen würde, würde ich es auch nicht mal verlangen, dass er weiß wie man so etwas programmiert.

Naja, was will man auch erwarten? Du bist kein ausgebildeter fachinformatiker, sondern die Firmen soll dich ausbilden. Wenn du schon alles weißt, bräuchtest du ja keine Ausbildung mehr. Außerdem muss man sich ja aus der Menge herausstechen. Da könnten solche Fachbegriffe schon hilfreich sein.

Warum sollte man sowas nicht erwähnen? Das zeigt, dass du dich intensiver mit den Themen beschäftigst und da es um ein Ausbildungsplatz gehen soll, kann man sowieso nicht erwarten, dass du schon alles kennst. Die Nebenläufigkeit und die Parallelisierung sind auch ein sehr komplexe Themen. Siehe z.B. das Philosophenproblem (mal unter Wikipedia suchen).

Ich gehe davon aus, dass er/sie meinte, dass der Informatiker nicht wissen muss, wie man ein Drucker oder ein Betriebssystem installiert. Informatiker wurden dann oft in der Wissenschaft eingesetzt um z.B. Algorithmen zu entwerfen. Da braucht man eigentlich keine Programmier-, oder Administratorkenntnisse. Die Informatik ist die Wissenschaft Informationen systematisch zu verarbeiten. Von Programmieren ist da erst einmal keine Rede.

Ja, das tun sie. Aus mehreren Gründen: Die Anforderungen der Firmen gegenüber den Azubis ist deutlich gestiegen. Wo man früher zu meiner Zeit (ich bin jetzt 32 Jahre alt) Azubis noch mit Haupt- und Realschulabschluss eingestellt heute, wird heute schon Fachhochschulreife oder Abitur verlangt. Es ist schon sehr schwer, überhaupt Firmen zu finden, die ausbilden. Ich wohne in Raum Hamburg (aber noch in Schleswig-Holstein) und obwohl Hamburg neben Berlin als DIE IT-Stadt in Deutschland gilt, gibt es kaum Firmen, die FIAEler ausbilden. Auf der IHK-Lehrstellenbörse sind es gerade mal 18 Lehrstellen. Sind die Reaktionszeiten einiger Firmen extrem hoch. Von vielen Firmen bekommt man nicht mal eine Antwort. Ist das Einstigsgehalt eines Studienabsolventen höher, als einem Absolventen einer Ausbildung. Kann ich dir sagen: Die Anforderungen der Schulen werden weiter gesenkt. In Schleswig-Holstein ist es schon so, dass man ab der siebten Klasse nicht mehr sitzenbleiben kann. Man wird also komplett bis zur neunten Klasse durchgeschliffen und hat dann automatisch den Hauptschulabschluss (oder wie sich dieser heute nennt). In Schleswig-Holstein hat man auch nun die Noten der letzten Jahre verglichen und festgestellt, dass sie durchschnittlich so schlecht wie noch nie waren. Als Konsequenz daraus, wir das Niveau an Schulen wohl noch weiter gesenkt. Die andere Seite der Medaille ist aber, dass Schleswig-Holstein noch nie so viele Abiturabsolventen mit einem Schnitt von 1,0 hatte. Früher gabs pro Schule vielleicht alle drei oder Jahre mal so einen Absolventen. Heute sind es gleich mehrere pro Jahr. Da kann man eigentlich sehen, dass das heutige Abitur-Niveau eher dem Niveau des damaligen Realschulabschlusses gleicht. Das Bildungssystem von Schleswig-Holstein galt damals, gleich nach Bayern, als das härteste System in Deutschland. Bei den Wirtschaftsinformatikern spricht man auch Klischeehaft von den BWLern der Informatik. Ein Wirtschaftsinformatiker programmiert eigentlich auch nur sehr wenig, sondern ist eher für die Planung der Anwendungssysteme zuständig, um den Betrieb zu optimieren und automatisieren. Wenn du also Wirtschaftsinformatiker suchst, die auch programmieren können sollen, dann musst du schon schauen, wie deren Studium aussah. Allgemein kann man aber sagen, dass Wirtschaftsinformatiker, die auf einer Fachhochschule studiert haben, eher das Programmierhandwerk gelernt haben, als Absolventen einer Universität. Ja, das halte ich auch für Problematisch. Die Medienwelt spricht zwar von der "digital native"-Generation, da die jungen Leute heute mit Internet, Smartphones und Co. aufwachsen, aber kaum ein jugendlicher macht sich noch Gedanken darüber, wie die Technik überhaupt funktioniert. Ich gehe auch stark davon aus, dass nur die wenigen Jugendlichen wissen, was überhaupt ein Byte ist. Witzig fand ich auch die Story eines Arbeitskollegen, der berichtete, dass sein Sohn nicht mal mehr weiß, was eine Diskette ist aber gleichzeitig ist das heutige "Speichern"-Symbol immer noch eine Diskette. Die Jugendlichen kennen also das "Speichern"-Symbol, wissen aber gar nicht was das Symbol darstellen soll.

Nein. Ein Zeichensatzproblem wäre es nur, wenn anstatt ä ein kryptisches Zeichen geschrieben wird. Das ä wird dann vorher in ein ae umgewandelt.