"كم عدد المشاهدين الذين سيحضرون حديث جافا الخاص بك؟" يعتمد ذلك على ما إذا كان فينكات يؤدي في القاعة المجاورة في نفس الوقت ".
هذه مزحة مع قدر لا بأس به من الحقيقة: في عالم جافا ،
Venkat Subramaniam هو واحد من أشهر المتحدثين ، وهو قادر حقًا على جذب المتفرجين من القاعات الأخرى في المؤتمرات. لقد كان يتحرك بلا هوادة حول الكوكب وحقق مؤخرًا رقمًا قياسيًا مثيرًا للإعجاب ، بحلول عيد ميلاده الخمسين الذي يتحدث في عام واحد قبل 50 مجموعة مختلفة من مستخدمي جافا.
كيف يبدو الأمر عندما تكون مهنتك في Java ليست "جالسة في المكتب" ، بل "تتحرك باستمرار"؟ وماذا تعتقد فينكات حول قضايا جافا الحالية؟ في تشرين الأول (أكتوبر) ، سيصل إلى سان بطرسبرغ ، وتحسبًا لذلك ، أجرينا
معه (
الفلبين ،
أوليغشير ) مقابلة معه بالتفصيل ، حيث بدأنا "بالحياة على متن الطائرة" ونصائح
للمبتدئين ، ثم انتقلنا إلى التكنولوجيا.
نظرًا لأن Venkat يجيب بالتفصيل ، فإن النص طويل. إذا كنت ترغب في ذلك ، يمكنك الانتقال فورًا إلى الجزء الثاني:
مدى الحياة
- دعنا نبدأ بجولتك ، التي قمت خلالها بزيارة 50 مجموعة مستخدمي Java ، بالكاد قام أي شخص بذلك من قبل. ماذا كانت انطباعاتك؟- كان الشيء الأكثر إثارة للاهتمام بالنسبة لي هو إدراك أنه في الثقافات المختلفة في أجزاء مختلفة من العالم ، فإن الأشخاص الذين يتحدثون لغات مختلفة ، على الرغم من كل هذه الاختلافات ، يجمعهم البرمجة كخيوط ربط واحد. عندما نبدأ الحديث عن البرمجة ، اتضح أن المشاكل التي نواجهها كل يوم هي نفسها. كان هذا اكتشافًا رائعًا بالنسبة لي - يمكنك مقابلة مبرمج في أي مطار في العالم ، وستجد بالتأكيد موضوعات مشتركة للمحادثة. يمكنني سرد الحالات التي شاركت فيها في الحديث عن Java على الجانب الآخر من الأرض إلى ما لا نهاية.
لذلك ، كانت تجربة هذه المجموعات مفيدة جدًا بالنسبة لي. إدارة مجموعة المستخدمين أمر صعب للغاية ... لا أريد أن أقول "عمل" لأنها ليست عملية ، ولكن عليك بذل الكثير من الجهد. لدي احترام كبير لجميع القادة الذين يجمعون هذه الأحداث مرارا وتكرارا كل شهر. المجموعات المختلفة لها ديناميكيات مختلفة - بعضها لديه 20 أو 30 شخصًا في الاجتماعات ، والبعض الآخر 200 أو 300. ومع ذلك ، فإن العدد ، في الواقع ، لا يلعب دورًا ، لأن الشيء الرئيسي هو شغف المطورين القادمين إلى هذه الاجتماعات ، واهتمامهم بـ التكنولوجيا ورغبتهم في التعلم. لذلك كنت محظوظًا جدًا لأنني أتيحت لي الفرصة للقاء هذه المجموعات ، وأنا ممتن جدًا لذلك.
- وبالتشابه الذي ذكرته ، هل لدى مجموعات المستخدمين في أجزاء مختلفة من العالم أي اختلافات محلية ملحوظة؟- هذه الاختلافات قليلة بشكل مدهش. لقد لاحظت أنه في بعض المناطق يتم إعطاء الأفضلية لإطارات الوزن الثقيل ، وفي مناطق أخرى لمزيد من الحلول الخفيفة. ولكن ، كقاعدة عامة ، كل هذه الميزات سطحية ، والأسئلة والمشكلات العميقة الجذور ، على العكس ، عالمية. أود بصدق أن أخبرك أنه في مرحلة ما على الخريطة ، يقوم الناس بأشياء مختلفة تمامًا عما نقوم به ، وكل شيء مثير للاهتمام وغير متوقع هناك ، ولكن لا يمكنني أن أقول ذلك.
كلنا نسعى جاهدين من أجل التعقيد ، يجرنا ، وعندما يجر ، نبدأ في محاربته. هذا اتجاه عام في كل مكان تقريبًا. مشكلة أخرى مهمة لم يفلت منها أحد هي المتطلبات الصارمة للأعمال التجارية وضيق الوقت للعمل على الجودة. يمكنني التحدث عن بعض الأمثلة للناس في أي مكان في العالم ، وبعد قصتي سيتم سؤالي: "هل حدث أن عملت في شركتنا؟" مشاكلنا عميقة وعالمية لدرجة أنها ، على ما يبدو ، مشتركة بين العالم كله. الأمر الذي يجعلنا لا إراديا نفكر في جوهرنا البشري المشترك ، في علم النفس والفلسفة ، الذي نتبعه في نهاية المطاف. بغض النظر عن مقدار ما نتخيل أنفسنا عندما يتحول المهووسون إلى التكنولوجيا ، يجب ألا ننسى الجانب البشري في تطوير البرمجيات. يبدو أنه قوة موحدة وعالمية.
- أود أن أسأل عن نمط حياة "تخييم". عندما تجلس في المكتب ، قد لا يكون من الواضح ما إذا كنت تريد حياة مثل حياتك. على سبيل المثال ، بالنسبة للكثيرين ، يمثل jetlag مشكلة ، ولهذا السبب ، قد تبدو الرحلات الجوية المستمرة بمثابة كابوس. ولكن ربما مع الممارسة ، هل تتكيف مع هذا؟- للإجابة على سؤالك ، دعونا نتذكر التكامل المستمر. إذا قام الفريق بإجراء الاندماج مرة واحدة في الشهر ، فإنك تقترح أن يفعلوا ذلك طوال الوقت ، وسوف يعتبرونك مجنونًا. في هذا ، تشبه علاقات السفر التكامل المستمر والتسليم المستمر: إذا كنت تتعامل معها كثيرًا ، فإن نهجك تجاهها يتغير.
لا تفهموني خطأ ، لست فخورًا بطريقي في الحياة ، في رأيي ، لا يستحق العيش بهذه الطريقة. أقول دائمًا أنه في الرحلات لا أحب السفر بأنفسهم. الجلوس على متن طائرة متعب ، والجسد يتآكل ، ومع تقدم العمر ، لا تذهب هذه المشاكل إلى أي مكان. ولكن عندما أصل إلى وجهتي ، عندما أقابل مطورين آخرين ، أرى شغفهم بالتكنولوجيا وحماسهم ، أحصل على فرصة لمشاركة هذا الشغف ، وتعلم شيء جديد والمساعدة في تعلمه ، كل الصعوبات تؤتي ثمارها باهتمام.
إذا تحدثنا عن تغيير المناطق الزمنية ، فهذا لا يزعجني على الإطلاق. بسبب الرحلات الجوية المستمرة ، إلى حد ما ليس لدي وقت ثابت "الوطن". لديّ قاعدة: أستيقظ دائمًا في نفس الوقت المحلي ، حوالي الساعة 3.30 ليلًا ، ويدخل الجسم بسرعة كبيرة إلى إيقاع معين. وبالطبع ، القهوة مرحب بها دائمًا.
- كثير من الناس يرغبون في رؤية العالم ، لكنهم عادة ما يذهبون في رحلات سياحية ، وليس في رحلات عمل. هل أنت قادر على إلقاء نظرة على المدن ، أو بسبب ضيق الوقت فقط في قاعات المؤتمرات؟- نعم ، جزئياً هناك مشكلة مع الوقت. ولكن بالإضافة إلى ذلك ، بسبب الرحلات الجوية المستمرة ، لدي بعض المبادئ التي ألتزم بها. إذا كانت الرحلة مرتبطة بالعمل ، فلن أفعل شيئًا سوى العمل. أحاول قضاء أكبر وقت ممكن مع المطورين. عندما يكون لدي السبت أو الأحد مجانًا ، على سبيل المثال ، في أوروبا ، أقضيه عادةً في مجموعة مستخدمين. إنه لمن دواعي سروري أن أتواصل مع المطورين ، لذلك في رحلات العمل الخاصة بي ، لا أذهب أبدًا إلى الأماكن المهمة.
ولكن كل عام لمدة أربعة أو ستة أسابيع في الصيف أسافر مع عائلتي ، ونذهب لمشاهدة معالم المدينة. هذا هو وقتنا لراحة مشتركة ، وفي الأشهر المتبقية أركز على العمل.
بالإضافة إلى ذلك ، فإن نهجي يسمح لي بإيلاء أقصى قدر من الاهتمام لمختلف الأحداث المجتمعية ، مما يمنحني أيضًا متعة كبيرة. هذا يستهلك الكثير من الوقت وهو نوع من الحل الوسط ، لكنه يناسبني. الحياة مرهقة في بعض الأحيان ، ويسرني أن أكون أحيانًا مشتتًا والاستماع إلى المطورين الذين قد لا تتاح لهم فرصة حضور مؤتمر أو دورة تدريبية. بالإضافة إلى ذلك ، أعتقد أن هذا هو واجبي المهني أيضًا ، لأن هذه الأشياء هي التي ألهمتني في شبابي. لقد زرت مجموعات المستخدمين ، واستمعت إلى العروض وحلمت في وقتي أيضًا بأداء نفسي. إذا تمكنت ، بدوره ، من إلهام شخص واحد على الأقل بنفس الطريقة ، فسيتم إنفاق هذه المرة بشكل جيد.
- سؤال السفر الأخير. في فيلم "Up in the Air" ، تعرف شخصية جورج كلوني ، التي تتنقل باستمرار بين المدن ، العديد من الحيل لتحسين كفاءة السفر: كيفية الوقوف في الطابور ، وكيفية حزم الأمتعة ، وما إلى ذلك. ربما لديك أيضًا بعض المعرفة غير الواضحة التي ترغب في مشاركتها؟"أشعر بالخجل من الاعتراف بذلك ، لكنني أحيانًا أرسل ملابس بين مدن فيديكس ، لأنني ببساطة لا أملك الوقت للسفر إلى المنزل وأخذ ملابس للأسبوع القادم. في كثير من الأحيان ، عندما أصل إلى الفندق ، تكون ملابسي موجودة بالفعل ، وعندما أغادر ، أرسلها إلى المنزل. لحسن الحظ ، لا يحدث هذا كثيرًا ، ربما ثلاث أو أربع مرات في السنة ، عندما أكون في طريقي لمدة ثلاثة أسابيع متتالية. كانت هناك لحظة واحدة محرجة عندما اضطرت زوجتي للذهاب إلى المطار لتسليمني الحقائب ، لأنني لم يكن لدي سوى نصف ساعة بين الرحلات الجوية. ولكن بمرور الوقت ، تتعلم حقًا القيام ببعض الأشياء بشكل أكثر كفاءة. يفاجئني أحيانًا عندما يقول الناس "أحتاج إلى حزم" لأن أغراضي يتم جمعها طوال الوقت.
بالحديث عن الكفاءة ، لدي ميزة واحدة على الأقل: أنا شخص مهم للغاية. نحن نعيش في عالم Facebook و Twitter ومختلف الرسل ، فهم يلهوننا باستمرار. لقد عملت بجد لتقليل هذا التأثير ، لأن الدقائق تتحول إلى ساعات ، وتتحول الساعات إلى أيام ، وتتحول الأيام إلى أسابيع ، وتدرك عاجلاً أم آجلاً أنه لا يمكنك تحقيق ما تريده. عادة ما يكون لدي مجلة أكتب فيها الأشياء التي يجب القيام بها لكل رحلة. وبالتالي ، لدي جدول زمني لكل يوم (على سبيل المثال ، في 7 نوفمبر أو 8 أكتوبر) ، ويذكرني هاتفي بكل مهمة في اليوم المقابل. على مدار رحلة تستغرق ثماني ساعات ، يمكنني كتابة معظم فصل واحد من الكتاب ، أو إعداد مثال للدورة. لذلك ، فإن الرحلات بالنسبة لي هي وقت فعال للغاية. لا أحتاج أبدًا إلى وسائل ترفيه إضافية أثناء الرحلة - فالكثير من وسائل الترفيه المتعلقة بتصحيح التعليمات البرمجية كافية تمامًا. لذا فإن المسافر المحترف (إذا كان هذا المصطلح ينطبق بشكل عام) يقضي الوقت في الرحلة بشكل مختلف تمامًا عن السائح.
- ربما ، بسبب شهرتك ، تحصل على رسائل أكثر بكثير من المطورين العاديين. كم يكتبون لك وكم يستغرق العمل مع البريد؟- من الجدير بالذكر أنني أقوم بالتدريس في الجامعة وأتلقى العديد من الرسائل من الطلاب. عادة أحصل على 20 أو 30 حرفًا في اليوم. قبل حوالي عام
كتبت على مدونة حول أحد مبادئي: "أجب الآن أو قل عندما تجيب."
أنا أقدر وقتي حقًا ، مما يعني أنني أقدر وقت الآخرين. في رأيي ، احترام شخص آخر ليس في نداء سيدي ، ولكن في تقدير وقت بعضهم البعض. لذلك ، إذا وصلت إلي رسالة ، فأنا دائمًا أرد في غضون 24 ساعة. ولكن هناك أوقات لا يعمل فيها لإعطاء إجابة كاملة - على سبيل المثال ، إذا طلب منظم المؤتمر إرسال تعليق توضيحي أو إذا طرح زميل في الصناعة سؤالًا حول حل مشكلة معينة ، أو طلب إعادة صياغة بعض التعليمات البرمجية ، أو سأل عن استخدام طريقة معينة. في بعض الأحيان قد يستغرق الجواب عشر دقائق ، وأحيانًا ساعتين ، ولكن حتى عشر دقائق لا يمكن إنفاقها دائمًا. قد يبدو الأمر غريباً بعض الشيء ، لكنني ما زلت أرد في مثل هذه الحالات في غضون 24 ساعة وأكتب: لقد تلقيت رسالتك ، سأعمل على هذه المشكلة ، على سبيل المثال ، 2 سبتمبر وأكتب لك الثالث. في نفس الوقت ، يتم تحديث تقويمي بالإدخال المقابل في اليوم الذي أمضي فيه وقتًا في الرحلة أو بعد الظهر.
بفضل هذا النهج ، يكون البريد الوارد فارغًا دائمًا ، وأقوم بتنظيفه كل ليلة قبل موعد النوم. لذلك أنا منضبط للغاية في الرد على الرسائل. غالبًا ما يتفاجأ الناس بأنني أرد على رسائلهم بسرعة كبيرة ، لكن على العكس ، لا أفهم كيف العكس. لا أريد الوقوف في طريق الناس ، لمنعهم من التطور. بالإضافة إلى ذلك ، أرى أنه من المهم أن تقول لا. أحب أن أكرر أنه كلما قلت نعم ، كلما حصلت على أسوأ ما تفعله. في لحظة معينة ، عليك أن تدرك أنه لا يمكننا تحقيق كل شيء في العالم. لذلك ، أحيانًا أجيب أنه للأسف لا يمكنني المساعدة. في المقابل ، أفضل أن يُقال لي لا على الفور ، ولا أنسحب المطاط وأقول لا لاحقًا. في رأيي ، هذا يتحدث أيضًا عن احترام الشخص وعدم الرغبة في إضاعة وقته دون جدوى. ليس عليك المساعدة ، ولكن على الأقل لا تهتم. لذلك ، من المهم أن تقول لا. هكذا يتم ترتيب الحياة ، لا تحاول التظاهر بأنه يمكنك القيام بكل شيء في العالم. بالنسبة لي ، فإن القدرة على الاستجابة بسرعة وصدق هي علامة على الاحتراف.
- أنت متحدث ذو خبرة كبيرة. كمنظمين للمؤتمرات ، نلتقي بأشخاص ليس لديهم خبرة في التحدث أمام الجمهور أو لديهم القليل جدًا. ربما لديك توصيات لهم؟ لديك نصيحة مهمة على تويتر "لزيارة القاعة التي سيعقد فيها التقرير مقدمًا" - هل هناك المزيد؟- كانت تقاريري الأولى في مجموعات المستخدمين ، ولهذا السبب أستمر في عمل 15 تقريرًا فيها كل عام. وأوصي بأن يبدأ الآخرون بالشيء نفسه: مع مجموعة مستخدمين في منطقتك ، ثم في مجموعة مجاورة ، وما إلى ذلك.
ولأسباب عديدة ، فإن هذه التقارير لها مخاطر أقل مما كانت عليه في مؤتمر كبير: هناك جو ودي ، يأتي الناس هناك لتبادل المعرفة ، وبعد تقاريرك سيكون من السهل عليك الحصول على رد. يمكنك أن تبدأ العرض التقديمي جيدًا بالقول إن لديك خبرة قليلة في هذا الأمر وترغب في معرفة رأي الجمهور. هذا العام كان لدي تقرير جديد ، واجهت خلاله الكثير. لقد كتبت عن هذا على تويتر: يبدو أن كل شيء يمكن أن يقال في دقيقتين ، ولكن في الواقع لا يمكن وضع المواد في ساعة ونصف. ويسعدني جدًا أنه في المرة الأولى التي قمت فيها بإعداد هذا التقرير في مجموعة مستخدمين ، حيث أعطاني هذا الفرصة لإعداده بشكل أفضل للمؤتمر.
في مجموعات المستخدمين أو في الشركة التي تعمل فيها ، لديك فرصة رائعة لممارسة العروض التقديمية. أولاً ، ستتلقى انتقادات من الزملاء ، مما سيسمح لك بتحسين التقرير. ثانيًا ، حتى إذا لم يقولوا لك أي شيء مباشرةً ، ستظل تفهم الكثير بنفسك عندما تبدأ في التحدث. أعتقد أنه من الممكن بالفعل تحسين التقرير من المرة الثالثة. في المرة الأولى التي تحاول فيها فقط جمع كل الأفكار معًا. وإليك ما هو مثير للاهتمام: ممارسة وحدها لن تساعد هنا ، والوعي بالمشاكل لا يأتي إلا عند التحدث إلى أشخاص آخرين. في المرة الثالثة ، تصبح السلسلة المنطقية لسردك أكثر وضوحًا بالنسبة لك ، فقد اكتملت. هذا لا يمكن ملاحظته دائمًا ، لكنني أتوقف أحيانًا أثناء خطابي للمرة الثالثة - في هذه اللحظة أدرك ما كنت أنا من أحاول أن أقول في التقرير أن هناك لحظة من الحقيقة تأتي. لذا ، الممارسة مهمة جدًا ، ولكنها ليست وحدها ، ولكن مع الناس. هذا يمكن أن يمنح المطور الشاب الثقة اللازمة.
صحيح أن البعض يقدمون تقاريرهم الأولى في المؤتمرات. في بعض الأحيان يكون موت الشخص أسهل من التحدث في الأماكن العامة ، ويسهل فهمه - يتطلب الكثير من الأعصاب. قبل سنتين أو ثلاث سنوات ، تحدثت في مؤتمر. جاء إليّ شخص مهتم جدًا وقال لي ، على ما يبدو ، إنني قلق للغاية ، وأجبته بأن هذا كان حقًا. سألني: "هل هذا هو تقريرك الأول؟" ، فأجبته: "لا ، ربما عشرة آلاف ، لهذا أنا قلق." يتطلب كل أداء أمام الجمهور الكثير من الضغط العاطفي ، حتى إذا كان لديك الكثير من الخبرة ، ببساطة لأنك تهتم بكيفية سير التقرير. ستقوم بعمل رائع إذا قمت بتخفيف هذا التوتر من خلال بعض تقارير الاختبار في مجموعات المستخدمين أو في شركتك. هذا ينطبق على جميع المتحدثين ، بما في ذلك من ذوي الخبرة.
- ولكن هل هناك شيء في الخطابة يجب تجنبه؟"لقد ارتكبت العديد من الأخطاء في حياتي التي علمتني أن الناس يتعلمون أفضل من التجربة." عندما تتحدث إلى جمهور ، هناك بعض الأشياء التي يجب وضعها في الاعتبار. أولاً ، تحتاج إلى الحفاظ على الثقة بالنفس: لقد عملت كثيرًا على الموضوع ، وأنت تعرف الكثير عنه. ثانيًا ، تذكر: من المستحيل معرفة كل شيء ، والجهل بشيء ليس خطأك. هذا يعني فقط أنه لم تتح لك الفرصة للانتباه إلى ذلك ، ولا يوجد شيء خاطئ في ذلك. من المهم للغاية أن تعترف بذلك بصدق. يمكنك الإجابة عن السؤال تمامًا في المؤتمر على النحو التالي: عذرًا ، لا يمكنني أن أخبرك بأي شيء ، لم تتح لي الفرصة لدراسة هذه المشكلة.
نقطة أخرى مهمة هي أنه يمكن تقسيم المستمعين إلى ثلاثة أنواع. هناك أشخاص يريدون تعلم شيء جديد منك. يحافظ الآخرون على أنفسهم أكثر حرصًا ، وسوف يستمعون إليك ، لكنهم لن يكونوا مستعدين لإدراك كل ما تقوله. أخيرًا ، هناك مجموعة ثالثة من الناس ، لحسن الحظ ، صغيرة نوعًا ما: أولئك الذين هم معادون ويحاولون القبض عليك طوال الوقت. عاجلاً أم آجلاً ، سيحتوي تقريرك بالتأكيد على مطور واحد سيقاطعك طوال الوقت ويعطل تقدم التقرير. في مثل هذه الحالات ، من المهم جدًا الحفاظ على الهدوء ، والسماح له بالتحدث وإعادة المناقشة إلى الاتجاه الذي تحتاجه - ولكن ، يجب أن أعترف ، أنا أيضًا شخص ، وأنا لا أنجح دائمًا في القيام بذلك. يمكنك ، على سبيل المثال ، أن تقول: أفهم أن هذا مهم بالنسبة لك ، فلنناقشه بعد التقرير ، هذا الموضوع مهم للكثيرين هنا. صحيح ، في كثير من الأحيان يكون لديك حلفاء في الجمهور ، وعندما ينتهك الشخص حقًا مسار خطابه ، يُطلب منه أن يهدأ. كل هذا أقول لحقيقة أنه من المهم عدم التعارض الشديد في مثل هذه المواقف ، على الرغم من أن طبيعتنا يمكن أن تقاوم ذلك. بصفتي متحدثًا شابًا ، غالبًا ما دخلت في مثل هذه المواجهات بكامل قوتها ، وهذا لم يجلب أي شخص أي خير. من الضروري إظهار النضج العاطفي وعدم محاولة إثبات أي شيء لأي شخص عن نفسك ، والدخول في هذا النوع من المناوشات. بدلاً من ذلك ، في مثل هذه الحالات ، يجب إعادة الموضوع إلى ما يثير اهتمام الجمهور.
أود أيضًا أن أتحدث عن بعض العادات السلبية خلال العروض ، والتي ، حسب رأي المطورين. بالنسبة للمبتدئين ، يجب أن ينظر الناس إلى أعينهم. أفهم أن هذا صعب للغاية ويتطلب الكثير من الجهد العاطفي ، ولكن عليك ممارسة هذا. غالبًا ما ينظر المتحدثون إلى شاشتهم ، أو حتى أسوأ من ذلك ، على الشاشة وهم يقفون مع ظهورهم للجمهور. يجب أن تواجه الجمهور دائمًا ويجب أن تنظر إليهم دائمًا. بالإضافة إلى ذلك ، يجب الحفاظ على الثقة بالنفس. أنت تتحدث إلى جمهور من المبرمجين ، ويمكنك الرهان على أنه ليس لدى أي منهم رمزًا يعمل في المرة الأولى. إذا لم يعمل العرض التوضيحي الخاص بك أثناء العرض التقديمي ، فلا حرج في ذلك. سيعتقد جميع الحاضرين على الأرجح: "اللعنة ، كل شيء هو نفسه تمامًا معي." على مر السنين ، تعلمت في مثل هذه المواقف اللجوء إلى الجمهور للمساعدة في تصحيح الأخطاء. عادة ، يبدأ المتحدثون في مثل هذه الحالة في تمتم شيء ما في أنفاسهم ومحاولة حل جميع الصعوبات بأنفسهم. بدلاً من ذلك ، يجب أن تسأل الجمهور - أصدقاء ، هل يمكنك أن تخبرني أين أنا غبي؟
ستتلقى العديد من العروض فورًا ، وغالبًا ما ستساعدك في العثور على الخطأ. من الصعب على شخص واحد التحدث وكتابة التعليمات البرمجية في نفس الوقت ، لا تخف من طلب المساعدة. بالنسبة للمستمعين ، تعتبر هذه التجربة ذات قيمة أيضًا هذا أحد أسباب زيارتي لتقارير الآخرين: لمعرفة ما يفعلونه وفهم ما لا يجب فعله بالضبط. في رأيي ، ستساعدك هذه العادات على إعادة صياغة مهاراتك في التحدث.
عن التكنولوجيا
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?"نعم بالتأكيد." علاوة على ذلك ، هذا هو أحد الأشياء التي تروق لي في Java - هذه ليست اللغة التي كانت عليها في عام 2000. على مدى السنوات القليلة الماضية ، بدأ مبدعو اللغة يدركون أنه عندما تصبح اللغة مطولة ومليئة بالحياة ، فإنها تعقد بشكل كبير عمل المبرمجين ، وليس فقط المبتدئين.لنفترض أنك تتحدث مع زميلك ، فإن بعض الأفكار الجديدة تزورك ، ولكن هذا ليس واضحًا على الفور لمحاورك ، ويطلب منك أن توضح ما تعنيه بالضبط. تفتح المحرر ، وتدرك في الثواني الأولى أنه لتنفيذ هذه الفكرة ، تحتاج إلى كتابة 70 كتلة تجريبية. وعلى الرغم من أن الفكرة جيدة ، فإنك تقرر تركها لوقت لاحق ، لأنه في الوقت الحالي قد لا يكون هناك وقت.بالنسبة لي ، البرمجة هي سلسلة من التجارب الصغيرة. بصفتي مستشارًا ، أعمل مع فرق من المبرمجين ، لكل منهم طريقته الخاصة في كتابة التعليمات البرمجية ، وغالبًا ما أوصيهم بالأفكار التي رأيتها مع أشخاص آخرين. عندما يحدث هذا ، فإنهم لا يريدون سماع فكرة جديدة في الكلمات فحسب ، بل يريدون رؤيتها في الكود. في مثل هذه الحالات ، من المهم أن يتمكنوا من إثبات ذلك بسرعة. في هذا الجانب ، أحب اللغات الأقل خيالًا التي تتيح لك تنفيذ فكرتك باستخدام بضعة أسطر من التعليمات البرمجية.هذا هو السبب في تطور Java 12 و 13 و 14 في هذا الاتجاه: يدرك المطورون أنه على الرغم من أن Java لغة قوية للغاية ، فإنه ليس من السهل جدًا تجربتها ، ومن الصعب تعلمها. عندما تعرف بالضبط ما تريد كتابته ، تعمل Java بشكل مثالي ، ولكن عادةً ما تبدو البرمجة مختلفة. تتعلم وتجرب دائمًا ، لديك دائمًا أفكار بدت مستحيلة سابقًا. إذا كنت أعمل في شركة لديها قاعدة تعليمات برمجية متطورة وبنية تعليمات برمجية معينة ، وإذا أضفت ميزات جديدة إلى التطبيق استنادًا إلى القوالب الموجودة ، فلن تؤثر علي هذه التغييرات بشكل كبير ، وهنا تعمل Java بشكل جيد في نموذج موجود. ولكن إذا كنت مهندسًا معماريًا أو قائد فريق أو مجرد مبرمج يكتب الشفرة بشكل مبتكر ويختبر ، فإن Java في شكلها الحالي ستقيدك إلى حد كبير. لذلك ،في رأيي ، من المهم أن تتطور اللغات في اتجاه أبهى ، وأنا مؤيد كبير للاتجاه الذي تتغير فيه Java الآن.
. Joker «Don't walk away from complexity, run» . , Joker , , .
- في سياق "جافا أقل شراسة" ، من المستحيل عدم سؤالك عن Kotlin ، والذي غالبًا ما يطلق عليه ذلك."نعم ، هذا صحيح." والأمر ليس فقط في ادعاء أقل. بالنسبة لي ، أحد أكثر الأشياء إثارة في الحياة هو التعرف على لغات جديدة وقدراتها. أحد الاحتمالات في Kotlin هو تشغيل لامدا في سياق كائن ، على الرغم من أنه ليس جزءًا من الفصل. أصبحت مهتمًا جدًا عندما اكتشفت ، لأن الاحتمال نفسه موجود في JavaScript. هناك يمكنك تمرير كائن سياق في المكالمة (ما يسميه Kotlin جهاز الاستقبال) ، ثم تنفيذ هذه الوظيفة العامة التعسفية كما لو كانت وظيفة لكائن ما. حقيقة أن هذه الميزة في جافا سكريبت ليست مفاجئة ، لأن هذه اللغة ديناميكية. لكن Kotlin هي لغة ثابتة ، وهي تفعل الشيء نفسه ، مع احترام سلامة النوع. بالطبع ، يعد الافتقار إلى التظاهر ميزة كبيرة للغة ، مثل حقيقة أنه يولد جزءًا كبيرًا من الشفرة تلقائيًا ، بحيث لا يمكننا كتابة نفس القوالب مرارًا وتكرارًا. لكن الفوائد لا تنتهي عند هذا الحد ، لأن هذه الميزة تسمح لك بإنشاء DSLs داخلية.
قادني العلم والرياضيات إلى البرمجة ، ولكن بعد 30 عامًا ما زلت مبرمجًا لأن هذا هو الفن. يجمع مجالنا بين العلم والفن ، ولا يوجد الالتفاف حوله. إن القدرة على جعل النظام يعمل ببساطة ليست محدودة ، هنا يمكنك رسم تشابه مع كتابة الشعر: اطلب من شخصين الكتابة عن الحب ، وسيكتب كل منهما بطريقته الخاصة. يمكن كتابة الرمز لأي مهمة بطرق مختلفة. هذا ما يجذبني إلى لغات مثل Kotlin والعديد من اللغات الأخرى: القدرة على التعبير عن بعض هذه الأفكار ، وإعطاء الكود مرونة وخفة. يمكنك التفكير بشكل أقل بكثير في بناء الجملة اللغوية والمزيد في التفكير الذي تريد نقله.
- جودة الكود ذات أهمية كبيرة بالنسبة لك. يبدو أنه مهم للجميع ، ويبدو أن الجميع يرغبون في الكتابة بشكل أفضل ، ولكن من المعروف أن جزءًا كبيرًا من الشفرة الحالية يعاني من مشاكل. لذلك ، فإن السؤال هو: حتى لا يكرهك زملاؤك في التعليمات البرمجية الخاصة بك ، تحتاج فقط إلى الانضباط الذاتي ، هل يمكنك تقديم أي توصيات محددة؟"أنا مقتنع بأن الطريقة الوحيدة لكتابة التعليمات البرمجية القابلة للقراءة هي قراءتها." عندما يقولون لي أن الرمز قابل للقراءة ، أسأل - من قرأه؟ إذا قرأه المؤلف نفسه مباشرة بعد الكتابة ، فهذا لا يحسب. لذلك ، أنا مؤمن قوي بمراجعة التعليمات البرمجية. أريد أن أوضح: أنا أعارض إدخال فريق إلى غرفة ذات شاشة كبيرة ، تظهر الشفرة عليها وتنتقدها. هذا يؤدي حتما إلى المظالم ، مثل okhayanie العامة لا أحد جيد.
يجب أن نعترف بصدق: كلنا نكتب رمزًا سيئًا. أنا فخور بأن أعترف: كود بلادي سيء ، لا أعرف كيف أكتب كود جيد. إذا سألت كيف يتناسب هذا مع حديثي حول جودة التعليمات البرمجية ، فسأجيب: كتابة التعليمات البرمجية هي عملية ذات ابتكار مستمر ، وعندما تحاول تنفيذ فكرة ما ، فإن جودة التعليمات البرمجية لا تزعجك كثيرًا. من الضروري دائمًا العودة وإعادة البناء ، وحتى عندما أفعل ذلك ، فعادة لا يوجد شيء يناسبني. ولكن على مر السنين ، أدركت ذلك ، على الرغم من أن التعليمات البرمجية الخاصة بي هي الأساس ، ولكن يمكنني العثور على عيوب في رمز شخص آخر. لذلك ، بدلاً من التظاهر بأن شفرتي ممتازة بالفعل ، سأكتبها بأقصى ما أستطيع وأعطيها لك للتحقق منها ، بينما في هذه الأثناء سآخذ رمز زميلي وأتفقده. ونتيجة لذلك ، ستكون كل من الكود الخاص بي وكود زميلي أعلى جودة.
من المهم جدا التخلي عن الكبرياء الكاذب. أذكر دائمًا المطورين أنهم جزء من فريق ، فلا معنى للتنافس مع بعضهم البعض ومعرفة من هو الأكثر برودة ، لا. أنا على استعداد للاعتراف بصدق بأن معرفتي محدودة للغاية - ولكن ما أعرفه ، أعرفه جيدًا. وزميلي لديه أيضًا معرفة عميقة جدًا في بعض المجالات الأخرى. معاً نصبح أقوى عندما نكون مستعدين للتعلم من بعضنا البعض. لذلك ، أقترح دائمًا التحقق من رمز بعضنا البعض ، والفخر الإضافي عديم الفائدة تمامًا هنا. يجب أن تكون صادقًا مع بعضها البعض ، فهذه إحدى أهم صفات الفريق الجيد. لا يجب معاقبة الصدق إذا اعترف الشخص بأنه كتب رمزًا سيئًا - فهذا أمر طبيعي. نرفع من مستوى من خلال تقديم طرق أخرى لتحسين التعليمات البرمجية.
نقطة مهمة أخرى: لا تحتاج إلى إخبار أي شخص أنه ارتكب خطأ ، يجب أن يقال ما يمكن تحسينه بالضبط. لا تقل: "يا إلهي ، يا له من اسم رهيب للمتغير" ، من الأفضل بهذه الطريقة: "ربما تريد أن تقول أن هذا المتغير يظهر تواتر التوزيع - ربما يجب تسميته وفقًا لذلك." هذا سيساعدك على نقل نواياك بشكل أفضل. وينطبق هذا أيضًا على تحرير الكتب: لا تتحدث فقط عما يجب تحسينه ، ولكن أيضًا عما تم عمله بشكل جيد. غالبا ما ننسى هذا. عندما أقوم بتحرير كود شخص آخر ورؤية مكانًا يتم تنفيذه بشكل جيد ، أكتب في تعليق أحبه حقًا ، وأننا بحاجة إلى القيام بذلك كثيرًا ، وشرح السبب. يؤدي هذا إلى إنشاء تعليقات بناءة ، ويوضح للمطور أنك لست معاديًا له ، وفي النهاية يحسن جودة رمز فريقك.
- لقد كتبت أن استخدام أداة تدفعك إلى الشوق يشبه التعثر في علاقة سامة: في هذه الحالة ، تحتاج فقط إلى المغادرة ، وفي أقرب وقت ممكن. يبدو هذا رائعًا ، ولكن في الغالب ليس للأداة أي بديل معين ، ثم ماذا بعد ذلك؟- سؤال مبرر بالكامل. في الواقع ، هناك حالات حيث لا يوجد مكان للذهاب إليه. لكنني تحدثت بالأحرى عن تلك الحالات عندما لا يزال هناك إمكانية للاختيار ، وفقط الرغبة في جعلها مفقودة. في رأيي ، هذا عامل مهم.
عندما لا يكون هناك خيار ، بدلاً من الشكوى ، يجب تحديد نقاط الألم: ما الذي يجعل هذه الأداة غير مريحة لك. ثم يمكنك القيام بذلك بطرق مختلفة. يمكنك الاتصال بالمطورين والقول - شكرا لعملك ، يبدو لنا أن أداتك يمكن أن تكون أفضل بكثير إذا انتبهت إلى هذا الجانب. أو يمكنك إقامة هاكاثون - اجتمع في عطلة نهاية الأسبوع مع العديد من المطورين ، وقم بتنظيم مجموعة مستخدمين ، وأخبرهم أنك تقضي تسع ساعات يوميًا مع هذه الأداة ، وهذا أمر فظيع ، واطلب منهم محاولة إضافة بعض الميزات إليه.
ربما لا يمكنك حل جميع المشاكل بمفردك ، ولكن على الأقل يمكنك جمع أشخاص آخرين معًا وحل هذه المشكلة معهم ، خاصة إذا كانت اهتماماتهم مماثلة لمصالحك. أخيرًا ، إذا كانت أداتك تتسبب لك في الكثير من المشاكل ، يمكنك محاولة كتابة واحدة جديدة بنفسك - إذا كان لديك ثلاثة أو أربعة أصدقاء في المجتمع بنفس الموقف الذي أنت عليه.
لذا ، في رأيي ، لا تزال هناك بدائل. لست مضطرًا لتحمل علاقة سامة. تحتاج دائمًا إلى أن تكون قادرًا على إيجاد مخرج - إما الاتفاق مع شريك وتحقيق التفاهم المتبادل ، أو المغادرة.
- لقد كتبت كتابًا عن لامداس ، وأنت معروف بفضل هذا الكتاب. قرأته أيضًا ، وأعتقد أنه مكتوب بشكل جميل ، ويعطي ما يحتاجه مطور التطبيق ، ولا يعطي أي شيء غير ضروري. بصفتي محترفًا حقيقيًا ، أود أن أسألك: ما هي البرمجة الوظيفية بالنسبة لك؟ هل يمكنك وصفها بكلماتك الخاصة؟ أطرح هذا السؤال لأن الجميع يعرفه قليلاً بطريقته الخاصة ، وفي كل مرة يتم الكشف عن معاني خفية تختلف عن التعريف القياسي من ويكيبيديا.- هذا سؤال رائع. لقد تطور فهمي لهذا المفهوم على مر السنين ، والآن بالنسبة لي أهم شيء في البرمجة الوظيفية هو إزالة التعقيد الدخيل. نحن نتحدث عن حقيقة أنه في البرمجة الحتمية ، لا تشير فقط إلى ما يجب القيام به ، بل تصف أيضًا بالتفصيل كيفية القيام بذلك. بالنسبة لي ، تعد البرمجة الوظيفية إضافة إلى أسلوب البرمجة التعريفية ، حيث نشير إلى ما يجب القيام به ، ولكن لا نقول كيف.
دعني أقدم لك تشبيهًا بدائيًا: أفضل أصدقائي يحبون السيارات ، لكنهم لا يهتمونني على الإطلاق. عندما نلتقي ، نتفق على عدم مناقشة السيارات ، لأننا نريد أن نبقى أصدقاء. لن أقود أبدًا سيارة مزودة بعلبة تروس يدوية - الحاجة إلى تغيير التروس باستمرار تفسد رحلتي بالكامل ، وينطبق الشيء نفسه على النمط المحتم للبرمجة. يجعل ناقل الحركة الأوتوماتيكي القيادة أسهل قليلاً ، لكن بالنسبة لي الخيار الأفضل هو أن يقودني السائق. في هذه الحالة ، أقول فقط من أين أحتاج إلى الحصول ، وعلى طول الطريق أكتب الرمز على جهاز الكمبيوتر المحمول الخاص بي في المقعد الخلفي. بالنسبة لي ، هذا هو الفرق بين البرمجة الحتمية والوظيفية. من خلال البرمجة الحتمية ، أنت بنفسك تقود ، تحتاج إلى معرفة إلى أين تذهب ، وكيف تذهب ، إلى أين تتجه ، إلى أين يمكنك قطعها. مع البرمجة الوظيفية ، أنت تجلس في المقعد الخلفي ، تخبر السائق أين يأخذك ، وينصب تركيزك بشكل كامل على عملك.
كيف تتم إزالة هذا التعقيد الغريب؟ من خلال تكوين الوظائف. عند إنشاء الوظائف ، يخضع الكود الخاص بك لسلسلة من التحولات التي تمر خلالها البيانات من نموذج إلى آخر. علاوة على ذلك ، من المهم بالنسبة لنا ليس كيف يتم تنفيذ كل خطوة من هذه الخطوات ، ولكن ما تحققه بالضبط. بالنسبة لي ، فإن الجانب الأول من البرمجة الوظيفية هو التكوين الوظيفي. تكمن المشكلة في أن العديد من اللغات التي يتم فيها تنفيذ التركيب الوظيفي - Ruby و Python و JavaScript و Groovy وما إلى ذلك - توفر الأناقة والتعبير عن ذلك ، ولكن أداءها منخفض جدًا. يتم تنفيذ التركيب الوظيفي فيها بشكل غير فعال. أعتقد أن الأناقة بدون كفاءة ليست قابلة للحياة. لا يجب أن يكون الرمز جميلًا فحسب ، بل يجب أن يعمل أيضًا بسرعة. وهنا نأتي إلى الجانب الحيوي الثاني للبرمجة الوظيفية - نحن نتحدث عن الحوسبة البطيئة. يتم حساب نتيجة وظيفة معينة فقط في الوقت الذي تكون فيه هناك حاجة إليه. بفضل هذا ، يتم تحقيق مزيج من الأناقة والكفاءة في البرمجة الوظيفية. لذا ، بالنسبة لي ، البرمجة الوظيفية هي التركيز على ما يجب القيام به ، وليس كيفية القيام بذلك ؛ استخدام التكوين الوظيفي كسلسلة من تحويلات البيانات ؛ والقدرة على أداء هذه التحولات بكفاءة بفضل الحوسبة البطيئة.
يرجى ملاحظة أنني لم أتحدث عن وظائف الحصانة والنظام العالي. والحقيقة هي أنها مجرد مكونات للحصول على النتيجة التي وصفتها. نحن نستخدم البرمجة الوظيفية ليس للحصانة والوظائف عالية الترتيب ، فهي ليست سوى وسيلة لتحقيق هدف أعلى: التخلص من التعقيد الدخيل.
- تعريف رائع. توجد اليوم لغة تمثل المعيار الذي يجب أن تكون عليه البرمجة الوظيفية: Haskell (وربما F #).- هذا صحيح.
"على الأقل يعتقد كثير من الناس ذلك." لكن من الواضح أن Java ليست Haskell ، فهي محدودة إلى حد كبير. هل البرمجة الوظيفية منطقية كنظام عند تطبيقها على جافا؟ بعد كل شيء ، لغتنا لديها مجموعة محدودة للغاية من الأدوات لهذا النهج.- بالنسبة لي ، الجانب العملي وليس السعي وراء التميز هو الأهم. أنا فضولي بشأن الكمال ، ولكن لكي يعمل كل شيء ، يجب أن أكون براغماتيًا. أنا مجنونة في هاسكل وأقضي الكثير من الوقت معه ، فقط لأكتشف كيف يتم حل مهمة معينة في البرمجة الوظيفية. لكن لموكلي لا أكتب على هاسكل. هنا يمكنك رسم تشابه مع "الكاتدرائية والبازار". الكاتدرائية جميلة ، لكن معظم الوقت الذي أقضيه في البازار. السؤال هو كيفية البقاء في هذا العالم. عندما تتطور اللغات وعندما نحاول الجمع بين العديد من النماذج المختلفة معًا ، نحتاج ، كمبرمجين ، إلى توخي الحذر الشديد في تنفيذها.
لا أعتقد أن البرمجة الوظيفية مستحيلة على الإطلاق في Java. في الحالات التي يوجد فيها خيار ، سأركز على اللغة الأنسب بالنسبة لي. ولكن لن أقول للعميل: يجب عليك استخدام هذه اللغة. غالبًا ما أسأل عما يفعلونه بالضبط ، وأحاول أن أجد طريقة للقيام بذلك بالطريقة المثلى ضمن إطار البيئة التي لديهم بالفعل. أعتقد أنه في لغات مثل Java ، فإن الجمع بين البرمجة الحتمية والوظيفية أمر ممكن تمامًا وحتى موصى به ، ولكن يجب القيام بذلك بحذر شديد. تخيل أن لديك نوعًا من دائرة الوظائف النقية ، والتي سيكون حولها حلقة من النجاسة. يجب أن يكون كل شيء تريد تغييره خارج الدائرة. داخل هذه الدائرة ، يمكنك تنفيذ سلسلة الوظائف الخاصة بك ، ولكن يجب أن تكون جميع التغييرات خارجها.
هذا أحد الأسباب التي تجعلني أستمتع بتعلم لغات جديدة. تعرفت مؤخرًا على لغة Elm ، وهي عبارة عن بنية Haskell مع F # intersperses التي يتم تجميعها في JavaScript. لقد أهتمني هذا النهج منذ البداية ، لأن جافا سكريبت عبارة عن بازار. عندما تسافر عبر JavaScript ، فأنت تخطو دائمًا في البرك. بفضل بنية Haskell ، فإن Elm هي بالتأكيد كاتدرائية. ومع ذلك ، يمكن تشغيل هذا الرمز المألوف في السوق. بنية Elm أنيقة ، ولها نموذج (أي بيانات) ، وهناك طريقة عرض تعرض هذه البيانات ، وهناك تحول وتحديث. المبدأ الرئيسي الأول هو تخزين البيانات في العرض. عندما يقوم المستخدم بتنفيذ إجراء (يضغط على مفتاح ، على سبيل المثال) ، يتم إرسال البيانات من العرض إلى وظيفة التحديث ، حيث يتم التحويل. البيانات غير قابلة للتغيير ، وتقوم وظيفة التحديث بإرجاع البيانات الجديدة التي يحفظها العرض بدلاً من القديم.
إذا فكرت في الأمر ، فعندئذ تمامًا بنفس الطريقة التي يعمل بها Redux. هناك بيانات فيه ومخفضات موجودة. عندما يتم إرسال البيانات إلى المخفضات ، تحصل على نسخة جديدة في المقابل ، والتي تحفظها بدلاً من القديمة. ولكن إذا كان Elm و Redux يعملان على نفس المخطط ، فيمكن تنفيذ نفس المخطط في Java. يمكننا إنشاء وظائف خالصة تأخذ البيانات وتحولها وترجع نسخة جديدة. من خلال التعلم من Redux و Elm ، يمكننا جعل هندسة Java أكثر وظيفية. أنا أتحدث عن هذا لأن Redux يتحول إلى JavaScript ، وهو عبارة عن بازار فريد من نوعه. أعتقد أن JavaScript هو أبعد ما يكون عن النقاء الوظيفي المثالي ، هنا في كل خطوة تخطوها إلى بركة. ومع ذلك ، يمنحك Redux نقاء وظيفي في هذا العالم غير النظيف للغاية. أثرني هذا النهج كثيرًا لأنه غير وجهة نظري حول البرمجة الوظيفية وأظهر أنه يمكنني تنفيذ هذه المبادئ في Java أيضًا.
- جيد شكرا. برأيك ، هل مجموعة الأدوات الكاملة التي لدينا في Java كاملة وكافية؟ هل نحتاج إلى أي شيء آخر غير تعبيرات لامدا ومراجع الطرق والمجموعات ذات التدفقات؟- في رأيي ، لا يزال لدينا الكثير لنفتقده. عالم جافا يتطور باستمرار. لقد أجريت حوارًا مؤخرًا مع رجل قال: "سمعت أنك كنت في مدينتنا قبل بضع سنوات وجادلت الكثير حول الأدوية الجنسية" ، فأجبتها: "أنا دائمًا أجادل كثيرًا حول الأدوية الجنسية". أعتقد أنه في لغة جافا يتم عملهم بشكل سيئ للغاية. بريان غويتز غاضب مني طوال الوقت: "سيكون هناك دائمًا شخص يشكو من الأدوية الجنسية" ، وهذا بالطبع هو أنا. في رأيي ، يمكن تحسين الكثير في هذا المجال. الإصلاح مهم جدا في رأيي. يمكن القيام بالكثير من حيث الحد من انتفاخ البطن ، والتخلص من شفرة الغلاية. يمكن جعل الرمز أكثر طلاقة. وحركة معينة في هذا الاتجاه مرئية بالفعل اليوم. تطبق Java الآن مطابقة الأنماط ، مما يجعلني سعيدًا جدًا - أحب حقًا كيف يتم تنفيذه في Scala و Kotlin. أعتقد أنها مهمة للغاية ، ويتبادر إلى ذهني التشابه مع آلة معالجة الأوراق النقدية. إذا قمت بتمرير مجموعة من الملاحظات من خلاله ، فسيتم فرزها وفقًا لقيمة كل ورقة نقدية. وبالمثل ، مطابقة النمط في أعمال البرمجة. يمكنك تمرير البيانات من خلال المعلمات التي يمكنها استرداد البيانات للمعالجة. أعتقد أن هذا يمكن أن يساعد في التخلص من العدد الهائل من مشغلي الفروع التي نكتبها في جافا. سيصبح الرمز أكثر تعبيرا. بشكل عام ، أعتقد أن Java تحتاج إلى الكثير من الإضافات ، ولكن ، على ما يبدو ، تتحرك بالفعل في هذا الاتجاه.
أريد أن أذكر جانبًا آخر يثير الفضول حقًا بالنسبة لي. لقد نشأت في عالم البرمجة التقليدية. لا أخشى أن أعترف علانية بأن لغتي الأولى كانت Visual Basic. بمعنى ما ، هذه لغة جيدة للتجربة الأولى ، لأنها لا يمكن أن تكون أسوأ. ثم كتبت لفترة طويلة في C و C ++ ، وفي معظم الأوقات من جميع اللغات التي قضيتها مع C ++. بعد ذلك ، بدأت في الكتابة بلغة Java ، C # ، لغات مثل Ruby. عند نقطة معينة ، أدركت أنني كنت دائمًا أكتب بلغات متعددة مؤشرات الترابط. لذا كان التعرف على Node نوعًا من البصيرة - استغرق الأمر مني بعض الوقت قبل أن أحسب البرمجة غير المتزامنة.
ولكن ، في رأيي ، يعد التزامن أحد أهم المجالات التي يمكن أن تتطور فيها لغة جافا والنظام البيئي. يشير عدم التزامن إلى coroutines والاستمرار. أعتقد أن Java تتحرك بالفعل في هذا الاتجاه ، وهذا في رأيي مهم للغاية. وأفترض أنه سيكون من الصعب على مبرمجي جافا أن يتعرفوا على البرمجة غير المتزامنة كما كانت بالنسبة لي. يعتمد نهجي في البرمجة بالكامل على التوازي ؛ لقد كتبت أطروحة حول الحوسبة المتوازية. لقد تطلب الانتقال من التوازي إلى التزامن الكثير من الجهد. الآن ، بمعرفة كلا النهجين ، أفهم أننا كمبرمجين جافا ، نحتاج إلى إيجاد طريقة لدمجهم. بالنظر إلى أن العالم يتحرك نحو أشياء مثل الخدمات الدقيقة ،تصبح عدم التزامن على المدى الطويل أكثر أهمية من التوازي. تتطور Java في هذا الاتجاه ، وأعتقد أنها صحيحة.— , ? JVM-, . . ?- هذا سؤال شائع للغاية ، ولكن ليس من السهل مناقشته. أشعر بالخجل من الحديث عنه الآن ، لكنني قضيت شبابي في مصحح أخطاء. سبب خجلتي من هذا الآن هو: في الصباح ، عندما وصلت إلى العمل ، وجدت المؤشر في نفس الوضع الذي تركته في المساء السابق ، لأنني كنت متعبًا لدرجة أنني لم أتمكن من متابعة تصحيح الأخطاء. على مر السنين ، أتقنت التطوير من خلال الاختبار ، والآن أقوم به بطريقة منضبطة للغاية. سأعطي مثالا. في التطبيق الذي نقوم بتطويره حاليًا مع العميل ، ربما لدينا الملايين من lambdas. هذا مشروع عن البيانات الضخمة. نحن ندير رمزًا متوازيًا يطلق باستمرار مجموعة من لامداس. كما تفهم ، لا يعمل النظام دائمًا كما هو متوقع. ومع ذلك ، عندما يحدث هذا ، نتعلم عنه عادةً لأن اختبار الوحدة لا يعمل.ثم يقوم عميلي بتعيين نقطة توقف في الاختبار حيث حدث الخطأ ، ويقوم بتصحيح هذا الاختبار. بفضل هذا ، نحن لا نقوم بتصحيح صفائف ضخمة من التعليمات البرمجية ، ولكن وحدات فردية.بعبارة أخرى ، غالبًا ما تكون عدم القدرة على تصحيح التعليمات البرمجية نتيجة لصفات تقنية معينة ، ولكن عدم وجود وحدات نمطية في التعليمات البرمجية. وكلما ازدادت النمذجة ، أصبحت الشفرة أكثر تحكمًا. وينطبق ذلك على كل من الحوسبة المتوازية ولامداس ، وغير المتزامنة. إذا كان لدينا العديد من سلاسل الرسائل ويصعب علينا تصحيحها ، فهذا أمر متوقع تمامًا ، نظرًا لأن خاصية سلاسل الرسائل المتعددة غير حتمية بطبيعتها. في الجوهر ، تفتح الخلايا في حديقة الحيوانات ، ثم تحاول معرفة مكان الهروب. مهمتك هي ترويض حديقة الحيوانات هذه ، والسيطرة عليها ، ولهذا تحتاج إلى جعل الرمز وحدات. وينطبق نفس الشيء على لامداس. عندما يسألوني كيف يمكنني تصحيح لامبدا ، أجيب: لا مفر. لا تحتاج لامدا تتكون من 30 سطر من التعليمات البرمجية. تحتاج إلى وظيفة منفصلة ،حيث سيكون لديك اختبار وحدة يمكنك تصحيحه ثم استدعاءه كمرجع أسلوب عبر lambda.عدم التزامن جميل ، وهنا السبب. يمكنك إجراء مكالمة وتحديد ما يجب القيام به عند اكتمال هذه المكالمة. ولكن لا يجب استدعاء هذه الخطوة التالية من داخل مكالمة غير متزامنة. يمكن استدعاء الطريقة التالية بشكل منفصل لتصحيح الأخطاء والاختبار. ولا يجب تنفيذ الطريقة غير المتزامنة نفسها ؛ بدلاً من ذلك ، قد يكون لديك كعب روتين يتحقق ببساطة ما إذا كان قد تم إجراء المكالمة أم لا. أكرر: عدم القدرة على تصحيح التعليمات البرمجية غالبًا ما لا يكون نتيجة لخصائص تقنية معينة ، ولكنه يشير إلى عدم وجود وحدات نمطية من التعليمات البرمجية. وكلما عملت مع العديد من التقنيات في نفس الوقت ، كلما كنت مقتنعًا بذلك أكثر وأجد طرقًا لتصحيح الأخطاء النشطة التي تسمح لي بعدم فقدان عقلي.— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?- نعم ، بالطبع ، كثير من الناس يستخدمونه. ولكن ، بالعودة إلى ما قلته عن التغيير في طريقة التفكير ، أتفق تمامًا مع هذا. لم أكن على دراية بـ Angular 1 في وقت واحد ، وطلب مني العميل الذي كنت أعمل معه أن ألقي نظرة على هذا الإطار. في Angular ، يمكنك كتابة الحرف "$" والوصول إلى مساحة الاسم العامة. عندما اكتشفت هذا الأمر ، كان رد فعلي الأول: "يا له من هراء. لا يمكنك فعل ذلك ". أقول هذا ليس لأثني على نفسي ، ولكن بالمناسبة حول الموضوع الذي أثير حول طريقة التفكير. لأنني بدأت بعد ذلك في البحث عن جوجل ، واستغربت تمامًا عندما علمت أن الجميع يفعل ذلك. كنت مقتنعا بأنني لن أكتب أبدا مثل هذا. بعد بضعة أشهر أو سنوات - لا أتذكر بالضبط - خرج Angular 2 ، حيث اعترف المطورون بأن هذا الشيء كان غبيًا حقًا ويجب التخلص منه.كمطورين ، يسعدنا أن نتعلم كيفية العمل مع مكتبات جديدة وتقنيات جديدة. ولكن ، عندما نفعل ذلك ، لا يكفي تعلم بناء الجملة الجديدة وواجهة برمجة التطبيقات الجديدة - فأنت بحاجة إلى تعلم طريقة التفكير المناسبة. ما الذي يجب أن يكون رمزًا جيدًا؟ ما هي الأنماط المضادة التي يجب تجنبها؟ يتم إنشاء هذه التقنيات من قبل الموهوبين ، ولكن تذكر أنها لا تزال الناس. والناس يخطئون. هذا هو السبب في Java - وبأي لغة - هناك طرق موقوفة. لذلك ، مر Angular 1 مرة - لقد وجدنا طرقًا أكثر تقدمًا لحل المشكلات. بشكل عام ، عندما تتقن تقنية جديدة ، يجب أن يتم ذلك بشكل عملي وبنسبة من الشك الصحي.بالعودة إلى سؤالك الآخر - في رأيي ، فإن الأنظمة التي تحركها الأحداث (الأنظمة التي تحركها الأحداث) هي مستقبل البرمجة. وهي تمتزج جيدًا مع عدم التزامن والخدمات الدقيقة. العديد من هذه التقنيات والتطبيقات وواجهات برمجة التطبيقات والمكتبات موجودة منذ عدد كبير من السنين ، ولكن الآن انتعشت طفرة حقيقية حولها. بفضل تفاعلهم ، يتغير فهمنا لكيفية تطوير التطبيقات في المستقبل. إذا نظرت إلى الوراء في الوقت المناسب ، سترى أنه تقريبًا كل 5-10 سنوات ، فكرتنا حول ما يجب أن تكون عليه بنية التطبيقات يجب أن تتغير. لقد تحولنا من تطبيقات سطح المكتب إلى تطبيقات الخادم والويب ، ثم إلى تطبيقات الهاتف المحمول ، والآن نفكر في الخدمات الصغيرة والأنظمة الموجهة للحدث. أعتقد ذلكأننا اليوم في المرحلة التالية من الانتقال. عندما يسألوني عما إذا كان المستقبل ينتمي إلى البرمجة الوظيفية ، أجيب - لا ، إنه ينتمي إلى البرمجة التفاعلية. لأن البرمجة التفاعلية بالنسبة لي هي البرمجة الوظيفية ++. التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.سواءً كان المستقبل ينتمي إلى البرمجة الوظيفية ، فأجبت - لا ، إنه ينتمي إلى البرمجة التفاعلية. لأن البرمجة التفاعلية بالنسبة لي هي البرمجة الوظيفية ++. التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.سواءً كان المستقبل ينتمي إلى البرمجة الوظيفية ، فأجبت - لا ، إنه ينتمي إلى البرمجة التفاعلية. لأن البرمجة التفاعلية بالنسبة لي هي البرمجة الوظيفية ++. التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.ينتمي إلى البرمجة التفاعلية. لأن البرمجة التفاعلية بالنسبة لي هي البرمجة الوظيفية ++. التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.ينتمي إلى البرمجة التفاعلية. لأن البرمجة التفاعلية بالنسبة لي هي البرمجة الوظيفية ++. التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.التفاعلية هي تكوين من الوظائف والحسابات البطيئة كما يتم تطبيقها على دفق البيانات. لذا ، في رأيي ، لم تسقط البرمجة التفاعلية من السماء ، ولكنها استمرار منطقي للوظيفة. فهو يجمع بين نموذج موجه نحو الحدث وتكوين وظيفي وحوسبة بطيئة وإمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.إمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.إمكانية التزامن. ربما يكون كل من هذه المفاهيم في حد ذاته فضوليًا فقط ، ولكنها تؤدي معًا إلى تغييرات أساسية في بنية التطبيقات في المستقبل ، لأنها تغير الأدوات والتقنيات التي نستخدمها.
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?- الكثير مما تتجه إليه Java كان موجودًا في .NET لبعض الوقت. كان C # في البداية إصدارًا محسنًا قليلاً من Java ، وقلنا أن C # يكرر كل شيء بعده. لكن الوضع اليوم عكس ذلك. ظهرت Lambdas في Java بعد بضع سنوات من إضافة LINQ في C # ، مما يسمح لك بكتابة lambdas ، والتي لها عمل ووظيفة (ما يسمونه Func). وبالمثل ، ظهر عدم التزامن في C # قبل بضع سنوات من الوعد بإضافة عدم التزامن إلى Java. صحيح ، يجب أن أقول أنه في Java منذ عام 2014 هناك CompletableFuture. ولكن ظهرت التزامن في C # قبل ذلك بوقت طويل.يمكن قول شيء مشابه عن Java و JavaScript. أعلم أن عبارة "لدينا الكثير لنتعلمه من جافا سكريبت" يمكن أن تكون مخيفة ، لكن مبرمجي جافا سكريبت رأوا الكثير ويعرفون كم رطل. لديهم مفهوم "رد اتصال الجحيم" ، عندما لا تتناسب عمليات رد الاتصال بشكل جيد مع بعضها البعض ، يصبح من الصعب للغاية التعامل مع الاستثناءات ومن الصعب جدًا بناء شيء على وظائف رد الاتصال التي يجب أن تؤدي مكالمات غير متزامنة. في النهاية ، تم العثور على حل في عالم جافا سكريبت في شكل وعود ، والتي تشبه CompletableFutures في جافا. ومع ذلك ، يجب على المرء أن يعترف: جمال عالمنا هو أنه لا توجد طريقة واحدة صحيحة طوال الوقت. إحدى فوائد الوعود هي أنه من الممكن إنشاء وظائف هناك.ميزة أخرى هي أنه يمكنهم التعامل مع الاستثناءات ويمكنك تمرير البيانات من خلال الوعود. ومع ذلك ، تخيل أن شفرتك ، من بين أمور أخرى ، لديها عدة مستويات من الاستثناءات. يمكن أن تصبح معقدة للغاية ، وفي مرحلة ما ستدرك أنها كانت ستبدو أفضل بكثير إذا كانت مكتوبة بأسلوب إلزامي بدلاً من أسلوب عملي. هذا هو السبب في إضافة المتزامن والانتظار إلى JavaScript. في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.ومع ذلك ، تخيل أن شفرتك ، من بين أمور أخرى ، لديها عدة مستويات من الاستثناءات. يمكن أن تصبح معقدة للغاية ، وفي مرحلة ما ستدرك أنها كانت ستبدو أفضل بكثير إذا كانت مكتوبة بأسلوب إلزامي بدلاً من أسلوب عملي. هذا هو السبب في إضافة المتزامن والانتظار إلى JavaScript. في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.ومع ذلك ، تخيل أن شفرتك ، من بين أمور أخرى ، لديها عدة مستويات من الاستثناءات. يمكن أن تصبح معقدة للغاية ، وفي مرحلة ما ستدرك أنها كانت ستبدو أفضل بكثير إذا كانت مكتوبة بأسلوب إلزامي بدلاً من أسلوب عملي. هذا هو السبب في إضافة المتزامن والانتظار إلى JavaScript. في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.يمكن أن تصبح معقدة للغاية ، وفي مرحلة ما ستدرك أنها كانت ستبدو أفضل بكثير إذا كانت مكتوبة بأسلوب إلزامي بدلاً من أسلوب عملي. هذا هو السبب في إضافة المتزامن والانتظار إلى JavaScript. في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.يمكن أن تصبح معقدة للغاية ، وفي مرحلة ما ستدرك أنها كانت ستبدو أفضل بكثير إذا كانت مكتوبة بأسلوب إلزامي بدلاً من أسلوب عملي. هذا هو السبب في إضافة المتزامن والانتظار إلى JavaScript. في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.في جوهرها ، هم أغلفة حتمية للوعود. يمكنك كتابة رمز حتمي ، وعندما يتم إجراء استدعاء لوظيفة ، تصبح هذه المكالمة غير متزامنة ، ولا يتم تنفيذ الرمز الموجود تحت هذه الوظيفة على الفور ، ولكن بعد أن تكون الوظيفة غير المتزامنة قد أكملت عملها بالفعل. مع CompletableFuture ، هذا غير ممكن ، ولكن مع الاستمرار في Java في المستقبل سيكون ممكنًا. وهذا بالضبط ما تفعله corotines في Kotlin.إذا قارنا كل هذه اللغات ، فسوف يتضح أنني متعدد اللغات لأسباب أنانية بحتة. بمعنى ما ، البرمجة بلغات مختلفة تشبه السفر إلى بلدان مختلفة. أحب أن أكون في روسيا وإستونيا والهند وأجزاء مختلفة من الولايات المتحدة ، لأنه خلال هذه الرحلات أقابل ثقافات مختلفة وأرى ممارسات مختلفة وطرق مختلفة يحل بها الناس نفس المشاكل. لذلك ، أخبر المطورين دائمًا أن إحدى أهم صفات المبرمج الجيد هي فهم حقيقة أنه لا توجد طريقة فريدة لكتابة التعليمات البرمجية. بالطبع ، بعض الطرق لها مزايا في بعض المواقف ، والبعض الآخر لها عيوب ، ونحن بحاجة إلى اختيار أفضلها. إذا قارنا غير متزامن في C # ، غير متزامن / انتظار ووعود في JavaScript و coroutines في Kotlin ، فسنرىأنه من الأفضل في بعض المواقف استخدام أسلوب وظيفي ، وفي حالات أخرى من الضروري ، ولكن يمكنك تنفيذ التزامن مع كلا النهجين. يبدو فضولي للغاية بالنسبة لي. جافا في مجال هذه الابتكارات متخلفة عن لغات أخرى. ولكن أعتقد أن Java تتغير ، ليس فقط لأن هذه التغييرات حدثت بالفعل بلغات أخرى ، ولكن أيضًا لأن البيئة التي ننشئ فيها هذه التطبيقات تتغير. يجب أن تتطور اللغة لتوفير القدرة على إنشاء تطبيقات حديثة. أعتقد أن اللغة التي تتوقف عن تلبية متطلبات العمل تصبح عتيقة وغير مستخدمة. يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.ولكن من الممكن تنفيذ التزامن مع كل من النهج والآخر. يبدو فضولي للغاية بالنسبة لي. جافا في مجال هذه الابتكارات متخلفة عن لغات أخرى. ولكن أعتقد أن Java تتغير ، ليس فقط لأن هذه التغييرات حدثت بالفعل بلغات أخرى ، ولكن أيضًا لأن البيئة التي ننشئ فيها هذه التطبيقات تتغير. يجب أن تتطور اللغة لتوفير القدرة على إنشاء تطبيقات حديثة. أعتقد أن اللغة التي تتوقف عن تلبية متطلبات العمل تصبح عتيقة وغير مستخدمة. يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.ولكن من الممكن تنفيذ التزامن مع كل من النهج والآخر. يبدو فضولي للغاية بالنسبة لي. جافا في مجال هذه الابتكارات متخلفة عن لغات أخرى. ولكن أعتقد أن Java تتغير ، ليس فقط لأن هذه التغييرات حدثت بالفعل بلغات أخرى ، ولكن أيضًا لأن البيئة التي ننشئ فيها هذه التطبيقات تتغير. يجب أن تتطور اللغة لتوفير القدرة على إنشاء تطبيقات حديثة. أعتقد أن اللغة التي تتوقف عن تلبية متطلبات العمل تصبح عتيقة وغير مستخدمة. يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.أن Java تتغير ليس فقط لأن هذه التغييرات حدثت بالفعل بلغات أخرى ، ولكن أيضًا لأن البيئة التي ننشئ فيها هذه التطبيقات تتغير. يجب أن تتطور اللغة لتوفير القدرة على إنشاء تطبيقات حديثة. أعتقد أن اللغة التي تتوقف عن تلبية متطلبات العمل تصبح عتيقة وغير مستخدمة. يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.أن Java تتغير ليس فقط لأن هذه التغييرات حدثت بالفعل بلغات أخرى ، ولكن أيضًا لأن البيئة التي ننشئ فيها هذه التطبيقات تتغير. يجب أن تتطور اللغة لتوفير القدرة على إنشاء تطبيقات حديثة. أعتقد أن اللغة التي تتوقف عن تلبية متطلبات العمل تصبح عتيقة وغير مستخدمة. يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.يجب أن تتطور جافا من أجل البقاء. وأنا لست قلقة للغاية من تأخر Java عن بعض اللغات الأخرى - لا يزال لديها الوقت.أنا حقًا أقدر جانبًا آخر من جافا. دعونا نلقي نظرة على لامداس. عادة ما أقول أن جافا تأخرت في العطلة ، لكنها جلبت حلوى رائعة. ظهرت Java lambdas في وقت متأخر جدًا ، ولكن تنفيذها مع الاستدعاء الديناميكي ، في رأيي ، مدهش. يحسن استخدام lambdas في جميع اللغات التي تعمل على JVM. جافا ليست مبتكرة في مجال اللغات ، لكنها مبتكرة في البحث عن طرق أفضل لتطبيقها. وفي رأيي ، هذه ميزة مهمة للغاية. أعتقد أنه في المستقبل ستستمر اللغات الأخرى في الصدارة على Java من حيث توفر الميزات الجديدة ، لكن Java ستبحث عن طرق أفضل وأكثر عملية وأداء عالي لتنفيذ هذه التقنيات على JVM. لكننا حقا بحاجة إليها. نحن لا نحتاج إلى فرص جديدة فقط للجمال ، نحن بحاجة إلى رمز يلبي متطلباتنا.من وجهة النظر هذه ، فإن حقيقة أن Java لا تتطور بسرعة كبيرة هي ميزة.— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?- هذه قضية مهمة للغاية. أقول دائمًا إنه يجب أن تحاول تجنب الانخراط في التكنولوجيا. عن طريق الهواية ، أعني الشعور عندما ترى شيئًا جديدًا ويبدو لك أنه يجب عليك بالتأكيد استخدامه في تطبيقك الآن. هنا ، كمطورين ، نحتاج إلى العمل على أنفسنا. أولاً ، يجب ألا نتعلم التكنولوجيا الجديدة لمجرد أنها ضرورية في المشروع الحالي. ثانياً ، يجب ألا نطبق كل ما تعلمناه. أقول هذا لأن العديد من الأشياء التي تعلمتها لا تنطبق لمدة ست أو سبع سنوات. لم أدرس هذه التقنيات للتطبيق المباشر ، ولكن لدي فكرة عن وجودها. هناك حاجة إلى حكمة معينة لتقرير أن هذه التكنولوجيا ليست ضرورية في هذا المشروع حتى الآن. ينشأ التعقيد عندما نتراكم مكونات مختلفة ،لا يفهمون فضائلهم بشكل كامل. على سبيل المثال ، عندما أزور موقع أحد العملاء ، أسأل دائمًا: لماذا تستخدم هذا؟ علاوة على ذلك - لماذا تحاول حل هذه المشكلة؟ ما سبب أهمية العديد من المشكلات الأخرى التي يمكنك حلها؟ لذلك ، أوصي بأن يأخذ المطورون وقتهم ومعرفة سبب إنشاء التكنولوجيا التي تهمهم. غالبًا ما أسألهم: هل يمكنك معرفة متى وفي أي ظروف ستستخدم Angular ، ومتى - تتفاعل؟ في بعض الأحيان لا يستطيع الناس الإجابة ، ولكن في نفس الوقت يستخدمون رد الفعل في مشروعهم. سؤالي في هذه الحالة - هل تحتاجه حقًا هنا؟ أنا لا أقول أنه ليس ضروريًا ، لكننا غالبًا لا نعرف لماذا نستخدمه ونفعله فقط لأن أحدهم قال إنه يجب أن يكون. ينشأ التعقيد عندما نستخدم التكنولوجيا ،لا يفهمون غرضهم بالكامل. يمكنك محاربته من خلال دراسة هذه التقنيات ومقارنتها مع بعضها البعض ، وتقييم المزايا والعيوب. إذا كان المطور لا يستطيع أن يخبرني بخمسة جوانب تجذبه في أداة معينة ، وخمسة عوامل تطرده ، فهذا يعني أنه لم يدرس هذه الأداة جيدًا. عندما نرى كل أداة من جوانب مختلفة ونحصل على عرض غير متحيز لها ، يمكننا استخدامها بنجاح.عندما نرى كل أداة من جوانب مختلفة ونحصل على عرض غير متحيز لها ، يمكننا استخدامها بنجاح.عندما نرى كل أداة من جوانب مختلفة ونحصل على عرض غير متحيز لها ، يمكننا استخدامها بنجاح.آخر شيء أود أن أقوله عن التعقيد. عند تقييم التكنولوجيا ، تخلص من مشاعرك ورغباتك. في مناقشاتنا ، عادة ما يقول أحدهم: أنا أحب هذه التكنولوجيا أو تلك ، أريد استخدامها. أوصي بأن ترسم الفرق جدولًا وتدرج الميزات التي يحتاجها تطبيقك: قابلية الاختبار ، وقابلية التوسع ، وعدم التزامن ، والأمان ، وما إلى ذلك ، اعتمادًا على التطبيق. ثم ، بجانب كل منها ، اكتب رقمًا من 1 إلى 10 ، حيث تعني 10 "مهم للغاية" ، وتعني 1 "لا تهتم". بعد ذلك ، لكل فرصة ، اكتب قائمة بالتكنولوجيات الحالية ولكل منها وضع رقمًا من 1 إلى 10 ، حيث يعني 1 "لا يدعم" و 10 - "يعمل بشكل مثالي". أخيرًا ، عد النقاط واعرف أي التقنيات الحالية ستكسب أكبر عدد من النقاط.الآن لا تشارك عواطفك في التقييم بأي شكل من الأشكال ، وهذا يسمح لك باختيار التكنولوجيا الضرورية بشكل أكثر ذكاءً. أنت لا تجري هذا التقييم على نطاق عالمي أو حتى على نطاق ثابت ، بل تقوم به بناءً على احتياجات المشروع الحالي. لذلك ، لا أحب تصريحات بعض الشركات التي لديها Angular أو React أو Java كمعيار مشترك. أسأل دائما في مثل هذه الحالات: لماذا؟ نحن لا نعرف حتى ما سنفعله بالضبط. هذا هو نفس القول: ستنتقل شركتنا بالكامل حصريًا على الدراجات. هذا لا معنى له. كل هذا يتوقف على ما نقوم به ، وهذا هو السؤال الذي يجب الإجابة عليه أولاً. بشكل عام ، أعتقد أنه يمكن تقليل التعقيد بشكل كبير إذا فهمنا بشكل صحيح ما نقوم به ولماذا نستخدم هذه التكنولوجيا أو تلك ؛إذا تخلصت من العواطف والرغبات وقمت بتقييم الموارد والاحتياجات ؛ إذا قمت بتقييم قابلية حلولنا للمقارنة بشكل صحيح.أخيرا ، آخر شيء أود أن أذكره هو البساطة. أقول دائمًا للفرق - إن إضافة الأشياء إلى المشروع أمر سهل ؛ وإزالتها من المشروع أمر صعب للغاية. تكاليف الإزالة هي عشرة أضعاف تكاليف الإضافة. لذلك ، عند إضافة أي شيء ، يجب أن تتأكد من أنك تقوم بالفعل بخفض التكاليف ، ليس الآن فقط ، ولكن أيضًا على المدى الطويل. وتحتاج ، من بين أمور أخرى ، إلى التفكير في إمكانية عكسها. إنها تتعلق بالقدرة على التراجع عن القرارات المتخذة بشأن هندسة التطبيقات. إذا كان الحل قابلاً للعكس ، فحينئذٍ يمكنك رفضه غدًا ، وفي هذه الحالة يجب ألا تفكر فيه لفترة طويلة. إذا كان الحل يمكن عكسه بشكل سيئ ، فأنت بحاجة إلى قضاء المزيد من الوقت عليه ، وجمع المزيد من البيانات. إذا أخذنا في الاعتبار درجة التراجع عن قراراتنا ،وبالتالي فإننا نقلل بشكل كبير من تعقيد التطبيقات. بشكل عام ، أعتقد أنه في العديد من الجوانب يجب أن نتغلب على شغفنا بالتكنولوجيا من أجل تقليل درجة التعقيد."شكرا لك ، هذه إجابة رائعة." في مؤتمر Joker لدينا ، سوف تتحدث أيضًا عن التعقيد ، حتى تتمكن من مواصلة المناقشة هناك.- نعم ، سوف أتطلع إليها بحماس.