لا أحد يخطط في البداية لتطوير الشبكة. حتى في كابوس. بشكل عام ، وبدعم من الشركات الكبيرة والعلوم ، رأى الناس إنشاء أنظمة تكنولوجيا المعلومات باهظة الثمن كعملية علمية متقاربة متاحة للنخبة ، والتي من المهم للغاية فيها أن لا ننسى معظم الخوارزميات بسرعة فقط (لقد تعلمت مبدأ تجاوز الخشب الأحمر والأسود 5 مرات مع نشرة - نظرة على الوركين يتمايل في أوائل الربيع يمحو تماما المعلومات الواردة) ، ولكن أيضا في الدواخل من الحديد. بطبيعة الحال ، كان لابد من التحكم بشكل صحيح في هذا
العمل المقدس (المجد
للديمينغ العظيم) وقياسه واختباره واختباره إلى الأبد. ولكن حدث خطأ ما على الفور والخطأ ...
الكفاح من أجل حرية التعبير
بسرعة كبيرة ، بدأ تطوير البرمجيات يتحول إلى خوارزمية graphomania و nymphomania ، وكثير من المال ، للعملاء. بدأ الموقف مع إنشاء منتجات برمجية واسعة النطاق ومجتمعات المطورين من حولهم يشبهون المشاركة في الطوائف الدينية على أساس حب التعذيب الذاتي الهندسي.
استجابت حركة البرمجيات المجانية بسرعة إلى هذه التشويهات ذات المنطق السليم ، وذلك بفضل أدواتنا المجانية عالية الجودة والمفيدة للغاية في أوقات فراغنا وفي الأعمال التجارية التي اعتدنا عليها كثيرًا:
Linux و
MySQL و
PHP وغيرها الكثير.
جيد جدًا ، تكون قيمة البرنامج المجاني مرئية في سياق الحظر المفروض على استخدام Android في أجهزة Huawei. كما أن التطوير النشط للعملات المشفرة الحديثة يضيف الوقود إلى النار - فالبنوك المشفرة دخلت على محمل الجد في الأعمال التجارية وتسحب التربة من تحت أقدام المؤسسات والتقنيات التقليدية.
الأشرار في التنمية - البرمجة
هذا لا يعني أن البرنامج تبين أنه سيء. تم إنشاؤه للتو لفترة طويلة ، ثم تم اختباره لفترة طويلة ، ثم تلقوا ما عفا عليه الزمن بالفعل. العملية ، ومع ذلك ، تعمل. التطور: في ملايين الساعات من الاختبارات ، ستختفي الأخطاء وستبقى السحالي والصراصير بدلاً من الديناصورات ، ولكن ... عنيدة. قضى الناس الكثير من الوقت في حل مهام النظام منخفضة المستوى ، ونسيان أهداف العمل. وقد تفاقم الوضع بسبب الاعتقاد بأنه كلما زاد عدد المبرمجين ، زادت سرعة كتابة النظام. الرغبة في التخلص من تقديم الكود لمجد استخدامه للأعمال التي تم إنشاؤها عند العطش البري الأول ، ثم تنفيذ فئة كاملة من لغات البرمجة ، والتي كانت أهدافها هي السلامة وسرعة التطوير والبساطة والدقة: Python ، PHP ، Ruby ، Lua ، JavaScript. على الرغم من القيود النظرية: الافتقار إلى الكتابة الثابتة ، ووجود جامع القمامة وقت التشغيل ، والكسل المباشر والخداع الدلالي ، فإن التقنيات تتطور بشكل نشط وتحقق فائدة أكبر بكثير من الضرر.
مفاهيم متسربة
سرعان ما أصبح من الواضح أنه كان من الممكن للتدريس بعصا ، ولكن كتابة التعليمات البرمجية التي تحل مشكلة العمل التي كانت بسيطة ومفهومة لممثلي Homo Sapiens الآخرين كانت أكثر صعوبة وأنت تريد فعل ذلك بنفسك. للتعبير عن هذه الفكرة البسيطة ، أحرقوا القديس
ديكسترا على قيد الحياة تقريبًا . يتعلق الأمر بكيفية كتابة الكتب (تحتاج إلى رغبة كبيرة في التعلم والانتقال إلى الهدف = المواهب) وكتابة منشورات على Facebook (تحتاج إلى حساب). ولكن هذا المفهوم بعيد عن الجميع ، لأنه من الأسهل تعلم قواعد اللغة للغة بدلاً من تعلم كيفية كتابة أشياء مثيرة عليها ، وبالتالي لا يزال النقاش العنيف مستمرًا:
- أي لغة برمجة أفضل
- نظام التشغيل الذي هو أكثر صحة
- كتابة الاختبارات قبل الزواج وأثناءه وبعده
- ما قدم للاستيقاظ في الصباح ، وما إلى ذلك
المواجهة التقليدية بين الكتاب وأمناء المكتبات ، والنقاد الموسيقيين ونجوم المسرح ، ومبدعي الشركة والإدارة الوسطى :-)
في أيدي مهندس حقيقي ، تكون الشفرة جيدة ومدعومة وخالية من الأخطاء - بأي لغة برمجة. ومن قصر النظر للبحث عن بيئة تطوير يمكنك من خلالها قيادة الطلاب في إجازة ، والفتيات ، والبيرة ، وجهاز PS4 وتوقع شيء ما في المقابل.
اتضح أن الحياة متنوعة جدًا ، والمهام التي يتم حلها بمساعدة البرمجة تكون في بعض الأحيان أصلية إلى حد أن مفهومًا تقليديًا واحدًا لا يعمل ببساطة بشكل مباشر أو ينشأ عنه "مفاهيم هولي" المفعمة بالوعي:
- تعمل البرمجة الموجهة للكائنات بشكل جيد في الألعاب والأنظمة الرسومية ، ولكن في بيثون يكره بشدة كمفهوم يحد من الحرية. أتذكر أنني رأيت في PHP فئة الأدوات التي تمتد لفئة Utils
- تقوم البرمجة الوظيفية بعمل رائع في معالجة تدفقات البيانات والقيود (Apache Spark) ، لكن Haskell لم "تنطلق" أبدًا ، لأن الحياة ليست مجرد تجريد رياضي ، ولكنها غالبًا مجموعة من العكازات المبعثرة والضحكة
- تعمل البرامج النصية في PHP و Python و Ruby على الربط بين التقنيات المختلفة ومكونات التطبيق ، وهي تصف Lua في البرامج النصية في الألعاب ، لكن كتابة خدمات الشبكة المحملة للغاية عليها من الأفضل أن تطلق النار على رأسك. بيثون لا يفكر حتى في إضافة تعدد.
بشكل عام ، اتضح أن حل جميع المشكلات باستخدام أداة واحدة (Java Spring) ، بعبارة ملطفة ، غير فعال ، ومن الأفضل اختيار الأداة المناسبة للمهمة بدلاً من مطرقة المسامير باستخدام المجهر. لكن لسوء الحظ ، لا يرغبون في الدراسة ...
الصعوبة هي العدو الرئيسي
مع نمو النظم ، أصبح من الواضح بشكل متزايد أن بعض الموظفين يتعلمون بسهولة ، ويقومون بتنفيذ المفاهيم المتقدمة واللغات والتقنيات وقراءة الكثير ، وأحيانًا لسوء الحظ ، فإن الأغلبية ، بصراحة ، ليس لديهم الوقت ويبدأون في فهم الزملاء المتقدمين. تبدأ الوحدات المكتوبة بفاعلية ، والتي لا يمكن فهمها في البداية بالنسبة للأغلبية ، ثم للمؤلفين أنفسهم ، في أن يعيشوا حياتهم ويموتوا ، وعادة ما يكونون في عزلة فخورة. أصبح من الواضح أن الفريق بأكمله يجب أن يمتلك التكنولوجيا ، وإلا فإن التكنولوجيا يمكن أن تضر أكثر مما تنفع.
لغة برمجة ممتازة وجريئة ولائقة ، مع منحنى دخول حاد ، على سبيل المثال ،
صدأ وسيم ، يمكن أن يكون ناقصًا وخطرًا على المشروع.
الناس جميلون
كم عدد العقود التي طورت فيها لغات وتقنيات البرمجة في نفس الاتجاه:
- رمز سريع وسريع قريب من الأجهزة. مترجم ، غير مدروس ، مترجم يحل محل مطور. C / C ++.
- جامع القمامة ، لغة آمنة. مفاهيم قوية. الكتابة صارمة جدا. لكننا نفقد السرعة ونستهلك ذاكرة الوصول العشوائي. في بعض الأحيان نكتب تحت جامع القمامة. جافا ، C # ، سويفت (نعم أنا على علم RC).
- لغة بسيطة جدا ، دخول سريع ، تطور سريع. ولكن عدم وجود الكتابة (المخاطر) وجامع القمامة. PHP ، بيثون ، روبي.
ثم تظهر فكرة عظيمة: "شباب ، نحن لا نسير في الطريق الصحيح من الكلمة ؛ ودعونا نجعل المترجم أكثر ذكاءً؟ " ولد الصدأ ، الذي استوفى تقريبا جميع الطلبات:
- رمز فعال وسريع ، صفر التجريد
- برنامج التحويل البرمجي الذكي الذي يحمي المطور من الأخطاء الفادحة عند العمل مع الذاكرة
- لا جامع القمامة ، كارل. ليس كذلك!
المجد للعقل والجمال!

تطوير الشبكة - كيف يمكن أن يحدث هذا حتى؟
بعد أن اكتسبت التجربة اللازمة وحشوات المطبات ، أدركت البشرية فجأة أنه إذا عبرت أبسط
أداة لتخطيط النص ، اخترعت
لغة في ليلة واحدة
لأتمتة أزرار صفحة الويب ،
والقواعد الخاصة بتعيين الألوان ، وحذرة ، دون أي حركات مفاجئة ، اتبع جميع التعليمات ، وسحبها في جميع أنحاء الإنترنت ج باستخدام PHP ، مع العلم بأنهم يولدون الأطفال بالفعل - يمكنك الحصول على التآزر التكنولوجي الأقوى والبدء بسرعة في حل مشاكل العمل هنا والآن:
- تقديم واجهات فعالة باستخدام HTML / CSS. نعم ، لم يكونوا دائمًا مثاليين ، لكنهم فعّالون ، وخاصة الآن ، يتمتعون بقوة كبيرة.
- تخزين بيانات التطبيق بشكل آمن في MySQL
- تصفح الشبكة عبر لينكس
- نقل الرسائل بين المكونات باستخدام أنماط معمارية ناضجة مثل قوائم الانتظار
لا أحد ، في الواقع ، يفهم سبب حدوث هذه الثورة ، ولكن تظل الحقيقة هي أن التآزر بين التقنيات البسيطة قد أحدث قنبلة نووية. ودع PHP يواصل المفاجأة في استعارة المفاهيم المصقولة منذ فترة طويلة من لغات أخرى ، والسماح لبيثون بعدم إدخال التعددية المتعددة - إنها البرمجة النصية ، أي البساطة والدقة ومستوى عالٍ من التجريدات التي مكّنت من إحداث ثورة في البرمجة وحل مشاكل العمل بسرعة وببساطة وكفاءة في 3 -5 خطوط من التعليمات البرمجية.
يستمر التآزر - BigData والتعلم الآلي
كان للأسباب المذكورة أعلاه أن أقلعت بيثون لمهام معالجة البيانات وتحليلها. جلس علماء الرياضيات ، وكتبوا على أداة
الكتابة البطة "الرهيبة" ، التي تمت كتابتها على نحو ضعيف ، وهي أمر مخيف لتأخذها في يديك - لا يوجد مترجم ، واو ، يا لها من مشكلة! لقد كتبوا وكتبوا و ... كتبوا مجموعة من المكتبات من الدرجة الأولى:
- Numpy - معالجة عالية السرعة للصفائف متعددة الأبعاد ، هذا ليس غير متوقع في PHP
- الباندا - معالجة البيانات العلائقية القوية في الذاكرة
- Matplotlib ، Seaborn - العظمى أدوات تصور البيانات
لقد قمت بتنزيل توزيع
Anaconda المجاني ، وقمت بتثبيت الحزم وهذا كل شيء ، وإنشاء bigdat ، وإطلاق
الخلايا العصبية والتنبؤ بالمستقبل! مجانا
ومع ذلك ، هذه لا تزال الزهور. التوت هو بيئة تطوير وتواصل تفاعلية قياسية شائعة للغاية -
جوبيتر نوت بوك . الانطباع الأول هو الانحدار. حسنا ، هل هناك بيئة تطوير متكاملة قوية؟ ولكن بعد ذلك يأتي الفهم - هذه خطوة كبيرة إلى الأمام. دور Jupiter هو نفس دور تطوير الويب في وقت ظهوره: نتائج سريعة ، اتصالات سريعة ، قدرات حاسمة للأعمال ومعايير مفتوحة.
استوديو الويب ومبرمج الويب - الغلاف الجوي
أنت تسأل ، لماذا أكتب كل هذا؟ الحقيقة هي أنه من دون الانغماس في جو تطوير الويب ، لا يمكنك رؤية أفضل طريقة للتحكم في الجودة عند إنشاء تطبيقات الويب. بدون الوقوع في حب هذه الروح ، لا يمكنك النجاح على الويب. الأساليب القياسية والكلاسيكية لا تعمل هنا ، وهنا لماذا:
- على عكس عالم C ، C ++ ، حيث من المعتاد إصدار إصدارين كل عام ، هنا يتم إصدارها مرة واحدة في الأسبوع ، أي يحدث التطور بسرعة فائقة الخفة
- على عكس عالم C # و Java ، حيث من المعتاد أن تشارك في البرمجة الموجهة للكائنات وتغطي كل شيء من خلال اختبارات الوحدة والتكامل ، فغالبًا ما تكون هناك مفاهيم ومهام معقدة للغاية وغير قياسية بحيث يمكن للبرنامج النصي المكون من 10 أسطر حل المهمة بشكل أسرع وأكثر جمالا من إطار عمل من 10 فصول. يعد اختبار المخططات والبرامج النصية ، للأسف ، أمرًا صعبًا ومكلفًا للغاية ، لذلك غالبًا ما يتم اختبارها بالعين والمستخدمين :-)
- على عكس عالم البرمجة الوظيفية وجمال التعبير الوظيفي لمشكلة ما ، يتم التعبير عن الأساليب الحالية للحل من خلال ، بالمعنى الحرفي ولكن الجيد ، وهذا ، له ما يبرره - الجدوى الاقتصادية لنص إجرائي فظيع يمكنك التخلص منه وكتابة واحدة جديدة (وحتى 10 مرات)
- على عكس البرامج التقليدية ، يتم تنفيذ الأفكار بسرعة في الكود ، والتحقق منها ، والتخلص منها ، واختيارها بشكل أفضل. 90 ٪ من رمز - يموت ، 10 ٪ - يعيش وفرحة العملاء. من الأفضل أن يكون لديك 10 خطوط عمل موثوقة ومفهومة ، هنا والآن ، أكثر من 1000 سطر أكاديمي في مكان ما في الوظائف والفصول ذات الثقل والتغطية غير المحددين بواسطة الاختبارات الذاتية.
ولكن الشيء الرئيسي هو الناس. بين مطوري الويب ، فهي خاصة. ليسوا أنهم لا يحبون كتابة الكود ، بل يكرهون ذلك. هدف الإعجاب لمطور الويب هو سرعة حل المشكلة. إذا كان هناك خيار بين سطرين من كود PHP وإطار من 20 فئة ، فإن الخيار سيكون نحو حل جنسي أكثر من خلال ثغراتها. لهذا السبب ، إذا كان يمكنك اختيار كتابة أو عدم كتابة التعليمات البرمجية ، فسيقوم مبرمج الويب المحترف باختيار الأول وقضاء المزيد من الوقت مع الفتاة ، على سبيل المثال ، في غرفة القراءة بالمكتبة ، ودراسة
الملحمة الهندية القديمة ، وسوف يتعلم القادم الجديد الثاني حتى يدرك أن المزيد من التعليمات البرمجية ، كلما كان هناك المزيد من الأخطاء ، وفي الاختبارات الذاتية على رمز الخطأ ، سيكون هناك أكثر من ذلك ، وبالتالي فمن الأفضل أن تكتب 5 أسطر وتحقق منها بسرعة بعيونك بدلاً من إنشاء مظهر للجودة وإصلاح أي خطأ لعدة أسابيع :-)
كيفية إدارة جودة مشاريع الويب
بحلول هذا الوقت ، من المحتمل أن تكون قد تعلمت بالفعل أن تطوير الويب هو مجال برمجة خاص وجديد وعاصف للغاية ، مليء بخلاف الزملاء المهندسين الذين يكرهون الكود ولديهم رغبة ملحة في حل المشكلات في أسرع وقت ممكن وبمساعدة أدوات جاهزة وبسيطة . لهذا السبب غالباً ما ينمو مطورو الويب ليصبحوا مسؤولي نظام يرغبون في كسب المزيد من العمل. ونعم ، جمعية أخرى ، مطور ويب يشبه الطالب الذي يذاكر كثيرا بسلاح أكثر من الساموراي 8 دان بالسيف ، واللافتات ومليئة بالمفاصل. جعل الرهانات ، من سيفوز في معركة الشارع ، دون القواعد؟
ولكن هذه ليست سوى نصف المعركة. يمكن لعملاء الأعمال الذين أدركوا أن استخدام تطوير الويب حل المشكلات المعقدة بسرعة: إنشاء متجر ديناميكي عبر الإنترنت باستخدام اتصال CRM والبحث المدمج في كتالوج المنتجات في أسبوع واحد ، إذا قمت بإعادة تشكيل نصف وظائف الصندوق ، فيمكنك كتابة كتب ذات جودة بنفسك تطوير الويب ، الذي من المحتمل أن يتدحرج منه Deming باستمرار
على الجحيم . فيما يلي النقاط الأساسية التي تهز أساسيات ضمان الجودة الكلاسيكية:
- سرعة تجاوز المنافس أكثر أهمية من الجودة. إذا كان مشروع الويب ينطلق ويتدحرج (1 من 10 أو أقل) ، فيمكنك إعادة كتابته "بشكل صحيح" ، لكن الغريب أنه لا أحد يعيد كتابته ويعيش ، وغالبًا ما يكون ناجحًا ومريحًا لسنوات.
- تم تنفيذ المشروع للعمل ، ويمكن نسيان الجودة الداخلية لمرة واحدة مع ضمير واضح. احتمال أن يدخل شخص ما في الكود لاحقًا يساوي 0.00001٪ (لقد صعدت إلى هذه المشاريع ؛ في عشية رأس السنة الجديدة ، يمكن أن تصبح شعبية مرة أخرى).
- لا يرغب العملاء في كتابة الاختبارات التلقائية التي تزيد من تكلفة التطوير بمقدار 2 مرات وتضخيم بنية الفئات في مجموعات من المفاهيم المجردة والقائمة. لكن في بعض الأحيان ، بالنسبة للمكتبات ، ومع احتمال إعادة الاستخدام الكبير ، فإنهم يوافقون على ذلك.
- يكون العملاء على استعداد للمساعدة في اختبار نظام الويب ، وغالبًا ما يدركون (مع الأسف ، أن هناك استثناءات) أنه مع وجود فترات التطوير هذه (4 أشهر لمشروع تسليم المفتاح بالكامل) ومكافحة الاختبار الذاتي والتضخم بالرمز على مستوى العقد ، من المستحيل تحقيق نفس الجودة لجميع مكونات النظام .
- المعارف التقليدية ليست ضرورية ، لأنها تتغير باستمرار ، وتصبح قديمة وتحتاج إلى الاحتفاظ بقسم الوثائق لتحديثه. أسهل لإنشاء على الطاير ، ورؤية النتائج وقلب عجلة رشيق.
- أحمق يحب العمل
لفهم هذا ، يقوم متخصصو الجودة إما بالطيران بعيدًا عن التنين ولم يعدوا عائدين ، مرعوبون مما يحدث ، أو قبول قيم تطوير الويب ، واختراقهم ، وبناء شيء مثل هذا:
- يجب عدم اتباع الأساليب المتبعة في التصميم والتطوير والاختبار على أساس ديني. من المهم أن تصبح توماس . لذلك تحتاج إلى كتابة الاختبارات الذاتية ، ثم تحتاج إلى. من يحتاج إليها أه؟ دليل على الجدوى الاقتصادية. لماذا autotests إلى موقع بطاقة العمل إذا كان يمكنك التحقق بسرعة كل شيء بعينيك؟ لماذا تكتب كائنات صورية إلى الإطار الذي تستخدمه ، إذا كان يولد الكثير من التعليمات البرمجية التي قد تحتوي على أخطاء والتي يجب أن تكون مرفقة. أليس من الأسهل أن تكتب 10 سطور من الكود الواضح بدون DI؟
- بالمعنى الدقيق للكلمة ، من المستحيل تقدير فترة تطوير مشروع الويب مع 3-5 أيام للتصميم ، لذلك يتم أخذ التقييم من مشروع الويب الأكثر تشابهًا
وضربه في 666 - في بعض الأحيان ، عندما يكون ذلك ممكنًا من الناحية الاقتصادية ، تحتاج إلى إزالة المخاطر الحرجة على النموذج الأولي وإجراء اختبارات إجهاد وقائية
- من المهم التحقق من استخدام الأدوات والأطر والتقنيات الجاهزة وأن هناك إدراكًا واضحًا بأنه كلما زاد عدد التعليمات البرمجية ، سيتعين إصلاح المزيد من الأخطاء
- من المهم جدًا ، توفير الاتصالات الأكثر كثافة التي تتيح لك الانغماس الكامل في نظام الويب والشعور بحركته وبنيته وإنشاء تأثير "العديد من العيون تنظر إلى الكود". تذكر أنه في نظام التشغيل Linux ، وهو نظام تشغيل ناجح ، ولم يكن هناك اختبار تلقائي لمدة طويلة ، وإذا كان تصميم Test-Driven Design موجودًا على الفور ، فسيظل من المحتمل إطلاقه. ولكن من ناحية أخرى ، كان لنظام Linux على الفور تدقيقًا عميقًا في الشفرة ونظام قبول التغيير المركزي. تحتاج أن تشعر به جيدا.
- في مثل هذه المشروعات ، يمكنك تقليل المخاطر بشكل كبير إذا قمت بتوصيل مهندسين ذوي خبرة لتخطيط بنية منخفضة المستوى وتقرر الحاجة إلى نموذج أولي. بمجرد أن يكون هناك شعور بأن هناك زيادة في المتطلبات والميزانية ، لتكون في مأزق - تحتاج إلى صنع بضع الحيل الانتحارية ، ورش الدماء على العديد من الجدران ولوحات Agile. ضحية لنجاح المشروع - ماذا يمكن أن يكون أكثر برودة؟

وبالتالي ، لا يزال من الممكن إدارة جودة نظام الويب بشكل فعال إذا تعاملت مع الأمر بحكمة وعناية ، دون أخذ عقائد الهندسة الدينية في الإيمان ، والتدقيق المزدوج في كل شيء والسعي لتحقيق البساطة وتقليل مقدار الكود والمكتبات التي تم إنشاؤها من الأعلى. إن كبح الإبداع الفني السريع في الفرق وتوجيهه نحو البحث عن البساطة والدقة والتكلفة المنخفضة والشفافية - يساعد كثيرًا ، لا سيما في إنشاء أنظمة ويب معقدة وغير قياسية.
لكن الأصعب ، لسوء الحظ ، تركنا وراء الكواليس. الجزء الأصعب هو تعلم كيفية الموازنة بين التركيز على الحلاقة. أنت ، مطور ويب ، تقف بدون دروع ، في
أفراد الأسرة الضيقين وقميص مع نقش "Agile" ، مع حبال الغزل في يديك ، أمام العملاق. وإذا ضربته على الجبهة - مشروعك. لكن افتقدها عدة مرات متتالية - سوف تداسك فرق الساموراي 8 دان بامتداد جيد ومليء بالمفاصل ، والتي ، بأكل جثتك ، ستبصق بالعظام وتضحك: "أردت حل مشكلة مع 50 فصول و 7 أطر في PHP ، مجنون" . بشكل عام ، لا تفوت ، حمل الأسلحة النارية ، وتعلم تطوير الشبكة و ... حظ سعيد!