Share
Een van de beste dingen aan mijn opleiding aan de universiteit van Scranton was de terugkerende les die we hebben geleerd hergebruik. Hergebruik is om vele redenen ongelooflijk belangrijk in programmeren: eenvoudiger testen, tijd besparen, de mogelijkheid om je te richten op meer geavanceerde dingen, enz. Toen ik afstudeerde en de wondere wereld van fulltime freelancen betrad, besloot ik of ik het zou blijven doen. WordPress werk, ik zou die hergebruiklessen in mijn dagelijks leven moeten toepassen. Nummer één op mijn lijst was een eenvoudig WordPress-themakader.
Het eerste artikel in deze serie zal een beetje anders zijn dan andere op deze site. In dit artikel wil ik u een deel van de les vertellen die ik heb geleerd over hergebruik en het definiëren van uw behoeften. In het volgende artikel zal ik mijn kader aan u verstrekken, maar het is een feit dat iedereen anders codeert en wat ik aanlever, misschien niet het beste bij u past!
Iedereen met formeel onderwijs in Computer Science of Software Engineering kan bevestigen dat er ontelbare theorieën, bibliotheken en klassen (programmeerlessen, geen schoolklassen) zijn die zich toeleggen op enkele zeer geavanceerde vormen van hergebruik en generieke programmering. Hoewel ik denk dat die overkill zijn voor een themakader, zijn er enkele principes die ik probeerde te volgen bij het maken van de mijne:
"Testen zorgt ervoor dat uw code werkt voordat u deze 5, 10 of 20 keer implementeert."
Nu we enkele dingen hebben uiteengezet om in gedachten te houden, moeten we definiëren wat we willen dat ons raamwerk tot stand brengt. Onthoud dat ieder van ons zijn eigen behoeften heeft, en terwijl ik over de mijne praat, kan de jouwe anders zijn. In het begin waren mijn behoeften vrij eenvoudig: ik wilde een eenvoudig raamwerk dat mijn eerste werk voor mij deed.
Bij het maken van WordPress-thema's voor mijn klanten, merkte ik dat mijn proces hetzelfde was: kopieer K2 (het standaardthema op dat moment), verwijder de dingen die ik niet wilde gebruiken, vervang deze door mijn code. Veel van mijn code was vergelijkbaar: dezelfde CSS-reset, dezelfde CSS-structuur, dezelfde stijlkop, navigatie, enzovoort. Na een tijdje vond ik het eenvoudiger om het thema van mijn laatste klant te kopiëren en daarvan af te bouwen. Op dat moment besloot ik om mijn eigen raamwerk te bouwen.
"We moeten definiëren wat we willen dat ons raamwerk volbrengt"
Toen dat besloten was, moest ik mijn behoeften definiëren: wat deed ik steeds opnieuw en wat kon ik generaliseren. Mijn lijst met vereisten was als zodanig:
Ik wilde ook een functie bouwen voor de functies van verschillende pagina's, zoals het bericht 'page not found' en de paginanavigatie van posts. Dit gaat terug op de mentaliteit dat een enkele functie me zal helpen om sneller functies van meerdere pagina's te wijzigen.
Het mooie van open source software is dat als je iets nodig hebt, het waarschijnlijk al is gedaan. Hetzelfde gaat van Frameworks. Er zijn tientallen raamwerken die er zijn, dus voordat je er zelf een gaat ontwikkelen, is het zeker de moeite waard om uit te zoeken wat er al is. Het doel is om tijd te besparen, toch? Geen betere manier om tijd te besparen dan helemaal niet te hoeven ontwikkelen!
Om je te helpen, heb ik een korte lijst met raamwerken samengesteld waar ik op zijn minst naar heb gekeken (hoewel de meesten van hen die ik heb gebruikt):
Bij het verkennen van deze kaders moet u rekening houden met uw vereisten. Test deze goed: downloaden, installeren, inschakelen. Probeer vervolgens een kindthema te maken en met de instellingen te spelen. Zie wat je vindt. Maak dan uw beslissing.
Voor mij voelde ik dat degenen die ik probeerde te complex en niet licht van gewicht waren. Ze zijn geweldig voor mensen die snel een thema nodig hebben, maar voor zover het gaat om maatwerk, moest ik een heel nieuw systeem leren om thema's te maken. Zoals ik eerder al zei: ik ken het complexe framework / API van WordPress al. Ik zou die kennis moeten vervangen door het framework / de API van een ander thema. Ik besloot om mijn eigen te bouwen, die nog steeds de functies van WordPress zou gebruiken en niet zou vervangen.
Ik weet zeker dat je aan het begin van dit artikel kon raden dat de onvermijdelijke conclusie zou zijn dat we ons eigen raamwerk uitbouwen. We hebben onze principes en vereisten en we hebben ons onderzoek gedaan. We zijn klaar om een raamwerk te bouwen, wat we de volgende keer zullen doen!
Het laatste wat ik je uitnodig om te doen, is de betekenis van wat ik hier heb gezegd: wat zijn je principes en vereisten. Gebruik je een van de frameworks die ik hier heb genoemd, of heb je je eigen framework al ontwikkeld? Laat het ons weten!
In de volgende sessie in deze serie zullen we deze principes toepassen op de eerste dag van ons nieuwe framework!
Accentsconagua