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

اما با این اتفاق، سؤالاتی مطرح می‌شود که چه کسی از این برنامه‌ها پشتیبانی می‌کند؟ و اگر درخواست ویژگی یا اشکالی وجود داشته باشد چه کسی به روز رسانی را انجام می دهد؟

بسیاری از برنامه‌های کم‌کد اغلب توسط یک توسعه‌دهنده ایجاد می‌شوند که ذاتاً منجر به یک نقطه شکست می‌شوند.

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

این بدان معنا نیست که سازمان‌ها باید به شدت محدود کنند که چه کسی می‌تواند این برنامه‌ها را ایجاد کند. انجام این کار با هدف کم کد در تضاد است. این مدلی است که به ذینفعان قدرت می‌دهد تا به سرعت ایده‌ها را نمونه‌سازی کنند و راه‌حل‌های کم‌هزینه‌ای برای مشکلاتی ایجاد کنند که در توسعه سنتی ممکن است میلیون‌ها دلار هزینه داشته باشد.

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

چگونه پیچیدگی را ساده کنیم

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

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

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

برای افزایش سرعت، سرعت خود را کاهش دهید

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

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

برنامه نویسی جفت

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

به عنوان مثال، فرآیند ساخت یک برنامه Power App را در نظر بگیرید. به طور سنتی، تنها یک نفر می تواند یک برنامه را در یک زمان ویرایش کند. اگرچه این محدودیت تغییر کرده است - اکنون چند نفر می توانند یک برنامه را به طور همزمان ویرایش کنند - تعریف یک فرآیند مشارکتی بسیار مهم است.

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

این روش همه را درگیر می کند و به کاهش اثرات دید تونلی بر روی محصول کمک می کند. و این رویکرد مشترک به ویژه برای جنبه های پیچیده تر برنامه ارزشمند است.

برای کارهای ساده تر، ما اغلب به صورت موازی کار می کنیم، اما از طریق Teams یا Zoom به صورت نزدیک در ارتباط هستیم، آماده هماهنگی و اطمینان از اینکه هر جزء مختلف بخشی از یک کل منسجم است.

تحلیل برنامه/کد

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

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

اگر از کدهای سنتی در پروژه خود استفاده می کنید، برخی از این کارها را می توان با PR انجام داد. برای پیاده‌سازی‌های کاملاً کم‌کد، یک سند تغییرات را نگه دارید و یک فرآیند ثبت نام داشته باشید تا مطمئن شوید سایر اعضای تیم می‌توانند به تغییرات جدید دسترسی داشته باشند.

به عنوان مثال، تصور کنید که یک صفحه نمایش جدید به برنامه Canvas اضافه کنید، که به کاربران اجازه می دهد تنظیمات شخصی را به روز کنند. این تغییر باید تا زمانی که حداقل یکی دیگر از اعضای تیم این ویژگی جدید را تحلیل و امضا نکرده باشد، به عنوان تحلیل نشده ثبت شود.

سایر اعضای تیم را درگیر کنید

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

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

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

زمانی که حضور مستقیم امکان پذیر نیست...

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

با این حال، به ناچار، زمانی که این تجربه عملی امکان پذیر نیست، داشتن شیوه هایی ضروری است که می تواند اثرات توسعه مجزا را کاهش دهد - یعنی توسعه ای که توسط یک یا فقط چند نفر انجام می شود.

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

سند، سند، سند

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

چه در یک تیم یا یک توسعه دهنده انفرادی باشید، ایجاد اسنادی که هر جنبه از محصولات شما را توصیف می کند بسیار مهم است. برای پروژه های کوچک، این ممکن است یک سند متنی ساده باشد. برای پروژه های بزرگتر، می توانید از سایت شیرپوینت استفاده کنید. البته، با پیچیده‌تر شدن محصولات، وابستگی‌های مختلف احتمالاً مستندات خاص خود را خواهند داشت (مثلاً مخازن Git).

در اینجا مثالی از نحوه مستندسازی محصولی که در حال ساخت آن هستید آورده شده است:

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

در اینجا نحوه مستندسازی این پروژه آمده است:

یک منبع واحد از حقیقت در مورد این پروژه، مانند صفحه شیرپوینت ایجاد کنید.

این صفحه به طور خلاصه پروژه، صاحبان محصول و توسعه دهندگان اصلی را توضیح می دهد.

این صفحه همچنین اجزای این پروژه (برنامه Canvas، کد سفارشی، و داشبورد گزارش) را به طور خلاصه شرح می دهد.

در نهایت، شما می توانید اسنادی را در مورد هر جنبه ای که به راحتی قابل چشم پوشی است یا اجرای غیر استاندارد پروژه را شامل می شود (در ادامه در مورد استانداردسازی بیشتر توضیح خواهیم داد).

دیگر اخبار

نگاه بازار ارز به دو انتخابات ایران و آمریکا

صفحه شیرپوینت نمای کلی پروژه را در سطح بالایی انجام می دهد و شما را در جهت درست راهنمایی می کند. با توجه به اجزای جداگانه، برنامه Canvas نظرات و یادداشت‌هایی را در تاریخچه نسخه شامل می‌شود و کد سفارشی شما از Git استفاده می‌کند و اغلب شامل یک readme مفصل می‌شود.

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

تا حد امکان استاندارد کنید

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

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

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

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

در اینجا چند سوال برای شروع شما وجود دارد:

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

از چه ابزارهایی استفاده خواهید کرد؟ (به عنوان مثال، Power Apps، Appian، Pega)

آیا می توانید از توسعه سنتی حمایت کنید؟ اگر چنین است، چگونه به نظر می رسد؟

رویکرد فلسفی شما به توسعه چیست؟ به عنوان مثال، ابتدا باید رابط کاربری یا منطق تجاری را طراحی کنید؟ از چه پایگاه داده ای استفاده خواهید کرد؟ (به عنوان مثال شیرپوینت یا دیتاورس)

از چه قراردادهایی در کد خود استفاده خواهید کرد؟ (به عنوان مثال، قراردادهای نامگذاری برای صفحات و متغیرها)

بیشتر بخوانید

قیمت بیت‌کوین و اتریوم امروز ۷ فروردین ۱۴۰۳/ کاهش قیمت ها +جدول




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

البته این فهرست ادامه دارد. هرچه بیشتر یاد بگیرید، بیشتر متوجه خواهید شد که چه چیزی باید مورد بحث قرار گیرد. با ایجاد یک رویه عملیاتی استاندارد (SOP) شروع کنید و برای ویرایش زودهنگام و اغلب آن آماده باشید.

اگر من یک توسعه دهنده انفرادی باشم چه می شود؟

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

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

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

نتیجه گیری

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

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

کنجکاو بمان

خبرکاو