Programmiertechniken

errox · 10. Februar 2015

Hallo Zusammen,

also vorab: Falls dieser Thread falsch sein sollte, dann bitte verschieben. Ich hab gedacht, dass das hier am besten rein passt.

Ich würde gerne neue Programmiertechniken kennen lernen (Oder wie auch immer dieser Begriff heisst)

Hier eine Liste was ich kenne:

Datenbanken:

- Index, Indizes (Damit ein Select auf dieser Spalte schneller funktioniert)

- LEFT, RIGHT, INNER JOIN (Sollte eigentlich bekannt sein)

- Trigger (Aktionen vor einem Select / Nach einem Insert, Vor einem Update, usw. ausführen)

- Stored Procedures (Abfragen die auf dem Server gespeichert sind, die nur Parametrisiert ausführen)

- Views (Abfragen zusammenfassen, auf dem Server gespeichert)

Programmiersprachen:

- Klassen

- Interfaces

- Reflection (Weniger bekannt, aber dient dazu Klassen zur Laufzeit zu erzeugen und Properties als Text zu laden, uvm.)

- Interfaces (Sollte auch bekannt sein)

- Vererbung

- Multithreading

Es gibt bestimmt noch mehr. Mir würden Stichworte reichen. Den Rest würde ich selber Recherchieren.

Ein Beispiel: Wenn man Trigger kennt, kann man aktionen viel einfacher ausführen. Anwendungsbeispiel: Man hat eine Tabelle von GPS Koordinaten die man befüllt, und der Trigger befüllt den letzen Punkt automatisch in einer Tabelle.

Oder Reflection ist auch weniger bekannt. Wenn man eine Datenbanktabelle als Klasse abbilden möchte oder ein serializiertes Objekt, kann man damit einfacher / angenehmer arbeiten (Simples beispiel)

Gibt es noch irgendwas, was hier nicht aufgelistet ist?

Vielen Dank und liebe Grüße

errox

Mttkrb · 10. Februar 2015

Hallo,

folgende Punkte fallen mir noch spontan ein:

-Sockets

-REST

-JSON

-RPC

-Objektrelationale Mapper

-Hardwarenahe Programmierung (Assembler, Treiber/IO-Devices, embedded,Signalverarbeitung,...)

-Pattern (MVVM,Adapter,Singleton,Factory,...)

-Programmierung numerischer Verfahren (Liste numerischer Verfahren)

-anonyme Funktionen (Lambda-Ausdrücke) in verschiedenen Sprachen (C++,C#,Java,...)

-GUI Programmierung mit verschiedenen Frameworks

und und und...

Bearbeitet 10. Februar 2015 von Jogibaer0411

SynonymOfGod · 10. Februar 2015

Hey,

ich verstehe nicht so ganz was das hier soll... sich konzepte angucken und oberflächlich zu verstehen nutzt niemanden...

und alles was du oben erwähnt hast kennt wohl jeder entwickler mit nem jahr berufserfahrung

aber hier mal meine buzzwords

mpi

openmp

hpc

physic engine

dll - so

IPC

reverse engeneering

thread synchronize(mutex, semaphore, lock free, wait free etc)

errox · 10. Februar 2015

Hallo.

Erstmal danke für das Feedback. Das meiste kenn ich aber lambda ist mir komplett fremd.

Zu der Aussage: das sollte man meinen. Das dachte ich auch. Ich war letzens auf einem (nicht gerade günstigen) Seminar. Dort wollte man eine Schnittstelle bauen von WaWi zu PIM System.

Gelöschte Artikel sollten erkannt und übermittelt werden, und in eine seperate Tabelle eingetragen werden. Anstatt einen DELETE Trigger zu verwenden, wurde ein Watchdog Programmiert, der alle 10 Sekunden die Tabelle abfrägt, und die nicht mehr vorhandenen Artikelnnummern in eine seperate Tabelle schreibt.

Deswegen frag ich lieber mal im Forum nach

mfk'); DROP TABLE Users;-- · 11. Februar 2015

Gelöschte Artikel sollten erkannt und übermittelt werden, und in eine seperate Tabelle eingetragen werden. Anstatt einen DELETE Trigger zu verwenden, wurde ein Watchdog Programmiert, der alle 10 Sekunden die Tabelle abfrägt, und die nicht mehr vorhandenen Artikelnnummern in eine seperate Tabelle schreibt.

Dir ist klar, dass die Watchdog-Methode die Systemlast begrenzt?

Mttkrb · 11. Februar 2015

Es fehlen halt Grundsätzliche Fragen in welche Richtung er sich spezialisieren möchte.

Wenn ich mich auf Datenzugriffe einer SQL-Datenbank spezialisiere, werde ich selten bis gar nicht in Berührung mit Assembler kommen.

Ich habs eher sportlich gesehen. Es wurde nach ein paar Buzzwörtern gefragt, hier sind sie. ;-)

errox · 11. Februar 2015

Dir ist klar, dass die Watchdog-Methode die Systemlast begrenzt?

-> Ja ist mir klar. Aber dem Seminarleiter nicht. Der Seminarleiter kannte keine Trigger. Er wusste nicht was das ist.

Ich habs eher sportlich gesehen. Es wurde nach ein paar Buzzwörtern gefragt, hier sind sie. ;-)

-> Ja vielen dank dafür

afo · 11. Februar 2015

Ich würde gerne neue Programmiertechniken kennen lernen (Oder wie auch immer dieser Begriff heisst)

* Funktionale Programmierung

* Logische Programmierung

* Memory-Management und Pointer "von Hand" -> C

* Andere "Schulen" der Objektorientierung. Wenn du vom Smalltalk-Pfad her kommst (Java z.B.) dann eine Sprache der Simula_Famile (C++ z.B.) und prototypenbasierte Objektorientierung (Javascript)

* Andere Philosophien der Objektorientierung -> weg von den "datenlastigen" Objekten, hin zu verhaltensbasierten Objekten (Object Thinking von David West)

Wenn du noch weitere Anregungen brauchst lies einfach mal http://www.amazon.de/dp/B0043D2EEU/

Ulfmann · 12. Februar 2015

ich verstehe nicht so ganz was das hier soll... sich konzepte angucken und oberflächlich zu verstehen nutzt niemanden...

Das hab ich mir auch sofort gedacht. Dazu kommt ja, dass bis hierhin verschiedenste Begriffe durcheinander geworfen werden, die z.T. völlig sprachabhängig sind. Also vielleicht muss man hier erstmal rausfinden, was jetzt mit "Programmiertechniken (Oder wie auch immer dieser Begriff heisst)" gemeint ist. Klassen, Interfaces, Vererbung - das sind Elemente des Objektorientierten Paradigmas. Joins, Trigger, Index - das gehört in die relationale Datenverarbeitung usw. Das sind aber doch keine Programmiertechniken.

Ich schmeiß an diesem Punkt mal Test Driven Development rein und wundere mich auch öfter mal, wie wenig Testing als solches erwähnt wird (das ist aber ein anderes Thema). TDD ist eben so eine besagte Programmiertechnik oder anders gesagt eine Methodik, um Code zu schreiben, die meist eng mit agiler Software Entwicklung verbunden ist und u. A. auch häufig über Pair Programming betrieben wird. Ich hab inzwischen auch Entwickler kennen gelernt, die sich damit sehr schwer tun und es eher ablehnen, aber ich bin der Meinung, wenn man diese Art zu entwickeln vernünftig beigebracht bekommt, ist es sehr effektiv und macht Laune.

Um das ganze abzurunden, hier noch 2 Literaturtipps, die jeder gelesen haben (oder zumindest kennen) sollte:

- The Clean Coder

- The Pragmatic Programmer

SynonymOfGod · 12. Februar 2015

Das hab ich mir auch sofort gedacht. Dazu kommt ja, dass bis hierhin verschiedenste Begriffe durcheinander geworfen werden, die z.T. völlig sprachabhängig sind. Also vielleicht muss man hier erstmal rausfinden, was jetzt mit "Programmiertechniken (Oder wie auch immer dieser Begriff heisst)" gemeint ist. Klassen, Interfaces, Vererbung - das sind Elemente des Objektorientierten Paradigmas. Joins, Trigger, Index - das gehört in die relationale Datenverarbeitung usw. Das sind aber doch keine Programmiertechniken.

Ich schmeiß an diesem Punkt mal Test Driven Development rein und wundere mich auch öfter mal, wie wenig Testing als solches erwähnt wird (das ist aber ein anderes Thema). TDD ist eben so eine besagte Programmiertechnik oder anders gesagt eine Methodik, um Code zu schreiben, die meist eng mit agiler Software Entwicklung verbunden ist und u. A. auch häufig über Pair Programming betrieben wird. Ich hab inzwischen auch Entwickler kennen gelernt, die sich damit sehr schwer tun und es eher ablehnen, aber ich bin der Meinung, wenn man diese Art zu entwickeln vernünftig beigebracht bekommt, ist es sehr effektiv und macht Laune.

Um das ganze abzurunden, hier noch 2 Literaturtipps, die jeder gelesen haben (oder zumindest kennen) sollte:
- The Clean Coder
- The Pragmatic Programmer

Ich bin um ehrlich zu sein auch kein Fan von TDD und agiler Entwicklung. In meinen jetzigen Unternehmen wird dies praktiziert und ich kann mich dafür einfach nicht erwärmen. Liegt aber wohl an mir selbst, da alle anderen im Team super damit klar kommen und damit prahlen was für scrum Zertifizierungen sie denn haben

Ulfmann · 13. Februar 2015

Ich bin um ehrlich zu sein auch kein Fan von TDD und agiler Entwicklung. In meinen jetzigen Unternehmen wird dies praktiziert und ich kann mich dafür einfach nicht erwärmen.

Is ja völlig in Ordnung. Ich wollte ja nicht dafür plädieren, dass TDD alle Probleme der Software Entwicklung löst und objektiv die besten Methodik ist. Da gibt es ja schon noch diverse Alternativen. Ich wollte wie gesagt nur mein Verständnis von Programmiertechniken darlegen und ein Beispiel nennen, das ich bisher am effektivsten empfinde. Mein jetziges Team steht auch überhaupt nicht auf TDD und tut sich generell auch sehr schwer, ausreichend Fokus auf einer zumindest passablen Testabdeckung zu haben. Für mich fühlt sich das oft sehr umständlich an, wenn fertige Features immer nur durch Rumklicken im Browser "getestet" werden. Aber ich schweife ab...

Liegt aber wohl an mir selbst, da alle anderen im Team super damit klar kommen und damit prahlen was für scrum Zertifizierungen sie denn haben

Das sind aber auch 2 paar Schuhe. Scrum gibt dir ja in gewisser Weise nur die Rahmenbedingungen, innerhalb derer TDD ganz gut klappt. Muss aber nicht! Und Zertifizierungen sind auch lange kein Garant dafür, dass man es richtig praktiziert.

Bearbeitet 13. Februar 2015 von Ulfmann

lilith2k3 · 14. Februar 2015

Ich bin um ehrlich zu sein auch kein Fan von TDD und agiler Entwicklung.

Was sind die Alternativen? Wasserfall und auf Tests verzichten?

Ich denke, Software kann sinnvollerweise ausschließlich agil entwickelt werden. Dafür sind die Budgets zu eng gesteckt und die Quote der Projekte, die in den Sand gesetzt werden zu hoch. Nur in dem kleinteilig und im engen Kundenkontakt entwickelt wird, kommt etwas, das der Kunde bezahlen will bei rum. Ansonsten ist die Gefahr zu groß, dass die beiden essentiellen Fragen Â»Are we building the right productÂ« bzw. Â»Are we building the product rightÂ« negativ beantwortet werden müssen.

Insofern ist es nicht die Frage, ob man Â»FanÂ« von agiler Softwareentwicklung ist.

Das gleiche gilt für TDD. Die Frage ist nicht, ob man anders als mit Test Driven Development gute Software schreibt - oder man auch hiervon Â»FanÂ« ist; sondern wie sieht die Unternehmenskultur aus, in welcher man TDD praktiziert. Von vielen wird TDD als religiöser Kult betrieben mit streng orthodoxen Vorgehensweisen - was die grundlegende Idee ad absurdum führt: es gibt auch sinnfreie Tests. Wenn man allerdings die logische Kette von Kundenanforderungen über Usecases zu Testcases betrachtet, so ist TDD das Vorgehen, das hilft, oben genannte Fragestellungen mit einem Klick zu beantworten. Es ist auf einen Blick ersichtlich wieviele der Anforderungen umgesetzt sind. Insofern ist TDD aus organisatorischer Sicht in Kombination mit agiler Entwicklung das Vorgehen der Wahl.