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