شاید بارها شنیده باشید برنامه نویس باید ریاضی بداند یا خوب بلد باشد، در حقیقت از نظر بنده این اصل اشتباهی هست، شاید خیلی از متخصصین به این جمله حمله بکنند شایدم خیلی ها هیجان زده شده موافق این باشند ولی هدف این مقاله به دور از تعصبات و باورها بررسی نرم افزار در چارچوب فلسفه هست.
ما در دنیای واقعی مشکلات رو خیلی زود میتونیم تشخیص بدیم. حین سفر اتو رو با خودم میبرم اروپا، رسیدم و میخام بعد استراحت لباسم رو اتو کنم، اتو کار نکرد چون اروپا با 110 ولت کار میکند و دستگاه من نیاز به 220 ولت دارد، مشکل رو خیلی زود متوجه شده و یک آداپتور تهیه میکنم و ازش استفاده میکنم. در دنیای توسعه درک این مشکل و حلش سالها زمان نیاز دارد چون مشکلات رو نمیتونیم ببینیم. این یعنی جنس کار توسعه نرم افزار کلا انتزاعی هست و همیشه درک انتزاع سخت هست و برای درک انتزاع همیشه مجبور هستیم چندین و چندین مثال بیاریم تا بتونیم مطلب رو منتقل کنیم.
برای درک مشکل اتو ما نیاز به ریاضی نداریم، برای درک این مشکل نیاز به منطق داریم، هومم یعنی میخای بگی که توسعه دهنده باید منطق رو خوب بلد باشه؟ دقیقا درسته
آنچیزی که در قالب منطق باشد میتوان در فلسفه در موردش صحبت کرد!! اینجا آورده فلسفه این هست، ما چیزهایی را که مجسم نیست را میتوانیم در فلسفه اثبات و درک کنیم تا بتوانیم راه یا تصمیم درست رو بگیریم.
منطق تغییر نمیکند پس فلسفه ثابت هست! مربع در این دنیاهم مربع هست در مریخ هم مربع هست چون داریم از ذات یک موجودیت بحث میکنیم.
در دنیای توسعه اگر دقت کنید معماری های مختلفی وجود دارد ولی همه دنبال حل یک مشکل هستند. کاهش وابستگی و افزایش انسجام.
کاهش وابستگی و افزایش انسجام کاملا انتزاعی هست و اینجا ریاضی، تیز هوشی و.. کار نمیکنه، اینجا باید فلسفه این موضوعات رو درک کنیم تا بتوانیم حین توسعه اندازه گیری کنیم. همانطور که خط کش یا واحد اندازه گیری اسلام تقوا هست توی نرم افزارم هم باید خط کش رو پیدا کنیم، به همین دلیل از همان ابتدای شروع دنیای برنامه نویسی افراد زیادی سعی کردن یکسری واحد ها تعریف بکنند ولی اگر دقت کنید قابل درک به راحتی نیستن چون انتزاعی هستن، چون فلسفه رو در این موارد کنار گذاشتیم و میخاییم یه موضع انتزاعی رو بدون ابزار درک کنیم. یکسری افراد با کسب تجربه چندین ساله آروم آروم متوجه میشوند که چه چیزهایی رو باید توی نرم افزار در نظر بگیرند یا نگیرند در حالی که اگر از همان ابتدا فلسفه موضوع رو درک میکردن اینقدر هزینه نمیدادن.
هومم! یعنی اگر ما به صورت فلسفی بتونیم معماری و برنامه نویسی رو درک کنیم، میتونیم بدون پرداخت هزینه های زیاد به صراط مستقیم هدایت بشیم!! از نظر من بله، چون وقتی شما مفهوم وابستگی رو درک کنید دنبال راه چاره خواهید بود، ببینید چی دارم میگم "وقتی مفهموم رو درک کنید" یعنی مشکل رو متوجه شدی، خیلی خیلی مهمه درک مشکل اگر تو موضوع اتو مشکل رو درک نمیکردم نمیتونستم ازش استفاده کنم و مجبور بودم اتو نو تهیه کنم.
از نظر بنده درک مشکل از همه مهمتر هست، چون برای درک مشکل شما نیاز دارید تفکر کنید، کسانی که می اندیشند با کسانی که نمی اندیشند قطعا برابر نیستن! اینجا فلسفه به ما کمک میکنه به موضوع بله یا خیر بگیم، اینو جلوتر باز خواهم کرد.
رسیدم به جایی که مشکلات رو میدونیم، یعنی میدونیم حین طراحی و توسعه باید یکسری پارامترهارو رعایت بکنیم تا هزینه ندیم، ولی برای حل مشکلات راه حل میخاد اینجام یکسری قوانین میاد وسط و خود این قوانین هم باید به لحاظ منطقی و فلسفی درک شوند، مثلا قوانین سالید یا گرسپ اومدن یکسری اصل تعریف کردن، مثل اصل تک وظیفه بودن، خوب اگر نتوانید این موضوع رو به صورت فلسفی اثبات کنید و نتوانید رابطه این اصل تک وظیفه رو با کاهش وابستگی و افزایش انسجام پیدا کنید یعنی درکش نکردید فقط یه مثالی زدن تو هم در حد اون مثال درکش کردی وقتی میخای پیاده کنی میبینی مثال ایشون مورد استفاده شما نیست!!!
تو مصاحبه میپرسن سالید رو تعریف بکن، طرفم شروع میکنه ورورورورورورو جواب میده، برادر داری اشتباه میزنی چون تعریف یه چیز یه موضوع هست، درکش یه موضوع دیگه، به همین خاطر بعد استخدام میبینی یارو کلا مخالف سالید کد میزنه، بله این کارا اینجوری که دیده میشه نیست.
وقتی اصل تک وظیفه رو نگاه میکنیم، اونجوری که نوشته شده یا نشون میده نیست یعنی نوشتارش با خواندنش یه چیز نیست باید بشینی موضوع رو از بعد فلسفی بررسی کنی.
یکم میخام بازتر کنم موضوع رو. طرف میاد اصل تک وظیفه رو میخونه بعدش وارد دنیای توسعه میشه و شروع میکنه یه کلاس پرینت مینویسه که داخلش دیتا رو پرینت میکنه ذخیره میکنه حتی لاگ میکنه حتی مدیریت استثنا میکنه، از دید این شخص این کلاس تک وظیفه هست و کارهایه مربوط به پرینت رو میکنه از دید ایشون خیلی منطقی هست ولی دلیل این اشتباه مهلک عدم درک انسجام و پیچیدگی و وابستگی هست .اینم بگم برنامه نویسی که با چنین منطقی کد میزنه خطرناکتر از داعش هست. جرات داری بهش بگو بالا چشت ابرو هست، بله دوستان میخام بگم باید با دید فلسفی نزدیک بشیم و بعد درکش استفاده کنیم.
جمله "خوب اینم که کار میکنه چرا باید اسم هارو صحیح بنویسم یا ..." اینو من باز نکنم چون ذاتا آدم بد دهنی هستم چیزی نگم چون مجبورم میشم صفحه رو ببندم برم.
کسی که درک فلسفی از تک وظیفه بودن نداشته باشه فکر میکنه باید یه کلاس تک وظیفه باشد ولی وقتی درک درست باشد میگه یه سطر کد باید تک وظیفه باشد بالاتر یه فانکشن بالاترش کلاس بالاترش پکیج بالاترش خود اپلیکیشن، اگر سوالت اینه یه اپلیکشن چطوری میتونه تک وظیفه باشه یعنی درک درست نداری از تک وظیفه بودن. وقتی این مفاهیم رو از بعد فلسفی تحلیل میکنی میگی میکروسرویس چیز جدیدی نیست که چون داره اصل تک وظیفه رو ارضا میکنه!!! هومم ببین گفتیم منطق ثابت هست و تغیر نمیکنه این برداشت های اشتباه ماست که موضوع رو تغیر میده.
اصل تک وظیفه و انسجام بیشتر، در معماری به شما میگه مدیریت خطا یه موجودیت عمومی هست یا لاگ گیری یه موجودیت عمومی هست و باید اینارو یکجا آنجام بدی نه که هر کلاسی یا بلوک کدی، بیاد از کنترل استثنا استفاده بکنه، میای میرسی به لایه اپلیکیشن و آسپکت ها و کراس کاتینگ کونسورن ها!! چیزی که معماری دامین ازش بحث میکنه!! ولی اینم چیز جدیدی نیست فقط موضوع انتزاعی رو آورده مجسم کرده وقتی میبینی میگی آره خیلی کار خفنی هست! حالا اینم یه چیزیه، چون خیلی ها مفهوم لایه اپلیکیشن و دامین رو نمیدونن و ماستارو میریزن تو قیمه!! اگر دنبال ساخت یه چیز مهندسی شده باشیم در دنیای نرم افزار باید به صورت فلسفی قوانین رو درک کنیم مشکلات رو درک کنیم بعدش میتونیم راه حل هارو بررسی کنیم ولی راه حل هایی که قرار هست بهش برسیم یکی هست چون صراط مستقیم یکی هست.
مختصری از راه حل ها بحث کنم! خود اینم باز انتزاعی هست یه جایی راه حل در سطح معماری مورد بحث هست که پترنهای معماری رو بررسی میکنیم یه جایی در سطح کد هست دیزاین پترن هارو بررسی میکنیم ولی حتی اگر راه حلهای عمومی که درجهان تا به امروز پیشنهاد شده رو ندونید یا استفاده نکنید ولی چون درک درست دارید به جایی که میرسید همین پترنها هستن. شما یه جایی آبجکت هایی دارید که باید از هم دیگه استفاده بکنند و این باعث افزایش پیچیدگی میشه و این یه مشکل هست باید حلش کنی میای از پترن مدیتور استفاده میکنی یا آبزرور ... حالا اگر این پترن هارو ندونی و بخای حلش کنی در نهایت یه همچین پترنی رو خود به خود بهش میرسی.
پترن فساد رو تعریف کنید باز شروع میکنه ورورورورورور !!! اگر ندونی مشکل رو هیچ وقت پترن رو نمیتونی استفاده کنی و اگر مشکل درک بشه فلسفه پشتش درک نشه باز نمیشه!!! چی گفتیم؟ کلی آبجکت هست باید از هم باخبر باشند!! مشکل جلو چشت هست اینجا پیچیدگی بالاست و باید رفعش کنی، وابستگی رو بیاری پایین، ولی بدون درک کوهیژن مشکل رو نمیتونی ببینی و آش درست میکنی برادر. در صورت درک صحیح، سریع میای دنبال پترن هایی که وابستگی رو کاهش میدن مثل مدیتور و استفاده میکنی، بیشتر برنامه نویس ها پترن هارو بارها خوندن ولی چیزی ازش متوجه نشدن، پترن آداپتور ورورورورورورورو خوب فهمیدم ولی کجا باید استفاده کنم!!! برادر پترن اومده مشکلی رو حل بکنه ، شما مشکل رو درک نکردی که بخای راه حلش رو درک کنی. یعنی میخاد دوستمون از راه حل به مشکل برسه از مشکل به منطق برسه و بعدش فلسفش رو درک کنه!!! بله میشه و نود درصد برنامه نویس ها همین کارو میکنن ولی بعد از تجربه چندین ساله و دادن هزینه های سنگین، چندین سال با کدهاشون اینو اونو کور میکنن بعدش میفهمن داستان چیه اونم همش رو نه کمی تا نیمه ابری.
توی فلسفه از جز به کل میشه رسید و از کل هم به جز میشه رسید ولی اولی خیلی سخته، به علامه طباطبایی میگن ایشون از جز میتونن به کل برسند جواب میده مزاح میکنن!!! مثل این میمونه بهتون فرمان رو بدم و بعدش سوال کنم چه مشکلی رو از چه چیزی حل میکنه؟!!
برای شروع میشه از این جمله پایین شروع کرد به نظرم.
آنچیزی که تعیین موجودیت میکند نفس سیستم هست.
در تعریف موجودیت انسان، انسان دوتا پا دارد تعیین موجودیت نمیکنه چون کلی حیوان هم دوتا پا دارد!! یک پروژه رو آن چیزی که تعیین موجودیت میکند، باید آنها را در برنامه توسعه قرار داد و الا خاسته های نفس قابل ارضا نخواهد بود. موجودیت هارا باید درست بشناسیم و آنچیزی که تعیین موجودیت میکنه رو پیاده سازی کنیم. قانون همه یا هیچ در تعیین موجودیت صادق هست.
سوال : در یک سیستم بانکی آیا تماس با مشتری یا ارسال پیامک تعیین موجودیت میکند؟
در صورت درک منطق این نوشته، ذات میکروسرویس قابل هضم خواهد بود.
در مقالات بعدی شاید بتونم دونه دونه قوانین" سالید،گرسپ،دیزاین پترن ها ، پترن های معماری" رو به لحاظ فلسفی باز کنم در این مقاله فقط خواستم به مهم بودن فلسفه در توسعه نرم افزار بپردازم.
