Umbratus

Sorry, aber das ist keinesfalls angebracht. Die Ich-Form wirkt sehr stümperhaft, wenn du noch die Zeit hast würde ich dir dringend raten alles Ichs zu entfernen. Ich setz mal diesen Satz noch als Negativ-Beispiel in Sachen Zeiten und Ich-Form: "Nach ausgiebiger Testphase implementierte ich den Server Im Rechenzentrum mit Herrn Wiebe, der für die Infrastruktur der Server zuständig ist." Klingt furchtbar findest du nicht ?

1. Person Singular sollte man vermeiden, das soll keine Prosa sein sondern eine technische Dokumentation. Am besten in Präsens schreiben. Bei dir wechselt es alle zwei Sätze zwischen Gegenwart und Vergangenheit.

Das ist imho die schlechteste aller Lösungen.

Vielleicht ist der Unterschied eben grade, dass ich weit vom Alter eines jugendlichen Azubis entfernt bin und ich deshalb nix mit euren (die PA's in diesem Forum) sicher gutgemeinten Tipps anfangen kann. Nix für ungut, weiter im Thema.

Man kann ein brisantes Thema durchaus ohne die Notwendigkeit den kompletten Code anzuhängen durchziehen, da wie ich meine, Struktogramm-Schnipsel von zentralen Stellen viel mehr aussagen als ein seitenlanges Genudel von Spaghetti-Code oder unübersichtlichen Klassen-Gewülsten. Mein PA hat händeringend nach Fragen gesucht die sie mir noch stellen können um dann das Fachgespräch nach 5min zu beenden und mich mit 100 Punkten nach Hause zu schicken. Ein kompletter Quellcode hätte den PA schlichtweg überfordert, die "Möglichkeiten" bleiben oft hinter der Realität zurück.

Dazu kann ich nur sagen: Quatsch. Viele Firmen sehen das sogar als Betriebsgeheimnis. Und um die Programmier-Skills zu zeigen genügen allemal Auszüge. Sicher is das unterschiedlich, also am besten bei der zuständigen IHK nachfragen.

Wenn du in diesem Deutsch deine Doku schreibst ist es relativ egal was du mit den Scripten machst. Ne im Ernst: Es ist nicht nötig den ganzen Code anzuhängen, Auszüge genügen.

Dein PA wird das wenig kümmern ob du das interessant findest oder nicht. Einige bestehen nunmal mehr andere weniger auf diese Vorgabe. Damit du nicht nur deinen eigenen Ansprüchen genügst sondern auch denen deines PA's, solltest du dich unbedingt bei deiner IHK erkundigen.

Tja, das hängt von der Zielgruppe ab. Wenn du z.B. Kunde angibst interessiert diesen kaum, wie du das Projekt im Detail umgesetzt hast, vielmehr aber das Ergebnis.

Und was wenn du Fehler "zufällig" nicht findest, sondern diese erst beim Anwender deiner Software auffallen ?? Testen immer auf NICHT-Funktion. Deine Funktionen sollen optimalerweise immer das richtige Ergebnis liefern und nicht nur im "Idealfall".

Wie war denn die Aufgabenstellung ??

Das solltest du nochmal nachrechnen *g*

Techniker kostet zum ersten Geld, zum zweiten braucht man 2 Jahre Berufserfahrung. Kuck dir mal an was man alles für IT-Specialists machen kann, das setzt zwar auch 2 Jahre Erfahrung vorraus und steckt noch in den Kinderschuhen, geht aber immerhin berufsbegleitend und man muss nicht auf die Schule. Ich werd in 1,5 Jahren nen Specialist in Angriff nehmen, denk ich.

Nun, für das Schulabschlusszeugnis zählt die Einreichnote. Und zwar zählt die Prüfungsnote doppelt soviel wie die Einreichnote, wenn ich mich recht erinner. Für den Facharbeiterbrief der IHK hat die schulische Einreichnote keinerlei Bedeutung.

Dito. Tipps & Tricks aus Paderborn und Umgebung (Gruß an Timmi-Bonn sind mit Vorsicht zu genießen. Man neigt dort dazu sich mit dem gesamten Bundesgebiet gleichzusetzen und alles in Schubladen zu stecken.

Wir hatten schonmal geklärt das Paderborn nicht gleich der Welt ist, bei meiner IHK is das für AE kein Bewertungskriterium.

Du kommst seit einem Jahr mit den selben Schlagworten ehrlich gesagt glaub ich dass du nicht nur kurz reingekuckt sondern nur nach den Überschriften gekuckt hast um deinen üblichen Senf dazu abzugeben. Ich schätz mal die Hälfte deiner Posts beinhalten: "Ist- Soll-Zustand sowas gibts nicht, dass muss Ist-Analyse und Soll-Konzept heissen" und "Ohne Kosten-Nutzen-Analyse kannst du ja garkeine gute Note bekommen" Sorry, das is Quatsch, ich mein es wirklich nicht persönlich. Es ist absolut okay Ist- und Soll-Zustand zu schreiben, es kommt auf den Inhalt an und nicht auf Überschriften nach Schema F. Eine fehlende Kosten-Nutzen-Rechnung führt nicht zwangsläufig zu Punktabzug. Mag das A und O für Kaufleute sein und wichtig bei den Integratoren. Ich fand auch die Doku von Herrn Rüd sehr kurz und knapp.

Das Glossar sollte man wohl alphabetisch sortieren. Besonders gut gefällt mir die Darstellung der Erkenntnis Zeitinvestition in Planung und Pflichtenheft spart Zeit bei der Realisierung. Die Formatierung der Inhaltsverzeichnisse gefällt mir persönlich nicht so gut. Ansonsten ehrlich und transparent, gibt sicher ne gute Note.

Hehe, unglaublich wieviel Code doch immer wieder für die Mülltonne erstellt wird. Wer soll sich jemals in dem von dir erstellten Programm zurecht finden bzw darauf aufsetzen. Und noch ein Nachtrag: Ob du beispielsweise ein Array in einer Schleife durcharbeitest oder jedes Element einzeln nacheinander ändert an der "Performance" garnix. Nur ist ersteres viel besser lesbar. Das ganze hier zeigt nur dass du von programmieren keinen Schimmer hast. Um zum Thema des Threads zurück zu kommen: Verzichte lieber komplett darauf deinen "Code" in den Projektanhang zu setzen und behandel es lieber als Betriebsgeheimnis, vielleicht kannst du so einigen unbequemen Fragen im Fachgespräch aus dem Weg gehn.

Kleiner Nachtrag noch dazu: Golden Rules of Programming 1. First think, then program. 2. As simple as possible. 3. No tricks and no mess. 4. A slow, but working program is better than a fast, but faulty program. 5. Comment immediately, not afterwards. 6. Remove poor codes and re-write during changes. 7. Set the warn level of the compiler as high as possible. 8. Always pay attention to warnings of the compiler. Notes: 1. Please don’t apply a “trial&error“ method for the program development. The best thing is to write down your thoughts on a paper first, before entering them into the computer. This is already a first “code reading“ of your writings, from which the program may only benefit (just try it!) 2. Perfection does not mean, that you cannot add anything more, but when nothing may be removed any longer. 3. A beautiful collection for scaring c programs may be found at the IOCCC (International Obfuscated C Code Contest). Anyone who wants to immortalize himself, may do this here and not during the daily programming work. 4. Before thinking about the efficiency of a program, you should think about the correctness and readability of a program or a program design. The improvement of the performance should not be started before the functions work properly. The possibility of tuning by programming are mostly overestimated. 5. In any case, the marginal conditions and possible bugs should be commented. 6. The effort to find your way into a poor code is much higher than for a new implementation. Of course, this should be written in a readable and commented way, so that further changes are possible without time-consuming training or mental acrobatics. 7. It does not have to be the highest warn level in any case, but the highest warn level possible. The warning should not be switched off under no circumstances. 8. Warnings of the compiler are always potential failure sources and should not be taken lightly.

Was hat man dir nur beigebracht :confused:

Wenn man Zugriffe auf Datenbanken nicht in Schleifen abhandeln kann, was dann ?

In der Tat. Solch Gewurstel sollte man lieber geheim halten.

Nur Geduld, du wirst rechtzeitig benachrichtigt werden. Wenn dus nicht erwarten kannst, ruf halt bei der IHK an oder schick ne Email.

Ich hätte mir garnicht erlauben können den kompletten Quellcode anzuhängen, da dieser unter das Betriebsgeheimnis fällt. Dies ist auch zu beachten !