قائمة رأس السنة الجديدة لأب كيراس، تستحقها في عام 2019

أشياء يجب ملاحظتها أثناء التطوير

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

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

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

كيفية كتابة واجهة برمجة التطبيقات (API) بشكل أفضل؟

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

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

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

• قم بتصميم سير عمل شاملة بشكل متعمد، وليس مجموعة من الميزات الذرية. يتعامل معظم المطورين مع تصميم واجهة برمجة التطبيقات من خلال السؤال: ما هي الإمكانيات التي يجب أن تكون متاحة؟ دعونا نضع خيارات التكوين لهم. بدلاً من ذلك، اسأل: ما هي حالات الاستخدام لهذه الأداة؟ بالنسبة لكل حالة استخدام، ما هو التسلسل الأمثل لإجراءات المستخدم؟ ما هي أسهل واجهة برمجة تطبيقات يمكنها دعم سير العمل هذا؟ يجب أن تجيب الخيارات الذرية في واجهة برمجة التطبيقات الخاصة بك على احتياج واضح ينشأ في سير عمل عالي المستوى - ولا ينبغي إضافتها "لأن شخصًا ما قد يحتاج إليها".تم تصميمه عمدًا لتدفقات العمل الشاملة بدلاً من مجموعة من الميزات الذرية.عند تصميم واجهة برمجة التطبيقات، يسأل معظم المطورين: ما هي الميزات التي يجب توفيرها؟ دعونا نقدم خيارات التكوين لتلك الميزات. في الواقع، السؤال الصحيح للمطورين يجب أن يكون: ما هي سيناريوهات استخدام هذه الأداة؟ بالنسبة لكل حالة استخدام، ما هو أفضل تسلسل للإجراءات بالنسبة للمستخدم؟ ما هي أبسط واجهة برمجة تطبيقات يمكنها دعم سير العمل هذا؟
• رسائل الخطأ، وبشكل عام أي تعليقات يتم تقديمها للمستخدم أثناء التفاعل مع واجهة برمجة التطبيقات الخاصة بك، هي جزء من واجهة برمجة التطبيقات. يعد التفاعل وردود الفعل جزءًا لا يتجزأ من تجربة المستخدم. قم بتصميم رسائل الخطأ الخاصة بواجهة برمجة التطبيقات الخاصة بك بشكل متعمد.يعد الإبلاغ عن الأخطاء وأي تعليقات يتم تقديمها للمستخدمين أثناء تفاعلهم مع واجهة برمجة التطبيقات جزءًا من واجهة برمجة التطبيقات.يعد التفاعل وردود الفعل جزءًا لا يتجزأ من تجربة المستخدم. يجب عليك تصميم رسائل الخطأ الخاصة بواجهة برمجة التطبيقات الخاصة بك بعناية.
• نظرًا لأن الكود هو وسيلة اتصال، فإن التسمية مهمة - سواء تسمية مشروع أو متغير. تعكس الأسماء كيفية تفكيرك في مشكلة ما. تجنب الأسماء العامة للغاية (x، متغير، معلمة)، وتجنب OverlyLongAndSpecificNamingPatterns، وتجنب المصطلحات التي يمكن أن تخلق احتكاكًا غير ضروري (master، slave)، وتأكد من أنك متسق في اختيارات التسمية الخاصة بك. تعني تسمية الاتساق كلاً من اتساق التسمية الداخلي (لا تسمي "dim" ما يسمى "axis" في أماكن أخرى) والاتساق مع الاتفاقيات الراسخة لمجال المشكلة. قبل الاستقرار على اسم، تأكد من البحث عن الأسماء الموجودة التي يستخدمها خبراء المجال (أو واجهات برمجة التطبيقات الأخرى). نظرًا لأن الكود هو وسيلة اتصال، فإن التسمية مهمة، سواء كان الأمر يتعلق بتسمية المشاريع أو تسمية المتغيرات. يعكس الاسم الطريقة التي تفكر بها في المشكلة.تجنب استخدام أسماء عامة للغاية، وتجنب استخدام أنماط التسمية الطويلة للغاية، وتجنب استخدام المصطلحات التي قد تسبب سوء فهم غير ضروري، وتأكد من أنك متسق في اختيارات التسمية الخاصة بك.تعني اتساق التسمية اتساق التسمية الداخلي والاتساق مع المعايير المعمول بها في مجال المشكلة. قبل أن تستقر على اسم، تأكد من البحث عن الأسماء التي يستخدمها بالفعل الخبراء في هذا المجال.
• تعتبر الوثائق عنصراً أساسياً في تجربة المستخدم لواجهة برمجة التطبيقات الخاصة بك. إنه ليس إضافة. استثمر في الوثائق عالية الجودة؛ سوف تحصل على عوائد أعلى من الاستثمار في المزيد من الميزات. تعتبر الوثائق عنصراً أساسياً لتجربة المستخدم الخاصة بواجهة برمجة التطبيقات الخاصة بك. إنه ليس إضافة.استثمر طاقتك في كتابة وثائق عالية الجودة.يمكن أن يؤدي هذا إلى تحقيق عوائد أعلى من تطوير المزيد من الميزات.

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

  إذا كان هناك امتحان على Keras، فقد أعددت ورقة غش

سوبر نيوروبيديا

كلمة

أحادي المتغير

 [جو:ن'فييررت] صفة أحادي المتغير

متعدد المتغيرات

 [mʌltɪ'veərɪɪt] صفة متعدد المتغيرات

عبارة

الانحدار اللوجستي  الانحدار اللوجستي

تنفيذ الخدمة  تنفيذ الخدمة