في فترة من الفترات، كنت مهووس بـ Clean Architecture و Design Patterns… زيادة عن اللازم شوية.
كل مرة بشتغل على Feature، كنت حاسس إني لازم أعملها فانسي، “مثالية” وشكلها حلو جوه الكود.
كنت أقعد أفكر فيها كتير، وأوقات تاخد وقت أطول من تنفيذ الـ Feature نفسه.

والأكيد… ساعات الكود كان بيبقى صعب الفهم، التيم يتلخبط، وأنا كنت محتاج documentation عشان أفهم أنا عملت إيه 😂.

لكن مع الوقت، التجارب، وبعض المشاكل اللي بتحصل في الـ production لما الـ codebase بيكبر، اكتشفت شوية حاجات مهمة:

• مش لازم تعرف وتستخدم كل الـ design patterns. المهم تعرف إمتى تستخدمها وإمتى تسيب الأمور بسيطة.

• الكود السهل المقروء أفضل 100 مرة من الكود الجامد اللي محدش فاهمه. الكود المفروض يكون واضح وسهل، مش لغز حد يحاول يحله.

• الكود الحلو مش اللي يبهرك. الكود الحلو هو اللي أي حد ممكن يفهمه بعدك.

• أهم حاجة الكود يخدم البيزنس. مش لازم تعقد الكود بس عشان تبين قد إيه إنت “جامد”، ويبقى صعب على أي حد يفهمه.

• كل الشركات عندها legacy و spaghetti code. ده طبيعي جداً، طالما شغال ما تلعبش في الزرار.

• ممكن تستخدم If Statements عادي جداً. مش لازم تلف كل if في Design Pattern بس عشان شكلها مش عاجبك. وحط تحتها خطوط لو تحب 🖍️.

• مفيش قرار هندسي صح 100% أو غلط 100%. كل قرار له trade-offs. المهم تكون فاهم تأثيره مش مجرد إنك جربته لأنه شكله حلو.

أوقات الحل الصح هو تكتب أقل كود ممكن يحل المشكلة ببساطة ووضوح.
وأوقات فعلاً محتاج تبني Architecture قوية لأنك هتبني عليها بعدين.
الفرق الحقيقي؟ إنك تعرف إمتى تستخدم إيه، وإزاي توازن بين جمال الكود وقوته وبين احتياجات البيزنس الواقعية.

في الآخر، الكود مش لوحة فنية.
الكود أداة لحل مشكلة. ولو حليتها ببساطة، يبقى كسبت… ✅