Get best of the week

ما تعلمته أثناء العمل على أول مشروع كبير لي

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



الموثق في شكله الأصلي

سياق الكلام


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

لقد بدأت في مراجعة مشاريعي بحثًا عن مشروع يمكن تحويله إلى شيء كبير ومعقد يمكن أن يحفزني. أخيرًا ، اخترت Binder - في ذلك الوقت تطبيق ويب بسيط سمح لك بإدارة الملفات من Onedrive و Google Drive و Dropbox في نفس الوقت. كان الهدف هو تطوير خدمة نسخ احتياطي قابلة للمقارنة في الوظائف مع هذا الثالوث ، ناقصًا القدرة على نقل الملفات إلى مستخدمين آخرين.

بداية الطريق


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

استقرت على حقيقة أنني سأكتب أربعة طلبات منفصلة. الأول هو عميل يعمل أصلاً على كمبيوتر المستخدم. والثاني هو API بواجهة خلفية ، وسوف يسهل إرسال الطلبات الآمنة. ثالثًا ، الخدمة السحابية ، المسؤولة عن تكامل جميع البيانات المخزنة عليها. وأخيرًا ، صفحة ويب "تسويقية" ، لأنه لا يمكن للمنتج الاستغناء عن موقع ويب متلألئ.

والآن تبدأ المتعة


حسنًا ، حسنًا ، حسنًا ، أعترف: كل ما قلته حتى الآن ليس له علاقة بالإلكترون ، ناهيك عن تطوير التطبيقات على نطاق واسع. لكنني كنت بحاجة إلى توضيح السياق حتى تفهم من أين حصلت على معرفتي. فيما يلي خمسة دروس رئيسية تعلمتها لنفسي:

# 1 تأكد من استخدام الهياكل التقليدية للواجهة الأمامية والخلفية ، لأن الاتصال بين العمليات أمر غبي

في كثير من الأحيان ، شعرت بالخوف بسبب كيفية تنفيذ الاتصالات بين العمليات البدائية في Electron (والآن مرة أخرى إلى psycho). نعم ، لم يتم تصميم الاتصال بين العمليات على الإطلاق لإجراء استخراج البيانات بروح جافا سكريبت ، مع تمثيل الوظائف كأشياء وما إلى ذلك. ولكن كم سيكون أسهل! وهكذا ، بدلاً من إنشاء تطبيق عميل أضيق الحدود ، في حين أن الصفيف الرئيسي من التعليمات البرمجية سيكون موجودًا في العملية الرئيسية ، اضطررت إلى الفصل بوضوح بين ما سيتفاعل مع المستخدم وما لن يتفاعل. المعيار الذي حددت من خلاله ما الذي سيخضع للعملية الرئيسية وما الذي تم صياغته في عملية التقديم على أنه سؤال بسيط: هل يخدم هذا الرمز أي شيء؟ حجم الجزء لا يهم. إذا خدم أجزاء أخرى من التعليمات البرمجية ،ثم انتقل إلى العملية الرئيسية. كان الاستثناء الوحيد هو نقطة النهاية لنظام الدفع Stripe - لأسباب أمنية ، أردت أن يكون موقعه قريبًا من المستخدم قدر الإمكان.

Making2 جعل الحفاظ على سلامة البيانات أمرًا صعبًا للغاية.

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

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

رقم 3 واجهات - مثل الأحذية التي يتم خياطتها حسب الطلب



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



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

رقم 4 ليس هناك الكثير من التسامح مع الخطأ

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

رقم 5 ليس مثاليا؟ ليس مخيفا

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

قبل أن نقول وداعا


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

تم نشر كل ما اعتقدت أنه آمن للوصول المفتوح على صفحة المشروع على GitHub. هناك سأقوم بنشر التحديثات (وهناك يمكنك تنزيل العميل بحيث يقوم بتحديث نفسه). آه ، حسنًا ، إليك الإحصائيات التي قمت بتجميعها في أربعة تطبيقات فرعية لإرضاء غروري:

الموثق المحلي (العميل على الإلكترون)



Binder-web (صفحة ويب جميلة)



في الاثنين المتبقيين ، لم أبدأ في حساب أسطر التعليمات البرمجية تلقائيًا لأسباب أمنية.

رابط الموثق

  • جافا سكريبت: 21 ملفًا ، 4117 سطرًا
  • الملفات الأخرى: 150 خطًا تقريبًا

binder-mongo (خدمة للتحقق من السلامة)

  • جافا سكريبت: 16 ملفًا ، 2374 سطرًا
  • الملفات الأخرى: ~ 140 سطر

العدد الإجمالي لخطوط الرمز: 30،015

More articles:


All Articles