يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.
خلوني أحكي لكم قصة صارت معي زمان، في بداية مشواري المهني. كنت وقتها شب متحمس، شايف حالي “إشي فخم” في البرمجة، وأي تحدي برمجي بيجيني كنت أفرمه فرم. قدمت على وظيفة في شركة كبيرة، وبعد المقابلة الأولى، بعتولي مهمة برمجية (Coding Task). المهمة كانت واضحة: اعمل تطبيق صغير بخصائص معينة.
قعدت عليها يومين، ما نمت الليل زي الناس. طلعت بكود، يا الله شو مرتب! نظيف، سريع، وبيعمل كل المطلوب وأكتر بشوي. سلمت الشغل وأنا كلي ثقة، بستنى في إيميل المقابلة الثانية أو عرض العمل مباشرةً. مر يوم، يومين، أسبوع… ولا حس ولا خبر. صابني إحباط مش طبيعي. شو القصة؟ الكود كان مثالي! بعتت إيميل متابعة، وردوا علي برد جاف ومختصر: “شكرًا لاهتمامك، نتمنى لك التوفيق في المستقبل”.
بقيت شهور وأنا أفكر، وين الغلط؟ لحد ما في يوم، بالصدفة، قابلت واحد من المبرمجين اللي بيشتغلوا في نفس الشركة. حكيتله القصة، ضحك وقلي: “يا أبو عمر، إحنا بيوصلنا عشرات الحلول المثالية. المشكلة مش في الكود، المشكلة إنه ما فهمنا ليش عملت اللي عملته. ليش اخترت هالمكتبة؟ ليش هالتصميم؟ ليش ما عملت تست؟ كودك كان صندوق أسود بالنسبة إلنا”.
هذيك الكلمة، “صندوق أسود”، رنت في راسي. من يومها، تغيرت نظرتي للمهام البرمجية 180 درجة. ما عادت مجرد كود، صارت فرصة لأحكي قصة. وهذا اللي بدي أحكيلكم إياه اليوم: كيف تحولوا مهمتكم البرمجية من “صندوق أسود” إلى “كتاب مفتوح” يخلي الشركة تتصل فيك قبل ما حتى تخلص قراءة.
لماذا الكود وحده لا يكفي؟
خلينا نكون عمليين. لما شركة تبعتلك مهمة، هي ما بتختبر قدرتك على كتابة الكود بس. هذا إشي مفروغ منه. هي بتختبر مجموعة أشياء تانية أهم:
- طريقة تفكيرك: كيف بتحلل المشكلة؟ كيف بتقسمها لأجزاء صغيرة؟
- مهارات التواصل: هل بتقدر تشرح قراراتك التقنية لشخص آخر؟
- الاحترافية: هل بتتعامل مع مهمة صغيرة بنفس الجدية اللي بتتعامل فيها مع مشروع كبير؟
- الوعي بالخيارات المتاحة (Trade-offs): هل بتفهم إنه ما في حل مثالي واحد، وكل قرار إله إيجابيات وسلبيات؟
لما تسلم مجلد فيه بس ملفات الكود، أنت بتضيع فرصة ذهبية لإظهار كل هالجوانب. المراجع (Reviewer) اللي بيشوف الكود ما بيعرفك، ما بيعرف خبرتك، وما عنده وقت يفك شيفرة نواياك. هو بيشوف كود، ويمكن ما يعجبه قرار معين، فيحكم عليك بالفشل بدون ما يعطيك فرصة للدفاع عن نفسك.
الحل السحري: وثيقة القرارات المعمارية (ADR) المصغّرة
الحل بسيط لدرجة ممكن تستغربها: ملف `README.md` قوي ومفصل. لا تستهين بهذا الملف أبداً! أنا بسميه “المحامي تبع الكود”. هو اللي بدافع عن شغلك لما أنت ما تكون موجود.
الفكرة إنك توثق كل قرار مهم أخذته أثناء عملك على المهمة. في عالم هندسة البرمجيات، هذا إشي بنسميه “Architecture Decision Record” أو ADR، لكن إحنا رح نعمل نسخة مبسطة منه مناسبة للمهمة البرمجية.
شو لازم أكتب في ملف الـ README؟
تخيل إنك قاعد بتشرح شغلك لزميلك في الفريق. شو بتحكيله؟ هذا بالزبط اللي لازم تكتبه. قسم الملف لعناوين واضحة:
1. فهمي للمتطلبات (Understanding the Requirements)
ابدأ بجملة أو جملتين بتلخص فيهم فهمك للمطلوب. هذا بيثبت إنك قرأت المطلوب بعناية وفهمته صح.
مثال: “المطلوب هو بناء تطبيق ويب بسيط لعرض قائمة مهام (To-Do List) مع إمكانية إضافة مهمة جديدة وحذفها. يجب أن يتم حفظ البيانات في المتصفح.”
2. الافتراضات التي قمت بها (Assumptions Made)
هذا القسم من أهم الأقسام. ما في مهمة بتكون كاملة 100%. دايماً في شغلات مش واضحة. بدل ما تخمن وتشتغل، أو تضل تسأل، ممكن تعمل افتراضات منطقية وتوثقها.
مثال: “لم يتم تحديد طريقة حفظ البيانات، لذا افترضت أن استخدام `localStorage` في المتصفح هو الحل الأنسب لهذه المهمة البسيطة لسهولته وعدم الحاجة لإعداد قاعدة بيانات.”
3. القرارات التقنية والهندسية (Tech Stack & Architectural Decisions)
هنا قلب الموضوع كله. ليش اخترت React مش Vue؟ ليش استخدمت Redux (أو ليش ما استخدمتها)؟ ليش قسمت الملفات بهالطريقة؟
- التقنيات المستخدمة: اذكر المكتبات والأدوات اللي استخدمتها مع سبب بسيط لاختيار كل وحدة.
- بنية المشروع: اشرح كيف نظمت ملفاتك. مثلاً: “اتبعت بنية (Feature-based) حيث كل مجلد يحتوي على كل ما يخص ميزة معينة (الكود، الستايل، الاختبارات) لزيادة سهولة الصيانة والتطوير مستقبلاً”.
- القرارات المهمة: أي قرار حسيت إنه ممكن يكون محط جدل، اشرحه هنا.
4. المقايضات (Trade-offs)
هذا القسم اللي بيميز المبرمج الخبير عن المبتدئ. أظهر إنك فاهم إنه ما في شي ببلاش. كل اختيار له ثمن.
مثال: “كنت أستطيع استخدام Redux لإدارة الحالة (State Management)، ولكني قررت استخدام React Context API لأن التطبيق بسيط ولا يستدعي التعقيد الإضافي الذي يأتي مع Redux. هذا القرار يوازن بين قابلية التوسع المستقبلية والبساطة الحالية.”
5. كيفية تشغيل المشروع واختباره (How to Run and Test)
لا تفترض إنهم بيعرفوا! اكتب خطوات واضحة وبسيطة لتشغيل المشروع على جهازهم. إذا كتبت أي اختبارات (Unit Tests)، اذكر كيف يتم تشغيلها.
# 1. Clone the repository
git clone [your-repo-link]
# 2. Install dependencies
npm install
# 3. Run the development server
npm start
# 4. To run tests
npm test
6. تحسينات مستقبلية (Future Improvements)
هذا بيعطي انطباع إنك بتفكر للمستقبل. اذكر شغلات كنت حابب تعملها لو كان عندك وقت أكتر.
مثال: “لو كان لدي المزيد من الوقت، كنت سأقوم بالتالي:
- إضافة اختبارات تكاملية (Integration Tests) للتأكد من عمل التطبيق ككل.
- تحسين واجهة المستخدم وإضافة حركات (Animations).
- تحويل `localStorage` إلى حل حقيقي باستخدام قاعدة بيانات مثل Firebase.”
نصيحة من أبو عمر
الحكي بينا، لما أكون أنا اللي براجع مهمة برمجية لمرشح، أول إشي بفتحه هو ملف الـ `README.md`. إذا كان فارغ أو فيه بس سطرين، نفسيتي بتتسد من الشغل كله. لكن لما أشوف ملف مفصل ومنظم، حتى لو الكود فيه أخطاء بسيطة، بعرف إني بتعامل مع شخص محترف، بيفكر وبيعرف يتواصل. هذا الشخص اللي بدي إياه في فريقي.
لا تخاف تكتب. لا تحكي “ما هو إشي واضح”. اللي واضح إلك، مش واضح لغيرك. مهمتك مش بس تسليم كود يعمل، مهمتك تبدأ حوار تقني مع الشركة، وملف التوثيق هذا هو أول جملة في الحوار.
الخلاصة 💡
في المرة القادمة اللي تجيك فيها مهمة برمجية، تذكر قصة أبو عمر. لا تسلم الكود صامتاً، خليه يحكي قصتك. استثمر ساعة إضافية في كتابة ملف `README.md` واضح ومفصل، وصدقني، هذه الساعة قد تكون أفضل استثمار عملته في عملية بحثك عن وظيفة.
الكود يخبر “ماذا” فعلت، أما التوثيق فيخبر “لماذا” و “كيف” فكرت. والشركات المحترمة تبحث عن العقول المفكرة، وليس فقط الأيدي الكاتبة للكود.
بالتوفيق يا جماعة الخير في رحلتكم. 👍
