Moderne Entwicklungsmethoden - Anspruch und Wirklichkeit
-
TheBigW schrieb:
andere Moeglichkeit: "leading by example". Ich hab auch in diversen chaos-projekten gearbeitet, aber gerade dann wenn Vorgaben und Richtlinien fehlen hat man meist Gestaltungsfreiraum weil eh jeder tut was er will. Was haelt Dich also ab fuer Deine Komponenten guten Code zu schreiben oder automatisierte UTs zu haben?
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben :).Hach. Wie schön es wäre Tests zu haben, denn das würde voraussetzten, dass es eine Anforderungsdefinition gegeben hätte. Bei uns ändern sich noch am Tage der Auslieferung die Anforderungen, weil es "der Kunde nun doch so will".
-
Mason_ schrieb:
Hach. Wie schön es wäre Tests zu haben, denn das würde voraussetzten, dass es eine Anforderungsdefinition gegeben hätte. Bei uns ändern sich noch am Tage der Auslieferung die Anforderungen, weil es "der Kunde nun doch so will".
Wenn sich Anforderungen ändern, sind Tests besonders hilfreich. Für Unit Tests braucht man keine Anforderungsdefinition. Die testen eher, dass das, was du tatsächlich geschrieben hast, deinen Erwartungen entspricht. Ob diese Erwartungen sich im Gesamtbild mit Anforderungen decken, ist eine andere Frage.
-
maximAL schrieb:
Ich bin schon länger unzufrieden damit wie in meiner Firma gearbeitet wird. Da ich aber keinen wirklichen Vergleich zu anderen Firmen habe bin ich mir nie so richtig sicher, ob ich nicht einfach zu viel erwarte.
Die Firma ist ein kleiner Mittelständler und die Codebasis ist Teils bis zu 20 Jahre alt. Da bleiben viele Legacy-Sünden natürlich nicht aus.Ich glaube du erwartest zu viel. Mir gehts wie dir, aber teils noch älterer Code und überhaupt kann ich dich um deine Punkte eher nur beneiden.
Wir maintainen immer noch einen System-Abstraktionslayer (Sachen wie Threads, Zeit, File-IO etc.).
Das heißt ja schon mal, dass nicht jede Funktion im Programm ihre eigene Lieblings-API benutzt.
Das Build-System ist immer noch GNU make (auch unter Windows - mit msys), die offizielle "IDE" ist Emacs etc.
Sei froh über gmake. Das ist zwar alt, aber nach wie vor modern und vor allem praktisch (d.h. man kann alles machen).
Ich darf mich hier mit so einer modernen (verbuggten IDE) rumschlagen, wo ich tausend Mausklicks machen muss, nur um zw. Debug und Release umzuschalten.
Die Projektdateien sind in XML und werden ständig automatisch von der tollen IDE verwurstelt.
Mit dem Compiler fange ich gar nicht erst an.Abgesehen davon das Emacs super ist, bedeutet das doch vor allem, dass du deinen Lieblingseditor nehmen kannst, der nur make aufrufen muss.
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Hier genauso. Aber das schöne daran ist, dass man für seine Sachen, den einzig richtigen Style nehmen kann
Unit Tests gibts nur für Dinge, die sowohl sehr kritisch sind und sich leicht testen lassen wie beispielsweise mathematische Algorithmen. Der Wert von testbaren Code, der positive Einfluss auf das ganze Design wird negiert.
Tests? lol, das wär mal was. Andererseits bin ich als Entwickler ja in der Situation, Tests schreiben zu können... Ganz ganz selten mache ich das sogar.
Es gibt keine Testabteilung oder wenigstens eine klar definierte Testphase. Neue Versionen gehen meistens direkt zum Kunden, wenn man gerade keinen kritischen Bug mehr gefunden hat - und scheitern dort regelmäßig.
Da stehen wir zum Glück besser da.
Am liebsten möchte man alles selbst implementieren und der Einwand, dass Tool X oder Bibliothek Y genau diese Probleme löst wird meistens ohne weitere Diskussion abgeschmettert.
Hier möchte man am liebsten alles irgendwie dazu kaufen weil die fertige Komponente billiger ist als die geschätzte Zeit für einen Entwickler.
Die Zeit die der Entwickler dann damit verbringt, sich durch irgendeine ranzige, undokumentierte Dritt-Software zu schlagen, wird leider nicht so genau eingerechnet.Ich bin schon froh, dass wir endlich CVS durch git ausgetauscht haben
Ja, sei froh über git
Erwarte ich wirklich einfach zu viel, wenn ich automatische Tests, Code Reviews, Bibliotheken und modernen Tools für selbstverständlich bei der Entwicklung von neuem Code halte?
Also wenn man sich so einige OpenSource-Projekte anguckt, scheint es das wohl tatsächlich zu geben. Innerhalb einer Firma, habe ich das noch nicht erlebt.
-
Hallo an alle, hab mir mal die Zeit genommen, diesen Thread zu lesen: manches kommt mir aus eigener Erfahrung sehr bekannt vor
Hab nach dem Studium 3 Jahre in der HW-Entwicklung gearbeitet (Netzwerke), danach (bis heute manchmal noch) im Embedded-Bereich (z.B. Maschinensteuerungen mit "harten" Echtzeitanforderungen).Bitte nicht falsch verstehen, aber ich kann nur sagen: Willkommen im "richtigen" Leben
Von Paradigmen haben zu meiner Anfangszeit als SW-Entwickler nicht viele geredet: SW-Goldgräberzeit oder gar SW-Wildwest? Test-Units: was ist das?
Ich kann nur den Rat geben: sich nicht frustrieren lassen, wenn es einem zu viel wird, in Ruhe eine neue Stelle suchen. Aber Vorsicht: man kann ganz leicht vom Regen in die Traufe geraten. Besonders dann, wenn die neue Firma bereits länger existiert und sich eine gewisse Codebasis "angesammelt" hat, aka. man auf etablierte Strukturen trifft.
Perfekt wäre eine neugegründete Garagenfirma, da kann man dann von Grund auf neu beginnen. Wird nach ein paar Jahren aber in einer ähnlichen Situation sein. So ist das nun mal.
Ansonsten muss man darauf hoffen, dass man mit Unterstützung selbst ans "Ruder" kommt....Einer, der mit über 50 die Firma nicht mehr wechseln kann (zumindest nicht als SW-Entwickler)
Grüße!
-
Seh ich auch so ....
Bei uns haben die "neuen", also frisch von der Uni und so, auch noch Ideale. Je nach Projekt, wo sie "verheizt" werden, dauerts 2-5 Jahre, bis sie die verlieren ....
Am Anfang: Unit-tests, Continius Integration, Ticket System ... wo find ich was ?
Nach ner Weile: Unit-tests, Continius Integration, Ticket System ... macht das hier wirklich Sinn ?Was ist die Ursache ?
Ich denk 90% unserer Projekte würden schon beim Anforderungs-Management durchfallen. D.h. Die meisten Projekte fangen an "produktiv" zu werden noch bevor klar ist, was die genauen Anforderungen sind.Die meisten Projekte sind so ausgeschrieben, das nen sauberes Anforderungsmanagment schon das halbe Gesamt-Budget fressen würde.
Der SW Architekt und die Entwickler kennnen auch meistens die Langzeit-Ziele (sofern es welche gibt) nicht.
Zeitknappheit durch Preisdruck tut dann das übrige ...
Unter solchen Umständen ist man dann froh, überhaupt was fertig zu bekommen, Qualität wird dann zum untergeordneten Problem, leider
Ciao ...
-
Inkompetenz wird gerne als Sparsamkeit getarnt. Eine saubere Arbeitsweise spart Zeit, aber man muss es auch können.
Eine Woche herumzueiern ohne Ergebnisse ist total akzeptiert, aber einen Tag Lesen und Ausprobieren ist Zeitverschwendung.
Andere darauf hinzuweisen, dass sie etwas besser machen könnten, birgt immer das Risiko, dass man sich unbeliebt macht oder dass stärker auf die eigenen Fehler geschaut wird.
-
Bis jetzt bin ich vom Arbeitsmarkt hier übrigens auch wenig begeistert. Einige KMUs, die einen ähnlich gestrigen Eindruck machen, hippe Startups für die ich nicht hipp genug bin und internationale Firmen, die sich hinter schnöseligen Assessment-Heinis verstecken. Und was soll ich von einer Firma halten, die mir ein Angebot macht ohne mir eine wirklich technische Frage im Interview gestellt zu haben, geschweige denn mir eine Testaufgabe zu geben?
-
maximAL schrieb:
Bis jetzt bin ich vom Arbeitsmarkt hier übrigens auch wenig begeistert. Einige KMUs, die einen ähnlich gestrigen Eindruck machen, hippe Startups für die ich nicht hipp genug bin und internationale Firmen, die sich hinter schnöseligen Assessment-Heinis verstecken. Und was soll ich von einer Firma halten, die mir ein Angebot macht ohne mir eine wirklich technische Frage im Interview gestellt zu haben, geschweige denn mir eine Testaufgabe zu geben?
Dir kann man es aber auch nicht recht machen...
-
Den EINEN, perfekten Job gibt es eben nicht.
-
dadidag schrieb:
Einer, der mit über 50 die Firma nicht mehr wechseln kann (zumindest nicht als SW-Entwickler)
Kommt auf die Fähigkeiten an. Ich hätte als SW-Entwickler nun nicht unbedingt wegen des Alters bedenken.
-
Und das Ende vom Lied: neue Stelle gefunden, alte gekündigt, zwei Monate Kündigungsfrist. Statt die restliche Zeit dafür zu nutzen einen der neuen Kollegen einzuarbeiten, wurde ich direkt freigestellt. Tja, viel Spass dann mit zehntausenden Zeilen Code die sich außer mir kaum einer angeschaut hat
Ich hab jetzt erst mal Urlaub
-
maximAL schrieb:
Das Build-System ist immer noch GNU make (auch unter Windows - mit msys), die offizielle "IDE" ist Emacs etc.
Schau dir mal cmake an und versuche wenigstens das durchzuboxen.
Mit cmake behalten die Entwickler ihr GNU make, aber du als Entwickler bist dann nicht mehr von GNU make abhängig, sondern kannst eine Projektdatei von IDE XY verwenden und damit auch IDE XY, dank cmake.Kurzfassung:
cmake generiert makes anderer makes und anderer projektdateien aus der cmake Konfiguration.Konfigurieren muss man also nur noch cmake.
-
cmake schrieb:
Konfigurieren muss man also nur noch cmake.
Dumm nur, dass gerade das der eigentlich Knackpunkt ist wenn man allein zehntausende Zeilen makefiles hat.
-
maximAL schrieb:
cmake schrieb:
Konfigurieren muss man also nur noch cmake.
Dumm nur, dass gerade das der eigentlich Knackpunkt ist wenn man allein zehntausende Zeilen makefiles hat.
Was machen die denn alles?
-
TyRoXx schrieb:
maximAL schrieb:
cmake schrieb:
Konfigurieren muss man also nur noch cmake.
Dumm nur, dass gerade das der eigentlich Knackpunkt ist wenn man allein zehntausende Zeilen makefiles hat.
Was machen die denn alles?
Bei einer Codebasis von über einer Million Zeilen, unterteilt in etliche Module und Submodule kommt schonmal grundsätzlich einiges zusammen.
Dann steckt da eine Menge Logik drin, weil der ganze Support für alle möglichen Compiler und Platformen drin ist, inkl. MS Toolchain. Dazu das Management von sehr vielen Abhängigkeiten in oft unterschiedlichen Versionen je nach Zielplatform. Und natürlich jede Menge copy & paste, viele grundlegende Targets z.B. für das Generieren von Dependency-Files oder cleanen des Builds stehen immer wieder in jeder Makefile.
Als Sahnehäubchen obendrauf gibts dann noch jede Menge redundaten Kram wie Compiler oder Betriebsysteme die schon seit 10 Jahren nicht mehr relevant sind. Immer toll, wenn man wieder über irgendwelche ifdef WIN_CE/MSC6/GCC3 Blöcke lesen muss.Das meiste davon wäre natürlich längst nicht nötig, wenn man ein Buildsystem wie cmake benutzen und einmal richtig aufräumen würde.