{{serviceMessage.text}}
مدت زمان تقریبی مطالعه: ۶ دقیقه   |   نویسنده:‌ فرانش

۵ اصل کلیدی برای توسعه‌دهنده‌های وب

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

من فکر می‌کنم چیزهای زیادی هست که ما می‌توانیم علی‌رغم تفاوت شاخه‌ی کاریمان از یکدیگر یاد بگیریم. بنابراین من به عنوان یک توسعه‌دهنده‌ی رابط کاربری (front‑end developer)، در اینجا پنج اصل کلیدی را آورده‌ام که روش کاری مرا دگرگون کرد:

۱. هر چیزی یک چرخه‌ی زندگی دارد

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

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

این همان چیزی است که باید اتفاق می‌افتاد. اما از آن موقع یاد گرفتم که به هر بخش از این چرخه‌ی حیات احترامی را که سزاوار است بگذارم. توسعه‌دهندگان از مخفف CRUD زیاد استفاده می‌کنند، که کوتاه‌شده‌ی واژگان Create (ایجاد)، Read (خواندن)، Update (به‌روزرسانی) و Delete (حذف) است؛ این‌ها چهار عملکرد اصلی هر قطعه اطلاعات است. بگذارید آن را کمی تعمیم بدهم:

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

۱. بعضی چیزها خراب می‌شوند و بعضی چیزها پیچیده و بغرنج

من یک نظریه دارم که اسمش را گذاشته‌ام «چرخه ی حیات 10 مرحله ای CMS (سیستم مدیریت محتوا).»

  1. یک توسعه‌دهنده‌ی دون‌پایه، در حالی که رو به مانیتورش فحش می‌دهد، دارد «قابلیتی که بد طرح‌ریزی شده» را در «یک CMS که حتی از آن هم بدتر معماری شده»، پیاده می‌کند.
  2. توسعه‌دهنده‌ی دون‌پایه‌ی، این ادعای جسورانه را می‌کند که «خودم می‌توانستم این کار را خیلی بهتر انجام بدهم،» در حالی که متوجه می‌شود همه‌ی همکارانش دارند به خشمش می‌خندند و درمورد آن توییت می‌کنند.
  3. توسعه‌دهنده‌ی دون‌پایه‌ی ما (در حال حاضر معمار ارشد) یک CMS جدید می‌سازد.
  4. CMS جدید یک سیستم انقلابی ستایش‌برانگیز است که کار با آن خیلی راحت و ساده است.
  5. از معمار یا سازنده‌ی اصلی تقدیر می‌شود، اما از او می‌خواهند که یک قابلیت کوچک را هم اضافه کند.
  6. از معمار یا سازنده‌ی اصلی تقدیر می‌شود، اما از او می‌خواهند که یک قابلیت کوچک را هم اضافه کند.
  7. از معمار یا سازنده‌ی اصلی تقدیر می‌شود، اما از او می‌خواهند که یک قابلیت کوچک را هم اضافه کند.
  8. از معمار یا سازنده‌ی اصلی تقدیر می‌شود، اما از او می‌خواهند که یک قابلیت کوچک را هم اضافه کند.
  9. به معمار اصلی گفته می‌شود که این قابلیت جدید حتی از قابلیت قبلی هم مهمتر است.
  10. یک توسعه‌دهنده‌ی دون‌پایه، در حالی که رو به مانیتورش فحش می‌دهد، دارد «قابلیتی که بد طراحی شده» را در «یک CMS که حتی از آن هم بدتر طراحی شده»، پیاده می‌کند.

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

من همیشه از خودم این چند سوال مفید را می‌پرسم:

  • آیا قبلا کسی آن را امتحان کرده؟
  • اگر دارم چیزی را درست می‌کنم، از کجا مطمئن شوم که مشکل اصلی برطرف شده؟
  • چقدر وقت لازم دارم تا زمانی که ارزشی واقعی به‌دست بیاید؟

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

۳. باید (بارها) جلوی خودت را بگیری که تکرار نکنی

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

مسئله این است: تعداد زیادی کد کارخانه ای (factory‑generated code) وجود دارد که به تدریج تبدیل به ملغمه‌ای می‌شود از «چیزهایی که یک کاری می‌کند». در آن سوی ماجرا، آدم‌هایی مثل من هستند که فهرست بی‌پایانی از کدهای اسنیپت را که هرگز دوباره استفاده نمی‌شوند می‌دارند. به هر کدام از این دو سو تمایل داشته باشید، فرقی ندارد، مبارزه‌ی ما برای یافتن ارزش است.

DRY مخفف عبارت Don't Repeat Yourself (خود را تکرار نکنید) و SRP مخفف عبارت Single Responsibility Principle (اصل تک‌مسئولیتی) ، ما را وادار می‌کند به اهمیت همان بخشی از کار که داریم ایجاد می‌کنیم، فکر کنیم.

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

ادغام این دو اصل و تزریق اندکی عمل‌گرایی (pragmatism) و تجربه، به من کمک کرد تا به راهکارهای خوبی که به دنبالشان بودم، نزدیکتر شوم. اما تجربه‌ی لازم برای تشخیص سطح متناسبی از عمل‌گرایی را از کجا بیاوریم؟ من به آمیزه‌ای از این موارد متوسل می‌شوم:

  • تمرین
  • خواندن
  • شکست خوردن و دوباره برخاستن
  • تمرین
  • صحبت با افرادی که از ما بهتر هستند

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

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

    1. می‌توانید در آینده از آن به عنوان مرجع استفاده کنید (و خواهید کرد).
    2. خودِ عملِ نوشتن واژه‌ها، کمک می‌کند جنبه‌های کلیدی چیزهایی که باید به به خاطر بسپارید در ذهن حک شود.
    3. گاهی باعث گفتگو با کسانی می‌شود که آن را می‌خوانند، که باز هم کمک می‌کند دانش کسب کنید و به خاطر بسپارید، و حتی جرقه‌ی پیشرفت در آینده را می‌زند.

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

۴. باید فکرت را توضیح بدهی

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

خیلی خوب است که پی ببرید کارتان مشکل دارد و شاید بهتر است به شکلی دیگر به آن فکر کنید. راه‌های دیگری وجود دارد که می‌توانید آنها را کشف کنید. بنابراین آنچه درونتان می‌گذرد را به دیگران توضیح دهید.

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

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

۵. همه چیز را ساده نگه دارید

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

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

گاهی باید صبور باشید. یاد بگیرید به هشدارها توجه کنید و نترسید که برگردید و جلوی زیان بیشتر را بگیرید. هیچ‌چیز هرگز کاملاً به هدر نمی‌رود.

  • نقطه‌ی تمرکز کنونی را بشناسید
  • شروع کنید و به پایان برسانید
  • چیزها را ساده توضیح دهید

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

نتیجه‌گیری

من چیزهای زیادی را فقط با فکر کردن به آنها و بررسی آنها با جزئیات هر چه بیشتر به دست آوردم. ظرافت‌های بسیاری وجود دارد، که می‌توانیم با کاوش و تجربه به آنها برسیم.

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

منبع: CreativeBlog