جنگولرن

چرا ذهن ما عاشق Abstraction زودهنگام است؟

خیلی وقت‌ها در تیم‌های نرم‌افزاری می‌بینیم که مهندسان خیلی زود به سراغ abstraction و generalization می‌روند. یعنی قبل از اینکه حتی نیاز واقعی شکل بگیرد، یک لایه انتزاعی طراحی می‌کنند تا برای آینده آماده باشند.

این رفتار بی‌دلیل نیست. ذهن ما از نظر تکاملی عادت دارد الگوها را سریع تشخیص دهد و تعمیم دهد. همین باعث شده است که حتی وقتی دو سناریوی مشابه می‌بینیم، ناخودآگاه به فکر ساختن یک راه‌حل عمومی می‌افتیم. در زندگی روزمره این توانایی به بقای ما کمک کرده، اما در دنیای نرم‌افزار همیشه مفید نیست.

مشکل اصلی اینجاست که وقتی زود abstraction بسازیم، سطح اشتباه را انتخاب می‌کنیم. نه آنقدر بالا که به درد بخورد، نه آنقدر دقیق که واقعاً نیاز را برطرف کند. نتیجه این می‌شود که کدی می‌نویسیم که پیچیده‌تر از چیزی است که لازم داریم، و سرعت یادگیری و تغییر را پایین می‌آورد.

در عین حال، فرهنگ و فضای آموزشی هم این عادت را تقویت می‌کند. همه جا به ما گفته‌اند تکرار بد است یا باید برای reuse طراحی کنی. در حالی‌ که در بسیاری از موقعیت‌ها بهترین کار این است که ابتدا با ساده‌ترین راه‌حل شروع کنیم و بعد، وقتی چند بار نیاز تکرار شد و الگو روشن شد، سراغ abstraction برویم.

به جای پیش‌بینی آینده، باید برای تغییر آماده باشیم. به جای اینکه یک معماری عمومی از روز اول طراحی کنیم، بهتر است ساختار را طوری بچینیم که refactor راحت باشد. یعنی اول مسأله را حل کنیم، بعد اگر دیدیم الگو دارد تکرار می‌شود، abstraction را بسازیم.

آیا ما واقعاً می‌خواهیم برای آینده‌ای که هنوز نیامده هزینه بدهیم؟ یا می‌خواهیم امروز ساده شروع کنیم و اجازه بدهیم کد و معماری با واقعیت رشد کند؟

✍🏻 Kayvan Alimohammadi

❤8✍5👍3

www.tgoop.com/djangolearn_ir/1107

1.92K viewsSep 1 at 13:06

چرا ذهن ما عاشق Abstraction زودهنگام است؟

خیلی وقت‌ها در تیم‌های نرم‌افزاری می‌بینیم که مهندسان خیلی زود به سراغ abstraction و generalization می‌روند. یعنی قبل از اینکه حتی نیاز واقعی شکل بگیرد، یک لایه انتزاعی طراحی می‌کنند تا برای آینده آماده باشند.

این رفتار بی‌دلیل نیست. ذهن ما از نظر تکاملی عادت دارد الگوها را سریع تشخیص دهد و تعمیم دهد. همین باعث شده است که حتی وقتی دو سناریوی مشابه می‌بینیم، ناخودآگاه به فکر ساختن یک راه‌حل عمومی می‌افتیم. در زندگی روزمره این توانایی به بقای ما کمک کرده، اما در دنیای نرم‌افزار همیشه مفید نیست.

مشکل اصلی اینجاست که وقتی زود abstraction بسازیم، سطح اشتباه را انتخاب می‌کنیم. نه آنقدر بالا که به درد بخورد، نه آنقدر دقیق که واقعاً نیاز را برطرف کند. نتیجه این می‌شود که کدی می‌نویسیم که پیچیده‌تر از چیزی است که لازم داریم، و سرعت یادگیری و تغییر را پایین می‌آورد.

در عین حال، فرهنگ و فضای آموزشی هم این عادت را تقویت می‌کند. همه جا به ما گفته‌اند تکرار بد است یا باید برای reuse طراحی کنی. در حالی‌ که در بسیاری از موقعیت‌ها بهترین کار این است که ابتدا با ساده‌ترین راه‌حل شروع کنیم و بعد، وقتی چند بار نیاز تکرار شد و الگو روشن شد، سراغ abstraction برویم.

به جای پیش‌بینی آینده، باید برای تغییر آماده باشیم. به جای اینکه یک معماری عمومی از روز اول طراحی کنیم، بهتر است ساختار را طوری بچینیم که refactor راحت باشد. یعنی اول مسأله را حل کنیم، بعد اگر دیدیم الگو دارد تکرار می‌شود، abstraction را بسازیم.

آیا ما واقعاً می‌خواهیم برای آینده‌ای که هنوز نیامده هزینه بدهیم؟ یا می‌خواهیم امروز ساده شروع کنیم و اجازه بدهیم کد و معماری با واقعیت رشد کند؟

✍🏻 Kayvan Alimohammadi

BY جنگولرن