بعد سنوات من ملء الاستمارات والانتظار، حصلت أخيرًا على رخصتك المصرفية. هذا يعني أنك أصبحت الآن مؤهلًا رسميًا لفتح بنكك الخاص، هنيئًا لك!
أولويتك الأولى هي تشغيل أنظمة تقنية المعلومات. وبعد يوم من العمل الشاق، أصبحت قادرًا بالفعل على فتح الحسابات وإغلاقها، وعلى التعامل مع عمليات السحب والإيداع.
ولأنك لم ترغب في تكبّد عناء كتابة الاختبارات، دعوت بعض أصدقائك لمساعدتك في اختبار النظام. لكن بعد خمس دقائق فقط، ادّعى أحد أصدقائك أنه فقد المال! ورغم ثقتك بأن الكود الخاص بك خالٍ من الأخطاء، بدأت تتصفح السجلات للتحقيق.
آه أجل، كما توقعت تمامًا، صديقك هو المخطئ! فقد شارك بيانات اعتماده للاختبار مع صديق آخر، وتآمرا معًا على تنفيذ عمليات إيداع وسحب من الحساب نفسه على التوازي. ومن قد يفعل شيئًا كهذا؟
وبينما تجادل بأنه من المستحيل فعليًا أن يصل أحدهم إلى حسابه على التوازي، يخبرك صديقك بثقة متعالية أن قواعد العمل المصرفي تقتضي أن تدعم ذلك. إذن، لا دعم للعمليات المصرفية المتوازية، ولا إشارة انطلاق. فتُنهِد وتدوّن في ذهنك أن تعمل على هذا غدًا. سيؤخر ذلك تاريخ إطلاقك يومًا آخر على الأقل، ولكن حسنًا...
مهمتك هي تنفيذ حسابات مصرفية تدعم الفتح والإغلاق وسحب الأموال وإيداعها.
بما أن الحسابات المصرفية يمكن الوصول إليها بطرق مختلفة عديدة (الإنترنت، والهواتف المحمولة، والخصم التلقائي)، يجب أن تسمح برمجيتك المصرفية بالوصول الآمن إلى الحسابات من خيوط/عمليات متعددة (تختلف المصطلحات حسب لغة البرمجة التي تستخدمها) في الوقت نفسه. على سبيل المثال، قد تحدث عمليات إيداع وسحب كثيرة في الوقت نفسه؛ عليك أن تضمن عدم وجود حالات تسابق بين قراءة رصيد الحساب وتعيين الرصيد الجديد.
ينبغي أن يكون من الممكن إغلاق الحساب؛ يجب أن تفشل العمليات التي تجري على حساب مغلق.
سجّل في Exercism لتتعلّم وتتقن Delphi Pascal عبر 76 تمرينًا، وإرشاد بشري حقيقي، وكل ذلك مجانًا.