Was die Tipps betrifft: jeder geht anders vor, jeder hat seine eigenen Vorlieben und Arbeitsweisen (oder "Macken"

), daher ist das Folgende auch nur meine persönliche Sicht.
Ich verwende QuickInstall und habe hierfür zwei Entwicklungsboards eingerichtet:
- Ein "jungfräuliches" fürs eigentliche Basteln
- Eines, in dem ich zusätzlich Extensions installiert habe, die sich optisch auf den Style auswirken bzw. Seiten/Elemente hinzufügen
Ersteres, weil das genau die Umgebung ist, in der der Style auf jeden Fall funktionieren muss und so "Einflüsse von außen" ausgeschlossen werden.
Letzteres, weil ich so prüfen kann, ob es da irgendwelche Konflikte gibt (falsch platzierte Events, erforderliche Folgeedits, die ansonsten nicht auffallen würden etc.)
- Die geplanten Änderungen sind in einzelne Blöcke ("Module") unterteilt, die Änderungen umfassen, die in meinen Augen zusammengehören (vermeidet, an zu vielen Baustellen gleichzeitig zu arbeiten und wichtiges zu vergessen)
Diese Blöcke, eventuell in Teilschritte unterteilt, werden dann sukzessive abgearbeitet, bis sie in sich soweit stehen, dass sie auch funktionieren. (Auf diese Weise lässt sich dann auch der Code gleich mit in "Blöcke" untergliedern, die, entsprechend kommentiert, übersichtlich bleiben)
- Es gibt einen "Spickzettel" bzw. eine Checkliste, was was alles an Änderungen geplant ist => so werden gegenseitige Abhängigkeiten sichtbar, die die Reihenfolge beim Bearbeiten beeinflussen, und es lassen sich zusammengehörige Arbeitsschritte zu den angesprochenen "Blöcken"/Teilblöcken zusammenfassen.
Ich arbeite aktuell sogar mit mehreren Versionen meines Styles:
- eine, an der ich aktuell bastele - was dort an Teilschritten soweit erst einmal als "fertig" abgehakt ist, wird dann übernommen in
- diejenige, die die angefangenen, in sich bereits funktionalen aber noch nicht vollständig abgeschlossenen "Module" enthält. Erst wenn diese vollständig und getestet sind, kommen sie in
- diejenige, die zum Download und Testen freigegeben werden kann.
Die zweite Version ist zwar nicht erforderlich, aber ganz praktisch für Zwischentests um "Auswirkungen" oder Sinnhaftigkeit einer Änderung beurteilen zu können, bevor ich zu viel Zeit uin etwas investiere, dass dann am Ende doch nicht passt oder zu aufwändig werden würde.
[Auf GitHub wäre (2) dann der develop Branch und (3) der master]
Mit Backups jeder Version vorm Ändern kann dann ruhig auch mal etwas komplett in die Hose gehen, ohne dass ich danach wieder völlig von vorne anfangen muss oder nicht mehr weiß, was ich jetzt alles noch zurückbauen muss, nur um wieder an den Ausgangspunkt zurückkommen zu können.
Bei kleineren Änderungen muss das alles nicht sein, aber wenn die "Umbauten" größer ausfallen sollen, dann lohnt sich diese Mehrarbeit für mich auf jeden Fall (hat schon so einiges an Frust erspart ...

).
Wichtig wäre in meinen Augen eines: mit Struktur und Plan an die Sache herangehen - nach ein paar Wochen weiß ich auch nicht mehr immer so genau, was ich jetzt so alles machen wollte und warum Code X jetzt
so aussieht, wie er aussieht.
Es war ein Fehler, den Style hätt ich einfach nur Anke zum Download schicken sollen
Warum?
Je früher und je mehr Leute den Style bzw. Code sehen und testen können, umso besser: je früher (Denk-/)Fehler oder nicht zuende gedachte Ansätze sichtbar werden, umso weniger Arbeit und Ärger hat man u.U. doch später.
--------------------------------
Nachtrag
Tastenplayer hat geschrieben:Also zum Teil war der Runterputz schon ziemlich krass, auch wenn ich hart im Nehmen bin und drauf gefasst war. Irgendwie muss man doch mal anfangen.
Kritik (im Sinne von: auf Fehler hingewiesen werden) hat doch nichts mit "Runterputz" zu tun
Sieh es mal von einer anderen Perspektive aus: wenn Du einen Style basteslt, der nicht nur für den reinen "Eigengebrauch" vorgesehen ist sondern auch Dritten angeboten wird, dann muss der auch etwas "härter" = genauer unter die Lupe genommen werden.
Wenn es nur um mich selbst geht, kann ich problemlos auf Vorgaben, Standards und Coding Guidelines etc. verzichten und munter drauflos coden. Solange das, was ich mache, auch funktioniert und meinen Usern keine Probleme bereitet, ist das durchaus okay (im Zweifel geht das auch nur mit mir heim).
Wenn Du den Style aber Dritten anbietest und diese ihn in ihrem Board einsetzen, dann muss er aber auch "sauber" codiert sein. Sie haben einen Anspruch darauf, dass auch alles so funktioniert, wie es das bei einem validierten der Fall sein sollte: in einem "nackten" Board ebenso wie in einem mit Extensions ausgebauten.
Zur Not musst Du dann nämlich auch Support für ihn leisten, wenn es zu Fragen oder Problemen kommen sollte: je sauberer er also umgesetzt ist, umso einfacher ist es dann auch für Dich (oder für Dritte, die dabei einspringen wollen)
Jeder hat mal ganz am Anfang gestanden,
jeder hat erst einmal Erfahrungen und Wissen ansammeln, in die diversen Fettnäpfchen treten müssen - und jeder kommt dennoch immer mal wieder an einen Punkt, an dem selbst dies nicht mehr reicht, um Fragen sofort beantworten zu können.
Kritik würde ich daher eher als Hilfe beim Lernen ansehen - alles, was bisher hier geschrieben wurde, ist doch auch
konstruktive Kritik gewesen!
Talk19zehn hat geschrieben:du solltest dich davon loslösen, dass du dein Konzept auf Anwender übertragen möchtest (xmas und Co.)

Ich verstehe z.B. dies so, dass es völlig okay ist, z.B. einen "Weihnachtsstyle" zu entwickeln - Du Dich aber nicht auch bis ins letzte Detail ausschließlich von Deinen eigenen Vorstellungen leiten lässt. Klar soll dabei am Ende auch etwas herauskommen, das Dir gefällt, mit dem auch Du zufrieden bist - nur zu eng sollte das dann auch wieder nicht gefasst sein.
Ein klein wenig mehr im Hinterkopf behalten, was ein "Kunde" darunter sehen möchte, was ihm an einem solchen Themenstyle wichtig sein könnte - und was nicht: Details, die ihn auf hierfür nebensächliche Gimmicks festnageln, würde ich dann auch erst einmal weglassen.
Siehe z.B. die Sache mit der Boardversion: wers möchte, kanns "nachrüsten" - es ist für das Thema nicht wirklich wesentlich und es gibt viele, die sowas eben
nicht vorgegeben bekommen möchten.
(Zumindest das Entfernen sollte dann auch einfach sein - besser vielleicht, sowas nur als
vorbereitete Option anzubieten, die sich bei Bedarf einfach "zuschalten" lässt.)