اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'تصور برمجي'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 1 نتيجة

  1. يتعامل المبرمجون مع شفرة البرامج المصدرية بأسلوبين مختلفين، فالأول يرى أنّ “الشفرة التي تعمل هي الشفرة الجيدة” أما الثاني فيرى أنّه “ما دامت الشفرة جيدة فإنّها ستعمل بكل تأكيد” وبصياغة أخرى: “المهمّ أنها تعمل” مقابل “المهمّ أن تكون صحيحة”. كل يوم تقريبًا أقرأ هذه العبارة وأشباهها في تعليقات المدونة: “ما الحاجة إلى مبادئ البرمجة كائنية التوجه إن كانت الشفرة البرمجية تعمل بشكل جيّد دون استخدامها؟ ما الهدف من إدخال طرق وأساليب جديدة يفترض بها أن تكون أفضل من سابقاتها، إن كانت الطريقة التقليدية الحالية - والتي تتوسط البرمجة الإجرائية وكائنية التوجه - تعمل جيّدًا؟” لنفكّر في الأمر من زاوية مختلفة، وننظر إلى الأمور على نحو أعمّ ونفكّر من ناحية تطوير البرمجيات لا من ناحية البرمجة كائنية التوجه. هناك الكثير من الأمثلة التي تنطبق عليها عقلية “المهمّ أنّه يعمل”. لنأخذ لغة Perl، وهي لغة برمجية تشتهر بقدرتها على القيام بأيّ شيء بثلاث طرق مختلفة، بمعنى أنّه لا وجود لطريقة واحدة صحيحة. لست خبيرًا في Perl، لذا فلنلق نظرة على شفرة Ruby التالية: if a > b m = 'Hello!' end يمكن كتابة الشفرة السابقة بهذه الطريقة أيضًا: m = if a > b 'Hello!' end أو هذه: m = 'Hello!' if a > b وإليك المزيد: m = a > b ? 'Hello' : nil أيّ الشفرات السابقة صحيحة؟ هل يمكن ﻷي مبرمج بلغة Perl أن يخبرنا بذلك؟ هل يمكن اقتراح طرق أخرى للوصول إلى نفس النتيجة؟ أما في لغة Java (وهي لغة أكثر صرامة من Ruby) فليس من المفاجئ أن تكون هناك طريقة واحدة للقيام بذلك: if (a > b) { m = "Hello!"; } أعتقد أنّني أخطأت، فهنالك طريقة ثانية: if (a > b) m = "Hello!"; ما الذي يمكن أن يجنيه المبرمجون من هذا التنوّع الكبير؟ أعتقد أن الإجابة تعتمد على كوننا نكتب الشفرة أم نقرؤها؟ كذلك يعتمد الأمر على موقفنا تجاه البرنامج الذي نعمل على إنشائه، فإما نرى بأنّه ملكنا (عقلية المخترق) أو أنّنا نبنيه وحسب (عقلية المصمّم). إن كنا نكتب الشفرة البرمجية، وكنا نرى أنفسنا أصحاب تلك الشفرة، فسنحتاج إلى ترسانة أسلحة التجميل اللغوي Syntactic sugar لنثبت لأنفسنا بأننا أذكياء، وبالتأكيد لنتباهى أمام أصدقائنا بمفسّر Ruby الكئيب. في المقابل، إن كنا نعدّ أنفسنا في عداد المصممين، فسنصاب بالانزعاج والإحباط عند قراءة شفرة برمجية مليئة بأساليب التجميل اللغوي والتي “تعمل دون مشاكل”. ربما يجب أن أقتصر في الحديث على نفسي، الواقع أنني متأكّد من أنني سأصاب بهذا الشعور. يمكن أن نعدّ صياغة لغة Ruby والتي تتيح هذا القدر الكبير من التجميل اللغوي مثالًا واضحًا على التناقض الحاصل بين مبدأي “المهمّ أن تعمل” و “المهم أن تكون جيدة”. إذ تتمثل فلسفة Ruby في أنّه لا أهمّية لطريقة كتابة الشفرة البرمجية ما دامت تؤدّي عملها المطلوب منها. أما فلسفة Java فمختلفة تمامًا، وهي أقرب ما تكون إلى: اكتب شفرة صحيحة وستعمل بالتأكيد. إضافة إلى ذلك، فإن نوع البيانات الضعيف والديناميكي Weak and dynamic type الذي تتمتع به لغة Ruby مقابل نوع البيانات الصلب والثابت Strong and static type في Java، يعدّ دليلًا آخر عمّا أتحدّث عنه. أرى عموما أنّه كلما زادت مرونة اللغة البرمجية، قلّت قابلية صيانة الشفرة المكتوبة بها، وبمعنى آخر فإن الجودة الأعلى تأتي من اللغات الأبسط. وهذا الأمر ينطبق كذلك على عملية تطوير البرمجيات: فكلما زادت القيود المفروضة على المبرمجين وقلّت الخيارات المتاحة أمامهم في طريقة كتابة الشفرة البرمجية، زادت جودة البرنامج المكتوب بتلك اللغة. تحاول المحلّلات الساكنة Static analyzers مثل Checkstyle في لغة Java أو Rubocop في لغة Ruby حلّ هذه المشكلة وذلك بمنعنا من استخدام خصائص معيّنة في اللغة البرمجية، ولكنّها لا تقدّم نتائج جيّدة لأنّنا مبدعون في كتابة الشفرات بأساليب وأشكال متنوعة. لنعد الآن إلى السؤال الخاص بالبرمجة كائنية التوجه: ما الحاجة إلى تطوير أي شيء إن كان يؤدي عمله بهيئته الحالية؟ الجواب: البرمجة كائنية التوجه الحديثة (كما في Java، Ruby و ++C) لا تنتج شفرة برمجية ذات جودة عالية لأنّها لا تتبع تصوّرا برمجيًّا Paradigm قويًا ومقيّدًا بشكل ملائم. كل ما في الأمر أنّها توفّر الكثير من “الميزات” التي أدخلتها في الغالب ++C وبقيت فيها لأجل منفعتنا المتبادلة. هذه اللغات تعمل بالفعل، ولكنّ قابلية صيانة البرامج التي ننتجها بهذه اللغات تكون منخفضة للغاية. الواقع أن قابليّة الصيانة هذه أقل بكثير ممّا كان سيكون عليه الحال لو كان “إبداعنا” مقيّدًا. ترجمة - وبتصرّف - للمقال Flexibility Equates to Lower Quality لصاحبه Yegor Bugayenko.
×
×
  • أضف...