"البرمجة أفضل من الجنس"



في فجر مسيرتي ، سمعت هذه العبارة من رئيس قسم ACS في أحد المصانع السوفيتية عندما عرض عليه الذهاب للعمل في قسمه.

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

ومع ذلك، والعواطف هي شيء واحد و رجل مهندس معقولة، كان مختلفا. لقد كنت مهتمًا بالسؤال منذ فترة طويلة ، ولكن ما هو السبب الحقيقي وراء رغبتي في جعل الرمز جميلًا؟

أي شخص مهتم بالتفكير في الأساس المنطقي لإيجاد الجميل في تطوير البرمجيات وفي التخصصات التقنية الأخرى ، أسأل تحت القط.

مقدمة


كان الدافع لكتابة هذه المقالة هو المادة الأخيرة على هبر " توقف بالفعل عن خوفك من القرارات الجميلة ذاتيا في الكود - أنت لست روبوتات " ، حيث يحاول المؤلف إثبات شغفه الحدسي لإنشاء كود جميل.

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

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





ولكن بالنسبة لي ، فإن تطوير البرمجيات أقرب ، والذي سيتم مناقشته لاحقًا.

أسرار عملية إنشاء البرمجيات


يمكن التعامل مع تطوير البرمجيات من زوايا مختلفة. من ناحية ، هذا نظام تقني بحت لا يسمح بالحريات ، مبني على نهج صارم ومتسق للتنمية. هذه عملية راسخة وتصحيحها ، والتي تشمل جمع المتطلبات ، وتطوير المواصفات الفنية ، والتخطيط ، ومراقبة تنفيذ الخطط ، وتنفيذ النتائج التي تم الحصول عليها ، وما إلى ذلك.

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

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

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

علاوة على ذلك ، يمكن التعرف على نفس الرمز على أنه جميل وقبيح في نفس الوقت! وهذا يعني أن مفاهيم الجمال هي فردية بحتة (من يشك في ذلك). ما هو الكود الجميل وكيف تكتبه؟ ، نتائج المسابقة الدولية 20 من التعليمات البرمجية غير معروف على C .

لذلك ، كان عليّ التعمق أكثر في قاعدة هذه العملية. في اتجاه الهوية الشخصية للمطور ، والتي يمكن أن تعمل كمبرمج ، أو مهندس معماري ، أو مختبر ، أو محلل ، أو حتى تكون جميعًا في وقت واحد في نفس الوقت أو في نقاط زمنية مختلفة.

ما الذي يدفع هذه التروس ، في الشركات الصغيرة والشركات الكبيرة ، في الآلات الخالية من الروح في صناعة البرمجيات؟

بالطبع ، لا يمكن البحث عن قوة دافعة بدون علم النفس.

ما هي القوة الدافعة؟


لا ، لن أقتبس من أوراق علمية حول علم النفس أو الدافع الشخصي. الآن سيجد أي شخص ، إذا رغبت في ذلك ، العديد من المقالات حول هذه المواضيع.

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

للأسف، لم ألتق هذا التصنيف (ربما لم أجد ذلك أم لم يكن يبحث هناك)، وبالتالي، نتيجة لتحليل تجربتي الخاصة والتواصل مع زملائي، وأنا قررت أن تحديد مستقل الأنواع التالية من الدافع للمطورين مع أسماء التقليدية: المواد ، الاجتماعية و الداخلية .

الدافع المادي


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

الدافع الاجتماعي


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

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

الدوافع الذاتية


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

بالطبع ، مثل هذا الفصل في دوافع المبرمجين مشروط ويمكن أن يتدفق من نوع إلى آخر أو حتى يكون مزيجًا من عدة عوامل تحفيزية.

ولكن إذا نظرت إلى نتيجة عمل المبرمجين من وجهة النظر هذه ، فعندئذ في نظام التصنيف هذا ، يمكنك بالفعل العثور على بعض المنطق ومحاولة العثور على الجمال في أي رمز مصدر تقريبًا (برنامج من مسابقة IOCCC ):

typedef unsigned char t;t*F="%c",l[]="|\\/=_ \n](.\0(),*(.(=(}*.)[[*.",N='\n',*
r;typedef(*H)();extern H Ar;Q(a){return(a|-a)>>31;}H S(c,a){return(H)(a&~c|(int
)Ar&c);}extern t*ist;V(t*u){*u^=*u&2^(*u>>7)*185;}Z(t*u,t n){*u-=n;}e(t c,H h){
R(h,Q(*                                                                 r^c));}
I(){r=l                                                                 +7-4*Q(
getchar                                                                 ()^*l);
}R(H h,                int                                              c){Ar=S
(c,h);-                main()                                           ;}P(){r
++;}z()                {                                                O(&N);}
O(t*c){                    printf(                                      F,+*c);
}T(){r=                        "This is not a function\n"               ;}w(U){
U=Z(r,8                    );                                           r-=~Q(*
r/8-4);	                   return 0;                                    }M(){r=
ist-68;                }                                                h(){t G
=r[1]-r                                                                 [2]^*r;
G^=30;V                                                                 (&G);e(
0,(O(&G                                                                 ),P(P(*
r++)),z));}g(){M();R(h,0);}f(){P(O(r));e('f',g);}p(){P();e('a',f);}d(){P(O(r));
e('n',p);}c(u){u=r[-2];T(Ar=d);R(f,Q(u^'"'));}n(){e(w(O(l+*r%8)),c);}a(){I();R(
n,0);}main(){S(Q(Ar),a)();}H              Ar;t*ist="Rene Magritte"-(1898-1967);

عندما تجعلك النكتة تفكر


في البداية ، تمت كتابة هذه المقالة كمزحة ، واسمها يتحدث عن نفسه ، لذلك تم اختيار الصورة وفقًا لذلك.

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



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

أليست هذه مزحة؟


نتيجة لمحاولة غير جادة لدراسة الرغبة الشديدة في الجمال بين المبرمجين ، تم الحصول على استنتاجات معقولة تمامًا يمكن استخدامها ، إذا رغبت في ذلك ، في صناعة تطوير البرمجيات.

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

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

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

تحديث 1: سأترك رابطًا للرسم منجانفاريفحول موضوع المقال: سيرجي و "البرمجة أفضل من الجنس"

تحديث 2:
وفقًا للنتائج الأولى للتصويت ، ظهر اتجاه للتصويت بشكل أساسي من أجل الدافع الداخلي (145 - 60.3٪). ولكن قبل اختيار الخيار الثالث عند التصويت ، يرجى مراعاة ما يلي: من يحدد معايير الجودة (أو الجماليات) في مشروعك؟

إذا كنت قائد فريق ، أو مهندسًا معماريًا ، أو أي شخص آخر يقبل أو يحدد بشكل كبير قواعد تحديد مثل هذا التقييم ، فإن اختيارك هو الخيار الصحيح.

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

للتحقق من ذلك بشكل لا لبس فيه ، تخيل موقفًا يكون فيه مزاجك "الأسود" السيئ ونتائج العمل (رمز البرنامج المكتوب في ذلك الوقت) يتوافق معها. هل ستتم الموافقة على التزامك؟ إذا كانت الإجابة بنعم ، حتى إذا كنت لا تلتزم تمامًا بمعايير الجودة المقبولة ، فإن دافعك هو حقًا داخلي. ولكن إذا تم رفض رمزك ، فإن الدافع الخاص بك لا يزال اجتماعيًا ، على الرغم من أنه عادة ما يكون متناغمًا مع الداخلي.

All Articles