Seit letztem Oktober habe ich jetzt mit der foodsharing Software zu tun. Am Anfang schrieb ich: Diese Seite verdient mehr Liebe von Entwicklern.

Seitdem waren die Fortschritte eher schwerfällig (trotzdem sind Fortschritte immernoch Forschritte, nicht wahr?), aber seit Kurzem gibt es wieder mehr Interesse daran einen klareren Weg nach vorn zu finden. Ich bekomme inzwischen das Gefühl, dass die Leute denken die Software wäre sowieso nicht mehr zu retten.

Durch die immer länger werdende Issue-Liste auf Gitlab, die Unklarheit ob jetzt zu Laravel gewechselt werden soll oder nicht, was es überhaupt mit foodsharing light auf sich hat und wie wir das Opensourcing vorantreiben können, ist meine persönliche Frustration auf jeden Fall gewachsen.

Aus irgendeinem Grund, der mir selbst nicht ganz klar ist, kann ich aber einfach nicht aufgeben!

Dass mehr Menschen über den yunity Slack mit uns in Kontakt getreten sind, war auf jeden Fall motivierend. Ich habe viel mit Peter aus Zürich und Kristijan aus Mainz gechattet und mehr davon verstanden, wie foodsharing eigentlich funktioniert. Dann gab es die foodsaving worldwide hack week letztes Wochenende bei München, bei dem ich die Gelegenheit hatte mit Clara aus dem erweiterten Vorstand von foodsharing zu sprechen, und nicht zu vergessen die andauernden Entwicklergespräche mit Matthias, Tilmann und Raphael.

Matthias hat außerdem letztens automatisches Deployment eingerichtet, sodass alle Änderungen am Git Master Branch direkt auf beta.foodsharing.de wirksam werden, und Tilmann hat einige sinnvolle Tools eingerichtet, die uns helfen werden PHP-Fehler zu verorten.

Kürzlich habe ich ein Buch mit dem Titel Modernizing Legacy Applications In PHP gekauft. Es ist eine Schritt-für-Schritt-Anleitung für Refactoring und fühlt sich an wie ein Freund, der meine Hand hält. Hier ist ein Auszug über den inkrementellen Refactoring-Ansatz:

Aufgrund der Risiken eines kompletten Umschreibens, empfehle ich stattdessen Refactoring. “Refactoring” bedeutet, ohne die Funktionalität des Programms zu ändern, dessen Qualität in kleinen Schritten zu verbessern. Eine einzelne, relativ kleine Änderung wird über das komplette System eingeführt. Dann wird das System getestet, um sicherzugehen, dass es nach wie vor ordentlich funktioniert und zu guter Letzt wird es wieder in Produktion gesetzt. So folgt eine kleine Änderung auf die nächste, und nach einiger Zeit wird das System merkbar leichter instand zu halten und zu verbessern sein.

Nach all diesen Gesprächen, der Lektüre und den Diskussionen habe ich jetzt das Gefühl, dass sich ein Plan abzeichnet. Noch ist er nicht völlig da, aber er scheint in diese Richtungen zu gehen:

  • Klarere Abläufe zwischen technischen und nicht technischen Leuten schaffen, um zu verstehen, wie all das funktioniert.
  • Die Zeit verkürzen, die es braucht, bis Änderungen am Code auf der Website sichtbar werden.
  • Entwickler ermutigen Verwantwortung für ihre Änderungen zu übernehmen (und sicher zu stellen, dass alles so funktioniert wie es vorgesehen war).
  • Eine Gruppe interessierter Entwickler dabei unterstützen sich langsam durch die Schritte aus dem Buch zu arbeiten.
  • Währenddessen weiterhin kleine Bugfixes und Feature-Änderungen fördern.

Das berührt zwar noch nicht die großen Themen und zukünftigen Ziele, sollte aber ein Schritt in die richtige Richtung sein. Wenn du im Wald bist, solltest du auf einen Hügel steigen, um die Gegend besser einschätzen zu können.

Vor ein paar Wochen erst bin ich auf diesen Hügel gestiegen :)