تسريع سير عملك عند بناء سمات WordPress

السرعة أمر بالغ الأهمية لأي مشروع تقريبًا. في كثير من الأحيان ، تكون المواعيد النهائية ضيقة جدًا وسير العمل الجيد في الفريق هو الطريقة الوحيدة للوفاء بها في الوقت المحدد ومنع الجميع من الإرهاق طوال العملية.

كيف سيبدو سير العمل هذا؟ وكيف يمكنك تنفيذ بعض أفضل الممارسات لعملك اليومي لتسريع عمليات التسليم؟ حسنًا ، هناك عدة طرق يمكننا من خلالها النظر في الأمر. اول واحد هو:

تحسينات سير العمل الفني

في هذا الجزء ، سنلقي نظرة على الأدوات التي يستخدمها المطورون لتسريع عملهم. أسهل طريقة لمعرفة ما هو الأفضل هي الإشارة إلى أبطأ العمليات - ما الذي يستغرق معظم الوقت للقيام به. سيكون التالي - ما الذي يتطلب أكبر قدر من الطاقة العقلية للقيام به. في بعض الأحيان ، قد تكون العملية سريعة جدًا ، ولكن في كل مرة تقوم فيها بذلك بالفعل ، يبدو الأمر وكأنه عمل روتيني ، والذي تفضل تأجيله لاحقًا.

الاقتراح 1 - تحضير موضوع كاتب

كان أحد التحسينات الضخمة لسير العمل لدينا في DevriX هو القيام بجميع الأشياء القياسية التي نقوم بها قبل بدء كل مشروع ، واستضافتها في مستودع ثم استنساخها في كل مرة يأتي فيها بناء جديد.

كيف تساعد؟

1. ليست هناك حاجة للقيام بإعداد Gulp في كل مرة. جميع الحزم موجودة خارج الصندوق ، يتم تشغيلها ، تم اختبار التكوين على أكثر من جهاز واحد.
2. يأتي مع وثائق قصيرة. إذا كان هناك أعضاء جدد بالفريق ، فلا يتعين عليهم طرح أسئلة حول مهام الإعداد الأساسية حيث تم شرح معظم ذلك بالفعل.
3. لا حاجة لاتخاذ قرار بشأن بنية الملف للواجهة الأمامية في كل مرة. يعمل فريق الواجهة الأمامية في الغالب على سمة جديدة اعتبارًا من اليوم الأول ، لذلك إذا كان عليهم أن يتوصلوا إلى بنية مجلد / ملف لملفات Sass في كل مرة ، فسنضيع ساعات لكل مشروع.
4. نحافظ على اتساق كل شيء - وهذا دفعة كبيرة أخرى. عادة ما يكون هناك أكثر من مشروع واحد نشط في نفس الوقت ، لذا فإن معرفة مكان العثور على ما تبحث عنه لأول مرة عند فتح مشروع هو توفير كبير للوقت. بنفس الهيكل عبر جميع السمات والأنماط وملفات JS وملفات PHP كلها في نفس المكان.

عندما نجد طريقة أفضل لمشكلة ربما تعمل على تحسين إعداد البنية ، أو تقديم linters ، أو الخطافات ، أو إضافة بعض الإجراءات هنا وهناك أو الوظائف المساعدة التي يتم استخدامها غالبًا ، نقوم بتحديث موضوعنا المبدئي. إذا كانت التغييرات التي تم إجراؤها على إعداد الإنشاء كبيرة ، فإننا نقوم بتحديث قاعدة الرموز للمشاريع الحالية أيضًا لمتابعتها.

الاقتراح 2 - حافظ على نفس أسلوب ونهج الترميز

مع هذا ، سوف يفهم جميع المطورين ما فعله الأشخاص من قبلهم. ومع ذلك ، هناك ما هو أكثر من ذلك - عندما يتم تطبيق نفس الأساليب في تنفيذ التخطيطات ، سيكون مصدر التعليمات البرمجية أكثر اتساقًا. هذا مطلوب بشكل خاص لمطوري الواجهة الأمامية لأن تلويث الأنماط يمثل مشكلة انحدار رئيسية.

يمكنك أن ترى على سبيل المثال دليل أسلوب ترميز HTML / CSS من Google.

مصدر

الطرق الشائعة لتسمية "الإدخال" أو "التعليق" أو طرق إدارة "القوائم" مثل .list-<name> وما شابه هي بعض الأساليب القياسية التي نتبعها عند إنشاء التخطيطات.

الاقتراح 3 - تحسين إعداد العمل المحلي الخاص بك

تعتبر الطريقة السريعة للتنقل بين المشاريع بمثابة توفير كبير للوقت بمفردها. يمكن أن يستغرق الأمر $cd'ing بين الدلائل نصف ساعة يوميًا بسهولة. هذا كله وقت ضائع. بدلاً من ذلك ، يمكنك إعداد TMUX على جهازك ، وإعداد نافذة منفصلة لكل مشروع ولوحة منفصلة لكل مهمة / غرض مثل "تشغيل Gulp" - اللوحة 1 ؛ "تشغيل الأوامر في الموضوع" - اللوحة 2 ؛ "تشغيل الأوامر في المكونات الإضافية" - اللوحة 3.

بالإضافة إلى ذلك - تأكد من أنه يمكنك فتح محرر التعليمات البرمجية الخاص بك مباشرة من المحطة. إنها طريقة أسرع للوصول إلى الترميز من الفتح من رمز ، ثم الانتقال إلى "فتح المشروع" وما شابه. يتميز VS Code بسهولة إعداده.

استخدم أدواتك بشكل أفضل

• يحتوي رمز VS والنص Sublime والعديد من الأدوات الأخرى على نافذة منبثقة "Command" حيث يمكنك كتابة أي شيء يمكن للمحرر فعله تقريبًا. حفظ كافة المستندات المفتوحة؟ فقط بضعة أزرار. إغلاقها؟ كل نفس.
• التنقل عبر لوحة الأوامر - يستغرق تصفح الملفات في الشريط الجانبي وقتًا طويلاً أيضًا. فقط انطلق واكتب اسم الملف الذي تريده. أضف بعض الامتدادات لتسريع العمليات الشائعة مثل إعادة تسمية الملفات ونقلها وتكرارها وحذفها.
• إعداد linters. لا داعي لإضاعة الوقت في تنسيق الملف عندما تكون هناك أدوات يمكنها القيام بذلك نيابة عنك. في كل مرة تقوم فيها بوضع مسافة بادئة للشفرة ، يمكنك إضافة مسافة بين الأقواس وما إلى ذلك بشكل أفضل في حل المشكلات.
• استخدم الاختصارات والمقتطفات - بالنسبة لمطوري الواجهة الأمامية ، فإن Emmet هو المنقذ. خطوط واحدة بسيطة مثل: nav>.site-nav>ul.list-items>li.list-item*5>a{title} إلى أكثر من 15 سطرًا من كود nav>.site-nav>ul.list-items>li.list-item*5>a{title} ، جميعها منسقة وجاهزة للتصميم. تستغرق كتابة هذا السطر ثوانٍ.

مثال على لوحة أوامر VSCode. يمكنك قراءة المزيد في صفحة النظرة العامة الخاصة بهم.

اتخاذ القرار لتحسين سير العمل

يمكن أن يكون هذا الأمر أكثر تعقيدًا وقد يتطلب المزيد من الخبرة وفهم احتياجات العمل الخاصة بالعميل. إنه أيضًا أحد الأساليب الأكثر ثقلاً بالمسؤولية ، ولكن في بعض الأحيان يمكن أن ينقذ المشروع من تفويت الموعد النهائي.

ابدأ من الأهم والأسرع في التنفيذ. إذا كانت هناك فرصة طفيفة لعدم بدء تشغيل الصفحة في اليوم الأول ، فلا داعي للبدء بها. إذا كان من الممكن وفقًا لتقديراتك أن يكون هناك شيء ما غير جاهز - فتأكد من مناقشة ذلك مع العميل. كلما ذكرت بوضوح ما قمت به ، وما الذي يمكن أن يتأخر وأين يمكن أن تحدث المشاكل ، كلما زاد احتمال قدرتك على التغلب على مشكلة محتملة.

قم بتفويض العمل مبكرًا ، ولكن اجعل العدد الإجمالي للأشخاص المشاركين منخفضًا. هذا شيء يلاحظه الجميع في مرحلة معينة. ربما يكون أقرب وقت في المدرسة ، عندما يبدأ 10 أطفال في العمل في مشروع ، لكن اثنين أو ثلاثة فقط يقومون بمعظم العمل.

يظهر هذا بشكل خاص في المشاريع التي تبدأ بمزيد من العمل الأمامي. نادرًا ما يمكنك منذ اليوم الأول أن يكون لديك أكثر من مطور واحد يعمل لأن أحد الأشياء الأولى التي يجب وضعها هي بنية المشروع. يجب أن تكون القرارات الأساسية لفريق التصميم هي البناء. ما هي المكونات ، وكيف يتم توسيعها ، وفصل الملفات ، وبنية وقواعد استعلام الوسائط ، واصطلاحات التسمية. كل هذا.

وعندما يكون هناك أكثر من مطور واحد في هذه المرحلة الأساسية ، فقد يبدأ كلاهما في تنفيذ جزء أساسي من الكود يحتاجانه ليتمكنوا من تصميم بقية الموقع. عندما يقومون بدفع هذا الرمز ، ستظهر تعارضات وقد يحتاج أحد المطورين إلى إعادة معظم العمل.

سيكون الوقت المناسب لإضافة المزيد من مطوري الواجهة الأمامية عندما يتم إنجاز المزيد من الأعمال الأساسية ويمكن تفويض العمل إلى مكونات منفصلة مثل "بطاقات المحتوى" أو "الصفحة المقصودة X" أو "صفحة 404" وما شابه. بحلول ذلك الوقت ، يتم تطبيق الخطوط وإعدادات الطباعة العامة ويتم إنشاء معظم الملفات ويتم إنشاء صفحة أو صفحتين على الأقل.

وبعد ذلك ، من المثالي أن يظل العدد الإجمالي للأشخاص الذين يركزون على مشروع واحد عند الحد الأدنى. فيما يتعلق بإدارة الوقت والتركيز على المهمة ، فإن النصيحة التي قد يرغب المطورون العاملون في فريق في أخذها في الاعتبار هي التبديل بين عبء العمل في مشروع معين.

لنفترض أن لدينا مطور الواجهة الأمامية جون الذي كان يعمل على موقع جديد لمدة أسبوعين بدوام كامل. بحلول ذلك الوقت ، كان يبحث عنها لأكثر من 80 ساعة في اليوم. من المحتمل جدًا أنه توقف عن اكتشاف المشكلات على الموقع! الآن سيكون الوقت المناسب لصديقه كيت لتتدخل وتتولى معظم أعماله. يمكن أن تبدأ كيت في إصلاح المشكلات البسيطة ، والتحقق مرة أخرى من أنها تتبع التصميم ، وتحسين الأداء هنا وهناك ، وإنهاء الصفحات والمكونات القليلة التي كان جون يؤجلها لمجرد أنه لا يمتلك الطاقة العقلية للقيام بذلك.

من المحتمل جدًا أن يكون معظم المطورين قد جربوا هذا ، ومن الجيد جدًا أن يكون لديك زميل في الفريق يمكنه التدخل وتولي الأمور لمدة أسبوع أو أسبوعين بينما تقوم بتصفية ذهنك قليلاً بمشروع جديد أو بعض أعمال الصيانة على مواقع الويب القديمة .

باختصار:

هناك أكثر من بضع طرق تقنية واضحة لتحسين سرعة تطوير الموقع. إنه مزيج بين العمل الجماعي - كيف تحدد الإرشادات المشتركة في فريقك وكيف تقوم بإعداد بيئة العمل / أتمتة عملك أثناء استخدام جميع الأدوات المتاحة لك. كيف تحافظ على عقلك منتعشًا وحادًا لفترات أطول من الوقت من أجل الحفاظ على معدل الإنتاجية المرتفع الذي كان لديك في اليوم الأول.

لإدارة كل هذا ، يحتاج الفريق القوي إلى مطورين كبار جيدين لوضع الهيكل ، وأعضاء مطورين مسؤولين لاتباع الإرشادات وإنتاج عمل جيد ومديري مشروع جيدين للبحث عن الحالة العقلية للجميع.