تمارين Kata في البرمجة بثلاثة مستويات مع الحلول

الحل البسيط هو أربعة فروع if تبدأ بحالة FizzBuzz، وهو يعمل، ولكن كل قاعدة جديدة تضاعف عدد الحالات المركبة (FizzBazz وBuzzBazz وFizzBuzzBazz)، لذلك نجعل القواعد بيانات Data وليست فروعاً في الكود:

# fizz.py: rules are data, so a new rule is one line, not a new if
RULES = [
    (lambda n: n % 3 == 0 or "3" in str(n), "Fizz"),   # the twist: a 3 anywhere in the number
    (lambda n: n % 5 == 0, "Buzz"),
]

def say(n, rules=RULES):
    words = "".join(word for test, word in rules if test(n))
    return words or str(n)

print(" ".join(say(n) for n in range(1, 36)))
print(" ".join(say(n, RULES + [(lambda n: n % 7 == 0, "Bazz")]) for n in range(1, 36)))

والمخرج سوف يكون كما يلي:

1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz Fizz 14 FizzBuzz 16 17 Fizz 19 Buzz Fizz 22 Fizz Fizz Buzz 26 Fizz 28 29 FizzBuzz Fizz Fizz Fizz Fizz FizzBuzz
1 2 Fizz 4 Buzz Fizz Bazz 8 Fizz Buzz 11 Fizz Fizz Bazz FizzBuzz 16 17 Fizz 19 Buzz FizzBazz 22 Fizz Fizz Buzz 26 Fizz Bazz 29 FizzBuzz Fizz Fizz Fizz Fizz FizzBuzzBazz

ونفس الفكرة في JavaScript:

// fizz.js: the same rules in JavaScript
const RULES = [
  [n => n % 3 === 0 || String(n).includes("3"), "Fizz"],
  [n => n % 5 === 0, "Buzz"],
];
const say = (n, rules = RULES) => rules.filter(([test]) => test(n)).map(([, w]) => w).join("") || String(n);

console.log(Array.from({ length: 35 }, (_, i) => say(i + 1)).join(" "));
console.log(Array.from({ length: 35 }, (_, i) => say(i + 1, [...RULES, [n => n % 7 === 0, "Bazz"]])).join(" "));

1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz Fizz 14 FizzBuzz 16 17 Fizz 19 Buzz Fizz 22 Fizz Fizz Buzz 26 Fizz 28 29 FizzBuzz Fizz Fizz Fizz Fizz FizzBuzz
1 2 Fizz 4 Buzz Fizz Bazz 8 Fizz Buzz 11 Fizz Fizz Bazz FizzBuzz 16 17 Fizz 19 Buzz FizzBazz 22 Fizz Fizz Buzz 26 Fizz Bazz 29 FizzBuzz Fizz Fizz Fizz Fizz FizzBuzzBazz

في الحل أعلاه لاحظ التالي:

• الرقم 13 و23 و31 إلى 34 أصبحت Fizz بسبب الشرط الإضافي، و35 أصبحت FizzBuzz لأنها تحتوي 3 وتقبل القسمة على 5، فإذا كان جوابك Buzz لهذا الرقم فقد نسيت أن الشرطين يجتمعان.
• إضافة القاعدة الجديدة كانت سطراً واحداً دون تعديل الدالة، والرقم 21 أصبح FizzBazz وحده دون أن نكتب له حالة خاصة.
• ترتيب القواعد في القائمة هو ترتيب الكلمات في الناتج، وهذا قرار واضح في مكان واحد بدلاً من أن يكون مخفياً في ترتيب الفروع.

الحل في C# بقاموس Dictionary وقائمة تحفظ ترتيب أول ظهور:

// dups.cs: duplicates in one pass with a Dictionary, in first-seen order
var emails = new[] { "[email protected]", "[email protected]", " [email protected]", "[email protected]", "[email protected]", "[email protected]" };

var counts = new Dictionary<string, int>();
var order = new List<string>();
foreach (var raw in emails)
{
    var key = raw.Trim().ToLowerInvariant();          // normalize before comparing
    if (counts.TryGetValue(key, out var c)) counts[key] = c + 1;
    else { counts[key] = 1; order.Add(key); }
}
foreach (var key in order.Where(k => counts[k] > 1))
    Console.WriteLine($"{key} x{counts[key]}");

dotnet run dups.cs

[email protected] x3
[email protected] x2

وفي JavaScript يكفي Map لأنه يحفظ ترتيب الإضافة كما يذكر توثيق Map:

// dups.js: the same idea with a Map, which keeps insertion order
const emails = ["[email protected]", "[email protected]", " [email protected]", "[email protected]", "[email protected]", "[email protected]"];

const counts = new Map();
for (const raw of emails) {
  const key = raw.trim().toLowerCase();
  counts.set(key, (counts.get(key) ?? 0) + 1);
}
for (const [key, n] of counts) if (n > 1) console.log(`${key} x${n}`);

// the simple version that looks right: indexOf inside filter is O(n²) and misses " [email protected]"
console.log(emails.filter((e, i) => emails.indexOf(e) !== i));

[email protected] x3
[email protected] x2
[ '[email protected]' ]

في الحل أعلاه لاحظ التالي:

• حل الزميل وجد [email protected] مرة واحدة فقط وفاته [email protected] تماماً، والسبب أنه يقارن النص كما هو، فالعنوان " [email protected]" بمسافة وحرف كبير يعتبر عنواناً مختلفاً.
• وحل الزميل بطيء لأن indexOf يمر على القائمة من أولها لكل عنصر، أي O(n²)، وهذا لا يظهر مع ست عناوين ويظهر مع مئة ألف.
• جدول الهاش يجعل البحث والإضافة O(1) في المتوسط، فالحل كله O(n).

للتفصيل: جدول الهاش Hash Table في مقال هياكل البيانات.

# brackets.py: a stack of the brackets still open
PAIRS = {")": "(", "]": "[", "}": "{"}

def balanced(text):
    stack = []
    for ch in text:
        if ch in "([{":
            stack.append(ch)
        elif ch in PAIRS:
            if not stack or stack.pop() != PAIRS[ch]:
                return False
    return not stack            # something still open means unbalanced

for t in ["([]{})", "([)]", "((", "})", "f(a[1], {b: 2})", ""]:
    print(f"{t!r:20} {balanced(t)}")

'([]{})'             True
'([)]'               False
'(('                 False
'})'                 False
'f(a[1], {b: 2})'    True
''                   True

والحل في Java باستخدام ArrayDeque كمكدس، لأن الكلاس Stack قديم ومتزامن دون حاجة، وتوثيق Deque يوصي باستخدامه بدلاً منه:

// Brackets.java: Deque as a stack (java.util.Stack is legacy)
import java.util.ArrayDeque;
import java.util.Deque;
import java.util.Map;

public class Brackets {
    static final Map<Character, Character> PAIRS = Map.of(')', '(', ']', '[', '}', '{');

    static boolean balanced(String text) {
        Deque<Character> stack = new ArrayDeque<>();
        for (char ch : text.toCharArray()) {
            if (ch == '(' || ch == '[' || ch == '{') stack.push(ch);
            else if (PAIRS.containsKey(ch)) {
                if (stack.isEmpty() || !stack.pop().equals(PAIRS.get(ch))) return false;
            }
        }
        return stack.isEmpty();
    }

    public static void main(String[] args) {
        for (String t : new String[] {"([]{})", "([)]", "((", "})", "f(a[1], {b: 2})", ""})
            System.out.printf("%-20s %b%n", "\"" + t + "\"", balanced(t));
    }
}

"([]{})"             true
"([)]"               false
"(("                 false
"})"                 false
"f(a[1], {b: 2})"    true
""                   true

في الحل أعلاه لاحظ التالي:

• النص ([)] فيه عدد متساو من كل نوع، ولذلك يفشل الحل الذي يعد الأقواس فقط، أما المكدس فيرى أن ) جاء وأعلى المكدس [.
• السطر return not stack هو ما يرفض ((، وكثير من الحلول تنساه فتقبل نصاً لم يغلق أقواسه.
• في Java قارنا بالدالة equals وليس بالعلامة !=، والسبب أن pop() يعيد كائن Character وليس قيمة، والمقارنة بين كائنين بالعلامة تقارن المراجع وليس القيم، وهي تعمل هنا صدفة لأن Java تخزن الحروف الصغيرة مسبقاً، وهذا فخ سوف تراه في التمرين الرابع.

للتفصيل: المكدس Stack في مقال هياكل البيانات.

مخرج C#:

1 99
0

ومخرج Python:

[1, 2, 3] [1, 2, 3] [1, 2, 3, 4]
[1, 2] [1, 2]
abc abcd

في الكود أعلاه لاحظ التالي:

• PointS هو struct أي نوع قيمة Value Type، فالسطر s2 = s1 نسخ الرقم، وتغيير s2 لم يلمس s1، أما PointC فهو class أي نوع مرجع Reference Type، فالمتغيران يشيران إلى نفس الكائن في ال Heap.
• الدالة Reset غيرت p.X فتغير الكائن الأصلي إلى 0، ثم جعلت p يشير إلى كائن جديد، وهذا لم يغير c1 لأن المرجع نفسه مرر بالقيمة، لذلك المخرج 0 وليس 7.
• في Python b = a لا ينسخ القائمة، وa[:] ينسخها، لذلك ظهر الرقم 4 في c وحدها.
• السطر الثاني [1, 2] [1, 2] هو أشهر فخ في Python، فالقيمة الافتراضية [] تنشأ مرة واحدة عند تعريف الدالة وليس عند كل استدعاء كما يذكر الدليل الرسمي، فالاستدعاءان أضافا إلى نفس القائمة، والحل bucket=None ثم إنشاء القائمة داخل الدالة.
• النص في Python غير قابل للتغيير Immutable، فالعملية t += "d" أنشأت نصاً جديداً ولم تغير s.

للتفصيل: نوع القيمة ونوع المرجع في مقال الذاكرة.

# twosum.py: indexes of two numbers that add up to target
import time

def two_sum_slow(nums, target):            # O(n²): every pair
    for i in range(len(nums)):
        for j in range(i + 1, len(nums)):
            if nums[i] + nums[j] == target:
                return i, j
    return None

def two_sum(nums, target):                 # O(n): remember what we saw
    seen = {}                              # value -> index
    for i, x in enumerate(nums):
        if target - x in seen:
            return seen[target - x], i
        seen[x] = i
    return None

print(two_sum([2, 7, 11, 15], 9), two_sum([3, 3], 6), two_sum([1, 2], 7))

n = 5_000
nums = list(range(1, n + 1))               # the only pair is the last two numbers
for f in (two_sum_slow, two_sum):
    t = time.perf_counter()
    r = f(nums, 2 * n - 1)
    print(f"{f.__name__:13} n={n:,} -> {r}  {(time.perf_counter() - t) * 1000:.1f} ms")

(0, 1) (0, 1) None
two_sum_slow  n=5,000 -> (4998, 4999)  2221.5 ms
two_sum       n=5,000 -> (4998, 4999)  3.3 ms

والحل في Java بنفس الفكرة باستخدام HashMap:

// TwoSum.java: the same O(n) idea with a HashMap
import java.util.Arrays;
import java.util.HashMap;
import java.util.Map;

public class TwoSum {
    static int[] twoSum(int[] nums, int target) {
        Map<Integer, Integer> seen = new HashMap<>();   // value -> index
        for (int i = 0; i < nums.length; i++) {
            Integer j = seen.get(target - nums[i]);
            if (j != null) return new int[] {j, i};
            seen.put(nums[i], i);
        }
        return null;
    }

    public static void main(String[] args) {
        System.out.println(Arrays.toString(twoSum(new int[] {2, 7, 11, 15}, 9)));
        System.out.println(Arrays.toString(twoSum(new int[] {3, 3}, 6)));
        System.out.println(Arrays.toString(twoSum(new int[] {1, 2}, 7)));
    }
}

[0, 1]
[0, 1]
null

في الحل أعلاه لاحظ التالي:

• الحل البسيط فحص نحو 12.5 مليون زوج لأن الزوج الوحيد في آخر المصفوفة، والحل بجدول الهاش مر على الأرقام مرة واحدة، والفرق في هذه التجربة على جهاز واحد مئات المرات، وهي أرقام توضيحية تتغير من جهاز لآخر، أما شكل النمو فلا يتغير.
• نتحقق من target - x قبل إضافة x إلى الجدول، وهذا ما يجعل [3, 3] مع الهدف 6 يعمل، فلو أضفنا أولاً لوجد الرقم نفسه.
• ثمن السرعة ذاكرة إضافية O(n) للجدول، وهي مقايضة الوقت بالذاكرة التي تتكرر في أغلب التمارين القادمة.

للتفصيل: اختيار الهيكل الصحيح في مقال Big-O.

مخرج C# ثم JavaScript ثم Python:

-2147483648
False
True
3
3
OverflowException

0.30000000000000004
true
9007199254740992
9007199254740993n
3.5 -3 -2
0.30000000000000004441

9223372036854775808
False True
0.3 0.1000000000000000055511151231257827021181583404541015625
3.5 3 -4 -3
2 4 2.67

في المخرج أعلاه لاحظ التالي:

• int.MaxValue + 1 أصبح أصغر رقم سالب بصمت، وهذا هو الالتفاف في المتمم الثنائي Two's Complement، أما داخل checked فرمت C# الاستثناء OverflowException كما يذكر توثيق checked، لذلك استخدمه في الحسابات المالية والعدادات.
• 0.1 + 0.2 == 0.3 خطأ في اللغات الثلاث، والنوع decimal في C# وDecimal("0.1") في Python يعطيان الجواب الصحيح لأنهما عشريان، ولاحظ أن Decimal(0.1) من رقم عشري يكشف القيمة الحقيقية المخزنة لأن الخطأ حدث قبل أن يصل إليه.
• في JavaScript لا يستطيع النوع Number تمثيل 2⁵³ + 1، فطبع الرقم المكتوب في الكود ناقصاً واحداً، والحل BigInt كما يذكر توثيق MAX_SAFE_INTEGER، وهذا يهم كل من يستقبل معرفات من نوع 64 بت في JSON.
• Math.round(-2.5) يعطي ‎-2، وround(2.5) في Python يعطي 2 لأنها تقرب الأنصاف إلى الزوجي كما في توثيق round، وround(2.675, 2) يعطي 2.67 لأن الرقم المخزن أصغر قليلاً من 2.675.
• في Python لا يوجد فيضان للأرقام الصحيحة، فالرقم 2⁶³ طبع كاملاً، و-7 // 2 تعطي ‎-4 لأن القسمة الصحيحة تقرب إلى الأسفل بينما int(-3.5) يقطع نحو الصفر.

للتفصيل: الفيضان Overflow والأرقام العشرية Floating Point في مقال الأنظمة العددية.

// words.js: reverse the order of words, and mirror letters without breaking them
const text = "مرحباً  بكم في عرب رووت 👋🏽";

// 1) word order: split on any run of whitespace, not on a single " "
console.log(text.trim().split(/\s+/u).reverse().join(" "));

// 2) the simple letter reverse breaks marks and emoji
const word = "مرحباً👋🏽";
console.log([...word].reverse().join(""));
console.log(word.length, [...word].length);

// 3) reverse by grapheme (what the reader sees as one character)
const seg = new Intl.Segmenter("ar", { granularity: "grapheme" });
const graphemes = [...seg.segment(word)].map(s => s.segment);
console.log(graphemes.length, graphemes.reverse().join(""));

👋🏽 رووت عرب في بكم مرحباً
🏽👋ًابحرم
10 8
6 👋🏽اًبحرم

وفي Python تحتاج المكتبة regex لأن الوحدة re القياسية لا تدعم النمط \X:

# words.py: the same in Python; grapheme splitting needs the third-party regex module (\X)
import regex

text = "مرحباً  بكم في عرب رووت 👋🏽"
print(" ".join(reversed(text.split())))     # split() with no argument splits on any whitespace run

word = "مرحباً👋🏽"
print(word[::-1], len(word))
g = regex.findall(r"\X", word)
print(len(g), "".join(reversed(g)))
print([hex(ord(c)) for c in word[-4:]])

👋🏽 رووت عرب في بكم مرحباً
🏽👋ًابحرم 8
6 👋🏽اًبحرم
['0x627', '0x64b', '0x1f44b', '0x1f3fd']

والصورة التالية تبين لماذا تعطي الطرق المختلفة أطوالاً مختلفة لنفس الحرفين الأخيرين:

في الحل أعلاه لاحظ التالي:

• القسمة على مسافة واحدة split(" ") كانت ستعطي كلمة فارغة بين المسافتين، لذلك قسمنا على أي عدد من المسافات \s+، وفي Python تفعل split() دون معامل نفس الشيء.
• العكس البسيط بالحروف [...word].reverse() أو word[::-1] وضع التنوين قبل الألف فالتصق بالرمز التعبيري، وفصل لون البشرة عن اليد، والسبب أنه يعكس نقاط Unicode وليس ما يراه القارئ.
• طول الكلمة 10 في JavaScript لأن length يعد وحدات UTF-16، و8 في Python لأنها تعد نقاط Unicode، و6 بالتقسيم إلى Graphemes كما يعرفها معيار Unicode UAX #29 ويطبقها Intl.Segmenter، وهذا يهم أيضاً عندما تحدد طول اسم المستخدم أو تقطع نصاً لعرضه.

للتفصيل: مجموعة الحروف والترميز ASCII وUnicode وUTF-8 في مقال الترميز.

الخطأ الأول lo = mid: عندما يكون lo وhi متجاورين فإن mid يساوي lo ولا يتحرك شيء، فتدور الحلقة إلى الأبد. والخطأ الثاني hi = mid - 1: المجال نصف مفتوح [lo, hi) أي أن hi مستبعد أصلاً، فطرح واحد يستبعد عنصراً لم نفحصه بعد. وهذا هو الملف كاملاً مع الإصلاح والفحص الشامل:

# bsearch.py: find the bugs, then prove the fix against a brute-force answer
def find_buggy(a, x, max_steps=100):
    lo, hi = 0, len(a)
    steps = 0
    while lo < hi:
        steps += 1
        if steps > max_steps:
            return "STUCK"                    # guard added only for this kata
        mid = (lo + hi) // 2
        if a[mid] == x:
            return mid
        if a[mid] < x:
            lo = mid
        else:
            hi = mid - 1
    return -1

def find(a, x):
    lo, hi = 0, len(a)                         # half-open range [lo, hi)
    while lo < hi:
        mid = (lo + hi) // 2
        if a[mid] == x:
            return mid
        if a[mid] < x:
            lo = mid + 1                       # mid is checked, skip it
        else:
            hi = mid                           # hi is excluded already
    return -1

a = [10, 20, 30, 40, 50]
print([find_buggy(a, x) for x in (10, 20, 30, 40, 50, 35, 60)], find_buggy([10, 20], 10))
print([find(a, x) for x in (10, 20, 30, 40, 50, 35, 60)])

# exhaustive check: every array size 0..9, every target 0..20
def expected(a, x):
    return a.index(x) if x in a else -1

bad = sum(1 for n in range(10) for x in range(21)
          if find(list(range(1, 2 * n, 2)), x) != expected(list(range(1, 2 * n, 2)), x))
bad_old = sum(1 for n in range(10) for x in range(21)
          if find_buggy(list(range(1, 2 * n, 2)), x) != expected(list(range(1, 2 * n, 2)), x))
print("wrong answers: buggy", bad_old, "fixed", bad, "of", 10 * 21)

[0, 'STUCK', 2, 3, 4, -1, 'STUCK'] -1
[0, 1, 2, 3, 4, -1, -1]
wrong answers: buggy 132 fixed 0 of 210

والأسلوب الآخر الصحيح هو المجال المغلق [lo, hi] في Java، ولاحظ أن كل الحدود تتغير معاً:

// BSearch.java: closed range [lo, hi], the other correct style
public class BSearch {
    static int find(int[] a, int x) {
        int lo = 0, hi = a.length - 1;
        while (lo <= hi) {
            int mid = (lo + hi) >>> 1;          // no overflow on huge arrays
            if (a[mid] == x) return mid;
            if (a[mid] < x) lo = mid + 1; else hi = mid - 1;
        }
        return -1;
    }

    public static void main(String[] args) {
        int[] a = {10, 20, 30, 40, 50};
        StringBuilder sb = new StringBuilder();
        for (int x : new int[] {10, 20, 30, 40, 50, 35, 60}) sb.append(find(a, x)).append(' ');
        System.out.println(sb.toString().trim());
        System.out.println(java.util.Arrays.binarySearch(a, 35));   // -(insertion point) - 1
    }
}

0 1 2 3 4 -1 -1
-4

في الحل أعلاه لاحظ التالي:

• الحماية max_steps أضفناها لهذا التمرين فقط حتى تطبع الدالة STUCK بدلاً من أن يتوقف البرنامج، فالبحث عن 20 و60 دار إلى الأبد، والبحث عن 10 في [10, 20] أعاد ‎-1 مع أن الرقم موجود.
• الإثبات لم يكن بأمثلة نختارها نحن، وإنما بمقارنة الدالة بالجواب البديهي a.index(x) على كل المصفوفات حتى تسعة عناصر وكل الأهداف من 0 إلى 20، فأخطأت الدالة القديمة في 132 حالة من 210، والجديدة في صفر، وهذه الفكرة هي أساس الاختبار بالخصائص Property-Based Testing.
• Arrays.binarySearch في Java يعيد ‎-4 للرقم 35 وليس ‎-1، لأنه يعيد ‎-(موقع الإدخال) ‎-1 كما في التوثيق، فلا تقارن نتيجته بالرقم ‎-1.

للتفصيل: البحث الثنائي Binary Search في مقال Big-O، وفيه قصة خطأ (low + high) / 2 في مكتبة Java.

في Python نحول إلى المنطقة الزمنية قبل أخذ التاريخ، وعلى Windows تحتاج الحزمة tzdata لأن النظام لا يوفر قاعدة المناطق التي تقرأ منها الوحدة zoneinfo:

# tz.py: orders are stored in UTC (correct); the report groups them by day (the bug)
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo
from collections import Counter

RIYADH = ZoneInfo("Asia/Riyadh")
orders = [  # created_at in UTC, as the database returns it
    datetime(2026, 10, 6, 20, 59, tzinfo=timezone.utc),
    datetime(2026, 10, 6, 21, 0, tzinfo=timezone.utc),
    datetime(2026, 10, 6, 22, 30, tzinfo=timezone.utc),
    datetime(2026, 10, 7, 9, 15, tzinfo=timezone.utc),
]

print("buggy:", dict(Counter(o.date().isoformat() for o in orders)))
print("fixed:", dict(Counter(o.astimezone(RIYADH).date().isoformat() for o in orders)))
print(orders[2].astimezone(RIYADH).isoformat())

# part 2: "remind me every day at 09:00 Berlin time", computed by adding 24 hours in UTC
BERLIN = ZoneInfo("Europe/Berlin")
first = datetime(2026, 10, 24, 9, 0, tzinfo=BERLIN)
utc = first.astimezone(timezone.utc)
for i in range(3):
    buggy = (utc + timedelta(days=i)).astimezone(BERLIN)
    fixed = (first + timedelta(days=i))                 # wall-clock arithmetic in the zone
    print(f"day {i}: buggy {buggy:%a %H:%M %Z}   fixed {fixed:%a %H:%M %Z}")

buggy: {'2026-10-06': 3, '2026-10-07': 1}
fixed: {'2026-10-06': 1, '2026-10-07': 3}
2026-10-07T01:30:00+03:00
day 0: buggy Sat 09:00 CEST   fixed Sat 09:00 CEST
day 1: buggy Sun 08:00 CET   fixed Sun 09:00 CET
day 2: buggy Mon 08:00 CET   fixed Mon 09:00 CET

وفي JavaScript نستخدم Intl.DateTimeFormat مع المنطقة، والإعداد en-CA يعطي التاريخ بالشكل YYYY-MM-DD:

// tz.js: the report day in the customer's zone with Intl
const orders = ["2026-10-06T20:59:00Z", "2026-10-06T21:00:00Z", "2026-10-06T22:30:00Z", "2026-10-07T09:15:00Z"];
const day = new Intl.DateTimeFormat("en-CA", { timeZone: "Asia/Riyadh", year: "numeric", month: "2-digit", day: "2-digit" });

const buggy = {}, fixed = {};
for (const o of orders) {
  const d = new Date(o);
  const utcDay = d.toISOString().slice(0, 10);
  buggy[utcDay] = (buggy[utcDay] ?? 0) + 1;
  const local = day.format(d);                      // en-CA gives YYYY-MM-DD
  fixed[local] = (fixed[local] ?? 0) + 1;
}
console.log("buggy:", buggy);
console.log("fixed:", fixed);

buggy: { '2026-10-06': 3, '2026-10-07': 1 }
fixed: { '2026-10-06': 1, '2026-10-07': 3 }

في الحل أعلاه لاحظ التالي:

• الطلب في 20:59 UTC هو 23:59 في الرياض يوم 6، والطلب بعده بدقيقة هو منتصف الليل يوم 7، لذلك الجواب الصحيح طلب واحد يوم 6 وثلاثة يوم 7، والتقرير الخاطئ عكس الرقمين تقريباً.
• التخزين بتوقيت UTC لم يكن الخطأ، وإنما أخذ التاريخ دون تحويل، فالقاعدة أن تحفظ UTC وتحول عند الأطراف، وحدود اليوم في التقرير طرف من الأطراف.
• في الجزء الثاني انتهى التوقيت الصيفي في أوروبا يوم الأحد 25 أكتوبر 2026 حسب التوجيه الأوروبي 2000/84/EC الذي يحدده بآخر أحد من أكتوبر، فإضافة 24 ساعة بتوقيت UTC أوصلت التذكير في 08:00، أما الإضافة على الوقت المحلي في المنطقة نفسها فأبقته في 09:00.

للتفصيل: احفظ UTC وحول عند الأطراف والتوقيت الصيفي في مقال التاريخ والوقت.

الاختبارات أولاً بالوحدة unittest المدمجة في Python، واستخدمنا subTest حتى يظهر كل مدخل مرفوض كحالة مستقلة:

# test_duration.py: written BEFORE duration.py has any code
import unittest
from duration import parse_duration

class ParseDuration(unittest.TestCase):
    def test_single_units(self):
        self.assertEqual(parse_duration("90s"), 90)
        self.assertEqual(parse_duration("2m"), 120)
        self.assertEqual(parse_duration("2h"), 7200)

    def test_combined_in_order(self):
        self.assertEqual(parse_duration("1h30m"), 5400)
        self.assertEqual(parse_duration("1h0m5s"), 3605)

    def test_spaces_around_are_ignored(self):
        self.assertEqual(parse_duration(" 15m "), 900)

    def test_rejects_bad_input(self):
        for bad in ["", "h", "10", "1m1h", "1h1h", "1.5h", "-5m", "5 m", "5d"]:
            with self.subTest(bad=bad):
                with self.assertRaises(ValueError):
                    parse_duration(bad)

if __name__ == "__main__":
    unittest.main()

ثم ملف الدالة فيه سطر واحد يرمي NotImplementedError، والتشغيل يفشل كما يجب، وهذا أول المخرج وآخره:

python -m unittest test_duration

EEEEEEEEEEEE
----------------------------------------------------------------------
Ran 4 tests in 0.012s

FAILED (errors=12)

والعدد 12 هو ثلاثة اختبارات وتسعة مدخلات مرفوضة، كل واحد منها حالة مستقلة. بعد ذلك نكتب الدالة:

# duration.py: written after the tests, only enough code to make them pass
import re

PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text):
    m = PATTERN.fullmatch(text.strip())
    if not m or not any(m.groups()):
        raise ValueError(f"bad duration: {text!r}")
    h, mnt, s = (int(g) if g else 0 for g in m.groups())
    return h * 3600 + mnt * 60 + s

python -m unittest -v test_duration

test_combined_in_order (test_duration.ParseDuration.test_combined_in_order) ... ok
test_rejects_bad_input (test_duration.ParseDuration.test_rejects_bad_input) ... ok
test_single_units (test_duration.ParseDuration.test_single_units) ... ok
test_spaces_around_are_ignored (test_duration.ParseDuration.test_spaces_around_are_ignored) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.001s

OK

ونفس المواصفات في JavaScript بالوحدة المدمجة node:test دون أي مكتبة خارجية:

// duration.test.mjs: the same spec with node:test (built into Node.js)
import { test } from "node:test";
import assert from "node:assert/strict";

const parseDuration = (text) => {
  const m = /^(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?$/.exec(text.trim());
  if (!m || !m.slice(1).some(Boolean)) throw new RangeError(`bad duration: ${text}`);
  const [h = 0, mn = 0, s = 0] = m.slice(1).map(g => Number(g ?? 0));
  return h * 3600 + mn * 60 + s;
};

test("units and combinations", () => {
  assert.equal(parseDuration("90s"), 90);
  assert.equal(parseDuration("1h30m"), 5400);
  assert.equal(parseDuration(" 15m "), 900);
});
test("rejects bad input", () => {
  for (const bad of ["", "h", "10", "1m1h", "1.5h", "-5m", "5 m", "5d"])
    assert.throws(() => parseDuration(bad), RangeError, bad);
});

node --test duration.test.mjs

1..2
# tests 2
# suites 0
# pass 2
# fail 0
# cancelled 0
# skipped 0
# todo 0
# duration_ms 557.1408

في الحل أعلاه لاحظ التالي:

• رؤية الاختبار يفشل أولاً تثبت أنه يختبر شيئاً، فالاختبار الذي ينجح قبل كتابة الكود قد يكون لا يستدعي الدالة أصلاً.
• كل الأقسام في التعبير النمطي Regex اختيارية، فالنص الفارغ يطابقه، لذلك أضفنا الشرط any(m.groups())، وهذا السطر لم نكن لنتذكره لولا وجود "" في قائمة المرفوضات.
• fullmatch وليس match، لأن match يقبل 1h1h بمطابقة أول جزء وتجاهل الباقي.

للتفصيل: اختبار الوحدة Unit Test في مقال أنواع الاختبارات.

بدلاً من قياس الزمن، وهو يتأثر بالجهاز، نعد الخطوات نفسها ونقارن العدد عندما تتضاعف n، وهذا هو الملف كاملاً:

// ops.js: count the steps of each snippet when n doubles (counting, not timing, so the numbers are exact)
let ops = 0;
const A = (n) => { for (let i = 0; i < n; i++) for (let j = i + 1; j < n; j++) ops++; };
const B = (n) => { for (let i = 1; i < n; i *= 2) ops++; };
const C = (n) => { const seen = []; for (let i = 0; i < n; i++) { for (const s of seen) { ops++; if (s === -1) break; } seen.push(i); } };
const D = (n) => { const a = Array.from({ length: n }, (_, i) => (i * 7919) % n); a.sort((x, y) => { ops++; return x - y; }); };
const E = (n) => { for (let i = 0; i < n; i++) for (let j = 0; j < 3; j++) ops++; };
const F = (n) => { const fib = (k) => { ops++; return k < 2 ? k : fib(k - 1) + fib(k - 2); }; fib(n); };

const run = (name, f, sizes) => {
  const row = sizes.map(n => { ops = 0; f(n); return ops; });
  const ratio = (row.at(-1) / row.at(-2)).toFixed(2);
  console.log(`${name}  ${sizes.map((n, i) => `n=${n}: ${row[i].toLocaleString("en")}`).join("  ")}  last ratio ${ratio}`);
};
run("A", A, [1000, 2000, 4000]);
run("B", B, [1000, 2000, 4000]);
run("C", C, [1000, 2000, 4000]);
run("D", D, [1000, 2000, 4000]);
run("E", E, [1000, 2000, 4000]);
run("F", F, [20, 21, 22]);

A  n=1000: 499,500  n=2000: 1,999,000  n=4000: 7,998,000  last ratio 4.00
B  n=1000: 10  n=2000: 11  n=4000: 12  last ratio 1.09
C  n=1000: 499,500  n=2000: 1,999,000  n=4000: 7,998,000  last ratio 4.00
D  n=1000: 8,525  n=2000: 18,586  n=4000: 38,343  last ratio 2.06
E  n=1000: 3,000  n=2000: 6,000  n=4000: 12,000  last ratio 2.00
F  n=20: 21,891  n=21: 35,421  n=22: 57,313  last ratio 1.62

والإجابات:

في المخرج أعلاه لاحظ التالي:

• A وC أعطتا نفس العدد بالضبط مع أن C تبدو حلقة واحدة، وهذا أهم درس في التمرين: الدالة الجاهزة داخل الحلقة لها تكلفة يجب أن تعرفها.
• في F زدنا n بواحد فقط وليس بالمضاعفة، والنسبة 1.62 هي النسبة الذهبية تقريباً، لذلك التعقيد الدقيق O(φⁿ)، وهو أقل من 2ⁿ ولكنه أسي، وإضافة عشرة إلى n تضرب العمل في أكثر من مئة.

للتفصيل: ترميز Big-O والاستدعاء الذاتي والحفظ Memoization.

# merge.py: busy slots of a meeting room in minutes from midnight, merged
def merge(slots):
    out = []
    for start, end in sorted(slots):                  # sort by start: O(n log n)
        if out and start <= out[-1][1]:               # overlaps or touches the last one
            out[-1][1] = max(out[-1][1], end)         # max: the new slot may be inside the old one
        else:
            out.append([start, end])
    return out

slots = [(800, 810), (540, 600), (570, 660), (720, 730), (700, 720), (590, 600)]
print(merge(slots))
fmt = lambda m: f"{m // 60:02}:{m % 60:02}"
print([f"{fmt(s)}-{fmt(e)}" for s, e in merge(slots)])

[[540, 660], [700, 730], [800, 810]]
['09:00-11:00', '11:40-12:10', '13:20-13:30']

// merge.cs: the same merge in C#
var slots = new List<(int Start, int End)> { (800, 810), (540, 600), (570, 660), (720, 730), (700, 720), (590, 600) };

var merged = new List<(int Start, int End)>();
foreach (var s in slots.OrderBy(s => s.Start))
{
    if (merged.Count > 0 && s.Start <= merged[^1].End)
        merged[^1] = (merged[^1].Start, Math.Max(merged[^1].End, s.End));
    else
        merged.Add(s);
}
Console.WriteLine(string.Join(" ", merged.Select(m => $"[{m.Start},{m.End}]")));

[540,660] [700,730] [800,810]

في الحل أعلاه لاحظ التالي:

• الفترة (590, 600) تقع داخل (540, 660) بعد الدمج، ولو كتبت out[-1][1] = end بدلاً من max لقصرت الفترة المشغولة إلى 10:00 وظهرت الغرفة فارغة وهي محجوزة.
• الشرط start <= end بالمساواة هو ما دمج (700, 720) مع (720, 730)، والمواصفات هي التي تحدد هل المتلاصقتان واحدة، فاقرأها قبل أن تختار بين < و<=.
• التكلفة O(n log n) بسبب الترتيب، والمرور بعده O(n).

للتفصيل: الترتيب الجاهز Built-in Sort في اللغات.

في Python الكلاس OrderedDict هو جدول هاش مع قائمة مزدوجة، وفيه move_to_end وpopitem(last=False):

# lru.py: get and put in O(1); OrderedDict is a hash table plus a doubly linked list
from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.data = OrderedDict()

    def get(self, key):
        if key not in self.data:
            return None
        self.data.move_to_end(key)                 # just used: move to the "newest" end
        return self.data[key]

    def put(self, key, value):
        self.data[key] = value
        self.data.move_to_end(key)
        if len(self.data) > self.capacity:
            self.data.popitem(last=False)          # drop the oldest

c = LRUCache(2)
c.put("a", 1); c.put("b", 2)
print(c.get("a"))          # a becomes the newest
c.put("c", 3)              # evicts b, not a
print(c.get("b"), c.get("a"), c.get("c"), list(c.data))

1
None 1 3 ['a', 'c']

وفي Java يكفي LinkedHashMap بترتيب الوصول Access Order مع removeEldestEntry:

// Lru.java: LinkedHashMap in access order already is an LRU
import java.util.LinkedHashMap;
import java.util.Map;

public class Lru {
    static class LRUCache<K, V> extends LinkedHashMap<K, V> {
        private final int capacity;
        LRUCache(int capacity) { super(16, 0.75f, true); this.capacity = capacity; }   // true = access order
        @Override protected boolean removeEldestEntry(Map.Entry<K, V> eldest) { return size() > capacity; }
    }

    public static void main(String[] args) {
        LRUCache<String, Integer> c = new LRUCache<>(2);
        c.put("a", 1); c.put("b", 2);
        System.out.println(c.get("a"));
        c.put("c", 3);
        System.out.println(c.get("b") + " " + c.get("a") + " " + c.get("c") + " " + c.keySet());
    }
}

1
null 1 3 [a, c]

وفي JavaScript يحفظ Map ترتيب الإضافة، فالحذف ثم الإضافة ينقل المفتاح إلى النهاية، وسوف نستخدم هذا الملف في التمرين 17:

// lru.js: a Map keeps insertion order, so delete + set moves a key to the newest end
class LRUCache {
  constructor(capacity) { this.capacity = capacity; this.map = new Map(); }
  get(key) {
    if (!this.map.has(key)) return undefined;
    const v = this.map.get(key);
    this.map.delete(key); this.map.set(key, v);
    return v;
  }
  set(key, value) {
    this.map.delete(key); this.map.set(key, value);
    if (this.map.size > this.capacity) this.map.delete(this.map.keys().next().value);   // oldest
  }
}
module.exports = { LRUCache };
if (require.main === module) {
  const c = new LRUCache(2);
  c.set("a", 1); c.set("b", 2);
  console.log(c.get("a"));
  c.set("c", 3);
  console.log(c.get("b"), c.get("a"), c.get("c"), [...c.map.keys()]);
}

1
undefined 1 3 [ 'a', 'c' ]

في الحل أعلاه لاحظ التالي:

• السطر get(a) جعل a الأحدث، فلما أضفنا c حذف b وليس a، ومن توقع حذف a فقد بنى ذاكرة FIFO وليس LRU.
• الحل البسيط بقائمة عادية يبحث عن المفتاح لينقله، وهذا O(n) في كل get، وهو ما يمنعه شرط O(1).
• في Java المعامل الثالث true في المنشئ Constructor هو ما يحول الترتيب من ترتيب الإضافة إلى ترتيب الوصول، ونسيانه يعطي FIFO بصمت.

للتفصيل: القائمة المترابطة Linked List وجدول الهاش في مقال هياكل البيانات.

شغلنا ملف C# ثلاث مرات على جهاز بثماني نوى:

dotnet run race.cs

count++ 998,722   Interlocked 1,000,000   lock 1,000,000   cores 8
count++ 1,000,000   Interlocked 1,000,000   lock 1,000,000   cores 8
count++ 999,704   Interlocked 1,000,000   lock 1,000,000   cores 8

والصورة التالية تبين كيف تضيع الزيادة:

وهذا ملف JavaScript كاملاً مع الإصلاح:

// race.js: one thread, and still a race: check, then await, then write
let balance = 100;
const sleep = (ms) => new Promise(r => setTimeout(r, ms));

async function withdraw(amount) {
  if (balance >= amount) {          // check
    await sleep(10);                // e.g. a call to the payment service or the database
    balance -= amount;              // act on a value that may be stale now
    return "ok";
  }
  return "rejected";
}

// fix: make check and act one step that nothing can interleave with
let queue = Promise.resolve();
function withdrawSafe(amount) {
  const run = queue.then(() => withdraw(amount));
  queue = run.catch(() => {});
  return run;
}

(async () => {
  console.log(await Promise.all([withdraw(80), withdraw(80)]), "balance", balance);
  balance = 100;
  console.log(await Promise.all([withdrawSafe(80), withdrawSafe(80)]), "balance", balance);
})();

[ 'ok', 'ok' ] balance -60
[ 'ok', 'rejected' ] balance 20

في الحل أعلاه لاحظ التالي:

• المخرج الثاني في C# كان مليوناً كاملاً بالصدفة، وهذا أخطر ما في حالة السباق، فالاختبار ينجح مرة ويفشل مرة، ومن يشغله مرة واحدة يظن أن الكود سليم. والحل Interlocked.Increment للعداد البسيط أو lock لما هو أكبر منه.
• في JavaScript نجح السحبان وأصبح الرصيد ‎-60، مع أنه لا يوجد إلا خيط واحد، والسبب أن التحقق والتنفيذ Check-then-Act بينهما await، وهذا نفس نمط ثغرة TOCTOU.
• الطابور في withdrawSafe يكفي داخل عملية واحدة فقط، فإذا كان التطبيق يعمل على أكثر من سيرفر فالحل أن يكون التحقق والخصم جملة واحدة في قاعدة البيانات، مثل UPDATE accounts SET balance = balance - 80 WHERE id = 1 AND balance >= 80 ثم فحص عدد الصفوف التي تغيرت.

للتفصيل: الخيوط المتعددة Multithreading وحلقة الأحداث Event Loop في مقال المعالج والتزامن، وثغرات TOCTOU في مقال البرمجة الآمنة.

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

# order_new.py: same behaviour, one job per function, rules as data
VAT = {"SA": 0.15, "AE": 0.05}
SHIPPING = {"SA": 25}
DEFAULT_SHIPPING, FREE_SHIPPING_FROM = 60, 300

def validate(items):
    if not items:
        return "empty order"
    for it in items:
        if it["qty"] <= 0:
            return "bad qty for " + it["sku"]
    return None

def subtotal(items):
    return sum(it["price"] * it["qty"] for it in items)

def apply_coupon(total, coupon):
    if coupon == "WELCOME10":
        return total - total * 10 / 100
    if coupon == "FLAT50" and total >= 200:
        return total - 50
    return total

def add_vat(total, country):
    return total + total * VAT.get(country, 0)

def add_shipping(total, country):
    if total >= FREE_SHIPPING_FROM:
        return total
    return total + SHIPPING.get(country, DEFAULT_SHIPPING)

def process_order(order):
    error = validate(order.get("items"))
    if error:
        return "ERROR: " + error
    total = subtotal(order["items"])
    total = apply_coupon(total, order.get("coupon"))
    total = add_vat(total, order["country"])
    total = add_shipping(total, order["country"])
    return "TOTAL: " + str(round(total, 2))

واختبار التوصيف يولد 2402 طلباً بكل تركيبات الدول والقسائم، مع بذرة ثابتة Seed حتى يتكرر نفس الاختبار:

# golden.py: characterization test, the old and new functions must agree on many orders
import itertools, random
import order_old, order_new

random.seed(7)
cases = [{"items": []}, {"items": [{"sku": "x", "price": 10, "qty": 0}], "country": "SA"}]
for country, coupon in itertools.product(["SA", "AE", "EG"], [None, "WELCOME10", "FLAT50", "BAD"]):
    for _ in range(200):
        items = [{"sku": f"s{i}", "price": random.choice([5, 19.99, 49.5, 120, 250]), "qty": random.randint(1, 4)}
                 for i in range(random.randint(1, 3))]
        cases.append({"items": items, "country": country, "coupon": coupon})

diff = [c for c in cases if order_old.process_order(c) != order_new.process_order(c)]
print(len(cases), "orders,", len(diff), "different")
print(order_new.process_order(cases[5]), "|", order_old.process_order(cases[5]))

2402 orders, 0 different
TOTAL: 59.5 | TOTAL: 59.5

ثم كسرنا الكود عمداً لنتأكد أن الاختبار يرى الخطأ، فبدلنا سطري الخصم والضريبة في نسخة مؤقتة، وكانت النتيجة:

2402 orders, 253 different

في الحل أعلاه لاحظ التالي:

• تبديل الخطوتين غير النتيجة في قسيمة FLAT50 فقط، لأن الضريبة قد ترفع المجموع فوق 200 فيطبق الخصم، أما الخصم بالنسبة WELCOME10 فلا يتأثر بالترتيب، وهذا خطأ لا تراه العين في المراجعة ورآه الاختبار في 253 طلباً.
• الحالة {"items": []} دون دولة بقيت تعمل لأن التحقق يأتي قبل قراءة order["country"]، وهو سلوك قديم يجب أن يبقى حتى لو بدا غريباً.
• اختبار التوصيف يثبت أن السلوك لم يتغير ولا يثبت أنه صحيح، فبعد أن تنتهي حوله إلى اختبارات وحدة لكل دالة صغيرة.

للتفصيل: اختبار الانحدار Regression Test في مقال أنواع الاختبارات.

# topk.py: the 3 most requested paths; equal counts are ordered by path so the answer never changes
import heapq
from collections import Counter

counts = Counter(line.split()[1] for line in open("access.log"))
print(counts.most_common(3))                                   # ties keep first-seen order
print(heapq.nsmallest(3, counts.items(), key=lambda kv: (-kv[1], kv[0])))   # O(n log k)

[('/login', 4), ('/api/orders', 3), ('/health', 3)]
[('/login', 4), ('/api/orders', 3), ('/api/users', 3)]

والحل في Java بكومة يدوية من PriorityQueue:

// TopK.java: a min-heap of size k keeps only the best k while reading
import java.nio.file.*;
import java.util.*;

public class TopK {
    public static void main(String[] args) throws Exception {
        Map<String, Integer> counts = new HashMap<>();
        for (String line : Files.readAllLines(Path.of(args[0])))
            counts.merge(line.split(" ")[1], 1, Integer::sum);

        int k = 3;
        // the "worst" of the kept k sits on top: smaller count first, then the larger path
        Comparator<Map.Entry<String, Integer>> worstFirst =
            Map.Entry.<String, Integer>comparingByValue().thenComparing(Map.Entry.comparingByKey(Comparator.reverseOrder()));
        PriorityQueue<Map.Entry<String, Integer>> heap = new PriorityQueue<>(worstFirst);
        for (var e : counts.entrySet()) {
            heap.offer(e);
            if (heap.size() > k) heap.poll();          // drop the worst, the heap never grows past k
        }
        List<Map.Entry<String, Integer>> top = new ArrayList<>(heap);
        top.sort(worstFirst.reversed());
        System.out.println(top);
    }
}

java TopK.java access.log

[/login=4, /api/orders=3, /api/users=3]

في الحل أعلاه لاحظ التالي:

• ثلاثة مسارات لها 3 طلبات، وmost_common اختار /health لأنه ظهر قبل /api/users في السجل، وهذا موثق في توثيق Counter، فالجواب يتغير إذا تغير ترتيب السجل، ولذلك أضفنا المسار نفسه إلى مفتاح الترتيب.
• في Java الكومة ترتب «الأسوأ أولاً»: العدد الأقل، ثم عند التساوي المسار الأكبر أبجدياً، لأنه الأولى بالخروج، وهذا عكس ما تتوقعه في المرة الأولى، فإذا أخطأت في الاتجاه سوف يخرج الأفضل ويبقى الأسوأ.
• مع مليون مسار وk = 10 تبقى الكومة بحجم عشرة عناصر في الذاكرة، والدالة heapq.nsmallest تفعل نفس الشيء من الداخل.

للتفصيل: الكومة Heap وطابور الأولوية Priority Queue.

شغلنا نفس الدالة مرة مع Map ومرة مع ذاكرة LRU من التمرين 13 بسعة عشرة آلاف، مع تشغيل جامع القمامة قبل كل قياس حتى لا نقيس ما ينتظر الحذف:

// leak.js: a "cache" that only grows, then the same cache with a limit
//   node --expose-gc leak.js map      node --expose-gc leak.js lru
const { LRUCache } = require("./lru.js");
const cache = process.argv[2] === "lru" ? new LRUCache(10_000) : new Map();

function getProfile(userId) {
  let v = cache.get(userId);
  if (v === undefined) {
    v = { id: userId, profile: "x".repeat(1024) };   // as if loaded from the database
    cache.set(userId, v);
  }
  return v;
}

for (let round = 1; round <= 3; round++) {
  for (let i = 0; i < 100_000; i++) getProfile(`user-${(round - 1) * 100_000 + i}`);   // new users keep arriving
  global.gc();
  const mb = (process.memoryUsage().heapUsed / 1048576).toFixed(1);
  const size = cache.size ?? cache.map.size;
  console.log(`${process.argv[2]} after ${round * 100}k requests: heapUsed ${mb} MB, entries ${size.toLocaleString("en")}`);
}

node --expose-gc leak.js map
node --expose-gc leak.js lru

map after 100k requests: heapUsed 37.5 MB, entries 100,000
map after 200k requests: heapUsed 71.7 MB, entries 200,000
map after 300k requests: heapUsed 109.2 MB, entries 300,000
lru after 100k requests: heapUsed 7.4 MB, entries 10,000
lru after 200k requests: heapUsed 7.6 MB, entries 10,000
lru after 300k requests: heapUsed 7.6 MB, entries 10,000

في الحل أعلاه لاحظ التالي:

• كل مئة ألف مستخدم جديد أضافت نحو 35 MB لا تخرج أبداً، والسبب أن ال Map نفسها متغير عام يعيش طوال عمر العملية، وهي تشير إلى كل الكائنات، فلا يستطيع جامع القمامة حذف أي منها، فهو لا يعرف أنك لن تحتاجها.
• مع LRU بقي عدد العناصر عشرة آلاف وبقيت الذاكرة نحو 7.6 MB بعد 300 ألف طلب، والثمن أن المستخدم القديم الذي يعود سوف يقرأ من قاعدة البيانات مرة أخرى، وهذا مقبول.
• كل ذاكرة مؤقتة تحتاج حداً أعلى للحجم أو مدة صلاحية TTL، وإلا فهي تسرب ذاكرة بطيء، والأرقام هنا توضيحية على جهاز واحد.

للتفصيل: تسرب الذاكرة Memory Leak في لغة فيها جامع قمامة.