لینک کوتاه مطلب : https://hsgar.com/?p=3617

کد در مقابل بدون کد | جیسون موریس

این هفته یک مکالمه در توییتر وجود داشت که به روشن شدن تفکر من در مورد چیزی کمک کرد و من می خواستم به اشتراک بگذارم.

نوعی تنش بین راه‌حل‌های «کد» و «بدون کد» (گاهی اوقات «کد پایین») وجود دارد.

افرادی که خود را توسعه‌دهنده نرم‌افزار می‌دانند، افرادی را می‌بینند که سعی می‌کنند از راه‌حل‌های بدون کد برای انجام کارهایی استفاده کنند که راه‌حل‌های بدون کد در آنها خوب نیستند، و از اینکه توانایی‌های آن ابزارها بیش از حد برآورد شده است، ناامید می‌شوند.

آنها چیزی را می گیرند که واقعاً در حال رخ دادن است، و آن را واقعاً اشتباه تفسیر می کنند. درک چگونگی و چرایی آن مفید و مهم است.

منحنی پیچیدگی/تلاش

بیایید جهان را ساده کنیم، و وانمود کنیم که تلاش یک بعد واحد است، جایی که همه چیز در یک طیف واحد همیشه «سخت‌تر» یا «آسان‌تر» است. بیایید جهان را نیز ساده کنیم و وانمود کنیم که پیچیدگی پروژه نرم افزاری نیز در یک بعد واحد است که از «ساده» به «پیچیده» می رسد. هیچ یک از این موارد درست نیست، اما به تظاهر کمک می کند.

اگر این چیزها درست باشد، پس هر ابزار نرم افزاری، چه یک زبان برنامه نویسی، یک برنامه یا یک راه حل بدون کد که جایی در وسط بین این دو قرار دارد، دارای منحنی تلاش/پیچیدگی است. این خط نشان می دهد که استفاده از این ابزار برای یک کار با پیچیدگی مشخص چقدر دشوار است.

همه ابزارها یک خط با همبستگی مثبت دارند، اما شکل خط متفاوت خواهد بود. اگر یادگیری یک ابزار بسیار سخت باشد، اما بسیار قدرتمند باشد، از بالا شروع می شود و سریعتر صاف می شود. مثلاً یک زبان برنامه نویسی.

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

حال، اگر فردی هستید که هم زبان های برنامه نویسی را می شناسید و هم هیچ ابزار کدی را نمی شناسید، این یک مشکل ساده به نظر می رسد. ترکیب این دو خط به این شکل است و می توانید سطح پیچیدگی آنها را مشاهده کنید.

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

این چیزی نیست که اتفاق می افتد. در ذهن فردی که از ابزارهای بدون کد استفاده می کند و برنامه نویس نیست، این چیزی است که اتفاق می افتد.

آنها شکل منحنی برنامه نویسی را نمی دانند، زیرا که چیزی است که آنها نداشته اند استفاده شده. آنها ممکن است منحنی ابزارهای بدون کد را کاملاً درک نکنند، اما قطعاً آن را بهتر درک می کنند.

با توجه به این اطلاعات، چه تصمیمی می گیرید؟

بدیهی است که از ابزاری که دارید استفاده خواهید کرد.

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

تلاش زیادی برای رسیدن به این سطح جدید از پیچیدگی وجود دارد و برای هر ابزار، سطح راحتی دارند.

بنابراین اگر شخصی را تصور کنید که قبلاً از ابزار بدون کد برای چیزی استفاده کرده است، اما قبلاً از کد استفاده نکرده است، چگونه محاسبه را انجام می دهد؟

اگر می‌خواهید ناراحتی ناشی از ندانستن کاری که انجام می‌دهید به حداقل برسانید، مدت‌ها پس از اینکه دیگر بهترین ابزار برای کار نیستند، به استفاده از ابزارهایی که می‌شناسید ادامه خواهید داد. و هر بار که این کار را انجام می دهید، هزینه ظاهری استفاده مجدد از همان ابزار را کاهش می دهید.

پس چه کنیم؟

ما باید به مردم بگوییم که خط آبی کجاست، درست است؟ ما باید مردم را بهتر آموزش دهیم که چه ابزارهایی برای چه چیزی خوب هستند.

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

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

بنابراین در یک دنیای ایده آل، چیزی که ما نیاز داریم ابزارهایی است که منحنی تلاش/پیچیدگی داشته باشند که هم قابل مشاهده باشد و هم به شکل زیر باشد:

چگونه آن را انجام دهید؟

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

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

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

مشکل اصلی دیگر این است که چگونه از گران شدن پیچیدگی جلوگیری می کنید؟

این کمتر آشکار است. ویژگی دامنه می تواند کمک کند، زیرا می توانید بگویید “اگر بیشتر می خواهید، به جای دیگری بروید” و سپس ابزارهایی را ترکیب کنید که هر کدام یک کار کوچک را به خوبی انجام می دهند. گره زدن ابزارهای بدون کد به یکدیگر، به روشی بدون کد، ایده اصلی پشت ابزارهایی مانند Zapier است که بسیار موفق بوده اند. اما مردم ناگزیر می‌خواهند کارهای بیشتری انجام دهند و پشتیبانی در رابط ساده‌شده سخت‌تر می‌شود.

احتمال دیگری که من با Blawx دنبال می‌کنم این است که لازم نیست فقط یک ابزار باشد. شما می توانید ابزار بدون کد مبتدی را داشته باشید که به فرد یاد می دهد از ابزار کد پیشرفته استفاده کند. Blawx به کاربر این امکان را می دهد که ببیند چه کد s(CASP) برای آنها نوشته شده است. به این ترتیب، استفاده از Blawx می تواند s(CASP) را به شما آموزش دهد، و زمانی که به محدودیت های آن می رسید کمتر در داخل ابزاری که از قبل می دانید گرفتار می شوید. اما راه‌حل‌های تجاری بدون کد اغلب نمی‌خواهند مشتریانشان از این طریق فرار کنند، بنابراین انتظار از راه‌حل‌های تجاری بدون کد ممکن است واقع بینانه نباشد.

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

من چیزی از این دست ندیدم، این فقط یک ایده است.

احتمال دیگر این است که زبان‌های برنامه‌نویسی قبلاً نوعی منحنی تلاش/پیچیدگی بهینه در انتهای پیچیدگی بالا داشته باشند، بنابراین اگر بتوانیم شروع منحنی را برای یک زبان برنامه‌نویسی واقعی پایین بیاوریم، مشکل حل می‌شود.

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

هیچ کس، که من از او اطلاع دارم، سعی نمی کند یک زبان برنامه نویسی بسازد که از نظر پیچیدگی از زبان برنامه نویسی مناسب برای بچه ها تا زبان برنامه نویسی همه منظوره باشد.

نکته

نکته این است که اگر مردم تصمیم دارند کاری را به یک روش انجام دهند، نه راه «بهتر»، مشکل هرگز با مردم نیست، مشکل از راه «بهتر» است. مردم کمترین هزینه را انجام می دهند، اما هزینه ها با استرس، ابهام، تلاش و تجربه انسانی سنجیده می شود.

یک چکش را در نظر بگیرید. چکش برای انجام یک کار خاص طراحی شده است. در چارچوب آن چیز، نحوه استفاده از آن واضح است. اما بیشتر از آن، وقتی آن را برمی دارید، می توانید به طور شهودی احساس کنید که اکنون که بدون آن نبودید، چه توانایی هایی دارید. می توانید تصور کنید که از آن برای انجام کارهای ساده و کارهای پیچیده استفاده کنید. و شما می توانید تصور کنید، و شاید حتی آرزو داشته باشید که در استفاده از آن بهتر شوید.

این تجربه ای است که هر ابزار نرم افزاری باید آرزویش را داشته باشد. آشکارا ارزشمند، آشکارا مقیاس پذیر، شهودی. یادگیری آن باید شبیه بازی باشد.

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

بدون شک می‌توان قدرتی را که در اختیار داریم، به اشتراک گذاشت، بدون اینکه مردم را مجبور کنیم از آنچه برای به دست آوردن آن گذشتیم. یادگیری انتزاع و رسمی سازی به طور غیر قابل جبرانی سخت است. هر چیز دیگری را می توان آسان تر کرد.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.