Deleted Account
Photo
الإضافة نزلت في
Visual studio code marketplace
شوفوا حملوها من visual studio code وجربوها إذا في أخطاء بلغونا وشكراً لكم
👍
Visual studio code marketplace
شوفوا حملوها من visual studio code وجربوها إذا في أخطاء بلغونا وشكراً لكم
👍
الحمد لله الذي بلغنا شهر رمضان، شهر الرحمة والمغفرة والعتق من النيران، شهر تتنزل فيه السكينة وتصفو فيه القلوب وتُرفع فيه الدرجات.
يسرّنا أن نهنئكم بحلول هذا الشهر الفضيل، سائلين الله أن يجعله شهر خيرٍ وبركة علينا وعليكم، وأن يعيننا فيه على الصيام والقيام وغضّ البصر وحفظ اللسان، وأن يتقبّل منا ومنكم صالح الأعمال.
نسأل الله أن يكتب لنا فيه أجر الصائمين، وقيام القائمين، وأن يجعلنا فيه من المقبولين، وأن يرزقنا الإخلاص في القول والعمل، وأن يختم لنا الشهر برضوانه والعتق من نيرانه.
🌙 شهر مبارك
✨ وكل عام وأنتم بخير
🤲 تقبّل الله منا ومنكم صالح الأعمال
يسرّنا أن نهنئكم بحلول هذا الشهر الفضيل، سائلين الله أن يجعله شهر خيرٍ وبركة علينا وعليكم، وأن يعيننا فيه على الصيام والقيام وغضّ البصر وحفظ اللسان، وأن يتقبّل منا ومنكم صالح الأعمال.
نسأل الله أن يكتب لنا فيه أجر الصائمين، وقيام القائمين، وأن يجعلنا فيه من المقبولين، وأن يرزقنا الإخلاص في القول والعمل، وأن يختم لنا الشهر برضوانه والعتق من نيرانه.
🌙 شهر مبارك
✨ وكل عام وأنتم بخير
🤲 تقبّل الله منا ومنكم صالح الأعمال
❤1
منشور مهندس مصري عجبني وبيتكلم على دوامة أحنا فيها حالياً 🤣💔 :
وهم الـ Microservices.. أو إزاي تدفن نفسك بدري وأنت لسه بتقول يا هادي!
واحدة من أكبر الكوارث اللي بشوفها بتتكرر بشكل مرعب مع الشباب في أول طريقهم في الـ Software Engineering، إنهم أول ما يخلصوا الـ Syntax بتاع لغة البرمجة ويحفظوا شوية Controllers في Framework معين، بيجيلهم إحساس زائف إنهم بقوا جاهزين يقفزوا فوراً لحاجات تقيلة جداً زي الـ Microservices والـ Kubernetes.
المشكلة هنا مش إن الـ Microservices وحشة.. بالعكس، هي Architectural Style قوي جداً ومفيد في سياقات معينة وللشركات العملاقة، لكن الكارثة بتحصل لما حد لسه مش فاهم يعني إيه Separation of Concerns، ولسه مش قادر يكتب Class واحدة Clean، ويروح فجأة يقرر يقسم السيستم لـ 10 Services وهو أصلًا مش عارف يظبط Service واحدة Monolithic صح.
عشان الصورة توضح، خليني أحكيلك موقف حصل معايا الأسبوع اللي فات في المينتور شيب بيشرح المأساة دي:
جالي واحد من الشباب المتحمسين جداً، عامل Project تخرج عبارة عن E-commerce App بسيط.
الولد داخل فخور جداً وبيقولي: "يا هندسة أنا مقسم السيستم لـ 5 Microservices: واحدة للـ User، وواحدة للـ Product، وواحدة للـ Order، وواحدة للـ Payment، وواحدة للـ Notification.. ورابط بينهم بـ RabbitMQ ومشغلهم بـ Docker Compose".
قولتله: "الله ينور.. شكلنا عاملين شغل عالي.. طب تعالى نجرب نعمل Order".
عملنا Request.. السيستم ضرب Error 500.
دخلنا نشوف الـ Logs.. قعدنا نص ساعة نلف بين الـ Logs بتاعت الـ Order Service والـ Inventory Service عشان نكتشف إن الـ Network وقعت بينهم في لحظة معينة.
المصيبة الأكبر بانت لما سألته: "طب لو الـ Payment نجح بس الـ Order فشل يتحفظ في الداتا بيز.. هتعمل إيه؟"
سكت وبصلي بذهول وقال: "ما هو أكيد لو ده نجح ده هينجح".
قولتله: "لأ يا قلب الهندسة.. في الـ Distributed Systems مفيش حاجة اسمها (أكيد).. أنت هنا خسرت الـ ACID Properties بتاعة الداتا بيز الواحدة، ودخلت في كابوس الـ Distributed Transactions والـ Eventual Consistency".
الولد اكتشف إنه بنى "وحش" مش عارف يسيطر عليه، وإنه بيقضي 90% من وقته بيصلح Configs للـ Docker والشبكة، و 10% بس بيكتب Business Logic.. وده هو الفخ.
تعالى بقى نتكلم Engineering بجد ونشوف ليه القفزة دي ممكن تدمر مستقبلك لو عملتها بدري:
١- أنت بتبني على رمل (Data Structures & Memory)
كتير من المبتدئين بيعدوا بسرعة على موضوع الـ Data Structures زي الـ Array و الـ List و الـ Map و الـ Set، فاكرينها مجرد "Containers" بنرمي فيها الداتا.. وده قصور شديد في الفهم.
في الـ Distributed Systems، اختيارك للـ Collection الغلط مش مجرد كود بطيء، دي بتكون تكلفة Memory و Performance Cost بتضرب في عدد الـ Services.
لو أنت مش فاهم الفرق بين Mutable و Immutable، ومش مستوعب يعني إيه Reference vs Value، ومش عارف إمتى الداتا بتروح للـ Stack وإمتى بتتحجز في الـ Heap Memory.. يبقى دخولك في Distributed System هو دوامة مالهاش أول من آخر، لأنك مش هتعرف تعمل Debugging لمشاكل الـ Memory Leaks اللي هتحصل.
٢- وهم الكود النضيف (The Clean Code Illusion)
ناس كتير بتفتكر إن الـ Clean Code ده حاجة رفاهية أو مرحلة Advanced.. الحقيقة إن الـ Clean Code هو "ألف باء" Engineering.
لو أنت مش بتعرف تسمي Variables صح، ومش بتعرف تقسم Functions صغيرة بـ Single Responsibility، ومش بتعرف تعمل Project Structure مفهوم.. لما تقسم "العك" ده على 5 سيرفسات، أنت مبقتش بتعمل Microservices، أنت عملت Distributed Big Ball of Mud.
أنت حولت المشكلة من "كود وحش في مكان واحد" لـ "كود وحش متوزع ومربوط ببعضه بشبكة"، وده كابوس لا يمكن صيانته.
٣- تعقيدات أنت في غنى عنها (The Complexity Beast)
الـ Microservices بتحل مشاكل زي الـ Independent Deployment والـ Scalability.. بس في المقابل بتخلق تعقيد مرعب أنت لسه مش قده:
الـ Communication: بدل ما كنت بتنادي Function في الميموري (In-process Call) بتاخد نانو ثانية، بقيت بتعمل Network Call بتاخد مللي ثانية.. عارف يعني إيه Network Latency؟ عارف يعني إيه Request Timeout؟
الـ Consistency: إزاي تضمن إن الداتا مظبوطة في 3 داتا بيز مختلفة في نفس الوقت؟
الـ Observability: لما يحصل Error، هتعرف تجيبه منين وسط مئات الـ Logs المتوزعة؟ هل عندك Infrastructure للـ Tracing؟
عشان كدة نصيحتي ليك واللي دايمًا بقولها للمتدربين عندي:
وهم الـ Microservices.. أو إزاي تدفن نفسك بدري وأنت لسه بتقول يا هادي!
واحدة من أكبر الكوارث اللي بشوفها بتتكرر بشكل مرعب مع الشباب في أول طريقهم في الـ Software Engineering، إنهم أول ما يخلصوا الـ Syntax بتاع لغة البرمجة ويحفظوا شوية Controllers في Framework معين، بيجيلهم إحساس زائف إنهم بقوا جاهزين يقفزوا فوراً لحاجات تقيلة جداً زي الـ Microservices والـ Kubernetes.
المشكلة هنا مش إن الـ Microservices وحشة.. بالعكس، هي Architectural Style قوي جداً ومفيد في سياقات معينة وللشركات العملاقة، لكن الكارثة بتحصل لما حد لسه مش فاهم يعني إيه Separation of Concerns، ولسه مش قادر يكتب Class واحدة Clean، ويروح فجأة يقرر يقسم السيستم لـ 10 Services وهو أصلًا مش عارف يظبط Service واحدة Monolithic صح.
عشان الصورة توضح، خليني أحكيلك موقف حصل معايا الأسبوع اللي فات في المينتور شيب بيشرح المأساة دي:
جالي واحد من الشباب المتحمسين جداً، عامل Project تخرج عبارة عن E-commerce App بسيط.
الولد داخل فخور جداً وبيقولي: "يا هندسة أنا مقسم السيستم لـ 5 Microservices: واحدة للـ User، وواحدة للـ Product، وواحدة للـ Order، وواحدة للـ Payment، وواحدة للـ Notification.. ورابط بينهم بـ RabbitMQ ومشغلهم بـ Docker Compose".
قولتله: "الله ينور.. شكلنا عاملين شغل عالي.. طب تعالى نجرب نعمل Order".
عملنا Request.. السيستم ضرب Error 500.
دخلنا نشوف الـ Logs.. قعدنا نص ساعة نلف بين الـ Logs بتاعت الـ Order Service والـ Inventory Service عشان نكتشف إن الـ Network وقعت بينهم في لحظة معينة.
المصيبة الأكبر بانت لما سألته: "طب لو الـ Payment نجح بس الـ Order فشل يتحفظ في الداتا بيز.. هتعمل إيه؟"
سكت وبصلي بذهول وقال: "ما هو أكيد لو ده نجح ده هينجح".
قولتله: "لأ يا قلب الهندسة.. في الـ Distributed Systems مفيش حاجة اسمها (أكيد).. أنت هنا خسرت الـ ACID Properties بتاعة الداتا بيز الواحدة، ودخلت في كابوس الـ Distributed Transactions والـ Eventual Consistency".
الولد اكتشف إنه بنى "وحش" مش عارف يسيطر عليه، وإنه بيقضي 90% من وقته بيصلح Configs للـ Docker والشبكة، و 10% بس بيكتب Business Logic.. وده هو الفخ.
تعالى بقى نتكلم Engineering بجد ونشوف ليه القفزة دي ممكن تدمر مستقبلك لو عملتها بدري:
١- أنت بتبني على رمل (Data Structures & Memory)
كتير من المبتدئين بيعدوا بسرعة على موضوع الـ Data Structures زي الـ Array و الـ List و الـ Map و الـ Set، فاكرينها مجرد "Containers" بنرمي فيها الداتا.. وده قصور شديد في الفهم.
في الـ Distributed Systems، اختيارك للـ Collection الغلط مش مجرد كود بطيء، دي بتكون تكلفة Memory و Performance Cost بتضرب في عدد الـ Services.
لو أنت مش فاهم الفرق بين Mutable و Immutable، ومش مستوعب يعني إيه Reference vs Value، ومش عارف إمتى الداتا بتروح للـ Stack وإمتى بتتحجز في الـ Heap Memory.. يبقى دخولك في Distributed System هو دوامة مالهاش أول من آخر، لأنك مش هتعرف تعمل Debugging لمشاكل الـ Memory Leaks اللي هتحصل.
٢- وهم الكود النضيف (The Clean Code Illusion)
ناس كتير بتفتكر إن الـ Clean Code ده حاجة رفاهية أو مرحلة Advanced.. الحقيقة إن الـ Clean Code هو "ألف باء" Engineering.
لو أنت مش بتعرف تسمي Variables صح، ومش بتعرف تقسم Functions صغيرة بـ Single Responsibility، ومش بتعرف تعمل Project Structure مفهوم.. لما تقسم "العك" ده على 5 سيرفسات، أنت مبقتش بتعمل Microservices، أنت عملت Distributed Big Ball of Mud.
أنت حولت المشكلة من "كود وحش في مكان واحد" لـ "كود وحش متوزع ومربوط ببعضه بشبكة"، وده كابوس لا يمكن صيانته.
٣- تعقيدات أنت في غنى عنها (The Complexity Beast)
الـ Microservices بتحل مشاكل زي الـ Independent Deployment والـ Scalability.. بس في المقابل بتخلق تعقيد مرعب أنت لسه مش قده:
الـ Communication: بدل ما كنت بتنادي Function في الميموري (In-process Call) بتاخد نانو ثانية، بقيت بتعمل Network Call بتاخد مللي ثانية.. عارف يعني إيه Network Latency؟ عارف يعني إيه Request Timeout؟
الـ Consistency: إزاي تضمن إن الداتا مظبوطة في 3 داتا بيز مختلفة في نفس الوقت؟
الـ Observability: لما يحصل Error، هتعرف تجيبه منين وسط مئات الـ Logs المتوزعة؟ هل عندك Infrastructure للـ Tracing؟
عشان كدة نصيحتي ليك واللي دايمًا بقولها للمتدربين عندي:
❤2
ابدأ بإتقان اللغة بعمق مرعب الأول.. افهم الـ Type System، افهم الـ Concurrency Basics، افهم الـ Runtime بتاع لغتك شغال إزاي.
اتعلم Clean Code و Refactoring بجد.. طبق مبادئ الـ SOLID في مشروع Monolithic صغير.
اشتغل على Project واحد حقيقي End to End.. فيه Authentication، Authorization، Validation، Logging، واكتبله Tests (سواء Unit أو Integration).
بعد ما تبني System Monolith نضيف، متماسك، وقابل للتطوير.. ساعتها بس اسأل نفسك: هل عندي Bottleneck؟ هل التيم كبر جداً ومحتاجين نتقسم؟
لو الإجابة لأ.. يبقى الـ Microservices مش ليك دلوقتي.
وهنا بيجي دوري في المينتور شيب.. إحنا بنحارب "هوس التريند"..
مش بنخليك تجري ورا الموضة، بنخليك تبني "أساس".. بنعلمك إزاي تعمل Modular Monolith محترم، وإزاي تفصل الـ Domain Logic عن الـ Infrastructure.. لأنك لو بنيت الأساس صح، الانتقال للـ Microservices بعد كدة هيبقى خطوة طبيعية وسهلة، مش قفزة في المجهول.
الخلاصة يا قلب الهندسة.. السر مش في إنك تجري بسرعة على أعلى تقنية، السر في إنك تبني طبقة ورا طبقة بثبات.. اللي بيستعجل غالباً بيلف دايرة كبيرة ويرجع تاني للأساسيات بعد سنين وهو محبط، بينما اللي بيبني صح من الأول بيختصر على نفسه الطريق كله وبيوصل أسرع بكتير مما تتخيل.
--
اتعلم Clean Code و Refactoring بجد.. طبق مبادئ الـ SOLID في مشروع Monolithic صغير.
اشتغل على Project واحد حقيقي End to End.. فيه Authentication، Authorization، Validation، Logging، واكتبله Tests (سواء Unit أو Integration).
بعد ما تبني System Monolith نضيف، متماسك، وقابل للتطوير.. ساعتها بس اسأل نفسك: هل عندي Bottleneck؟ هل التيم كبر جداً ومحتاجين نتقسم؟
لو الإجابة لأ.. يبقى الـ Microservices مش ليك دلوقتي.
وهنا بيجي دوري في المينتور شيب.. إحنا بنحارب "هوس التريند"..
مش بنخليك تجري ورا الموضة، بنخليك تبني "أساس".. بنعلمك إزاي تعمل Modular Monolith محترم، وإزاي تفصل الـ Domain Logic عن الـ Infrastructure.. لأنك لو بنيت الأساس صح، الانتقال للـ Microservices بعد كدة هيبقى خطوة طبيعية وسهلة، مش قفزة في المجهول.
الخلاصة يا قلب الهندسة.. السر مش في إنك تجري بسرعة على أعلى تقنية، السر في إنك تبني طبقة ورا طبقة بثبات.. اللي بيستعجل غالباً بيلف دايرة كبيرة ويرجع تاني للأساسيات بعد سنين وهو محبط، بينما اللي بيبني صح من الأول بيختصر على نفسه الطريق كله وبيوصل أسرع بكتير مما تتخيل.
--
ماذا استفدت من المقال :
هذه كل المصطلحات التقنية والهندسية الواردة في المقال، مرتبة ومنسقة بدون شرح:
أولاً: مفاهيم عامة في هندسة البرمجيات
Software Engineering
Syntax
Framework
Controllers
Architectural Style
Separation of Concerns
Class
Clean Code
Monolithic
Business Logic
Modular Monolith
Domain Logic
Infrastructure
Bottleneck
End to End
Refactoring
SOLID
Type System
Concurrency Basics
Runtime
ثانياً: معمارية الأنظمة
Microservices
Distributed Systems
Distributed Transactions
Eventual Consistency
ACID Properties
Independent Deployment
Scalability
In-process Call
Network Call
Network Latency
Request Timeout
Observability
Tracing
Big Ball of Mud (Distributed Big Ball of Mud)
ثالثاً: أدوات وتقنيات
Kubernetes
Docker
Docker Compose
RabbitMQ
رابعاً: مكونات التطبيقات
Project
E-commerce App
User Service
Product Service
Order Service
Payment Service
Notification Service
Inventory Service
Authentication
Authorization
Validation
Logging
Unit Tests
Integration Tests
Request
Error 500
Logs
Configs
Network
خامساً: هياكل البيانات والذاكرة
Data Structures
Memory
Array
List
Map
Set
Collection
Mutable
Immutable
Reference vs Value
Stack
Heap Memory
Memory Leaks
Performance Cost
سادساً: مفاهيم تنظيم الكود
Variables
Functions
Single Responsibility
Project Structure
يالله روح ابحث ايش معنى كل واحد واين تستخدمه في المشاريع 💔😆
هذه كل المصطلحات التقنية والهندسية الواردة في المقال، مرتبة ومنسقة بدون شرح:
أولاً: مفاهيم عامة في هندسة البرمجيات
Software Engineering
Syntax
Framework
Controllers
Architectural Style
Separation of Concerns
Class
Clean Code
Monolithic
Business Logic
Modular Monolith
Domain Logic
Infrastructure
Bottleneck
End to End
Refactoring
SOLID
Type System
Concurrency Basics
Runtime
ثانياً: معمارية الأنظمة
Microservices
Distributed Systems
Distributed Transactions
Eventual Consistency
ACID Properties
Independent Deployment
Scalability
In-process Call
Network Call
Network Latency
Request Timeout
Observability
Tracing
Big Ball of Mud (Distributed Big Ball of Mud)
ثالثاً: أدوات وتقنيات
Kubernetes
Docker
Docker Compose
RabbitMQ
رابعاً: مكونات التطبيقات
Project
E-commerce App
User Service
Product Service
Order Service
Payment Service
Notification Service
Inventory Service
Authentication
Authorization
Validation
Logging
Unit Tests
Integration Tests
Request
Error 500
Logs
Configs
Network
خامساً: هياكل البيانات والذاكرة
Data Structures
Memory
Array
List
Map
Set
Collection
Mutable
Immutable
Reference vs Value
Stack
Heap Memory
Memory Leaks
Performance Cost
سادساً: مفاهيم تنظيم الكود
Variables
Functions
Single Responsibility
Project Structure
يالله روح ابحث ايش معنى كل واحد واين تستخدمه في المشاريع 💔😆
❤1
مقال ثاني للمصري :
كتير مننا كـ Software Engineers في بدايتنا بنقع في فخ مثالي جداً ومشهور، فخ "أنا هكتب كود مفيش زيه ومفيش سطرين شبه بعض عندي".. أول ما الـ Developer يشوف سطرين كود متكررين، إيده بتاكله ويجري فوراً يطبق مبدأ الـ DRY (Don't Repeat Yourself) ويعملهم دمج في Function واحدة عشان يحس بالانتصار الهندسي.
بس الحقيقة الصادمة اللي بنكتشفها بعدين بالدموع في الـ Production، إن مش كل كود متكرر تجري تطبق عليه الـ DRY Principle بشكل أعمى.. لأن الـ Duplication أحياناً بيكون أرحم بكتير من إنك تعمل Tight Coupling بين جزئين في السيستم ملهمش أي علاقة منطقية ببعض، ولما تحتاج تعدل Requirement في حتة فيهم تلاقي التانية ضربت منك في صمت.
المقولة دي بتلخص واحدة من أهم وأعمق المشاكل اللي بيقع فيها المبرمجين في الـ Software Design، ومبنية على قاعدة ذهبية للمهندسة Sandi Metz بتقول: "Duplication is far cheaper than the wrong abstraction" بمعنى إن التكرار أرخص وأهون بكتير من الـ Wrong Abstraction.
عشان نفهم المعنى التقني ورا الكلام ده، تعالى نتكلم Engineering بجد ونقسم المشكلة دي لأجزاء عشان نستوعب الكارثة اللي بتحصل Under the hood:
١- التكرار بالصدفة (Coincidental Duplication)
مش كل كودين شكلهم متطابق يبقوا بيعملوا نفس الحاجة أو ليهم نفس الهدف في الـ Business Logic.. أحياناً الكود بيكون متطابق "بالصدفة" في اللحظة الزمنية دي بس. لو اتسرعت وعملت ليهم دمج في Shared Function، أنت كدة ربطت مسارين ملهمش علاقة ببعض لمجرد إن الـ Syntax الحالي واحد. هنا أنت معملتش DRY لمفاهيم أو Knowledge، أنت عملت DRY لسطور كود، وده فخ مرعب اسمه Temporal Coupling.
٢- كابوس الاعتمادية (Tight Coupling)
لما تجمع الكودين دول في مكان واحد لمجرد التشابه الشكلي، أنت خلقت رابط قوي جداً بينهم.. لو جزء في السيستم طلب تعديل في الـ Shared Function دي عشان يناسب Business Requirement جديد، التعديل ده هيسمع فوراً في الجزء التاني اللي بيستخدم نفس الـ Function، وممكن يبوظه بالكامل لأن الجزء التاني مكنش متوقع ولا محتاج التعديل ده أصلاً.
٣- ولادة الوحش (The Wrong Abstraction)
لما تكتشف إن الـ Function الواحدة مبقتش نافعة للطرفين بنفس الشكل، هتبدأ "ترقع".. هتبدأ تبعت Parameters زيادة، وتحط Boolean Flags زي isUser أو isAdmin، وتعمل Nested if/else conditions جوه الـ Function عشان تفصل بين الحالتين.. مع الوقت الـ Function دي هتكبر وهتتحول لـ God Function معقدة جداً بتكسر مبدأ الـ Single Responsibility Principle، وأي محاولة للـ Debugging فيها هتبقى عبارة عن Cognitive Load رهيب على دماغ أي حد بيقرأها، وهتلاقي نفسك بتعمل Shotgun Surgery مع كل تعديل بسيط.
عشان الصورة توضح بجد، خليني أحكيلك موقف حصل معايا الأسبوع اللي فات في Mentorship Session مع واحد من الشباب الشاطرين جداً معانا:
كنا بنعمل Code Review لـ Task في Project التجارة الإلكترونية بتاعه، وكان بيحسب ضريبة المبيعات.. هو لقى إن الـ Function اللي بتحسب الضريبة للمنتجات العادية، والـ Function بتاعة الخدمات، الاتنين بيضربوا السعر في 10%، فالكود متكرر بالمللي.. فقام مطبق الـ DRY وعمل Shared Function واحدة اسمها calculateTax.
السيشن اللي بعدها، اديتله Business Requirement جديد: "الضريبة على الخدمات بقت 15%، والمنتجات فضل عليها 10% بس ضفنا رسوم شحن للمنتجات اللي سعرها فوق رقم معين".
هنا الولد دخل يعدل في الـ Shared Function، وزود isService flag، وبعدين زود requiresShipping، وعمل شروط متداخلة جوه نفس الـ Function.. النتيجة؟ الكود بقى Spaghetti، ولما حب يعدل حسبة الخدمات، بقى مرعوب إنه يـ Break حسبة المنتجات.. هنا الـ Wrong Abstraction خلى الـ Maintenance بتاع الكود أصعب 100 مرة من لو كان ساب 2 Independent Functions كل واحدة بتعبر عن الـ Context بتاعها بوضوح.
في الـ Software Engineering عندنا Best Practice ممتازة اسمها Rule of Three.. لو الكود اتكرر مرتين، استنى وماتعملش حاجة وسيبه متكرر.. لو اتكرر تلات مرات بنفس الشكل ونفس المعنى، ساعتها بس ابدأ فكر تعمل Abstraction.. لأن المرة التالتة بتأكدلك إن ده Pattern حقيقي في الـ Domain مش مجرد صدفة مؤقتة.
وهنا بيجي دوري كمنتور.. لما بلاقي حد من الشباب بيعمل Pull Request وكل همه إنه يقلل عدد السطور لمجرد التقليل وإرضاء الـ IDE، بوقفه فوراً.. إحنا بنركز إننا نبني عقلية Software Engineer بيحلل الـ Context مش مجرد Coder بينفذ قواعد محفوظة.
بخليه يشوف بعينه إزاي التراجع عن الـ Wrong Abstraction وفك الـ Coupling بياخد مجهود خرافي مقارنة بدمج الكود المتكرر، وبفهمه إن الـ Readable Code المستقل أهم مليون مرة من إنك توفر كام سطر كود وتدفع تمنهم Technical Debt يخلي المشروع Unmaintainable.
كتير مننا كـ Software Engineers في بدايتنا بنقع في فخ مثالي جداً ومشهور، فخ "أنا هكتب كود مفيش زيه ومفيش سطرين شبه بعض عندي".. أول ما الـ Developer يشوف سطرين كود متكررين، إيده بتاكله ويجري فوراً يطبق مبدأ الـ DRY (Don't Repeat Yourself) ويعملهم دمج في Function واحدة عشان يحس بالانتصار الهندسي.
بس الحقيقة الصادمة اللي بنكتشفها بعدين بالدموع في الـ Production، إن مش كل كود متكرر تجري تطبق عليه الـ DRY Principle بشكل أعمى.. لأن الـ Duplication أحياناً بيكون أرحم بكتير من إنك تعمل Tight Coupling بين جزئين في السيستم ملهمش أي علاقة منطقية ببعض، ولما تحتاج تعدل Requirement في حتة فيهم تلاقي التانية ضربت منك في صمت.
المقولة دي بتلخص واحدة من أهم وأعمق المشاكل اللي بيقع فيها المبرمجين في الـ Software Design، ومبنية على قاعدة ذهبية للمهندسة Sandi Metz بتقول: "Duplication is far cheaper than the wrong abstraction" بمعنى إن التكرار أرخص وأهون بكتير من الـ Wrong Abstraction.
عشان نفهم المعنى التقني ورا الكلام ده، تعالى نتكلم Engineering بجد ونقسم المشكلة دي لأجزاء عشان نستوعب الكارثة اللي بتحصل Under the hood:
١- التكرار بالصدفة (Coincidental Duplication)
مش كل كودين شكلهم متطابق يبقوا بيعملوا نفس الحاجة أو ليهم نفس الهدف في الـ Business Logic.. أحياناً الكود بيكون متطابق "بالصدفة" في اللحظة الزمنية دي بس. لو اتسرعت وعملت ليهم دمج في Shared Function، أنت كدة ربطت مسارين ملهمش علاقة ببعض لمجرد إن الـ Syntax الحالي واحد. هنا أنت معملتش DRY لمفاهيم أو Knowledge، أنت عملت DRY لسطور كود، وده فخ مرعب اسمه Temporal Coupling.
٢- كابوس الاعتمادية (Tight Coupling)
لما تجمع الكودين دول في مكان واحد لمجرد التشابه الشكلي، أنت خلقت رابط قوي جداً بينهم.. لو جزء في السيستم طلب تعديل في الـ Shared Function دي عشان يناسب Business Requirement جديد، التعديل ده هيسمع فوراً في الجزء التاني اللي بيستخدم نفس الـ Function، وممكن يبوظه بالكامل لأن الجزء التاني مكنش متوقع ولا محتاج التعديل ده أصلاً.
٣- ولادة الوحش (The Wrong Abstraction)
لما تكتشف إن الـ Function الواحدة مبقتش نافعة للطرفين بنفس الشكل، هتبدأ "ترقع".. هتبدأ تبعت Parameters زيادة، وتحط Boolean Flags زي isUser أو isAdmin، وتعمل Nested if/else conditions جوه الـ Function عشان تفصل بين الحالتين.. مع الوقت الـ Function دي هتكبر وهتتحول لـ God Function معقدة جداً بتكسر مبدأ الـ Single Responsibility Principle، وأي محاولة للـ Debugging فيها هتبقى عبارة عن Cognitive Load رهيب على دماغ أي حد بيقرأها، وهتلاقي نفسك بتعمل Shotgun Surgery مع كل تعديل بسيط.
عشان الصورة توضح بجد، خليني أحكيلك موقف حصل معايا الأسبوع اللي فات في Mentorship Session مع واحد من الشباب الشاطرين جداً معانا:
كنا بنعمل Code Review لـ Task في Project التجارة الإلكترونية بتاعه، وكان بيحسب ضريبة المبيعات.. هو لقى إن الـ Function اللي بتحسب الضريبة للمنتجات العادية، والـ Function بتاعة الخدمات، الاتنين بيضربوا السعر في 10%، فالكود متكرر بالمللي.. فقام مطبق الـ DRY وعمل Shared Function واحدة اسمها calculateTax.
السيشن اللي بعدها، اديتله Business Requirement جديد: "الضريبة على الخدمات بقت 15%، والمنتجات فضل عليها 10% بس ضفنا رسوم شحن للمنتجات اللي سعرها فوق رقم معين".
هنا الولد دخل يعدل في الـ Shared Function، وزود isService flag، وبعدين زود requiresShipping، وعمل شروط متداخلة جوه نفس الـ Function.. النتيجة؟ الكود بقى Spaghetti، ولما حب يعدل حسبة الخدمات، بقى مرعوب إنه يـ Break حسبة المنتجات.. هنا الـ Wrong Abstraction خلى الـ Maintenance بتاع الكود أصعب 100 مرة من لو كان ساب 2 Independent Functions كل واحدة بتعبر عن الـ Context بتاعها بوضوح.
في الـ Software Engineering عندنا Best Practice ممتازة اسمها Rule of Three.. لو الكود اتكرر مرتين، استنى وماتعملش حاجة وسيبه متكرر.. لو اتكرر تلات مرات بنفس الشكل ونفس المعنى، ساعتها بس ابدأ فكر تعمل Abstraction.. لأن المرة التالتة بتأكدلك إن ده Pattern حقيقي في الـ Domain مش مجرد صدفة مؤقتة.
وهنا بيجي دوري كمنتور.. لما بلاقي حد من الشباب بيعمل Pull Request وكل همه إنه يقلل عدد السطور لمجرد التقليل وإرضاء الـ IDE، بوقفه فوراً.. إحنا بنركز إننا نبني عقلية Software Engineer بيحلل الـ Context مش مجرد Coder بينفذ قواعد محفوظة.
بخليه يشوف بعينه إزاي التراجع عن الـ Wrong Abstraction وفك الـ Coupling بياخد مجهود خرافي مقارنة بدمج الكود المتكرر، وبفهمه إن الـ Readable Code المستقل أهم مليون مرة من إنك توفر كام سطر كود وتدفع تمنهم Technical Debt يخلي المشروع Unmaintainable.
الخلاصة يا قلب الهندسة.. مبدأ الـ DRY مش قرآن منزل نطبقه بشكل أعمى من غير فهم السياق. الـ Good Software Design مش سباق لتقليل أسطر الكود، هو سباق لتقليل التعقيد.. الـ Duplication الواضح الصريح أحياناً بيكون أرحم وأفضل بكتير من Wrong Abstraction بيخفي التعقيد Under the hood ويخلي أي Maintenance في المستقبل كابوس حقيقي.
---
مصادر مهمة جداً أنصحكم تقرأوها عشان تتعمقوا في الموضوع ده:
1- مقال "The Wrong Abstraction" للمهندسة العظيمة Sandi Metz (موجود على البلوج بتاعتها sandimetz.com).
2- كتاب "Clean Code" لـ Robert C. Martin (Uncle Bob) - تحديداً الفصول المتقدمة اللي بتتكلم عن الـ Cohesion والـ Coupling وإمتى نضحي بالـ DRY.
3- كتاب "Patterns of Enterprise Application Architecture" لـ Martin Fowler (تحديداً كلامه المهم عن الـ Tangential Coupling).
4- مقال ومحاضرة "Goodbye, Clean Code" لـ Dan Abramov (من تيم React) اللي بيحكي فيها عن هوسه بتقليل الكود في بداية حياته وإزاي دمره.
5- كتاب Refactoring للمؤلف Martin Fowler وتحديدا فصل الـ Code Smells وكلامه عن الـ Duplicated Code ومبدأ الـ Rule of Three.
--
Have A Nice Day 😊 ✌
---
مصادر مهمة جداً أنصحكم تقرأوها عشان تتعمقوا في الموضوع ده:
1- مقال "The Wrong Abstraction" للمهندسة العظيمة Sandi Metz (موجود على البلوج بتاعتها sandimetz.com).
2- كتاب "Clean Code" لـ Robert C. Martin (Uncle Bob) - تحديداً الفصول المتقدمة اللي بتتكلم عن الـ Cohesion والـ Coupling وإمتى نضحي بالـ DRY.
3- كتاب "Patterns of Enterprise Application Architecture" لـ Martin Fowler (تحديداً كلامه المهم عن الـ Tangential Coupling).
4- مقال ومحاضرة "Goodbye, Clean Code" لـ Dan Abramov (من تيم React) اللي بيحكي فيها عن هوسه بتقليل الكود في بداية حياته وإزاي دمره.
5- كتاب Refactoring للمؤلف Martin Fowler وتحديدا فصل الـ Code Smells وكلامه عن الـ Duplicated Code ومبدأ الـ Rule of Three.
--
Have A Nice Day 😊 ✌
أنا بالبيت يشتوني اصلح تلفونات تعريب ، فك شفرة ، ثري جي ، فورجي
او الدش او اي حاجة داخل الجوال من تحديثات وحسابات والذي ضيع حاجة او حذف يشتي استعيده والذي يشتي اخترق حسابات تواصل اجتماعي والذي يشتيني أعمل رحلة ماجلان ههههههه 🤣
المهم طحنة
هل عندكم من هذه المشاكل
او أنا فقط محبوط عمل
🤣💔
#يوميات_مهندس
او الدش او اي حاجة داخل الجوال من تحديثات وحسابات والذي ضيع حاجة او حذف يشتي استعيده والذي يشتي اخترق حسابات تواصل اجتماعي والذي يشتيني أعمل رحلة ماجلان ههههههه 🤣
المهم طحنة
هل عندكم من هذه المشاكل
او أنا فقط محبوط عمل
🤣💔
#يوميات_مهندس
🤣6
📱 فهرس تعلم صيانة وبرمجة الهواتف مبتدئ (كمبرمج وليس عتاد)
🔹 المرحلة الأولى: الأساسيات التقنية
1️⃣ مدخل إلى عالم الهواتف
مكونات الهاتف الداخلية (CPU – RAM – Storage – Modem)
الفرق بين GSM و CDMA
ما هو IMEI؟
آلية عمل الشبكات 2G / 3G / 4G / 5G
بنية نظام Android
2️⃣ أساسيات أنظمة التشغيل
نظام Android
Bootloader
Recovery
Fastboot
ADB
الفرق بين Stock ROM و Custom ROM
مفهوم Root وصلاحيات النظام
🔹 المرحلة الثانية: الصيانة البرمجية (Software Maintenance)
3️⃣ التفليش وتحديث الأنظمة
تثبيت تعريفات USB
استخدام Fastboot
تفليش عبر Odin (أجهزة سامسونج)
تفليش عبر SP Flash Tool (أجهزة MediaTek)
حل مشاكل Bootloop
إزالة FRP بطريقة قانونية
4️⃣ التعريب وتخصيص النظام
تثبيت رومات متعددة اللغات
إضافة اللغة العربية
حل مشاكل الخطوط
تثبيت Google Services للأجهزة الصينية
5️⃣ استرجاع البيانات
متى يمكن استعادة البيانات؟
الفرق بين الحذف العادي والتهيئة
أدوات استرجاع الملفات
النسخ الاحتياطي الاحترافي
🔹 المرحلة الثالثة: الشبكات والاتصال
6️⃣ مشاكل الشبكة
إصلاح No Service
ضبط APN للـ 3G و 4G
تحديث مودم الشبكة
فحص IMEI
التعامل مع مشاكل فقدان الإشارة
7️⃣ إعداد الراوتر والدش
ضبط إعدادات الراوتر
فتح البورتات
تقوية الإشارة
برمجة أجهزة الاستقبال (الدش)
🔹 المرحلة الرابعة: الحسابات والأمان
8️⃣ إدارة الحسابات
استرجاع حساب Google
مشاكل قفل الحساب
تفعيل المصادقة الثنائية
حماية الجهاز من الاختراق
🔹 المرحلة الخامسة: الاحتراف والدخل
9️⃣ الأدوات الاحترافية
Dongles
Box Tools
منصات السيرفر المدفوعة
إدارة ورشة صيانة
🔟 مهارات العمل الحر
تسعير الخدمات
التعامل مع العملاء
بناء سمعة محلية
إنشاء صفحة خدمات
🔹 المرحلة السادسة (للمهندس الحقيقي 👨💻)
1️⃣1️⃣ الانتقال من صيانة إلى هندسة
تحليل Firmware
بناء رومات مخصصة
دراسة Reverse Engineering
أساسيات الأمن السيبراني للهاتف
🎯 النتيجة النهائية
لتتخلص من بعض المشاكل السابقة.😅
🔹 المرحلة الأولى: الأساسيات التقنية
1️⃣ مدخل إلى عالم الهواتف
مكونات الهاتف الداخلية (CPU – RAM – Storage – Modem)
الفرق بين GSM و CDMA
ما هو IMEI؟
آلية عمل الشبكات 2G / 3G / 4G / 5G
بنية نظام Android
2️⃣ أساسيات أنظمة التشغيل
نظام Android
Bootloader
Recovery
Fastboot
ADB
الفرق بين Stock ROM و Custom ROM
مفهوم Root وصلاحيات النظام
🔹 المرحلة الثانية: الصيانة البرمجية (Software Maintenance)
3️⃣ التفليش وتحديث الأنظمة
تثبيت تعريفات USB
استخدام Fastboot
تفليش عبر Odin (أجهزة سامسونج)
تفليش عبر SP Flash Tool (أجهزة MediaTek)
حل مشاكل Bootloop
إزالة FRP بطريقة قانونية
4️⃣ التعريب وتخصيص النظام
تثبيت رومات متعددة اللغات
إضافة اللغة العربية
حل مشاكل الخطوط
تثبيت Google Services للأجهزة الصينية
5️⃣ استرجاع البيانات
متى يمكن استعادة البيانات؟
الفرق بين الحذف العادي والتهيئة
أدوات استرجاع الملفات
النسخ الاحتياطي الاحترافي
🔹 المرحلة الثالثة: الشبكات والاتصال
6️⃣ مشاكل الشبكة
إصلاح No Service
ضبط APN للـ 3G و 4G
تحديث مودم الشبكة
فحص IMEI
التعامل مع مشاكل فقدان الإشارة
7️⃣ إعداد الراوتر والدش
ضبط إعدادات الراوتر
فتح البورتات
تقوية الإشارة
برمجة أجهزة الاستقبال (الدش)
🔹 المرحلة الرابعة: الحسابات والأمان
8️⃣ إدارة الحسابات
استرجاع حساب Google
مشاكل قفل الحساب
تفعيل المصادقة الثنائية
حماية الجهاز من الاختراق
🔹 المرحلة الخامسة: الاحتراف والدخل
9️⃣ الأدوات الاحترافية
Dongles
Box Tools
منصات السيرفر المدفوعة
إدارة ورشة صيانة
🔟 مهارات العمل الحر
تسعير الخدمات
التعامل مع العملاء
بناء سمعة محلية
إنشاء صفحة خدمات
🔹 المرحلة السادسة (للمهندس الحقيقي 👨💻)
1️⃣1️⃣ الانتقال من صيانة إلى هندسة
تحليل Firmware
بناء رومات مخصصة
دراسة Reverse Engineering
أساسيات الأمن السيبراني للهاتف
🎯 النتيجة النهائية
لتتخلص من بعض المشاكل السابقة.😅
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
دعونا من البرمجة قليل |
ولنسمع الى هذا الداعية 💔🔥
ربي ارجعون
ولنسمع الى هذا الداعية 💔🔥
ربي ارجعون
❤2
جوجل تطلق Pomelli عبقري التسويق الجديد للشركات الصغيرة
أعلنت جوجل مؤخراً عن إطلاق أداة Pomelli، وهي تجربة ثورية مدعومة بالذكاء الاصطناعي (من تطوير Google DeepMind) تهدف لتحويل أي موقع إلكتروني إلى "ماكينة محتوى" تسويقي في دقائق.
تستهدف الأداة أصحاب المشاريع الصغيرة الذين لا يملكون ميزانية لتوظيف مصممين أو كتاب محتوى، حيث توفر لهم جودة احترافية بشكل مجاني (حالياً).
• تحليل "الحمض النووي" للعلامة (Business DNA): بمجرد وضع رابط موقعك، تقوم الأداة بتحليل ألوانك، خطوطك، ونبرة صوتك في الكتابة لتفهم هويتك بدقة.
• توليد أفكار حملات إعلانية: تقترح عليك زوايا تسويقية مبتكرة بناءً على نشاطك التجاري.
• صناعة محتوى جاهز للنشر: تنشئ لك منشورات لمنصات التواصل الاجتماعي (صور ونصوص) متناسقة تماماً مع هوية براندك.
• تعديل مرن: يمكنك تغيير الصور أو العناوين داخل الأداة قبل تحميلها.
الأداة في مرحلتها التجريبية العامة (Public Beta) وتدعم اللغة الإنجليزية حالياً في الولايات المتحدة، كندا، أستراليا، ونيوزيلندا (مع توقعات بتوسعها عالمياً قريباً).
أعلنت جوجل مؤخراً عن إطلاق أداة Pomelli، وهي تجربة ثورية مدعومة بالذكاء الاصطناعي (من تطوير Google DeepMind) تهدف لتحويل أي موقع إلكتروني إلى "ماكينة محتوى" تسويقي في دقائق.
تستهدف الأداة أصحاب المشاريع الصغيرة الذين لا يملكون ميزانية لتوظيف مصممين أو كتاب محتوى، حيث توفر لهم جودة احترافية بشكل مجاني (حالياً).
• تحليل "الحمض النووي" للعلامة (Business DNA): بمجرد وضع رابط موقعك، تقوم الأداة بتحليل ألوانك، خطوطك، ونبرة صوتك في الكتابة لتفهم هويتك بدقة.
• توليد أفكار حملات إعلانية: تقترح عليك زوايا تسويقية مبتكرة بناءً على نشاطك التجاري.
• صناعة محتوى جاهز للنشر: تنشئ لك منشورات لمنصات التواصل الاجتماعي (صور ونصوص) متناسقة تماماً مع هوية براندك.
• تعديل مرن: يمكنك تغيير الصور أو العناوين داخل الأداة قبل تحميلها.
الأداة في مرحلتها التجريبية العامة (Public Beta) وتدعم اللغة الإنجليزية حالياً في الولايات المتحدة، كندا، أستراليا، ونيوزيلندا (مع توقعات بتوسعها عالمياً قريباً).
Deleted Account
أنا بالبيت يشتوني اصلح تلفونات تعريب ، فك شفرة ، ثري جي ، فورجي او الدش او اي حاجة داخل الجوال من تحديثات وحسابات والذي ضيع حاجة او حذف يشتي استعيده والذي يشتي اخترق حسابات تواصل اجتماعي والذي يشتيني أعمل رحلة ماجلان ههههههه 🤣 المهم طحنة هل عندكم من هذه المشاكل…
طلع الموضوع صدق والله، يشتوني أكون مبرمج تلفونات صميل 💔🤣
كل يوم يجي لي واحد اصلح له التلفون
لا حول ولا قوة إلا بالله
يا جماعة الخير كيف افهمهم اننا درست ++C ما ليش دخل بالتلفونات
لازم نعمل دورة برمجة وصيانة جوالات
هكذا ما ينفعش كل ساعة وأنا باليوتيوب ابحث عن مشكلة
💔😅
كل يوم يجي لي واحد اصلح له التلفون
لا حول ولا قوة إلا بالله
يا جماعة الخير كيف افهمهم اننا درست ++C ما ليش دخل بالتلفونات
لازم نعمل دورة برمجة وصيانة جوالات
هكذا ما ينفعش كل ساعة وأنا باليوتيوب ابحث عن مشكلة
💔😅
🤣9❤1
تتبنى الصين حالياً نموذجاً ثورياً في التعليم العالي يهدف إلى كسر الجمود الأكاديمي، حيث أتاحت لطلاب الدكتوراه في التخصصات الهندسية والتقنية نيل الدرجة العلمية عبر تقديم ابتكارات واقعية ونماذج تقنية فعالة بدلاً من الأطروحات النظرية الطويلة. هذا التحول، المدعوم بـ قانون الدرجات العلمية لعام 2025، يسعى لتحويل الجامعات إلى محركات إنتاجية تدعم الاكتفاء الذاتي التكنولوجي، من خلال تقييم النجاح بناءً على القيمة الابتكارية والأثر الاقتصادي الملموس، وليس فقط النشر الورقي، مما يربط البحث العلمي مباشرة بمتطلبات الصناعة والأهداف الوطنية.
#101technology l #technews l #أخبار_التكنولوجيا l #china🇨🇳
#101technology l #technews l #أخبار_التكنولوجيا l #china🇨🇳