خمسة اتجاهات مخيفة للتصميم الحديث

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

نحن مستعدون للجديد وقد لا ننتظر حتى يأتي المستقبل ، وسيتعين علينا التكيف معه. يمكننا المضي قدما ، لمعرفة فقط في أي اتجاه.

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



التالي هو النص النصي لتقرير إيجور على AppsConf ، لكنه لا يشير فقط إلى تطوير الهاتف المحمول ، وليس فقط إلى تطويره ككل. إيجور بوجانكو ، مؤسس Zerocracy ، مطور Cactoos ، Takes Framework ، JCabi وغيرها من المشاريع مفتوحة المصدر. كتب سلسلة من الكتب بعنوان "الأجسام الأنيقة" ، ويحافظ على مدونة استفزازية ، ويقدم تقارير مثيرة للتفكير مثل هذا الكتاب.



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

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

• اختبارات الوحدة
• تحليل ثابت
• التكامل المستمر
• إدارة التبعية ؛
• تسليم مستمر
• بيئة التدريج ؛
• التطبيق الموافقة على العملية على متجر أبل
• عملية تجميع العيوب من الإنتاج ، إلخ.

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

وجدت مثل هذا الاختصاصي ، لكنه أخبرني: "لماذا تفكر في هذا؟ ارسم الطلب أولاً. ما هو التكامل المستمر؟ انتظر حتى مع اختبارات الوحدة - اجعلها تعمل. ما هو خط أنابيب التسليم؟ لماذا TestFlight - استخدام جهاز محاكاة. "

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

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

نشر أولا ، ثم رمز

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

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

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

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

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

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

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

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

يجب أن ينتهي المبتدئ في بيئة صديقة له من وجهة نظر التجميع - يجب عليه فتح الملف التمهيدي وفهم بضع دقائق كيفية التأكد من أن كل شيء يبدأ على جهاز المحاكاة. ما الذي يجب النقر عليه للتحقق مما إذا كان كل شيء مبنيًا من سطر الأوامر - وليس من معرفات IDE معقدة تحتاج إلى تكوين لعدة ساعات أخرى. يجب أن يكون من الممكن كتابة make / build / etc على سطر الأوامر. بعد ذلك ، يتم جمع كل شيء وطباعة خط أخضر - كل شيء جاهز - ثم سحب الطلب. هذه هي الفكرة الأولى التي أريد مشاركتها اليوم.

بالطبع ، ستقول إنك لا تعمل بمفردك ، لا بصفتك المؤسسين الوحيدين للمشروعات ، وليس كمدير CTO. إنك تعمل ضمن فرق ولا يمكنك القدوم للتو وتقول إنك الآن ستتعامل مع النشر و TestFlight وتحتاج إلى فهم CI بشكل عاجل. هذه ليست مهمتك ، فلن يتم منحك الوقت لذلك ، إلخ.

لذلك ، أوصي بأن تقوم بمشاريع الحيوانات الأليفة الخاصة بك - وهي المشروعات التي تقوم بها من أجل المتعة الخاصة بك - لفهم كل شيء بالكامل.

فقط 20-30 ٪ من المبرمجين لديهم تطبيقهم المنشور الخاص ، ويجب أن يكون لدى الجميع. إذا كنت تفكر في نفسك وترغب في أن تكون مبرمجًا مطلوبًا ، فإنني أوصي بعمل تطبيق للهاتف المحمول الخاص بك والاطلاع على الدورة الكاملة لدخولها إلى السوق: إجراء فحوصات على Apple Store و CI والتعبئة والتغليف وكل شيء آخر. اجعله مفتوحًا حتى يتمكن الأشخاص من المساهمة ويظهرون لك كيف فشلوا.

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

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

الخوف الثاني ، في رأيي ، هو المال.

كم رمز سوف تكتب ل 100 دولار؟

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

بالتأكيد أنت تعرف كم تريد أن تكسب كل شهر. تخيل كم يكلفك شهر كامل من حياتك: شقة ، سيارة ، مدفوعات منتظمة ، درجة الراحة والترفيه المعتادة.

يعمل مطورو البرامج المدفوعة الأجر بدوام كامل على نفاد الوقت.

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

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

أصبح السوق عالميًا ؛ وأصبح الوصول عن بُعد إلى سوق العمل أسهل وأكثر سهولة. ستكون الشركة التي يوجد مقرها في موسكو غير مفيدة وغير مربحة لإعادة تدريب الأشخاص ، على سبيل المثال ، من iOS إلى Android أو من C ++ إلى Java. من الأسهل توظيف متخصصين جدد سيحضرون مهامهم كموظفين مستقلين ، ويستكملون المهمة ويغادرون.

أعتقد أن هذا النوع من المشاريع سيكون شائعًا: مشاريع مؤقتة ، حيث يجتمع المستقلون ، ينجزون مهامهم - خبير في هذا ، خبير آخر في ذلك ، ويغادر.

من المبرمجين يتوقع هذا الوقت الجديد:

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

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

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

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

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

ابحث عن البدائل ، انظر ، حاول ، بيع . في البداية لن يتم شرائك ، ستكون هناك مشاكل - الكثير من المشاكل! لكن لحل هذه المشكلات ، سوف تصبح مبرمجًا أكثر رواجًا على مستوى أعلى.

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

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

لا أعرف عنك ، لكن لا يمكنني الجلوس لمدة 8 ساعات لكتابة التعليمات البرمجية. أنا متأكد من أن كل واحد منكم سيؤكد أنه من بين 8 ساعات عمل في المكتب أو في الكمبيوتر ، تكتب رمزًا أقل كثيرًا بالفعل. وهم يدفعون ثمن هذه الساعات الثماني ، ويعتقد العميل أن هذا العمل 8 ساعات. هذا نظام خداع مزدوج: إنهم سعداء بالخداع ، ونحن نخدعهم. لذلك ، أنا استخدم عامل الضرب. سأعمل لمدة لا تقل عن 20 عامًا ، ولكن بعد ذلك سأفعل 3 أسابيع ما يمكنني فعله حقًا خلال ساعتين.

علم زبائنك وتعلم كيفية حساب الأموال بنفسك.

المبرمجين جيدة كتابة التعليمات البرمجية ، وأفضل - التذاكر

كل من العملاء والمبرمجين معتادون على التواصل غير الرسمي.

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

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

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

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

ثم تمر 2-3 أسابيع ، ولم نعد نتذكر ما اتفقنا عليه. يقول العميل إنه لا يريد ذلك ، فنحن نحاول إثبات أن هذا هو ما طلب ، نحن نبحث عن بعض الإشارات في الدردشة - يبدأ البحث عن البراغيث.

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

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

هذا خطأ يجب علينا ، كمبرمجين ، تحويل أي اتصال غير رسمي إلى تذاكر. تحدثنا مع العميل (العميل ، مالك المنتج ، مبرمج آخر) ، اكتشفنا ما الذي يجب تغييره - فنحن نقوم بتحويل أي اتصال إلى تذكرة محدودة بموجب إطار نظامنا (Jira ، GitHub ، وما إلى ذلك) ، حيث نكتب: ما لا يعمل ، وكيف تحتاج إلى إصلاحه ، ولماذا تحتاج إلى إصلاحه ، ما هو الدافع ، ومن ثم نعمل على هذه البطاقة.

عجز المبرمج عن تنظيم العمل في التذاكر قد يشير إلى انخفاض مؤهلاته. أعتقد أن هناك نوعان من التطوير:

• التطوير المستمر - البرمجة من الساعة 9 صباحًا حتى الساعة 5 مساءً: وصلت ، شغّلت الكمبيوتر ، ثم فعلت شيئًا ، هناك ، غداء ، مشفرة أيضًا ، في نهاية اليوم - حسنًا ، سأستمر غدًا. أي أننا نبرمج بينما هناك طاقة ووقت وقوة.
• يختلف التطوير التدريجي : فهناك المهمة رقم 13 ، وسأقوم بذلك حتى النهاية ، ثم أرى المهمة التالية. في هذا النموذج ، سيتم دائمًا إكمال المهمة (التذاكر). ولكن في حالة عدم وجود تذكرة ، لا توجد مهمة موثقة تمت صياغتها ، فلن يتحرك المشروع - لم تتم كتابة الرمز ، ولا يظهر طلب السحب.

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

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

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

يعتقد بعض الناس عن طريق الخطأ أن التطوير التدريجي يعني بالضرورة مهمة مدتها أسبوعان ، وأن البطاقة يجب أن تنتهي بطلب سحب يبلغ 5 آلاف سطر تم تغييره. هذا ليس تطورا تدريجيا. التزايدي مهمة لمدة 0.5 إلى 2 ساعة ، وفي نهاية طلب السحب من 50-100 سطر من التعليمات البرمجية. مستمر ، على العكس - أنت تعمل لفترة طويلة (أيام ، أسابيع) وتنتج القليل.

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

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

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

أي لغة البرمجة لتعلم أولا؟ اللغة الإنجليزية!

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

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

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

تعتقد أنه من الأسهل التواصل مع مواطن باللغة الروسية. Telegram-, , . — , . , , .

, . , .

, .

. , , .

. . , -, . , , , . — . . , , , .

. , , , . , .

— . Twitter, , Telegram- . , . .

, , , , . , , , , , — .

5-10 . 2 , , .

, . — . , , .

GitHub —

, open source , 10–15 open source, (NASA ).

, .

open source . , — . : , pull requests , , GitHub, .

open source- . open source-, , , .

, , . — open source, ? , , , — .

, — , . , , . open source- . open source community: , -, , pulll request, .

open source-, : , , — - . 2 300 followers GitHub — , 6 .

— , . -, , . , .

, . , . , , , , . — , 25 , , community .

, . , . , full-time, . , .

— , . , 20 Twitter 2 GitHub, . open source-, , . .

— .

2000 , 2019. 2029 . , , followers, , .

, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .

— . .