✨ این پست در مورد چیست: به عنوان بخشی از رشد حرفه ای خود، برای تماشای گفتگوهای فنی وقت می گذارم. قبلاً فقط آنها را تماشا می کردم، اما اکنون یادداشت برداری می کنم و برای مراجعات بعدی منتشر می کنم.
✨ صحبت: “Simple Made Easy” نوشته ریچ هیکی
✨ خلاصه یک بند: ریچ هیکی، نویسنده Clojure و طراح Datomic، یک توسعه دهنده نرم افزار با بیش از 30 سال تجربه در حوزه های مختلف است. ریچ روی سیستم‌های زمان‌بندی، اتوماسیون پخش، آنالیز صدا و انگشت نگاری، طراحی پایگاه داده، مدیریت بازده، سیستم‌های نظرسنجی خروجی و گوش دادن ماشینی به زبان‌های مختلف کار کرده است. این سخنرانی کلیدی در Strange Loop 2011 ارائه شد و شاید شناخته شده ترین و مورد توجه ترین سخنرانی های بسیار عالی ریچ باشد که راه جدیدی را برای اندیشیدن در مورد مشکلات طراحی نرم افزار و مبارزه مداوم با پیچیدگی ایجاد می کند.
✨ احساس؛ عقیده؛ گمان: من این صحبت را دوست داشتم. غذای زیادی برای فکر کردن، هم در رابطه با کار مهندسی و هم در رابطه با روابط توسعه دهنده. با وجود اینکه این سخنرانی بیش از یک دهه پیش ارائه شد، اما بسیاری از نکات هنوز بسیار مرتبط هستند – و بسیاری از بحث ها هنوز ادامه دارد. این نشان می دهد که چقدر این گفتگو برنامه ریزی شده بود، اما همچنین نشان می دهد که برخی موضوعات در گفتمان جامعه فناوری جهانی هستند.
معرفی
- اگر می‌خواهیم سیستم‌های خوب بسازیم، باید سیستم‌های ساده بسازیم».
- ریشه های کلمه
- ساده – ریشه ها “sim” و “plex” هستند که به معنی “یک چین” یا “یک بافته” است.
- پیچیده – در ریشه به معنای “بافته شدن با هم” است
- آسان – در ریشه، به معنای “دراز کشیدن” (در مجاورت) است.
- سخت – در ریشه، به معنای “قوی” است
“ساده”
- چیزهای ساده مانند یک دسته هستند: آنها یک نقش، یک وظیفه، یک هدف، یک مفهوم دارند. آن متمرکز است
- ممکن است نمونه‌های زیادی از یک چیز ساده وجود داشته باشد – و تا زمانی که این نمونه‌ها با هم ترکیب نشوند، ساده می‌ماند.
- سادگی را می توان به طور عینی بیان کرد
- یادداشت جانبی من: ساده زبان افسانه هاست
“آسان”
- چیزهای آسان نزدیک، در دست، آسان به دست آوردن، آنها در دسترس هستند. در نرم افزار، دسترسی آسانی مانند هارد دیسک، مجموعه ابزار، IDE ما خواهد بود
- چیزهای آسان نزدیک به درک ما هستند، مهارت ما، آشنا هستند
- یادداشت جانبی من: آسان سوئدی است زیرا برای من شبیه انگلیسی و آلمانی است
- چیزهای آسان نزدیک به توانایی های ما هستند
- آسان نسبی است، بستگی به زمینه ای دارد که یک فرد دارد
ساخت و ساز در مقابل مصنوع
- Construct: “ما با ساختارها برنامه نویسی می کنیم. ما زبان های برنامه نویسی داریم. ما از کتابخانه های خاصی استفاده می کنیم، و آن چیزها، به خودی خود، وقتی به آنها نگاه می کنیم، مانند زمانی که به کدهایی که می نویسیم نگاه می کنیم، به خودی خود ویژگی های خاصی دارند. “
- مصنوعات: “اما ما در تجارت مصنوعات هستیم. ما کد منبع را ارسال نمی کنیم، و کاربر به کد منبع ما نگاه نمی کند و نمی گوید: “آه، این خیلی خوشایند است.” آنها نرم افزار ما را اجرا می کنند و آنها را اجرا می کنند. آن را برای مدت زمان طولانی اجرا کنید. (…) همه آن چیزها، اجرای آن، عملکرد آن، توانایی تغییر همه آن، ویژگی مصنوع است، نه ساختار اصلی.”
- ما بیش از حد روی ساختار (زبان های برنامه نویسی) تمرکز می کنیم
- حتی اگر کاربران شیفته این مصنوع (مثلاً رابط کاربری) هستند، توسعه دهندگان بر ساختار (کتابخانه) تمرکز می کنند.
- کارفرمایان ما نیز شیفته “آسانی” ساختار هستند – جایگزین کردن یک برنامه نویس “آسان” است و این برنامه نویس می داند که چگونه در پایگاه کد حرکت کند و از ابزارها استفاده کند زیرا آنها “آسان” هستند – نزدیک به زمینه و آشنا. (اگرچه لزوماً آسان نیست به این معنا که آیا شخص توانایی کدنویسی در این پایگاه کد را دارد یا خیر)
- ما باید روی نتایج بلند مدت استفاده از مصنوع تمرکز کنیم
- آیا نرم افزار کاری را که قرار است انجام دهد انجام می دهد؟
- کیفیت بالایی داره؟
- آیا می‌توانیم برای انجام کاری که قرار است انجام دهد به آن تکیه کنیم؟
- آیا می‌توانیم مشکلات را در صورت بروز برطرف کنیم؟
- و اگر نیاز جدیدی به ما داده شود، آیا می توانیم آن را تغییر دهیم؟
- نتیجه گیری: باید سازه ها را بر اساس مصنوعاتشان ارزیابی کنیم
- یادداشت جانبی من: این یک قاب واقعا جالب است. برای من، این واقعاً مفید است، زیرا من خیلی به این فکر کرده‌ام که چقدر در مورد برخی از کتابخانه‌ها (مثلاً React) صحبت می‌شود و صحبت‌های کمی در مورد عدم دسترسی به رابط کاربری حاصل شده است.
کار با محدودیت
- فقط چیزهایی که می توانیم بفهمیم می توانیم قابل اعتماد کنیم
- هرچه مطالب توسعه پذیرتر، انعطاف پذیرتر و پویاتر باشند، توانایی ما برای درک آن ها بیشتر است.
- ما فقط می توانیم چند چیز را در یک زمان در نظر بگیریم. این تعداد محدود است
- “اگر چیزها با هم در هم تنیده شوند، ما توانایی جدا کردن آنها را از دست می دهیم.”
- هر درهم تنیدگی بار بیشتری را اضافه می کند – و درهم تنیدگی (بافته کردن چیزها با هم) توانایی ما را برای درک سیستم ها محدود می کند.
- نتیجه: پیچیدگی درک را تضعیف می کند
تغییر چیزها
- “تأثیر این تغییر بالقوه چیست؟”: اگر می خواهید نرم افزار را تغییر دهید، باید آنچه را که انجام می دهد تجزیه و تحلیل کنید و در مورد کارهایی که باید انجام دهد تصمیم بگیرید.
- “و چه بخش هایی از نرم افزار باید بروم تا تغییر ایجاد کنم؟”: اگر نمی توانید در مورد برنامه خود استدلال کنید، نمی توانید بدون ترس این تصمیم ها را بگیرید.
- وقتی نرم‌افزار داریم، دو کار انجام می‌دهیم: قابلیت‌ها را اضافه می‌کنیم و مواردی را که کار نمی‌کنند اشکال‌زدایی می‌کنیم
- شوخی خوب در مورد اشکال زدایی در ساعت 15:43
- اگر ما نتوانیم برنامه خود را بفهمیم، آزمایش ها بی فایده هستند. آنها ممکن است در نهایت ما را شکست دهند
- یک شوخی خوب دیگر، این بار در مورد چابک، در ساعت 17:27، و من قصد دارم آن را در اینجا نقل کنم: > چه نوع دونده ای می تواند از همان شروع یک مسابقه به همان سرعتی که ممکن است بدود؟ دونده سرعت، فقط کسی که مسابقات واقعاً کوتاه را می دود، باشه؟ اما البته، ما برنامه‌نویس هستیم و ظاهراً از دونده‌ها باهوش‌تر هستیم، زیرا می‌دانیم چگونه این مشکل را برطرف کنیم، درست است؟ ما فقط هر صد یارد تپانچه شروع را شلیک می کنیم و آن را یک سرعت جدید می نامیم.
- اگر پیچیدگی را نادیده بگیرید، در مدت طولانی سرعت خود را کاهش خواهید داد
- اگر روی سهولت تمرکز کنید، می‌توانید از ابتدای مسابقه با بیشترین سرعت ممکن پیش بروید، اما پیچیدگی در نهایت شما را به دست می‌آورد، و در هر دوی سرعت بعدی کمتر به نتیجه خواهید رسید، و در نهایت کارهایی را که انجام داده‌اید دوباره انجام خواهید داد. در حال حاضر انجام شده است، “و اثر خالص این است که شما به هیچ وجه به سمت جلو حرکت نمی کنید.”
آسان اما پیچیده
- برخی از چیزهایی که آسان هستند در واقع پیچیده هستند
- به اختصار شرح داده شده اند
- آنها آشنا هستند
- آنها در دسترس هستند
- آسان برای استفاده
- کاربران به پیچیدگی زیربنایی اهمیت نمی دهند، آنها به آنچه برنامه انجام می دهد اهمیت می دهند
- آیا نتیجه کار شما در پیچیدگی غرق شده است؟
- مزایای سادگی:
- سهولت درک
- سهولت تغییر
- سهولت اشکال زدایی
- افزایش انعطاف پذیری (تغییر چیزها در اطراف) – مدولار بودن
- آیا تغییر قلعه بافتنی آسان تر است یا قلعه لگو؟
آسان کردن کارها
- آن را در دسترس قرار دهید – نصب آسان، تأیید آسان
- آن را آشنا کنید – این یک تمرین یادگیری است
- آن را ساده کنید تا درک آن آسان باشد، ما در توانایی خود برای درک پیچیدگی محدود هستیم
- نکته خوب در مورد پرنس در Clojure: مواردی وجود دارد که می توانید حل کنید (آشناتر شوید، استفاده از ابزار را شروع کنید) و برخی را که نمی توانید (ابزار پیچیده است)
- توسعه دهندگان ارزش همه چیز و هزینه هیچ چیز را نمی دانند (بازنویسی شده از: “برنامه نویسان LISP ارزش همه چیز و هزینه هیچ چیز را می دانند” از آلن پرلیس) – ما در مورد مزایا زیاد صحبت می کنیم، اما نه مبادله
- از پیچیدگی اجتناب کنید (با هم جمع و جور نکنید)
- در عوض، بنویسید (با هم قرار دهید)
- ترکیب اجزای ساده کلید سیستم های قوی است
- این فقط در مورد مدولارسازی نیست
- حالت هرگز ساده نیست، اما آسان است (آشنا، در دسترس)
- شما به این همه پیچیدگی نیاز ندارید. شما می توانید یک سیستم پیچیده با ابزارهای ساده بسازید – می توانید به جای ساختارها، روی سیستم تمرکز کنید، آنچه قرار است انجام دهد.
- اگر تصمیمی باید توسط شخصی گرفته شود که زمینه بهتری دارد، آن سیستم ساده نیست.
نکات اصلی پیچیدگی
| ساختن | کامل می کند |
|---|---|
| حالت | هر چیزی که آن را لمس می کند |
| اشیاء | دولت، هویت، ارزش |
| مواد و روش ها | تابع و حالت، فضاهای نام |
| نحو | معنی، سفارش |
| وراثت | انواع |
| سوئیچینگ/تطبیق | چند جفت who/what |
| متغیرها | ارزش، زمان |
| حلقه های تاثیرگذار | چه چیزی / چگونه |
| بازیگران | چه چیزی / چگونه |
| ORM | همه چيز |
| شرایط | چرا، ساختار برنامه |
این موارد را می توان با موارد ساده تر زیر جایگزین کرد:
| ساختن | دریافت کنید از طریق … |
|---|---|
| ارزش های | مجموعه های نهایی و ماندگار |
| کارکرد | روش های بی تابعیت |
| فضاهای نام | پشتیبانی از زبان |
| داده ها | JSON، نقشه ها، مجموعه ها، آرایه ها، xml |
| پلی مورفیسم A la carte | پروتکل ها، کلاس های نوع |
| داوران مدیریت شده | زبان هایی مانند Clojure |
| توابع را تنظیم کنید | کتابخانه ها |
| دم | کتابخانه ها |
| دستکاری داده های اعلامی | SQL |
| قوانین (سیستم اعلامی قوانین) | کتابخانه ها |
| ثبات | معاملات، ارزش ها |
داده ها در واقع واقعا ساده هستند. تعداد زیادی تغییرات در ماهیت اساسی داده ها وجود ندارد: نقشه ها، مجموعه ها، چیزهای خطی و متوالی وجود دارد. دسته بندی مفهومی دیگری از داده ها وجود ندارد. ما صدها هزار تنوع ایجاد می کنیم که هیچ ارتباطی با ماهیت این چیزها ندارند و نوشتن برنامه هایی را که ماهیت چیزها را دستکاری می کنند دشوار می کند. ما فقط باید ماهیت چیزها را دستکاری کنیم. سخت نیست. ساده تر است.
انتزاع برای سادگی
- انتزاعی (به معنای دور شدن از ماهیت فیزیکی آن)
- “انتزاع” گاهی اوقات به معنای پنهان کردن پیچیدگی به کار می رود، اما موضوع این نیست
- اگر می خواهید چیزها را جدا کنید، به یک مفهوم نگاه کنید و بپرسید که چه کسی، چه چیزی، چه زمانی، کجا، چرا، چگونه
- چی
- عملیات چیست؟ چه چیزی را می خواهیم انجام دهیم؟
- اگر “چه” را از “چگونه” جدا کنید، می توانید “چگونه” را مشکل شخص دیگری ایجاد کنید
- سازمان بهداشت جهانی
- داده ها یا موجودیت ها – اینها چیزهایی هستند که انتزاعات ما در نهایت بسته به نحوه عملکرد فناوری شما به آنها متصل می شوند.
- بسیاری از مولفه های فرعی را دنبال کنید تا با رابط های کوچک کار کنید
- چگونه
- نحوه انجام کار – منطق پیاده سازی
- از طریق چند شکلی به انتزاعات و موجودیت ها متصل شوید
- انتزاعی‌هایی را ترجیح می‌دهند که چگونگی را تعیین نمی‌کنند (اعلامی خوب هستند)
- کی کجا
- با طراحی کامل نکنید (اگر A باعث B شود، شما پیچیده هستید – به جای آن از صف استفاده کنید)
- چرا
- خط مشی و قوانین برنامه
- اغلب در همه جا پراکنده می شود
اطلاعات ساده است
- خرابش نکن
- فضای مشکل یا کدی را که شخص دیگری نوشته است با جداسازی ساده کنید:
- شناسایی موضوعات/نقش/ابعاد فردی
- دنبال کردن داستان کاربر
- سادگی یک انتخاب است – اگر یک سیستم ساده ندارید تقصیر شماست
- شما به هوشیاری، حساسیت و مراقبت نیاز دارید
- آسان ساده نیست. ساده چیزی است که در هم پیچیده نیست.
سادگی آسان شده است
- سازه های ساده را به سازه های پیچیده زا انتخاب کنید
- این مصنوعات است، نه نویسنده
- انتزاعات ساده ایجاد کنید
- قبل از شروع، فضای مشکل را ساده کنید
- ساده سازی یعنی ساختن چیزهای بیشتر، نه کمتر
