Ein Projekt, zwei Vorgehensweisen und Eure Meinung...
-
guten Tag zusammen,
es geht um folgendes. In der Fachhochschule besuchte ich das letzte Semester ein Fach indem ein C++ Projekt umgesetzt werden sollte. Es wurden zwei Gruppen mit je 10 Studenten gebildet die jeweils ein eigenes Projekt mit einer eigenen Struktur entwickeln sollten. Ziel ist es zunächst ein Hauptprogramm zu entwickeln das mit Modulen erweiterbar ist. Es spielt jetzt keine Rolle um welches Thema es genau geht, aber damit man sich es besser vorstellen kann, sage ich mal es geht um ein Bildbearbeitungsprogramm.
Das Hauptprogramm hat grundlengende Funktionen wie Bild laden, Bild speichern, usw..
Jeder Student soll nun ein eigenes Modul schreiben, z.B. Farben invertieren oder einen Weichzeichnerfilter, mit dem das Hauptprogramm erweitert werden kann. Es muss also eine Schnittstelle oder etwas dergleichen existieren zwischen Hauptprogramm und den Modulen.
Jetzt gibt es zwei Lösungsvorschläge. Ein Vorschlag kommt von dem Professor selbst und ein anderer hat ein Student entwickelt. Wer was gemacht hat lasse ich jetzt mal offen, damit nicht im Vorfeld geurteilt wird. Ich verrate aber jedoch schon, dass dieses Thema für ordentlich Zündstoff gesorgt hat.
Ich stelle nun beide vor:Variante 1:
Jeder Student bekommt das Hauptprogramm als offenes C++ Projekt. Der Student nimmt dieses Projekt und fängt an darin sein Modul zu bauen. Er legt eine eigene Form an (Windows Fenster) und designd dieses. Ebenfalls ist er selbst dafür verantwortlich wie er z.b. an Daten wie das geladene Bild, die Breite und Höhe bekommt. Er Coded quasi alles direkt in das Hauptprogramm. Hat er sein Modul nun fertig gestellt, kompiliert er das ganze Projekt und sieht sein Modul in dem Programm.
Ab dem Zeitpunkt, an dem alle Studenten auf diese Weise ihr Modul fertig erstellt haben, setzen sie sich zusammen und fügen ihre Module zusammen. Das geschieht indem z.B. an einem Rechner alle Quellcodes in ein Projekt eingebunden werden und das komplette Projekt kompiliert wird. Es gibt dann also ein (ich nenne es mal) Master-Projekt mit allen Modulen.Variante 2:
Statt das jeder Student das Hauptprogramm als offnenes Projekt bekommt, bekommt jeder Student das fertig kompilierte Hauptprogramm. Zusätzlich bekommt der Studen ein kleines SDK womit ihm eine Schnittstelle zur Verfügung gestellt wird. Diese Schnittstelle beinhaltet alle notwendigen Daten wie das Bild, Breite, Höhe und eine Form, welche editiert werden kann. Der Student entwickelt darüber sein Modul und kompiliert nun eine eigene DLL Datei. Diese DLL Datei wird unabhängig von dem Hauptprogramm kompiliert.
Um das Modul (also die DLL Datei) in das Hauptprogramm einbinden zu können, muss der Student diese Datei in einen vorgesehen Ordner schieben. Beim Programmstart, wird das Modul automatisch erkannt und im Projekt angezeigt. Das Hauptprogramm wird also nicht komplett kompiliert sondern nur um die Module dynamisch erweitert.Das sind beide Varianten und mich würde jetzt interessieren, welche Variante ihr bevorzugen würdet. Stellt euch auch vor, so etwas als Auftrag einer Firma umzusetzen und geht die Vor- und Nachteile durch.
Ich selber habe einen deutlichen Favouriten und mich würde interessieren, welche Variante ihr bevorzugt.
Warum ich das hier mache und welche Variante ich bevorzuge, sowie die Vor- und Nachteile aus meiner Sicht, werde ich später dann erklären.
-
Ich bin definitiv für Variante 2.
Bei Variante 1 sehe ich das Hauptproblem, dass einzelne Studenten das Hauptprogramm verändern (insbesondere wenn sie noch keine große Erfahrung miot solchen Projekten haben) und sich die einzelnen Komponenten dann nicht ordentlich mehr zusammenfügen lassen.
Ein Vorteil von Variante 2: Es werden vorab klare Schnittstellen vereinbart, so dass sich die einzelnen Komponenten auch einheitlich einfügen. Bei Variante 1 kann es passieren, dass die Featueres alle auf vollkommen unterschiedliche Weise integriert werden und sich das gesamte Programm nicht einheitlich bedienen lässt.
-
Naja, beide Alternativen haben ihre Vor- und Nachteile.
Variante 1 geht bei einem kleinen, gut funktionierenden Team (welches auch etwa denselben Kenntnisstand hat) sehr gut. Aber der eine kann dem anderen das Leben ungewollt sehr sehr schwer machen. Ich würde es aber auch soweit abändern, dass alle gleichzeitig auf dem aktuellen Projekt rumschrauben (sprich auf demselben Repository-Pfad arbeiten) und nicht erst am Ende alles zusammenstecken müssen.
Aber sobald die Teamgröße mehr als 3-4 Mann übersteigt, wo auch noch verschiedene Erfahrungen durchgesetzt werden wollen von jedem, kannst du auch gleich einen Kleinkrieg anfangen mit deinen "Freunden"
Der Vorteil ist aber, wie ich finde, ganz klar, dass es bis zu einem gewissen Umfang ziemlich einfach sein sollte. Man hat halt keinen Overhead durch Moduleinbindung und der Compiler kann noch alles mögliche prüfen.Variante 2 lohnt sich bei größeren Projekten mit mehreren Leuten (wie bei euch 10 Leute). Es ist ein gewisser Grundaufwand vorhanden und auch eine gewisse Einarbeitungszeit, aber sobald das Interface steht und auch halbwegs stabil ist, sollte das ganz gut laufen. Vor allem ist man nicht davon abhängig, dass die Module der anderen Fehlerfrei sein müssten.
Ein blöder Nebeneffekt ist (wie ich finde), der Compiler kann dir beim Überschreiten der Modulgrenzen nicht mehr helfen. Hast du dich mit dem namen einer Funktion vertippt oder ein Parametertyp passt nicht, dann wird dir erst zur Laufzeit der Fehler um die Ohren fliegen. Bei Variante 1 passiert das zur Compilezeit, das ist schon angenehm.Ich rate dann auch einfach mal und sage, Variante 1 wurde vom Dozenten vorgeschlagen
PS: Das gehört eigentlich ins "Rund um die Programmierung"-Subforum...
-
Schonmal zwei interessante Antworten. Bin auf weitere gespannt.
Skym0sh0 schrieb:
PS: Das gehört eigentlich ins "Rund um die Programmierung"-Subforum...
Sorry, der Admin kann das bestimmt entsprechend verschieben ?!
-
Variante 1 hört sich in der Form sehr chaotisch an. Vor allem "Ab dem Zeitpunkt, an dem alle Studenten auf diese Weise ihr Modul fertig erstellt haben, setzen sie sich zusammen und fügen ihre Module zusammen."
Das ist nämlich auch das Problem. Sonst seh ich hier keinen so großen Unterschied. Eine Schnittstelle muss man so oder so vereinbaren, ob das eine Binärschnittstelle + SDK ist, oder eine "Source" Schnittstelle und jeder macht sein Modul rein, ist erstmal ziemlich egal. Man muss sich nur vorher Gedanken darüber machen, wie die Schnittstelle auszuschauen hat und jeder hält sich dran. Alles andere sind fürs Konzept irrelevante technische Details.
Problematisch wirds nur, wenn jeder erstmal irgendwas macht, wie er sich das grad vorstellt, und dann versucht man 10 verschiedene Module zusammenzufügen, die vorher nicht abgesprochen wurden. Das wird nämlich nicht funktionieren."Ebenfalls ist er selbst dafür verantwortlich wie er z.b. an Daten wie das geladene Bild, die Breite und Höhe bekommt." Das finde ich ebenfalls schlecht. Völlig unabhängig davon, ob die Module binäre Plugins sind, die unabhängig vom Hauptprogramm entwickelt werden, oder ob die alle im gleichen Source liegen und zusammen kompiliert werden, muss eine Schnittstelle existieren, über die alle relevanten Informationen übergeben werden. Es darf eigentlich gar keine Möglichkeit geben, dass sich Module selber irgendwas besorgen. Das bricht nur die Kapselung auf und führt zu Problemen.
-
themerx schrieb:
In der Fachhochschule besuchte ich das letzte Semester ein Fach indem ein C++ Projekt umgesetzt werden sollte. Es wurden zwei Gruppen mit je 10 Studenten gebildet die jeweils ein eigenes Projekt mit einer eigenen Struktur entwickeln sollten.
Bei uns waren es 20 Studenten und 5 Aufgaben, wobei die Strukturen gar nicht eigenständig sein konnten, sondern wie Menu/Datenbank/Graphen/Benutzerverwaltung keins ohne das andere ging.
themerx schrieb:
Ziel ist es zunächst ein Hauptprogramm zu entwickeln das mit Modulen erweiterbar ist.
Das Hauptprogramm hat grundlengende Funktionen wie Bild laden, Bild speichern, usw..Puh! Das existiert schon! Krass! Leichtes Spiel.
themerx schrieb:
Jeder Student bekommt das Hauptprogramm als offenes C++ Projekt. Der Student nimmt dieses Projekt und fängt an darin sein Modul zu bauen. Er legt eine eigene Form an (Windows Fenster) und designd dieses. Ebenfalls ist er selbst dafür verantwortlich wie er z.b. an Daten wie das geladene Bild, die Breite und Höhe bekommt. Er Coded quasi alles direkt in das Hauptprogramm. Hat er sein Modul nun fertig gestellt, kompiliert er das ganze Projekt und sieht sein Modul in dem Programm.
Das geht. Zappzarapp, ein Wochenende und man hat eine 1.
themerx schrieb:
Ab dem Zeitpunkt, an dem alle Studenten auf diese Weise ihr Modul fertig erstellt haben, setzen sie sich zusammen und fügen ihre Module zusammen. Das geschieht indem z.B. an einem Rechner alle Quellcodes in ein Projekt eingebunden werden und das komplette Projekt kompiliert wird. Es gibt dann also ein (ich nenne es mal) Master-Projekt mit allen Modulen.
Aua. Nen Tag für den Prof, das alles anzuschmiegen. Oder eine Woche (oder zwei (oder drei)) für die Studenten. Mist!, ist kaum bewertbar, wenn es nicht läuft, das mag der Prof nicht.
themerx schrieb:
Statt das jeder Student das Hauptprogramm als offnenes Projekt bekommt, bekommt jeder Student das fertig kompilierte Hauptprogramm. Zusätzlich bekommt der Studen ein kleines SDK womit ihm eine Schnittstelle zur Verfügung gestellt wird. Diese Schnittstelle beinhaltet alle notwendigen Daten wie das Bild, Breite, Höhe und eine Form, welche editiert werden kann. Der Student entwickelt darüber sein Modul und kompiliert nun eine eigene DLL Datei. Diese DLL Datei wird unabhängig von dem Hauptprogramm kompiliert.
Um das Modul (also die DLL Datei) in das Hauptprogramm einbinden zu können, muss der Student diese Datei in einen vorgesehen Ordner schieben. Beim Programmstart, wird das Modul automatisch erkannt und im Projekt angezeigt. Das Hauptprogramm wird also nicht komplett kompiliert sondern nur um die Module dynamisch erweitert.Jo, VIEL mehr Arbeit für jeden Studenten. Aber weniger für den Prof und er hat nen exakten Abgabezeitpunkt. Nebenbei auch viel sicherere 1 für die drei guten Programmierer von den 20. Spannend wird's, weil einer der guten Programmierer die ganz sichere 1 bevorzugt, die beiden anderen aber auch ihre 1 wissen und fair zu den 17 anderen sind. Nun steht's 2:2 und der Prof hat auch keine durch Rang besseren Argumente, sie hauen sich Argumente um die Ohren.
Arbeitgeber hat immer recht. Die Lösung wäre vielleicht, daß die beiden guten Programmierer, die den anderen helfen wollen, den DLL-Quatsch exemplarisch an einem Inverter lösen und allen bereitstellen und das dem Prof sagen. Kostet weniger Zeit als der Zank, der Prof kann dennoch alle termingerecht bewerten, die beiden haben sich eh Module gesucht, die weit jenseits sind. Und da der Prof überhaupt Diskussionen zuläßt, läßt mich annhemen, daß er für eine so einfache Lösung die 1(mit Sternchen) gibt, mithin einen groben Off-By-One-Fehler mal ignoriert wegen sozialer Kompetenz.
Das sind beide Varianten und mich würde jetzt interessieren, welche Variante ihr bevorzugen würdet. Stellt euch auch vor, so etwas als Auftrag einer Firma umzusetzen und geht die Vor- und Nachteile durch.
Ich selber habe einen deutlichen Favouriten und mich würde interessieren, welche Variante ihr bevorzugt.
Warum ich das hier mache und welche Variante ich bevorzuge, sowie die Vor- und Nachteile aus meiner Sicht, werde ich später dann erklären.[/quote]
-
Also wir hatten im Studium garkein C++ und nur 1 Semester C. Der rest war Java.
Wir hatten ein 6 personen Team und variante 1 hat eigentlich gut funktioniert. Schnittstellen wurden vorher entwickelt.
Alles in allem war das projekt dann dennoch ziemlich mist. Das problem ist, dass man Modul-Entwicklung eigentlich nie wirklich lernt.
Geht irgendwie immer nur um den Inhalt der einzelnen Teile und nie um die Struktur und noch weniger um die Umsetzung der Struktur.
Das kan ich leider bis heute nicht richtig. Der plan am Anfang ist meist ganz gut, das Ergebnis dann aber katastrophal.Deshalb bin ich nicht entwickler geworden ^^
-
Varinate 1 ist gar nicht gut. Jeder einfach direkt reinhacken wie es ihm beliebt - das führt bloss dazu dass die "Integration" zum Schluss der totale Horror wird.
Bewertung ist dann auch sehr schwer und sehr subjektiv. Es sei denn man vernachlässigt die "Integration", und bewertet nur wie gut der Teil jedes Schülers alleine, vor der Integration funktioniert hat.Varinate 2 ist auch nicht ganz optimal. z.B. weil man meist erst dann eine gute Schnittstelle festlegen kann, wenn man das "Plugin" bereits implementiert hat -- oder zumindest angefangen hat es zu implementieren.
Weiters kann es sein dass die fix vorgegebene Schnittstelle für das Plugin von Schüler A toll passt, aber für das Plugin von Schüler B sehr problematisch/schlecht passend ist.Ideal wäre ein Mittelweg: man arbeitet über definierte Schnittstellen, aber meisselt diese nicht vor Beginn der Plugin-Entwicklung in Stein, sondern entwickelt & adaptiert sie während die Plugins entwickelt werden.
Wenn ich mich nur für Variante 1 oder 2 entscheiden kann, dann ganz klar 2. Schonmal damit die Kids lernen dass man für Programme dieser Art gefälligst Schnittstellen zu verwenden hat. Und eben wegen des totalen Chaos das Variante 1 verursachen würde.
ps: Eine Modifikation von Variante 2 die mMn. bitter nötig ist: jeder bekommt den Source-Code des Projekts, darf bloss keine Änderungen darin machen. Ausgenommen eindeutige Bugs fixen. Dadurch wird keiner unnötig durch unklare Dokumentation oder Bugs ausgebremst.
(Bzw. von Bugs natürlich schon ein wenig, aber viel weniger als wenn er den Source-Code nicht hätte. Mit Source kann er wenigstens gucken warum und wie etwas schief geht, und es dann fixen, damit er an seinem Teil weiter arbeiten kann)
Ebenso könnte/sollte es vielleicht eine Ansprechstelle geben für fehlende bzw. "unpassend" definierte Funktionen in der Schnittstelle. Wobei dann entweder gemeinschaftlich entschieden werden müsste ob die Schnittstelle erweitert/angepasst wird, oder der Prof müsste das entscheiden.
Und dann sind wir fast schon dort was ich als Mittelweg bezeichnet habe.
-
Erstmal vielen Dank für die Antworten. Werde jetzt mal ein bisschen was dazu schreiben.
Variante zwei ist natürlich die von dem Studenten und um genau zu sein (wer hätte es gedacht) von mir.
Wie kam es dazu? Jede Gruppe sollte sich Gedanken über die Umsetzung machen und eine eigene Idee entwickeln. Für mich schien die Variante mit den DLL Dateien sinnvoll aus folgenden Gründen:
- jeder Student der ein Modul programmiert hat eine einheitliche Schnittstelle und damit alle Daten die er benötigt. Da jedes Modul als Ziel hat das Bild zu verändern war es auch recht klar, welche Daten die Schnittstelle übergeben muss und welche Methoden der Student braucht.
- Objektorientierte Programmierung statt Spaghetti-Code. Im zweiten Semester wurde uns die OOP in C++ beigebracht, also jeder war in der Lage eine Klasse zu schreiben, die von einer anderen erbt. Somit konnte man in dieses Projekt eine geordnete Struktur einbringen.
- Erweiterung ohne erneute Kompilierung. Dies ist wohl eine der wichtigsten Gründe und das nicht nur im Studium sondern vor allem in der späteren Berufswelt. Um das Programm mit einem Modul zu erweitern musste nicht das ganze Projekt kompiliert werden. Wenn ein Modul fehlerhaft war entfernte man die DLL Datei und/oder fügt sie, wenn sie repariert wurde, zu einem späteren Zeitpunkt wieder hinzu. Und jetzt kommt der eigentliche Vorteil. Angenommen dies ist ein Projekt, welches ihr an einen Kunden verkauft. Der Kunde sagt "ich brauche noch ein Modul, dass die Farbe invertieren kann". Wollt ihr dem Kunden jetzt dazu auffordern das ganze Programm nochmal neu zu installieren, nur weil eine neue 10kb Funktion hinzugekommen ist? Stellt euch das mal mit einem Programm vor wie Cinema4D oder Cubase. AUA!Es gibt noch ne Menge diverser Vorteile. Ein Nachteil ist, und der wurde hier genannt, dass es ein bisschen Zeit zur Einarbeitung bedarf, jedoch sind wir in einem Studiengang der Informatik und haben schon im 3. Semester ein C++ Fach. Da sollte man sowas langsam können. Zudem habe ich mich komplett um das Hauptprogramm, das SDK sowie ein vier seitiges Tutorial gekümmert, womit jeder problemlos einsteigen konnte.
Also gut, ich habe mich also für diese Variante entschieden und unsere Gruppe fand die Idee gut, also schlug ich sie unserem Prof vor. Was ich jedoch nicht wusste ist, dass der Prof eigenes Denken scheinbar überhaupt nicht leiden konnte. Er hatte seine Vorstellung des Programms (Variante 1) die für mich absolut katastrophal ist und wenn man diese Variante nicht vorschlägt, wird er böse. Ernsthaft er wurde wirklich böse und fing noch während der Vorstellung meiner Idee an mich zu diskriminieren. Also es wurde teilweise unschön aus mir völlig unerklärlichen Gründen. Seine Argumente waren in etwa so "Das versteht doch keiner, DLLs nutzt niemand, warum sollte man die Module vorkompilieren,...". Er brachte schein Argumente um meine Idee eben in den Boden zu stampfen.
Da ich von meiner Idee doch überzeugt war, hat unsere Gruppe es trotzdem umgesetzt und es funktionierte wunderbar.Tag der Präsentation:
Jede Gruppe stellte nun sein Projekt vor. Zuerst waren wir dran. Die Module wurde bewusst während der Präsentation eingebunden und das Programm lief ohne Probleme. Die andere Gruppe, die nach Variante 1 ihr Projekt umsetzte hatte jedoch Probleme. Ein Modul wurde vor der Präsentation nicht richtig eingebunden und das Programm stürzte während der Präsentation ab. Der Fehler wurde im Quellcode gesucht und auch irgendwann gefunden. Im Anschluss musste das komplette Projekt neu kompiliert werden. Alles passierte während die Gruppe präsentierte.Ok, warum mache ich das ganze hier:
Ehrlich gesagt stelle ich mir gerade selber kritisch die Frage, warum. Ich denke ich brauche nochmal die Bestätigung, denn ihr müsst wissen, seit dieser Aktion hasst mein Prof mich und das hat er mir letzte Woche wieder zu spüren gegeben. Leider habe ich noch ein Fach, dass ich bei ihm belegen muss und es geht wieder um C++ Programmierung. Eigentlich ist es jetzt egal was ich wann sage, er hat einfach total Bock drauf mich jedes mal zu diskriminieren. Es ist nicht so, dass er Ideen von mir argumentativ widerlegt sondern sich (wie eben erwähnt) Scheinargumente aus den Fingern zieht. Ehrlich gesagt bin ich ein bisschen verzweifelt, weil es auch so langsam an meinen Nerven nagt und mir schon selber die Frage stelle ob das alles richtig war, was ich damals gemacht habe.
Aber so wie es scheint lag ich mit meiner Variante wohl doch nicht ganz falsch.Ich bin jetzt mal sehr auf eure Meinungen dazu gespannt.
-
Hallo themerx,
.. bin i.A. etwas busy.
Nur soviel - meiner Meinung nach ist Variante 2 ganz klar der Favorit, wenn man nur die Wahl zwischen den beiden hat. Ansonsten bin ich einer Meinung mit der Aussage von hustbaer. Das von ihm beschriebene Vorgehen würde ich als professionell bezeichnet.Die Implementierung muss nicht zwingend eine mit DLLs sein, aber wenn Dein Prof sagt: "DLLs nutzt niemand", dann stellt er sich klar in's Abseits. Zumindest im Windows-Umfeld kenne ich keine mittlere bis große Applikation, die keine DLLs nutzt.
heute Abend melde ich mich vielleicht noch mal.
Gruß
Werner
-
themerx schrieb:
Ok, warum mache ich das ganze hier:
Ehrlich gesagt stelle ich mir gerade selber kritisch die Frage, warum. Ich denke ich brauche nochmal die Bestätigung, denn ihr müsst wissen, seit dieser Aktion hasst mein Prof mich und das hat er mir letzte Woche wieder zu spüren gegeben. Leider habe ich noch ein Fach, dass ich bei ihm belegen muss und es geht wieder um C++ Programmierung. Eigentlich ist es jetzt egal was ich wann sage, er hat einfach total Bock drauf mich jedes mal zu diskriminieren. Es ist nicht so, dass er Ideen von mir argumentativ widerlegt sondern sich (wie eben erwähnt) Scheinargumente aus den Fingern zieht. Ehrlich gesagt bin ich ein bisschen verzweifelt, weil es auch so langsam an meinen Nerven nagt und mir schon selber die Frage stelle ob das alles richtig war, was ich damals gemacht habe.
Aber so wie es scheint lag ich mit meiner Variante wohl doch nicht ganz falsch.Ja das Gefühl kann ich nachvollziehen.
Aber denk dran, wenn dich Computerspiele (wie. z.B. Doom oder so) eins gelehrt haben, dann das hier: Wenn du keine Gegner mehr siehst bist du auf dem falschen Weg. Oder umgekeht ausgedrückt, solange du auf Gegner triffst, bist du auf dem richtigen WegAls Prof sollte man sich eigentlich nicht so quer stellen und das auf persönliche Ebene runter ziehen. Mit dem Ausdruck "Diskriminierung" wäre ich etwas vorsichtig, da es schon ein recht hartes Wort ist. Aber wenn die Behandlung echt in die Richtung geht, dann würde ich mal mit dem Dekan oder Vertrauensprofessor reden. Da wird man sicherlich was machen können, und sei es nur ein Gespräch. Ausserdem gibt es genau für sowas Zweitprüfer.
Zum Inhaltlichen: Wie du auch selbst sagst (bzw meinst), jeder kann seine Meinung haben (z.B. für oder gegen DLLs) und das ist auch gut so, solange man sie gehaltsvoll begründen und vertreten kann. Und genau das ist auch Wissenschaft (Informatik ist zumindest bei uns ein Bachelor/Master of Science Titel). Egal ob etwas schön ist oder nicht, es hat seine Vor- und Nachteile und hat seine nachprüfbaren Wahrheiten. Da kann sich keiner gegen wehren.
Bei solchen Projektorganisationen kommt es sehr stark aufs Team an, die einen können [besser] mit Variante 1, die anderen [besser] mit Variante 2.
Und wenn wir mal in große Produkte schauen würden, ich glaube aus der Software-Engineering Sicht würden da viele durchfallen ;).
-
Ich z.B.
Habe das im Studium nie gelernt. Ich weiß bis heute nicht wie man dlls erzeugt, wann das Sinn macht, und wie man diese dann verwendet.
Nach dem Studium habe ich 1 Jahr entwickelt. Mit Java.
Dort habe ich aber fast nichts selbst geschrieben sondern mehr den Problemfall analysiert. Klar, auch programmiert im Sinne von tippen, aber das was höchstens 5% der Arbeit, wenn überhaupt. Dort haben wir auch keine dlls genutzt. Denke mal, das ist in Java auch nicht so gängig, bin mir aber auch nicht sicher.Wo ich mir jedenfalls sicher bin, ist das Architektur nahezu überall fehlt. Auch die frischen Anfänger in meiner jetzigen Firma haben da 0 schimmer von. Das ist ein riese Versäumnis. Sehr sehr schade.
-
Sqwan schrieb:
Das ist ein riese Versäumnis. Sehr sehr schade.
Nö.
Fast alle DLLs sind Unfug, da wäre eine statische lib besser gewesen. Dann hat die exe einfach die passende Version und fertig. Nur für fette Brummer wie das MS-Office macht es Sinn, DLLs zu bauen oder wenn man dem User erlauben will, Plugins von Fremdanbietern dazuzuschalten.
-
Aber dieses wissen gehört doch dazu.
Wenn ich sage eine DLL machen wir nicht, dann erkläre ich doch warum nicht.
Dann erkläre ich doch den unterschied zwischen Lib und dll.
Dann erkläre ich doch warum ich in diesem Fall lib nehme.
Das gehört doch mit zur "Architektur" und deshalb durch aus ein versäumnis.
-
Ich bin für 1). Denn: eigentlich sind beide Varianten gleichwertig. Im zweiten Fall einigt man sich in der Gruppe über ein Interface und baut dann die Programme passend. Im ersten Fall kann man das aber genausogut machen. Wenn die Interfaces festgelegt sind, dann unterscheiden sich beide Varianten nur noch dadurch, ob man einen weiteren Komplexitätslayer einbaut. Da bei einem kleinen Studienprojekt diese Komplexität nicht benötigt wird(Compilation dauert wahrscheinlich < 2min, s gibt keine 1000 unabhängig voneinander implemntierten module), schlägt für mich das Pendel zur ersten Variante.
Die ganzen Argumente darüber hinaus - von beiden Seiten - sind scheinargumente, weil es ansonsten keinen Unterschied gibt.
-
otze schrieb:
Im ersten Fall kann man das aber genausogut machen. Wenn die Interfaces festgelegt sind, dann unterscheiden sich beide Varianten nur noch dadurch, ob man einen weiteren Komplexitätslayer einbaut.
Es handelt sich um Studenten, die sich ein oder zwei Semester mit C++ beschäftigt haben. Ich bezweifle ganz stark, dass diese die Disziplin haben, die Interfaces zu beachten und das Hauptprogramm nicht zu verändern (kann bei Anfängern ganz schnell mal passieren, muss nichtmal absichtlich sein).
-
otze schrieb:
Ich bin für 1). Denn: eigentlich sind beide Varianten gleichwertig. Im zweiten Fall einigt man sich in der Gruppe über ein Interface und baut dann die Programme passend. Im ersten Fall kann man das aber genausogut machen.
Ja, kann. Die Beschreibung klingt aber nicht danach als ob das vorgesehen wäre.
Natürlich kann man die DLL-Sache bei Variante 2 weglassen, die ist eben nicht der Knackpunkt bei Variante 2. Der Knackpunkt ist dass bei Variante 2 vorgeschrieben ist dass ein Interface definiert wird, und nur über dieses zugegriffen werden darf (bzw. mit DLLs: kann).
Und genau das ist der Unterschied, und genau deswegen sind die Varianten eben nicht gleichwertig.
-
IMHO ist es hier nicht angebracht ein Diskussion über Sinn und Unsinn von DLLs vom Zaun zu brechen.
Ob das in der Realisierung der Variante 2 eine DLL wird oder eine statische Lib - oder womöglich ein paar Source-Dateien, aber mit wohldefiniertem Interface, halte ich für zweitrangig.
Ich interpretiere den Hilferuf von themerx (ich unterstelle es ist ein Hilferuf) so, dass er sich die Bestätigung hier abholen möchte, dass er mit seinem Vorschlag auf einem besseren Weg ist, als es der Prof vorgeschlagen hat.Aus meiner Erfahrung heraus kann ich sagen, dass man sich bei jedem Programmentwurf von Anfang an zwingend über die 'grobe' Struktur Gedanken machen muss. Und zwar insbesondere darüber, wie es am Ende(!) aussehen soll. Und die endgültige Fassung besteht doch hier ohne Zweifel aus genau einem Programm, für das jeder der Beteiligten seinen Beitrag abzugeben hat.
Und ohne eine vorhergehende Planung wie diese Teile zusammen spielen sollen, ohne jede Diskussion oder klärende Leitlinien wie das geschehen soll - so interpretiere ich die Variante 1 - ist so etwas bei nicht trivialen Programmen zum Scheitern verurteilt.Aber das wichtigere Thema hier ist IMHO die von themerx beschriebene Reaktion des Profs. Also ein zwischenmenschliches Problem.
Wir kennen die Meinung des Profs nicht, sondern nur die von themerx. Deshalb möchte ich mich auch mit jeder Beurteilung seiner Person zurückhalten.
@themerx: ich würde Dir empfehlen, Dich an Deine Studentenvertretung zu wenden. Und zwar möglichst frühzeitig, bevor irgendwas eskaliert. Und auch nicht nach dem Motto "der böse Prof", sondern eher "ich habe ein Problem".
Wenn alles 'normal' läuft, wirst Du mit ihm klar kommen müssen. Die Frage, die Du Dir nur selber beantworten kannst, ist: wie mache ich das?Solltest Du später mal die Gelegenheit haben, eine SW-Architektur zu gestalten, so wirst Du schnell merken, dass es nicht nur darauf ankommt, eine technisch gute Lösung zu haben, sondern sie auch verkaufen zu können. Die größten Widerständen resultieren dabei aus folgenden Denk-Schemata:
"die Idee ist nicht von mir, also kann sie nicht gut sein"
"das verstehe ich nicht, was soll das"
"das haben wir schon immer so gemacht"Am Anfang meiner Karriere habe ich auch großzügig meine Gedankengänge an meine Kollegen weiter gereicht und mir dabei manch blutige Nase geholt. Im Laufe der Zeit bin ich mehr dazu übergegangen Fragen zu stellen. .. wenn Du wirklich gut bist, bekommst Du es so hin, dass der andere denkt, es wäre seine Idee
Aber auch da muss man vorsichtig sein, man kann auch mit Fragen jemanden bloß stellen.
Und wenn man sich dann irgendwann mal einen guten Ruf erarbeitet hat, dann darf man auch mal zu "wir machen das jetzt so - und Basta!" greifen; und das wird dann auch akzeptiert.Mich würde noch interessieren, welchen Background der Prof hat. Wie alt ist er? Wie viel praktische Erfahrung hat er? An welchen Projekten hat er mit wie vielen Beteiligten führend mit gewirkt?
Schöne Ostertage
Werner
-
Schöne Antwort Werner.
Werner Salomon schrieb:
Aber das wichtigere Thema hier ist IMHO die von themerx beschriebene Reaktion des Profs. Also ein zwischenmenschliches Problem.
Wir kennen die Meinung des Profs nicht, sondern nur die von themerx. Deshalb möchte ich mich auch mit jeder Beurteilung seiner Person zurückhalten.Natürlich kennt ihr die Sicht des Profs nicht, deshalb habe ich auch versucht die Varianten so neutral wie möglich zu beschreiben. Ich wollte ja auch eine ehrliche Meinung und keine erhaschte Bestätigung.
Werner Salomon schrieb:
@themerx: ich würde Dir empfehlen, Dich an Deine Studentenvertretung zu wenden. Und zwar möglichst frühzeitig, bevor irgendwas eskaliert. Und auch nicht nach dem Motto "der böse Prof", sondern eher "ich habe ein Problem".
Wenn alles 'normal' läuft, wirst Du mit ihm klar kommen müssen. Die Frage, die Du Dir nur selber beantworten kannst, ist: wie mache ich das?Es sollte definitiv was unternommen werden, jedoch habe ich Bedenken und glaube dass es die Sache verschlimmern könnte wenn ich ein Gespräch aufsuche.
Je nachdem wie sich die kommenden Vorelsungen enwickeln werde ich meine Entscheidung treffen.Werner Salomon schrieb:
Solltest Du später mal die Gelegenheit haben, eine SW-Architektur zu gestalten, so wirst Du schnell merken, dass es nicht nur darauf ankommt, eine technisch gute Lösung zu haben, sondern sie auch verkaufen zu können. Die größten Widerständen resultieren dabei aus folgenden Denk-Schemata:
"die Idee ist nicht von mir, also kann sie nicht gut sein"
"das verstehe ich nicht, was soll das"
"das haben wir schon immer so gemacht"Das verrückte ist, ich bin neben meinem Studium selbständig als Programmierer und habe als Freelancer mit einigen Firmen an Projekten gearbeitet. Dort wurden Vorschläge erwünscht statt niedergetrampelt. Ein Grund der mich auch wohl so aufwühlt. Warum schmettert ein Prof gut gemeinte Ideen ab bzw. warum buttert er einen dabei noch runter. Es war ja nie böse gemeint,... im Gegenteil, man möchte Einsatz zeigen.
Für mich wirkt das eher als hätte er ein grundlegendes Problem damit, wenn man eigene und eventuell bessere Vorschläge bringt.Werner Salomon schrieb:
Mich würde noch interessieren, welchen Background der Prof hat. Wie alt ist er? Wie viel praktische Erfahrung hat er? An welchen Projekten hat er mit wie vielen Beteiligten führend mit gewirkt?
Der Prof müsste so mitte 50 sein. Sein Schwerpunkt ist die Bildverarbeitung. Genauer möchte ich nicht auf seinen Beruf eingehen (wo er mal gearbeitet hat usw., da ich ihn hier auch nicht an den Pranger stellen möchte).
Seine Erfahrungen beruhen auf die damalige "struktierte" Programmierung, jedoch nicht mehr auf die heute "objektorientierte" Programmierung. Da liegt auch das eigentliche Problem, denke ich. So etwas wie Vererbungen oder Schnittstellen lehnt er grundsätzlich ab und sagt dann "zu kompliziert, versteht keiner,...".Werner Salomon schrieb:
Schöne Ostertage
WernerDanke. Wünsche ich Dir/Euch auch.
PS: auch ein großes Danke an alle die sich an dieser Diskussion beteiligen.
-
themerx schrieb:
Seine Erfahrungen beruhen auf die damalige "struktierte" Programmierung, jedoch nicht mehr auf die heute "objektorientierte" Programmierung. Da liegt auch das eigentliche Problem, denke ich. So etwas wie Vererbungen oder Schnittstellen lehnt er grundsätzlich ab und sagt dann "zu kompliziert, versteht keiner,...".
Ja, sowas kenne ich auch. Hatte auch Profs, die bei C und Nassi-Schneidermann stehengeblieben sind und alles andere ist dann zu kompliziert und braucht keiner. Am besten erst gar nicht versuchen mit denen zu diskutieren, sondern einfach ignorieren. In deinem Fall leider schon zu spät.
Da gibt es einfach völlig unterschiedliche Menschen, sowohl Profs als auch in Firmen. Wundert mich ein bisschen, dass du die Erfahrung nicht schon früher gemacht hast. Einige Profs sind offen für Vorschläge und neue Ideen, andere wollen einfach ihre Vorlesung, die sie genauso seit 20 Jahren halten, in Ruhe durchziehen. Sowas sollte man vorher in Erfahrung bringen, bevor man mit eigenen Vorschlägen kommt. Hatte auch schon paar Profs, die versucht haben, bestimmte Studenten zu schickanieren. Macht halt einfach Spass und bringt etwas Abwechslung in den langweiligen Professorenalltag, wenn man sich schon weigert, was neues zu lernen
Ist in Firmen genauso. Da wirst du sicher noch genug Leute treffen, die es gar nicht haben können, wenn jemand eine eigene Meinung oder eigene Vorschläge hat.
