السلام عليكم
الأسبوع الماضي أخيراً خلصت كتاب (مع إنه بسيط كله ٨٠ صفحة لطيفات ^^ وآخر أكم صفحة فيها تلخيص لكل الموجود فيه ولكنها غير مفهومة أو فيها فائدة بدون قراءة الكتاب ولكنها لطيفة كمرجع للي بخلصه).
Code simplicity : الكتاب مجاني على موقعهن بس اكتب الاسم على غوغل، مستوى الكتاب يعتبر قليل وأي حد سنة ثانية أو ثالثة في الجامعة واطلع ما أتوقع يواجه صعوبة في فهمه ممكن شوية صعوبة في شوية مفردات ولكن مع شوي مساعدة من غوغل او chatgpt ممكن الشخص يخلصه بيومين أو ثلاث ^^.
هذا الكتاب بتناول صناعة البرمجة بشكل بسيط الفكرة إنه يحط القواعد اللي بعتبرها المبرمجين كأنها من الواضحات (common sense) خصوصاً اللي صرلهم سنين ببرمجوا في مكان واحد وبشرحها وبشرح المنطق منها وسبب وجودها وبقسمها بما يسميه بحقائق "facts" وقوانين "laws" وقواعد "rules".
وخلينا نحكي عن مثال بسيط نشجعكم تقرأوه
Law: The Equation of Software Design
وهو ثاني واحد وببساطة بيحكي عن الأساس باختيارنا ايش نشتغل فيه وأبسط مثال على القانون إنه عنا برنامج بنبيع لعملاء وبدنا نصنع ميزة جديدة لكن فيه عنا خيارين وبدنا نختار وحدة بينهن لازم نطلع على الجهد اللي راح نبذله وكم شخص راح تفيد وايش راح يكون الاثر.
وهذا بتمثله المعادلة (الكتاب كله حكي هاي المعادلة الوحيدة اللي فيه حتى كود فيه يدوب اكم سطر):
Desirability = Value/Effort
Desirability = مقدار الرغبة في عمل الميزة أولاً أو بمعنى الأولوية
Value = القيمة اللي بتقدمها الميزة
Effort = الجهد المبذول
فمثلاً ميزة راح تفيد شخص واحد بشكل بسيط لكن فيه ميزة اخرى راح تفيد ١٠٠ الف شخص وبرضو بشكل بسيط فهنا راح نختار الثانية.
أو مثلاً عندي ميزة راح تفيد بحيث الأولى ممكن تنقذ حياة شخص والأخرى ممكن تفيد ١٠ اشخاص بشكل بسيط جداً لا هون بختار تبعت الشخص لأنه حجم تأثيرها كبير جداً حتى مع إنه عدد المستفيدين ممكن يكون قليل، وطبعاً لازم هذا بأخذ كم بدها شغل في الحسبان فمثلاً لو وحدة بدها سنة شغل ووحدة بدها يوم شغل راح نوزن كذلك هذا الحكي في الموضوع لنختار الميزات الأفضل، ومن تطبيقاته بحياة الطلاب بشكل مباشر هو مشروع التخرج فدائماً بنحكي نبلش بالشغلات الأهم وبعدها بنروح للشغلات الإضافية إذا ضل معنا وقت.
مثال آخر من الكتاب ع الحقائق:
• Fact: When your design actually makes things more complex instead of simplifying things, you’re overengineering
ببساطة هو بيعطينا تعريف سريع لمصطلح بنسمعه كثير overengineering وهو بكل بساطة بيحكي عن لما نيجي نعمل حل ونعقده زيادة عن اللزوم وبعقد الكود والحل نفسه بدل ما يبسطه هذا ببساطة هو overengineering
مثال آخير من الكتاب عن اللي سماه قواعد:
Rule: Don’t write code until you actually need it, and remove any code that isn’t being used.
ببساطة ترحش تكتب function تقول هذا الفنكشن احتمال احتاجه ب feature لقدام وطبعاً كل واحد من هذول القواعد بيتم شرحه بشكل تفصيلي وشرح المنطق ورائه وليش مثال بقلك لما تكتب function مش راح تستخدمه هس ممكن تطول عبين تستخدمه ولما تيجي تستخدمه بكونش مفحوص وقت ما عملته لأنك ما استخدمته وهذا راح يعمل مشاكل وممكن كذلك لما يوصل الوقت المناسب لاستخدامه يكون صار قديم أصلاً وبطل مناسب ويشتغل.
أتمنى تكون مقدمة خلتكم تتحمسوا تقرأوه ^^.