لوحة المتصدرين

أعلم أنَّه ليس من السهل الاعتراف بالأخطاء التي تقوم بها، لكن الخطأ هو جزءٌ رئيسي من كل عمليات التعليم، بدءًا من التعلم كيفية المشي إلى تعلم لغة برمجة جديدة مثل بايثون. هذه قائمة بثلاثة أخطاء التي وقعتُ فيها أثناء تعلمي لبايثون، عرضتها هنا لكي يحاول مبرمجو بايثون الجدد تفاديها وعدم الوقوع فيها، وهذه الأخطاء أدت إلى حدوث مشاكل كبيرة أخذت من وقتي ساعات حتى حللتها. الخطأ الأول: استخدام أنواع البيانات القابلة للتغير كوسائط افتراضية عند تعريف الدالة لنقل أنَّ لديك دالة صغيرة التي تبحث عن روابط في الصفحة الحالية وتستطيع إضافتها إلى قائمة (list) معيّنة. def search_for_links(page, add_to=[]): new_links = page.search_for_links() add_to.extend(new_links) return add_to لا يبدو أنَّ هنالك أيّ خطأ في الدالة السابقة، وهذا صحيح، فهي تعمل لكن هنالك مشاكل فيها؛ فلو مررنا قائمةً (list) إلى المعامل add_to فستعمل كما يجب، لكن ماذا يحدث لو تركنا القيمة الافتراضية دون تعديل؟ جرِّب تنفيذ الشيفرة الآتية: def fn(var1, var2=[]): var2.append(var1) print var2 fn(3) fn(4) fn(5) ستتوقع رؤية الناتج الآتي: [3] [4] [5] لكنك ستُفاجأ بالناتج الآتي: [3] [3, 4] [3, 4, 5] لماذا؟! يمكنك أن تستنتج أن القائمة (list) نفسها ستستعمل في كل مرة، فعندما نكتب دالة مثل الدالة السابقة في بايثون فسيتم تهيئة القائمة (list) كجزءٍ من تعريف الدالة، أي أنها لن تُهيّئ كل مرة تُستدعى فيها الدالة، وهذا يعني أنَّ الدالة ستحتفظ بكائن القائمة نفسه مرارًا وتكرارًا، ما لم تُحدِّد قيمةً أخرى له: fn(3, [4]) الناتج: [4, 3] الناتج يماثل ما قد توقعناه. الطريقة الصحيحة لفعل ذلك هي: def fn(var1, var2=None): if not var2: var2 = [] var2.append(var1) لنعد كتابة الدالة السابقة: def search_for_links(page, add_to=None): if not add_to: add_to = [] new_links = page.search_for_links() add_to.extend(new_links) return add_to نقلنا عملية التهيئة من مكان تعريف الدالة إلى داخلها مما يعني أنَّ عملية التهيئة ستتم في كل مرة تُشغَّل فيها الدالة. لاحظ أنَّ ذلك ليس ضروريًا إذا كنتَ تستعمل أنواع بيانات غير قابلة للتعديل مثل tuple أو string أو int. وهذا يعني أنَّك تستطيع تعريف دالة كما في الدالة الآتية دون إمكانية حدوث أخطاء غير متوقعة: def func(message="my message"): print message الخطأ الثاني: استخدام أنواع البيانات القابلة للتعديل كمتغيرات في الأصناف هذا الخطأ شبيهٌ كثيرًا بالخطأ السابق. تمعّن في الشيفرة الآتية: class URLCatcher(object): urls = [] def add_url(self, url): self.urls.append(url) الشيفرة السابقة تبدو طبيعية جدًا، فلدينا كائن لتخزين روابط URL، وعند استدعائنا للدالة add_url فسنمرر إليها رابط URL لتخزِّنه، صحيح؟ لنجرِّبها: a = URLCatcher() a.add_url('http://www.google.') b = URLCatcher() b.add_url('http://www.bbc.co.') الناتج: b.urls ['http://www.google.com', 'http://www.bbc.co.uk'] a.urls ['http://www.google.com', 'http://www.bbc.co.uk'] ما هذا؟! لم نتوقع ذلك. إذ أنشأنا كائنين منفصلين a و b، وأسندنا رابطًا للكائن a مختلفًا عن رابط الكائن b، فكيف امتلك كلا الكائنين الرابطين نفسهما؟ اتضح أنَّ هذه المشكلة شبيهة جدًا بالمشكلة في المثال الأول، فقائمة (list) عناوين URL قد تمت تهيئتها عند تعريف الصنف (class)، وبالتالي أمست جميع الكائنات المُنشَأة من ذاك الصنف تستعمل القائمة نفسها. هنالك بعض الحالات التي نستفيد فيها من هذه الميزة، لكنها ستضرك في أغلبية الأوقات، فلو أردتَ تخزين بيانات كل كائن على حدة فيمكنك تعديل الشيفرة لتصبح كما يلي: class URLCatcher(object): def __init__(self): self.urls = [] def add_url(self, url): self.urls.append(url) أصبحت قائمة urls تُهيّئ عند إنشاء الكائن، وعندما نُنشِئ كائنين فستُهيّئ قائمتان منفصلتان. الخطأ الثالث: عملية إسناد قيم إلى نوع بيانات قابل للتعديل هذا الخطأ أربكني لفترة حتى فهمته، دعنا نستعمل نوع بيانات قابل للتعديل مثل dict: a = {'1': "one", '2': 'two'} لنفترض أننا نريد أخذ قيمة المتغير a واستعمالها في مكانٍ آخر دون تعديل القيمة الأصلية: b = a b['3'] = 'three' أليس هذا بسيطًا؟ لننظر الآن إلى القيمة المخزّنة في المتغير a التي لم نُعدِّلها قط: {'1': "one", '2': 'two', '3': 'three'} ماذا؟! كيف ستبدو قيمة المتغير b إذًا؟ {'1': "one", '2': 'two', '3': 'three'} دعنا نعود خطوةً إلى الوراء وننظر ماذا يحدث لو استعملنا أنواع البيانات غير القابلة للتعديل، مثل tuple: c = (2, 3) d = c d = (4, 5) قيمة c هي: (2, 3) بينما قيمة d هي: (4, 5) لقد جرى كل شيءٍ على ما يرام، لذا ماذا حدث في مثالنا؟ عند استخدام أنواع البيانات القابلة للتعديل فسنحصل على شيءٍ شبيهٍ بالمؤشرات (pointers) في لغة C، فعندما قلنا أنَّ b = a في الشيفرة السابقة فهذا يعني أنَّ المتغير b أصبح يُشير إلى a، وكلا المتغيرين يشير إلى نفس الكائن في ذاكرة بايثون؟ هل هذا مألوف لديك؟ ذلك لأن هذه المشكلة شبيهة بالمشاكل السابقة، وكنتُ أنوي تسمية هذا الدرس باسم «المشاكل التي تحدث مع أنواع البيانات القابلة للتعديل». هل يحدث الأمر نفسه مع القوائم (list)؟ نعم. وكيف سنلتف على المشكلة؟ حسنًا، يجب أن نكتب الشيفرة الآتية التي تنسخ القائمة: b = a[:] السطر السابق سيؤدي إلى نسخ مرجعية كل عنصر من عناصر القائمة ووضعه في قائمة جديدة، لكن لنأخذ حِذرنا فإذا كان نوع بيانات أحد الكائنات الموجودة في القائمة قابلًا للتعديل فسيؤدي ذلك إلى الحصول إلى مرجعية لتلك الكائنات بدلًا من نسخها. تخيل وجود قائمة على قطعة من الورق، ففي المثال الأصلي كان ينظر الشخص A والشخص B إلى الورقة نفسها، فلو عدّل شخصٌ ما القائمةَ فسيرى كلا الشخصين التعديلات التي أجريت على القائمة، وعندما نسخنا المرجعيات فأصبح لكل شخصٍ قائمته الخاصة به، لكن لنفترض أنَّ تلك القائمة تحتوي على أماكن يمكن البحث فيها عن طعام، فلو كانت «الثلاجة» موجودة في القائمة فحتى لو نسخها الشخص A و B فما تزال تشير إلى الثلاجة نفسها؛ فلو أتى الشخص A وعدّل محتويات الثلاثة (لنفترض أنه أكل جميع الحلويات فيها) فسيلاحظ الشخص B أن الحلويات قد اختفت من الثلاثة. ولا توجد طريقة سهلة للالتفاف على هذه المشكلة، وهذا أمرٌ مهمٌ عليك تذكره عندما تبرمج لكي تكتب شيفرتك بطريقة لا تسبِّب أيّة مشاكل. تعمل أنواع dict بنفس الطريقة، ويمكنك إنشاء نسخة كاملة باستعمال الدالة copy()‎: b = a.copy() أكرِّر أنَّ ذلك سيُنشِئ متغيرًا جديدًا من نوع dict يُشير إلى نفس العناصر الموجودة في المتغير الأصلي، وبالتالي لو كان لدينا قائمتان متماثلتين وعدّلنا كائنًا قابلًا للتعديل مُشار إليه عبر مفتاح موجود في المتغير a فيمكن معرفة تلك التعديلات من داخل المتغير b. الإشكاليات التي تواجهنا مع أنواع البيانات القابلة للتعديل تكون نتيجةً لمرونة تلك الأنواع، حيث لا تُشكِّل أيٌّ مما سبق مشكلةً حقيقة، وإنما هي أمور ضرورية يجب أخذها بالحسبان لتنجب المشاكل. وعمليات النسخ الكاملة التي ذكرناها آنفًا لن تكون ضروريةً في 99% من الحالات، أي يجب تعديل برنامجك لكي لا يحتاج إلى استخدام تلك النسخ من الأساس. ترجمة –وبتصرّف– للمقال ‎3 mistakes to avoid when learning to code in Python لصاحبه Pete Savage

ماذا يحدث إن أُجبرت على تطوير كل شفراتك البرمجية Codes المفضلة والسرية والمملوكة لك في مستودع Github عام؟ بالتأكيد ستُنتقَد؛ سينتقد أقرانك هذه الشفرات البرمجية، وسيضعون تعريفًا فضفاضًا “للشفرة البرمجية السليمة”يتضمن كل شيء بدءًا بالملف وتنظيم الأصناف والتوثيق والاختبارات وتجنب وضع مفاتيح واجهات التطبيقات البرمجية API في الشفرة وتقليص اعتمادك على ” أمن المعلومات عبر الغموض” وحتى الجودة الفنية التي لا يوجد معيار لها. سيفرض عليك التطوير علانية خلق شفرة جذابة وذات جودة عالية، وما يدفعك إلى ذلك هو رغبتك في إبهار الآخرين. لعل هذا شيء جيد، لكن ماذا عن عملك التجاري؟ هل انفضحت كل أسرارك، فازدادت قوة منافسيك وتظن نفسك انتهيت؟ بمعنى أنه إن كانت شفرتك مفتوحة المصدر، فلن تكون ذات ميزة تنافسية، لأن منافسيك يستطيعون أيضًا عملها، وبالتالي عليك أن تضيف ميزة تنافسية جديدة لعملك. على سبيل المثال، إن أظهرت شركة Esty خفاياها كاملة للعلن، هل يستطيع منافس أن يحل محلها؟ بالطبع لا، لأنهم قد صنعوا سوقًا، يكون فيه حضور المشترين والبائعين أصلًا أوليًّا من أصول الشركة. وهل سيتفوّق منافس على فيسبوك لأنها فتحت الآن مصادر البنية التحتية لمركز معلوماتها، ؟ بالطبع لا. قيمة هاتين الشركتين لا يمكن تملّكها بالمال، ولهذا السبب هما قيّمتان. قد تكون الميزة التنافسية التقنية ميزة دائمة في حالات نادرة، مثل جوجل (التي استمرت في الابتكار بسرعة عالية لدرجة أنه لم يسبقها أحد) أو لأي شخص يستطيع أخيرًا فك شفرة السيارات ذاتية القيادة. لكن هذه الحالات نادرة، فالمميزات التقنية متلاشية، لأن معظمها يمكن تقليده، بل عادة ما يكون التقليد أسرع وأرخص من المنتج الأصلي، وقد ثبت أن “الأسبق” ليس دائمًا “الأنجح” في السوق. لذلك، العمل علانية يدفعك إلى خلق ميزة تنافسية دائمة. ماذا عن الأسرار الشخصية بدلًا من التقنية؟ إن أعلنت عن مفردات راتب كل شخص في شركتك، لن تستطيع بعد ذلك المنافسة على الكفاءة على أساس التعويضات بمفردها. فإن لم تكن قادرًا على دفع زيادة 10 ألاف دولار في العام لنيل الموظف الكفء ذي الخبرة المناسبة، فسيدفعك هذا إلى بناء شركة حيث تريد الكفاءات العمل مع انخفاض الأجر. توجد العديد من الإرشادات التي توضح بناء بيئة مثل تلك، لكنها بوجه عام تتلخص في: الاستقلالية: أي حرية الاكتشاف، القدرة الكاملة على ابتكار حلول للمشاكل، والقدرة على برهنة هذه الحلول بالتنفيذ، مقابل تحمل مسؤولية النتائج) النمو: أي العمل على حل أحجيات ومشاكل شيقة، سواء شخصية أو مهنية، بالإضافة إلى تحقيق رحلة مهنية مُرضية، تنتقل من نجاح إلى نجاح، الهدف: أي لماذا يجب أن توجد هذه الشركة؟ لماذا تستحق بذل العناء لرؤيتها تنجح، بالإضافة إلى الثقافة، والقيم، ومتعة العمل مع الآخرين الذين تحبهم وتحترمهم. لذلك، العمل علانية يدفعك إلى خلق شركة ذات ثقافة استثنائية ومنظمة ذات تمكين وهدف. يعد كلٌّ من خلق ميزة تنافسية دائمة (بدون أسرار البرمجيات) وبناء ثقافة شركة تجذب وتستبقي الكفاءات المميزة لأسباب تتعدى الرشوة المالية مكونيْن حاسمين لخلق شركات تقنية مُعَمَّرة لا تعيق نموها ولا تمحو هويتها الشركات الناشئة ذات الفطنة والمال والمجتهدة في العملالتي ستظهر حتما في أي سوق كبيرة كفاية ليكون العمل فيها شيقًا. لذلك عند إظهار كل شيء علانية، فأنت مجبر على تقديم “الأكثر قيمة” بالإضافة إلى تقديم “ما لا يمكن تقليده” سواء كان هذا يعني إتقان صنعتك أو إخفاء سر عملك أو جذب الكفاءات. لا يزال من الممكن أن تعمل في السر، لكن ضوء الشمس ليس فقط المُطهِّر الأفضل، بل هو أفضل طريقة للتفوق في السوق. ترجمة – بتصرّف – للمقال Building in public forces true competitive advantage لصحابه Jason Cohen. حقوق الصورة البارزة محفوظة لـ Freepik