هناك معسكران لا يمكن التوفيق بينهما. يقول البعض: يجب أن تصف التزاماتك بدقة وكفاءة. كل التزام هو عمل كامل وذي معنى. إذا لم تتمكن من تقديم وصف واضح وبسيط للارتكاب ، فأنت لديك أخطاء خاطئة.يعتبر البعض الآخر أنك تقوم بالتعهدات كما تريد ، وهذا جزء من سير عملك الشخصي. لكن مجموعة الطلبات موصوفة بالتفصيل: ما الذي تم عمله ، وكيف يتم ذلك ، ولماذا يتم ذلك. حسب الاختبار ، ما هي المشكلة التي تحل ، وما يجب الانتباه إليه.أنا من أشد المؤيدين للنهج الثاني - من غير المناسب بالنسبة لي أن أضرب عملي إلى قطع صغيرة. أقوم بمهمة صغيرة وأتسرع بشكل عشوائي حول قاعدة التعليمات البرمجية ، وأختبر وأجري تغييرات في الترتيب الذي اتضح به. إذا تمكنت من النقر فوق زر ، وإعادة هيكلة عملي إلى التزامات جيدة ، فسوف أنقر عليه. لكن لا يوجد زر ، لكني لا أريد أن أكسر نفسي. في الوقت نفسه ، وصلت إلى مهارة معينة في وصف مجموعة الطلبات. حدث أن اكتشفت الرمز في Microsoft (من خلال outstaff ، لا يتم احتسابه) ، وهناك حصلت على أعلى المعايير لمعالجة مجموعة من الطلبات. على مر السنين ، لقد طورت للتو هذه الممارسة. عادة تمكنت من إقناع الفريق باستخدام مثل هذا النهج.ولكن في الوظيفة الأخيرة ، حصلت على فضل - مؤيد قوي للالتزامات التفصيلية. أوه ، جادلنا لفترة طويلة. لقد لعبت موقفي الثانوي دورًا ، وليس من السهل إغلاق عادة سوفكوفسكي في الاتفاق مع الشيء الرئيسي. لم أكن قاطعًا كالمعتاد ، وتم وضعه على كلتا الشفرتين. مكدسة ، لكنها غير مقتنعة.
إذا اتحد المطورون فجأة في حكومة واحدة ، ووضعوا قواعد وبدأوا في إعلان بعض الأساليب المحظورة ، ستبدأ حرب أهلية في اليوم التالي. كل ذلك لأنه في عالم المطورين هناك إيمان موضوعي وقابل للقياس. في الحقيقة مستقلة عن الإدراك البشري. وإذا كان كل هذا موجودًا ، فهذا يعني أن أحد المتنازعين مخطئ بشكل موضوعي.وقعت أول نزاع عمل خطير لي في وقت مبكر جدا. كنت لا أزال خضرًا ، يعتقد أنه وسط متوسط ، وفي الواقع مطور رائع جدًا وذكي. ألقى مطور حقيقي واحد من فريقي العلاقات العامة. كان لدينا تدريب على أن يقوم جميع أعضاء الفريق بعمل كود المراجعة. فتحت الرمز ورأيت المشكلة على الفور تقريبًا. كتب رجل اختبارًا لبعض الوظائف التي أخذت رقمًا. لذلك أطعمها 0 ، 1000 ، وعشوائي (0 ، 1000).في ذلك الوقت ، شعرت بشدة أن زملائي الآخرين في الفريق رأوني كوافد جديد غبي. وانتظر لحظة لطمهم برؤيته. كنت محظوظا - عشوائي في الاختبارات!لم أفهم حقًا نظرية اختبار الوحدة ، لكنني قرأت كتابين ، وتذكرت بحزم - نفس اختبار الوحدة في نفس قاعدة الكود يجب أن يعطي نفس النتيجة. قضيت حوالي ساعة أفكر في التعليق حتى لا يبدو سامًا ، لكنني أوضحت أن القرد فقط ، الذي تم تعليمه للعد بالأمس فقط ، يمكنه التفكير في مثل هذا القرار. في النهاية ، وبطبيعة الحال ، بدا غبيًا للغاية ، مثل كل شيء تخيله المتدربون في الأمس الذين كانوا يتصورون أنفسهم كمطورين من أنفسهم.في اليوم التالي ، أدركت أنني فتحت بوابة للجحيم. كان هناك مائة آخرين تحت تعليقي. لبقية اليوم ، بدلاً من فريق من ستة مطورين ، كنا فريقًا من ستة قرود. جادلنا باللغة الإنجليزية في العلاقات العامة نفسها ، على الرغم من أن الجميع كانوا روسيين. عندما لم يكن مخزون الكلمات كافياً ، استدعيوا. رموا أنفسهم ببعضهم البعض بروابط ، اقتباسات من كتب ، دراسات ، تحولوا إلى الفرد. أجاب أحد الزملاء على أحد تعليقاتي بلقطة شاشة من قاموس إنجليزي من أجل السخرية من لغتي الإنجليزية. لكننا لم نتوصل إلى حل وسط.كان السؤال معقدًا. من ناحية ، لم نكن نعرف جميعًا على الإطلاق ما كانت هذه المعلمة مسؤولة عنه ، حيث نقلت وظيفتنا إلى أخرى ، من شبكة داخلية لا توجد بها أرصفة. لذلك ، من الناحية النظرية ، يمكن أن تقع الوظيفة على أي قيمة ، مما يعني أن الاختبار يمكن أن يمسك بها ، ومن ثم يمكننا توقع الخطأ في المنتج. من ناحية أخرى ، كان لدينا بالفعل مشكلة التراكيب العشوائية. وبسبب هذا ، إذا كان المشروع يتم بناؤه محليًا وكان يتعطل ، فقد طلبنا بغباء بناءًا جديدًا ولم ننظر إلى أي سجلات. بعد كل شيء ، استغرق البناء أربع ساعات ، ولن ينظر أحد في طلب السحب حتى يمر CI.بالإضافة إلى ذلك ، كانت السيارات مشغولة في كثير من الأحيان - كان من العملي أكثر بكثير طلب بناء بينما كان لا يزال يتم طلبه من البحث عن "مشكلة" محتملة (والتي غالبًا ما اتضح أنها مهلة طيران في اختبار التكامل). هذا يعني أنه حتى إذا خرج الاختبار العشوائي ، فلن ننتبه.تم حل كل شيء في dealik التالي. اتصلنا بالفريق بأكمله ، واستمرنا لمدة نصف ساعة في الجدل - باللغة الروسية. لم نلاحظ كيف انضم مدير التطوير الأمريكي لدينا إلى المكالمة ، وواصلنا تحطيم بعضهم البعض بحجج بألوان عالية. حتى سمعوا "مرحبًا ، هذا ليس مهمًا على الإطلاق. فقط قم بدمجها كما هي ". لا أعرف كم من الوقت استمع إلينا من قبل ، وبما أنه فهم ما كنا نتحدث عنه ، لكننا توقفنا عن الجدل فجأة. جمدوا ونسيوا ذلك. افترقنا بسلام ولكن غير مقتنع.
منذ ذلك الحين ، اكتسبت خبرة لكي أفهم - ولكن لا أهتم على الإطلاق ، بشكل عشوائي ، أو إعاقة ، أو حالات حدود. سوف يتداخل اختبار الوحدة اللعينة هذا - وسوف نعيد كتابته. كل شيء أفضل من الجدل طوال اليوم. ولكن إذا كنت تتخيل أنني في عالم مثالي ، حيث من الضروري دائمًا اتخاذ قرارات أكثر صوابًا فقط ، فأنا لا أعرف ماذا أفعل. لقد جمدنا اختبارًا بشكل عشوائي ، والآن أفهم هذا كخيار لصالح الموثوقية ، ولكن على حساب راحة التنمية.في اليوم الآخر واجهت معضلة مماثلة. لقد لعبت مع الرمز الزمني الجديد وكتبت شيئًا يمكن استخدامه مثل هذا
const consumeNumberLessThan100 = (v: LessThan<100>) =>
doWork(v);
const consumeNumberMoreThan100 = (v: MoreThan<100>) => doWork(v);
const sample = (x: number) => {
const lessThan100 = check(x,'<', 100);
if (lessThan100) {
consumeNumberLessThan100(lessThan100);
consumeNumberMoreThan100(lessThan100);
}
const moreThan100 = check(x, '>', 100);
if (moreThan100) {
consumeNumberMoreThan100(moreThan100);
consumeNumberLessThan100(moreThan100);
}
consumeNumberLessThan100(x);
consumeNumberMoreThan100(x);
}
اعتقدت ، اللعنة ، هذا رائع جدًا - لذا يمكنك التقاط عدد كبير من الأخطاء في مرحلة مبكرة. تصميم أدوات تقييد القيمة الخاصة بي أمر فظيع ، ولكنه في الوقت الحالي مجرد مفهوم. في المستقبل ، يمكنك بسهولة توسيعه ، وإنشاء DSL قوي وصياغة شروط معقدة حقًا لمطابقة المعلمات مضمونة في مرحلة التجميع. لقد اكتشفت كيف يمكن أن تزيد من موثوقية أي قاعدة تعليمات برمجية ، وأرسلت مقتطفًا إلى العديد من المطورين المألوفين.انقسمت الآراء مرة أخرى ، وليس في اتجاهي. إعادة التعقيد ، والإفراط في الهندسة ، غير مدعوم ، سيشوش الجميع على حارسك بمساعدة فريق الممثلين إلى eni. لا يمكن قراءتها. جيد كتجربة سيئة في المشروع الحالي. يتم رسم أمثلة للاستخدام من الإصبع. اذهب إلى العمل ، فيل.قال أنصار النهج ، نعم ، موثوق بها للغاية. كلما أسرعت في الخطأ ، كان ذلك أفضل. بالإضافة إلى ذلك ، إذا كتبت دالة تعمل مع عدد محدود ، فلا يزال عليك كتابة شيك ، لكنها ستعمل فقط في وقت التشغيل ، وستزيد من مقدار التعليمات البرمجية في نص الوظيفة.أنا الآن أكثر ذكاءً قليلاً من ذي قبل ، وتعلمت سماع الحجج. تخيلت نفسي أكتب وظيفة محمية من نوعي في مشروع حقيقي. مثل كل من يستخدمه يسألني ما هذا بحق الجحيم. كيف ، بعد تخبط الشريحة ، يبدأون في تغطية قاعدة الكود بـ DSL مخصص ، ذو مظهر فاسد. بينما نتحقق ثلاثمائة مرة من القيم التي في الواقع لن تتجاوز أبداً المسموح به. هذا النهج فظيع حقًا للاستخدام ، يمكن حل بعض المشكلات أو تخفيفها ، ولكن على سبيل المثال ، مثل هذه الحالةconsumeNumberLessThan100(90);
لا تنعم بأي شكل من الأشكال. يجب أن أثبت للمترجم أن 90 أقل من 100. سوف أورد أي نشاط ، وسوف يتحولconsumeNumberLessThan100(assert(90, '<', 100));
لا يبدو رائعًا. جميع الحجج ضد ، لكنها لا تتعارض مع الحجج. تبين معضلة - سهولة التنمية ، أو الموثوقية. هنا نقع في الفخ ، نبدأ في التفكير في أننا بحاجة إلى حساب نوع الراحة المتوفرة وأي نوع من الموثوقية موجود. لكن الراحة والموثوقية في التنمية هي أشياء معقدة للغاية. تتكون من آلاف المعلمات.على سبيل المثال ، الراحة هي عندما يقوم IDE بتجميع التعليمات البرمجية لك على زوج من الأحرف المدخلة ، عندما يكون الرمز سهل القراءة ، عندما يمكنك تغيير وظائف الطريقة دون النظر إلى المستند. عندما لا يتم تحميل المحول البرمجي بالتحليل الثابت ، يكون البناء سريعًا ، ويعرض محرر النصوص الأحرف على الفور. ولكن عندما يكتشف المترجم الخطأ ويبرزه لك ، فهذا أيضًا مريح. وأيضا من الموثوقية. والذي يتم تجميعه بدوره من عدد كبير من الأشياء المختلفة تمامًا.يجب عليك الجلوس وحساب المدة التي سيستمر فيها المشروع ، وفي أي اتجاه سوف يسير ، وكم مرة في تاريخ البشرية سيتصل بها شخص واحد أو طريقة أخرى لقاعدة التعليمات البرمجية الخاصة بك ، والتي سيعمل عليها المطورون هنا. هذه قائمة لا نهاية لها من الأسئلة للنصف الجيد من المستحيل حساب الإجابة الصحيحة. مجرد تخمين.
ذات مرة ، طلب مني أحد الأصدقاء إعداد أسئلة فنية لمقابلة مع أندريه بريسلاف. ذهبت إلى رصيف Kotlin لأجد نقاطًا مثيرة للجدل في التصميم. هم هناك ، كما في أماكن أخرى ، الظلام. ولكن أكثر ما أثار اهتمامي هو نهج التعامل مع الاستثناءات. معالج الاستثناء في Kotlin هو تعبير ، نهج فعال وموثوق به تمامًا. هذا فقط لمعالجة الأخطاء ليست ضرورية. مما يسقط كل الموثوقية إلى الصفر. وهذا مثير للاهتمام لأنه في الرصيف ، لم يكن المطورون كسالى للغاية لتفسير اختيارهم: "هناك دراسات تفيد بأن معالجة الأخطاء الإلزامية تقلل إلى حد كبير من إنتاجية المطورين مع انخفاض طفيف في الأخطاء."أنا مجنون ، كيف يمكنك كتابة الرمز إذا لم يكن لديك فكرة عما يجب فعله عندما لا يعمل بشكل صحيح!؟ إذا كنت لا تعرف كيفية التعامل مع الاستثناء ، فلا تتعامل معه - ليس حلاً للمشكلة ، بل الرفوف. في مرحلة ما ، ستسقط الشفرة ، وستسبب المشكلة الموجودة دائمًا ضررًا يمكن توقعه.ولكن لا حاجة إلى حجة منطقية ضد ، يمكنك القيام بالإحصاءات فقط. بالنسبة لمطوري kotlin ، يكسر البحث المنطق لأن لديهم فلسفة. فلسفتهم هي البراغماتية. الحديد ، البراغماتية غير القابلة للكسر ، مدمجة باستمرار في جميع ميزات لغة البرمجة هذه. المثاليون الذين شاهدوا Haskels / Idris و govnokoders الذين يكتبون golang يفعلون نفس الشيء تمامًا. تسود فلسفة التسوية المعقولة في قاعدة كود F #. وليس هناك شعور بأن أحدهم على حق ، والباقي حمقى.كل هؤلاء الناس أذكى بكثير وأكثر خبرة من أشخاص مثلي ، ويبدو أنهم قد فهموا منذ فترة طويلة أنك تطور فلسفة لنفسك ، ثم تتبعها ببساطة. لأن السمة القاتلة لأي فلسفة هي حل المعضلات.وهكذا ظهرت الفلسفة في كل شيء في مجال تكنولوجيا المعلومات ، والفلسفة هي عكس فكرة الموضوعية الموضوعية والحقيقية تمامًا ، لأن الفلسفة تقدم اختيار الحقيقة الذاتية لنفسك.لكل منا فلسفته الخاصة - لم يتم وصفها في كلمة واحدة ، إنها مجموعة معقدة من الأنماط لاتخاذ القرارات. وكثيرا ما نقوم بتغييرها أو توسيعها. من الناحية العملية ، اتضح أن لديك مشروعًا بفلسفتك الخاصة ، وهو مكتوب بلغة برمجة مع فلسفتك الخاصة ، باستخدام أطر وأدوات ، لكل منها فلسفته الخاصة. ويكتب المطورون هذا المشروع ، لكل منهم فلسفته الخاصة. وفي كل مرة تحتاج فيها إلى اتخاذ نوع من القرار ، لا تؤثر سوى مجموعة من الظروف على أي قرار سيتم اتخاذه. لا إدارة التعقيد ، وليس الخبرة ، وليس النهج ، وليس المعرفة ، ولكن مجرد حادث.وجميع هذه المشاريع تعمل. نصيب الأسد من جميع المهام التي يحلها المطورون هو القضاء على عواقب أخطاء المطورين الآخرين ، لكن المشاريع تعمل وحل مشاكل الناس. يأتي الأشخاص الأذكياء بالممارسات والأنماط المعمارية. لغات البرمجة مع التحكم القوي في النوع والعقود - كل شيء ، إذا كان المطورون فقط أقل خطأ. وفي كل يوم أفتح لوحة Edge في العمل ، وأرى أن هناك أخطاء أكثر من المهام. أين يوجد كل خلل ، هذا هو الآخر ، إدارة التعقيد ، مطور حماقة.فلسفة التطوير هي ببساطة اختيار الطريقة التي تضع بها يديك في النهائي. ولكن إذا لم تكن هناك فلسفة ، ولكن فقط منطق موضوعي خالص ، فإن أي حجة ستنزل إلى مشكلة الخالق القاهر والحجر الذي لا يطاق.
لقد كنت في مرحلة التطوير منذ فترة طويلة ، وتعلمت كيفية القيام بما يقولونه ، حتى عندما أختلف بشكل أساسي ، وبدأت في كتابة تعهدات مفصلة للغاية. Devlid مصاص دماء حقيقي. لا يتطلب الأمر مجرد وصف - يريدني أن أكتب ما يفعله كل ملف ، ولماذا يفعله ، وكيف يفعله. ما هي المشكلة التي يرتكبها؟أضفت ثماني عمليات تفصيل إضافية ، نفس الوصف التفصيلي لمجموعة الطلبات - وأعجبني ذلك kapets. منذ ذلك الحين ، لم نعمل تقريبًا على هذا المشروع بالتحديد ، ولكن من وقت لآخر أذهب إلى هناك للإعجاب بهذه الالتزامات. حقا ، رائع حقا. وفي جميع المشاريع الأخرى ، باستثناء مشاريعي الشخصية ، أقوم الآن بتطبيق هذا النهج.كان من الصعب للغاية بالنسبة لي إعادة بناء سير العمل. لقد مر شهر ونصف ، ولا يزال من الصعب علي كتابة رمز مثل هذا. ولكن يبدو أنه يستحق ذلك.أم لا. بصراحة لا أعرف. ولا أعلم أنه إذا كان الأمر يستحق ذلك بالتأكيد ، فهل يجعلني ذلك الشهرين أحمقًا كاملاً. يتجول حوالي عشرة أشخاص في مكان ما في العالم ، وقد تعلمت عدم ارتكاب مثل هذه الالتزامات. هل هم أغبياء؟ لا اعتقد هذا.
البودكاست الخاص بي