أولاً

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

التحديات التي تُحدِّثها

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

الوثائق

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

1. أدلة المطورين الجدد كيف تدير المشروع ** (المزيد من هذا في دقيقة واحدة)، ما هي الاعتبارات الموجودة (إذا كنت تحتاج، على سبيل المثال، إلى إطار مختلف عن الإطار الحالي، وينطبق ذلك بصفة خاصة على العقدة للأسف).
2. عدد حالات الوزع في هذه الأيام عندما يُنظر إلى CI/CD على أنه المعيار الذهبي للنشر غالباً ما يتم تجاهله أنك تحتاج إلى معرفة كيفية نشر النظام يدوياً. هذا صحيح بشكل خاص إذا كنت تعمل على نظام كان موجوداً منذ فترة ولديه الكثير من الخطوات اليدوية.
3. إجراءات حل المشكلةماذا تفعل عندما ينهار النظام؟ بمن تتصل؟ ما هي الأشياء الرئيسية للتحقق منها؟ وكثيراً ما يتم التغاضي عن هذا الأمر، ولكنه يتم في إطار نظام إنتاجي.
4. دكاتــب دكاتــب عــن العمــل الهنــدي/النظــم/المنظومة/المنظومةكيف يعمل النظام؟ ما هي المكونات الرئيسية؟ ما هي المعتمدات الرئيسية؟ فكروا في هذا كخارطة طريقكم عندما تتعلمون نظاماً جديداً. وهو يقدم لمحة عامة رفيعة المستوى عن كيفية عمل النظام الذي يمكن أن يكون بالغ الأهمية (لا سيما في النظم الأكبر والموزعة). وينبغي أن يشمل ذلك ما هي مستودعات الرموز المصدرية المستخدمة، وما هي النظم المستخدمة في نظام CI/CD، وما هي قواعد البيانات المستخدمة لكل عنصر من عناصر التطبيق. وهذا يمكن أن يشمل أي شيء بدءاً من رسم بياني بسيط إلى رسم بياني كامل الانفراد UML لكل مكون من مكونات النظام. على سبيل المثال في تطبيق refact هذا سوف يشمل عادة رسما بيانيا للمكونات وكيفية تفاعلها مع بعضها البعض وأي خدمات خلفية. وسيشمل ذلك، في التطبيقات الأساسية لشبكة الإنترنت، رسماً بيانياً للخدمات وكيفية تفاعلها مع بعضها البعض (والواجهة الأمامية وغيرها من النظم الخلفية) وربما آراء شبكة المعلومات الإحصائية وما هي الخدمات التي يمكن أن تستفيد منها.

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

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

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

تشغيل النظام محلياً

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

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

1. التخصيص - يبدو أن هذا قد أصبح "مطور متقدم متقدم فقط" مهارة، ولكن من الضروري أن تكون قادرة على توصيف رمزك لترى أين هي الاختناقات. وينطبق هذا بصفة خاصة على النظام القديم حيث قد لا يكون لديك ترف القدرة على إعادة كتابة النظام من الصفر. مثل الدالة الدالة وقد عقد مؤتمراً بشأن لا قيمة لها هنا. وعلى وجه الخصوص في تطبيقات ASP.NET؛ وأكبر القضايا هي عموماً "التسربات" في النظام؛ وتسربات الذاكرة، وتسربات الربط، وما إلى ذلك. بينما يبدو أن تطبيقك يعمل بشكل جيد لبعض الوقت تجد فجأة أنه ينهار / يستخدم كل الذاكرة على الخادم.
2. القضايا التي تُبحث في مُحَمِّل المُحَمِّل - تحبه أو لا تحب أيام Response.Write في كلاسيكي ASP انتهت. بالنسبة لتطبيق بسيط ومعقّد (ولا سيما تلك التي لم تكتبها) من المهم جداً أن "تخطّى من خلال" الكود. (ب) متابعة الطلب منذ إنشائه من خلال الخدمة لتحديد ما يمكن أن يحدث، وما هي الاستثناءات التي قد لا يتم ضبطها، وما إلى ذلك.
3. التفريغ - يتم تجاهله مرة أخرى في كثير من الأحيان (عذراً ولكن لا يوجد مرشّح إستثنائي لـ ASP.NET في أعلى الرزمة ليس كافياً). الإحالة المرجعية إلى م م م م م م م م م م م م م م م م ع م م م م م م م م م م م م م م م م م م م م م م م م م م م م م م م م، قطع الأشجار هو جزء حاسم في العمل في مدونة مكانيّة. تذكر أنه يمكنك استخدام نوع من أنواع تسجيل العملاء (على سبيل المثال باستخدام مُدَرَج المُسْتَجِدَات() في ASP.net as. ثم يمكنك أن تحدد أي نوع من أنواع الأحداث يجب أن يكون مسجلاً وما لا يجب أن يكون. وهذا أمر حاسم في نظام قديم حيث قد لا يكون لديك ترف القدرة على إعادة كتابة النظام من الصفر. لمعاينة التطبيقات التي قد ترغب في استخدام مسارات المستخدم وغيرها من الميزات، لكن كن مدركاً هذا يُصبحُ مُجَدًّا مُجَدَّدًا سريعًا (أ) LogInformation لكل طلب قد ترغب في استخدام معالج تفاضلي مخصص لفرز الطلبات التي لا تريد تسجيلها.
4. • في كثير من الأحيان أرى المطورين 'الاختبار في الإعدادية' أو التفكير أن اختبار وحدة الاختبار ثم التحقق في هو بما فيه الكفاية من حيث الاختبار. في الواقع، هناك الكثير من القيمة في استخدام أداة مثل Resharper / Ncrunch لتشغيل اختبارات الوحدة تلقائياً؛ على أي حال تذكر اختبارات الوحدة هي فقط ذلك؛ أنها تختبر 'وحدة' من الشفرة. تحتاج إلى الحفاظ على الوضوح في كيفية تشغيل النظام في الواقع بالتوافق مع مكونات أخرى. وهنا تأتي اختبارات التكامل؛ وهي تختبر كيف يعمل النظام ككل. يمكنك استخدام أداة مثل مُفرف وواز لكتابة هذه الاختبارات في شكل مقروء من الإنسان. مرة أخرى؛ حاسمة الأهمية في النظام القديم حيث قد لا يكون لديك ترف القدرة على إعادة كتابة النظام من الصفر.

في كل مشروع أعمل على الخطوة الأولى هو جعل النظام (أو جزء كبير منه) يعمل محليا. من خلال رؤية الشفرة، تشغيل الشفرة، تصحيح الشفرة يمكنك الحصول على شعور لكيفية عمل النظام.

القاعدة المشفرة

في كل نظام هذا هو لا يمكن نقل الحقيقة، بغض النظر عما يقوله الأطباء، ما يخبرك به الآخرون عن كيفية عملها هذه هي الطريقة التي تعمل بها.

تنفيذ a تركة رمز قاعدة

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

استخدم كل ما تحتاجه للتفاعل معها، سواء كان ما بعد الرجل، رايدر HtpClient أو حتى صفحة ويب. (هوك) في مُحَفِّلِكَ، يَجْعلُ النداءَ ويَتْبعُه خلال. اعيد واعيد لكل جزء من النظام.

عموماً تَتْركُ هذا حتى تَفْهمُ النظامَ. إنها دائماً تُغري بـ "رميها بعيداً والبدء من جديد" مع ذلك مقاومة هذا الإغراء. خصيصاً لنظام تشغيل الأعمال إعادة بناء/حتى إعادة تصنيع نظام ما هو خطر على الصحة. نعم انه ممتع لكن لكل سطر من الشفرة تغيرينه و تخاطرين بطرح حشرات جديدة مثيرة

مثل أي شيء آخر (خاصة عند التعاقد) تحتاج إلى تبرير العمل الذي تقوم به على النظام. فإما أن يكون هذا التبرير بحاجة إلى التركيز على أحد ما يلي:

1. م م م م - النظام بطيء ويحتاج إلى الإسراع به (من ناحية أخرى كن حذراً، ما تجده بطيئاً قد يكون كيفية تصميم النظام للعمل). وقد يؤدي إشراك شخص واحد في التدخين بسرعة إلى طرح مسائل أخرى في النظام. هل ستقتل خادم قاعدة البيانات، إذا قمت بعمل الكثير من الطلبات، هل لديك آلية لا تسبب استثناءات متعاقبة؟
2. 1 ف-5، 1 ف-4، 1 خ ع (ر أ)، 1 خ ع (ر أ) - النظام غير آمن ويحتاج إلى تأمين. وهذا أمر صعب، لا سيما في نظام تراثي. قد تجدون أن النظام يستخدم نسخ قديمة من المكتبات التي لديها قضايا أمنية معروفة. هذا هو مبرر جيد للعمل، ولكن كن مدركا أنك قد تحتاج إلى إعادة تصنيع كمية كبيرة من النظام للحصول على تحديثه؛ يؤدي مرة أخرى إلى قضية 'الحشرات الجديدة'.
3. المواصلة - النظام من الصعب صيانته ويحتاج إلى تيسير صيانته. بشكل عام هذا يصبح الكثير من العمل، هل العمر الحالي لقاعدة الرموز يبرر هذا؟ إذا كنت تنفق المزيد من الوقت في صنع هذه التغييرات لتحسين القدرة على الصيانة أكثر مما كنت من أي وقت مضى حفظ للزبون ثم فإنه لا يستحق ذلك (ومرة أخرى، تغير الشفرة == حشرات جديدة).
4. المُسِجِج -أنا عموماً أُعطي الأولوية لهذه القضايا. لـ (أ) ** لا يهم إذا كانت شفرتك أفضل بـ 1% إنهم هم الذين يدفعون مقابل العمل الذي تقوم به في النهاية إذا كنت تستطيع جعل تجربتهم أفضل مما هو عموما يستحق ذلك. على أي حال، كن مدركاً أن هذا يمكن أن يكون "ميلاً مائلاً" للتغييرات، قد تجد أنك تقوم بتغيير لوت من النظام لعمل تغيير صغير للمستخدم.

العمل في مجال نظم الإرث

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

لقد عملت كمقاول لأكثر من عقد من الزمن الآن، انها ليست EASY، كما مقاول كل ساعة من وقتك هو "تكلفة" للزبون. تحتاج إلى إضافة قيمة نقل إلى النظام أكثر مما تكلف. إن لم تكن كذلك، فستبحث بسرعة عن عقد جديد.

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

بشأن مشاركة أطول أجلاً الوظائف الجديدة الجديدة الجديدة الجديدة (ب) أن يكون الرمز محفوظاً وناجع التكلفة لتشغيله. في الأنظمة الموروثة هذا هو الكثير من HARDER. في كثير من الأحيان عليك أن تخوض خلال مستنقع، أن تكون حريصاً على أنه عندما تتعلم النظام لا يمكنك أن تقدم قيمة كبيرة. I'm not making any changes - - - - - - - - - - - - - - - - - - I'm just learning the system. هذه مغالطة، أنت تتعلم النظام لجعله أفضل. أنت تتعلم النظام لجعله أكثر كفاءة. أنت تتعلم النظام لجعله أكثر قابلية للصيانة. إذا كان العميل غير قادر على قبول هذه الخطوة، فعليك أن تكون حريصاً جداً على كيفية إيصال هذا (أو البحث عن عقد جديد).

الناس

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

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

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

المليم

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

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

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

النشر

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

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

التركة المُجَجَزَج

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

• إعدادات

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

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

عادة ما أستخدم نظام من الاختبارات في هذا الترتيب للأفضلية:

1. وحدات الاختبارات - مرة أخرى هذه هي المفضلة كما يمكنك استهداف هذه لتمارس فقط الشفرة التي تعمل عليها. ومع ذلك، ففي نظام قديم كثيراً ما لا يكون هذا النظام حاضراً وصعباً جداً للتعديل التحديثي (على سبيل المثال في نظام به العديد من المكالمات الخارجية / وهو نظام فوضوي في الكيفية التي يبني بها؛ لا في استخدام DI على سبيل المثال).
2. اختبارات التكامل - هذا مصطلح مثقل لأنه يمكن أن يغطي أي شيء من اختبار الوحدة الذي يمر عبر طبقات متعددة من الكود (من الأفضل تجنب هذه) إلى استخدام مثل أولا - حتى إلى اختبارات السيلينيوم. بشكل عام تريد أن تختبر النظام ككل، ومع ذلك كن مدركاً أن هذه الاختبارات يمكن أن تكون بطيئة وهشّة. استخدام التحقق يمكن أن يكون في كثير من الأحيان نهجا كبيرا للنظم القديمة كما يمكنك على الأقل 'التحقق' كنت لا كسر سطح API من النظام.
3. الاختبارات اليدوية - ينبغي لمطور كل مطور أن يجرب ويجري اختبارات يدوية لأي تدقيق شفري. هذا هو فقط ضمان أن ما تتوقعه من "المستخدم" (يمكن أن يكون مستخدماً فعلياً أو مكوناً آخر من النظام يتفاعل مع شفرتك) أن تراه هو ما يرونه فعلاً. ويمكن أن يكون هذا الأمر بسيطاً مثل تشغيل النظام محلياً والتحقق من مخرجات صفحة أو معقدة مثل إجراء مجموعة كاملة من الاختبارات على خادوم الإطلاق.

• البُقِيْن للعمل على النظم القديمة أنت عموما لن يكون لديك ترف إعادة عمل كاملة. هنا حيث أستخدم نهج "الجلد بالأونيون"

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

سأغطي هذا النهج أكثر في مقال مستقبلي لأنه عنصر رئيسي في كيفية عملي على أنظمة التراث

الحصول على مدفوعات مدفوعة

الآن بعد أن حصلنا على كل هذا خارج الطريق هناك تأتي المشكلة الشائكة للدفع. لدي قاعدة عامة:

أيّ قضايا دفع أنا أتطلّع للتحرّك على

إذا كانوا متأخرين في الدفع، يعتمدون على عقدك ولكن في LAAST في غضون 30 يوما ولكن بشكل عام أقرب إلى 7، هذه علامة سيئة. إذا كان هناك إكراميات على فاتورتك فكّر فيما إذا كانت الشركة قادرة على دفع تكاليف خدماتك على أساس مستمر.

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

كن صادقاً؛ مجرد تهمة للوقت الذي عملت فيه فعلاً؛ تأكد من وضوح ما فعلته ولماذا فعلت ذلك.

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

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

في الإستنتاج

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