Något vi pratat om är att strukturera koden så att alla actions byggs om till en pluginstruktur, tex så läggs all kod som tillhör marvin väder i en klass (eller motsvarande) och alla pluginer som ligger i en viss katalog läses in automatiskt vid uppstart och blir en del av den körande boten.
Strukturen för en plugin kan tex vara en klass med en metod som "gör allt" men att författaren till pluginen tillåts dela upp koden fritt i klassen. Eller så har vi en mer tydlig struktur för hur en plugin-klass skall se ut (förenklar troligen kodgranskning).
En plugin skulle kunna vara en katalog med många filer men jag lutar åt att vi håller det enkelt (för kodgranskning...) och tillåter att en plugin är en fil och den skall innehålla all kod inklusive förklarande docstrings. Om det finns variantern i svaren som "hej" eller "tjena" så måste det extraheras ur klassen (på något sätt) och placeras som en egen enhet (i klassen, eller ovan klassen, men i samma fil).
Lite osäker på vilka krav man skall ställa på pluginen när det gäller test, men det bör vara vältestat och stödja regressionstester.
Tanken är att skriva om koden på en gång så att marvin blir "tom" och sen är allt pluginer så det blir ju en rejäl strukturell förändring, men det känns inte orimligt att göra på det viset.
Om man kikar på min PR där jag uppdaterade marvin väder så var det 8 filer som behövde ändras. Tanken är alltså att vi kommer ned till 2 filer, själva pluginen och testerna mot den.
Jag ser nu i koden att vi kallar det för "actions" där marvin väder är en action. Alla actions skall alltså hanteras som en plugin.
Något vi pratat om är att strukturera koden så att alla actions byggs om till en pluginstruktur, tex så läggs all kod som tillhör
marvin väderi en klass (eller motsvarande) och alla pluginer som ligger i en viss katalog läses in automatiskt vid uppstart och blir en del av den körande boten.Strukturen för en plugin kan tex vara en klass med en metod som "gör allt" men att författaren till pluginen tillåts dela upp koden fritt i klassen. Eller så har vi en mer tydlig struktur för hur en plugin-klass skall se ut (förenklar troligen kodgranskning).
En plugin skulle kunna vara en katalog med många filer men jag lutar åt att vi håller det enkelt (för kodgranskning...) och tillåter att en plugin är en fil och den skall innehålla all kod inklusive förklarande docstrings. Om det finns variantern i svaren som "hej" eller "tjena" så måste det extraheras ur klassen (på något sätt) och placeras som en egen enhet (i klassen, eller ovan klassen, men i samma fil).
Lite osäker på vilka krav man skall ställa på pluginen när det gäller test, men det bör vara vältestat och stödja regressionstester.
Tanken är att skriva om koden på en gång så att marvin blir "tom" och sen är allt pluginer så det blir ju en rejäl strukturell förändring, men det känns inte orimligt att göra på det viset.
Om man kikar på min PR där jag uppdaterade
marvin väderså var det 8 filer som behövde ändras. Tanken är alltså att vi kommer ned till 2 filer, själva pluginen och testerna mot den.Jag ser nu i koden att vi kallar det för "actions" där
marvin väderär en action. Alla actions skall alltså hanteras som en plugin.