لقد حدث أن معظم حياتي الواعية وأنا برنامج في PHP. إن عقولنا ، التي تتصور المعلومات من أي مصدر ، تقوم بذلك دون انقطاع من سلطة هذا المصدر. تحدث تقريبًا ، إذا كنت تحب PHP - فأنت تضيف تلقائيًا نقاط مصداقية إلى مؤلف هذا المقال ، وإذا لم يعجبك - فقد أخذوها تلقائيًا. تتم هذه العملية على مستوى اللاوعي وهي في الأساس منظور للإدراك ، من ناحية تحمينا من الوقوع في تحليل لا نهاية له للمعلومات بأي درجة من السلطة ، ولكن من ناحية أخرى يحدنا في البحث عن معلومات جديدة أكثر صلة. أسوأ ما في الأمر هو أن مصداقية المصدر نادراً ما يتم التحقق منها على مستوى واعي (لأنه يستغرق وقتًا وموارد في شكل سعرات حرارية ثمينة) ، يمكن أن أكون مع نفس الاحتمال مطورًا زائدًا ، أو ربة منزل ، أو سباكًا بدون أميرة ، أو معدلة وراثياً القط. لا تحكم على مقالي بدقة ، لدي الكفوف.
الأمر نفسه ينطبق على قراءة رمز شخص آخر: إذا كان مؤلفه يجلس على يمين عرشك ، وكان يعمل في شركتك لمدة تزيد عن 10 سنوات ويكسب صفرًا أكثر منك ، فهذا ليس هو نفسه مطلقًا المؤلف الذي تم فصله بسبب شيء ما - هذا سيء ، وتم توظيفك في مكانه. لكن في الحقيقة ، الكود هنا وهناك فقط مجموعة من البايتات التي سيكون من المفيد تقييمها دون الرجوع إلى سلطة المصدر.
عندما نقرأ رمز شخص آخر ، يمكن لمجموعة متنوعة من العواطف زيارتنا: الإعجاب والضحك والتهيج وخيبة الأمل والرفض الكامل. من المفيد معرفة أن تجسيد أي عواطف في أي سياق هو استجابة تلقائية للمستوى الأدنى (الأول) من الجهاز العصبي ، الذي تشكل بطريقة تطورية ، وهو ضروري في بيئة بدائية. تتمثل المهمة الرئيسية لإجابة كهذه ، في حالة الانفعال "السلبي" ، في إطلاق آلية العمل "الضرب أو الركض" بهدف واحد - البقاء. في بيئة مكتبنا الحالية ، عند تحليل رمز شخص آخر ، تصبح هذه الإجابة عديمة الفائدة بل ضارة ، حيث تقضي وقتًا ثمينًا وموارد ثمينة ، بالإضافة إلى تلويث عقلك بالناقلات العصبية التي تخفض ذكائك السريع من أجل سرعة رد الفعل. والخبر السار هو أن هذه الإجابة يمكن إعادة برمجتها. يمكنك قمع ردود الفعل العاطفية السلبية ، أو يمكنك جردها ، على سبيل المثال ، تضحك حيث كنت غاضبًا. على عكس الغضب ، يضحك الضاحك في ناقلات عصبية جيدة ولذيذة ومفيدة تضفي السعادة وتعزز التجربة وتحفزك على مواصلة العمل.
من أجل إعادة برمجة المشاعر ، تحتاج إلى الذهاب عقليا إلى موقف ميتا من أجل تقييم الموقف الخاص بك وتقييم نفسك بدلا من إدانة رمز شخص آخر. لماذا هذه القطعة من رمز شخص آخر تقرفني؟ هل حقا أن الهواة كتبته ، والآن يجب أن أعاني جيدًا وذوي خبرة؟ إذا كنت جيدًا وذو خبرة ، فلماذا أواجه مشكلات من أجل فهم كود شخص آخر وإعادة كتابته كما أراها مناسبة؟ ربما ليس لدي ذاكرة RAM كافية لتحقيق هذه المعكرونة؟ ربما يعرف مؤلف هذه المقالة شيئًا لا أعرفه؟
تتيح لك أدوات التطوير الحديثة تحويل رمز شخص آخر إلى هياكل أكثر قابلية للفهم والمرح تقريبًا. يتم تسمية الوظيفة أو المتغير بشكل سيئ - ctrl + shift + R وفي بضع ثوانٍ يطلق عليه اسم "good". علامات التبويب بدلاً من المسافات ، غير مريح ، مسافات بادئة مبعثرة بشكل غير عادي وفتح الأقواس في النمط المصري - ctrl + shift + F واستعادة التنسيق! التعليق لازم أو قديم - CTRL + D وليس كذلك. إذا غيرت منظور الإدراك ، فقد تتحول قراءة رمز شخص آخر إلى لعبة تحريرية تفاعلية ممتعة.
الرمز هو مجرد أداة. بغض النظر عن مدى سوء وصعوبة كتابته ، في وقت محدد وفي مكان معين ، نجح في حل مشكلة معينة ، مما يعني أنه "مبرر" بالفعل. لقد تغير شيء ما في متطلبات العمل ، ولم يتم أخذ شيء بعين الاعتبار - لقد تم كسر الشفرة أو عفا عليها الزمن ، وهذا أمر طبيعي. المدونة لديها القدرة على التطور بطرق متنوعة: وبالتدريج ، امتلأت بالطبقات والثورية ، والكتابة من الصفر. بالطبع ، من الجيد أن يتوقع المبرمج المستقبل وفي المراحل الأولية يضع في الكود إمكانات لمزيد من التطوير. ولكن هذا الفأس حاد على الجانبين ، يمكنك أن تخطئ في التنبؤ بالمستقبل ، قد لا يأتي المستقبل على الإطلاق ، وسيضيع الوقت والموارد بلا رجعة. من المهم أن تفهم الكود لمعرفة درجة الجودة المطلوبة منك. إذا كان هذا نظامًا ضخمًا موزعًا ، حيث يتم برمجة الوحدات النمطية من قِبل زملائك من جميع أنحاء العالم في شركات مرتبطة ضعيفًا بك ، ثم نعم ، فمن المنطقي استخدام الأنماط العصرية ، لفاف الوحدات النمطية في حاويات الخدمة حتى في الأماكن التي لا تتخيل فيها سبب ذلك. بحاجة إلى. ولكن إذا كان هذا CRM محليًا صغيرًا لشركة واحدة ، تعتمد وحداتها بشكل صارم على بعضها البعض بحيث يؤدي تعطيل أي وحدة بشكل أساسي إلى إيقاف النظام بأكمله عن العمل ... في هذه الحالة ، من الممكن استدعاء أساليب الآخرين مباشرةً ، مما يقلل من عدد الفئات ويسهل تشغيلك الذاكرة وتقليل الوقت لتصحيح المشاكل. ولكن هنا ينشأ موقف عندما تتحول إدارة علاقات العملاء CRM محلية صغيرة إلى شيء قابل للتوسعة تريد شركتك أن تضعه في المجال العام وتبيعه. متطلبات العمل قد تغيرت. هل يجب إلقاء اللوم على المبرمج لعدم توقع ذلك؟
التقييس
الكود هو مجرد أداة ، ولكن إنشائها إبداع خالص. يمكن حل أي مشكلة عن طريق عدد لا حصر له من الطرق الأكثر تنوعًا. بعضها أكثر إنتاجية من غيرها - مثال على التقييم الموضوعي. بعضها أكثر قابلية للقراءة من غيرها - مثال على التقييم الشخصي. حتى إذا كنت تقنع المكتب بأكمله بأن بعض التعليمات البرمجية غير قابل للقراءة ، فسيظل هناك مؤلف واحد على الأقل يختلف معك. يهدف توحيد الكود إلى تحويل الإبداع الخالص إلى مجموعة من الإجراءات الروتينية بحيث يسهل على المبرمجين الآخرين فهم الكود. هذا هو ، في الواقع ، بحيث يمكنك استبدالك بأخصائي آخر ، أكثر سهولة وسعر أرخص. وبعد عقدين من الزمن ، أصبح ذكاءً مصطنعًا تمامًا. تجدر الإشارة إلى أنه إذا كان هناك معيار ما يتعارض مع المنطق السليم ، فقد يكون من المنطقي انتهاكه في بعض الأماكن ، أو حتى التخلي عنه تمامًا أو استبداله بأخرى أكثر ملاءمة.
المعايير الناضجة تبيع نفسها من موقع "عند اختيار معيار ، وإيلاء الاهتمام لشعبية المجتمع". أتساءل كيف باعوا أنفسهم عندما خرجوا للتو. الفكرة الرئيسية هي أن شعبية معيار معين ليست عاملاً تود التفكير فيه أولاً وقبل كل شيء عند الاختيار. الشعبية والمجتمعات خاملة للغاية ويمكن لعقود عديدة رفض معايير جديدة أفضل. خاصة إذا كانت ثورية.
يتم إيلاء اهتمام خاص للمعايير التي رسخت نفسها تمامًا في الثقافة لمجرد أنها نشأت قبل المعايير الأخرى المماثلة. مثال قانوني هو الحرب المقدسة بين مخططات QUERTY و Dvorak. من الواضح أن الثانية أفضل ، ولكن الأولى تحمل ضربة (لا تزال أكثر شعبية) ببساطة بسبب الكتلة الحرجة من المستخدمين الذين لا يريدون كبح جماح واحدة جديدة.
تم العثور على أمثلة مماثلة طوال الوقت وفي ثقافة البرمجة. يرتكز معيار PSR على 4 مسافات بدلاً من علامات التبويب ، متجاهلاً الحقيقة الواضحة: لقد تغيرت بيئة التطوير لمعظم مبرمجي PHP من محرري وحدة التحكم إلى IDEs الكاملين ، حيث يكون الجدولة أكثر ملاءمة بعدة طرق: من السهل حذفه بالضغط على Backspace مرة واحدة ، ويمكنك تكوين أطوال علامات التبويب لتذوق.
عند تطبيق هذا المعيار أو هذا المعيار ، اطرح السؤال التالي: إلى من تجعله أكثر ملاءمة؟ من هو أكثر غير مريح؟ من الذي سيستفيد من قاعدة "تسمية أسماء أساليب theKamelKeysom السفلى"؟ من الواضح فقط لأولئك الذين اعتادوا على استدعاء لهم ذلك. سيصبح الجميع غير مرتاحين ، وسيتعين عليهم التكيف ، وهذه الضياع للوقت والموارد من الصفر تمامًا ، نظرًا لحقيقة أن
أ) الآن لدينا IDEs السحرية التي تسلط الضوء على عناصر مختلفة من التعليمات البرمجية بألوان مختلفة ،
ب) المبرمجين لديهم القدرة على القفز من مشروع إلى آخر ، ومعايير الترميز التي قد تختلف.
شخصيا ، عند تطوير المشاريع التي أستخدمها:
- CamelCase لتسمية الطبقات والأساليب
- CamelCase $ لتسمية المتغيرات التي تحتوي على مثيل لكائن
- snake_case $ لتسمية المتغيرات التي تحتوي على أنواع بسيطة
ليس لدي أي مشكلة في التمييز بين اسم الفصل الدراسي واسم الطريقة لأن الاسم الأول عبارة عن اسم والثاني فعل. بالإضافة إلى ذلك ، تساعد الإضاءة الخلفية. ولكن هذا هو ذوقي الشخصي ، وأنا لا أفرض ذلك على أي شخص. هذا هو منظور شخصي للإدراك ، إنه فردي لكل رأس فردي. كان شخص ما "محظوظًا" بالانغماس على الفور في المعيار الشعبي ، وكان شخص ما "محظوظًا" في بدء مسيرته المهنية بوظائف بديلة ، وطور شخص ما حياته الخاصة بشكل عام. أنا أقودك إلى حقيقة أنه بدلاً من إعادة تدريب الآخرين ، قد يكون من المنطقي إعادة تدريب نفسك على إدراك الرمز في أي معايير. أو حتى خارج المعايير.
بطبيعة الحال ، سوف يكون غضب أتباع التوحيد في هذا المكان ورمي لي العديد من الأسباب ضد. هذه المقالة ليست لهم ، أنا أكتبها لأولئك الذين يهتمون بفهم جوهر الأشياء ، ويحاولون تخيل ما كان يفكر فيه المؤلف حقًا وما الغرض الذي اتبعه.
القدرة على فهم رمز شخص آخر
الزناد الذي يسبب نبضات القيء في الغالبية العظمى من المبرمجين (مثال على التقييم الذاتي). لم يبدو غريباً بالنسبة لك أنه من الأسهل بالنسبة لنا في كثير من الأحيان إعادة كتابة جميع الشفرات من الصفر بدلاً من فهم شخص آخر؟ في أي صناعة أخرى ، نتصرف بشكل مختلف: أولاً نتعلم القراءة ، ثم نكتب ؛ أول استخدام (الأجهزة الكهربائية والمباني) ، ثم تصميمها. يبدو لي أن بيت القصيد هو في تعليمنا (على وجه التحديد في مجال البرمجة). يتم تدريسنا لتحقيق الهدف في الطريقة الأكثر مباشرة وسريعة ، وذلك باستخدام بعض المعرفة المكتسبة حديثا. نتيجة لذلك ، نجمعها (المعرفة) تمامًا حتى تعمل "تعمل" ، ونختبر القليلًا ونرسلها إلى المدرس للاعتدال. في رأيي ، سيكون من الجيد إضافة خطوة إضافية إلى هذه العملية ، حيث نقوم بمقارنة الكود الخاص بنا مع الكود الرئيسي ، والذي على الرغم من أنه ليس مثاليًا والوحيد الصحيح ، ولكنه يوفر حلاً بديلاً ، وغالبًا ما يكون أفضل وأكثر قابلية للقراءة.
بالنسبة إلى المشغل ، من أجل إيقاف تشغيله ، يكفي فقط أن تضع نفسك عقلياً في مكان العميل ، الذي كان يراقب المبرمجين المغادرين طوال حياته ، مدعيا أن عمل أسلافهم هو براز وتحتاج إلى إعادة كتابة كل شيء لجعله جيدًا. لا يمتلك العميل القدرة على معرفة ما إذا كنت تقول الحقيقة أم أنك كسول لفهم كود شخص آخر. لكسب ثقته في مثل هذه المسألة ، يجب عليك الخوض في رمز شخص آخر والعثور على اثنين من الثقوب الأمنية العملاقة وعرضها على العملاء. ولكن حتى في هذه الحالة ، من وجهة نظر العمل ، قد يكون من "المصلب" أكثر ربحًا. خاصة إذا كان الاستعانة بمصادر خارجية مع المواعيد المحددة والمال. هل يجب إلقاء اللوم على المبرمج؟
Zaklyuchenka
وها ، shcha اكتب بالحرف الأول بدلاً من وجبة الإفطار ، اشرب القهوة والزبدة من خلال الخلاط.
تبدو أعمق ، والتفكير على نطاق أوسع ، والبحث عن البدائل. لا تتوقف ابدا عن تطوير.