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

به نظر می رسد همه می خواهند برنامه های خود سریعتر و سریعتر اجرا شوند. صدها پست در مورد عملکرد برنامه هر ساله منتشر می شود. اما مقالات مربوط به ایجاد برنامه های کاربردی به سرعت بسیار نادر هستند. حیف است زیرا وقتی فشار به بیل زدن می آید این چیزی است که برای تجارت مهم است. بهره وری توسعه دانشی است که به شما امکان می دهد جدا از یک برنامه نویس معمولی ، از یک CTO / tech led بگویید. بگذارید در مورد آن صحبت کنیم در این پست ، ما 3 رویکرد توسعه نرم افزار مدرن را توصیف می کنید که می توانید از آنها برای ارائه ویژگی هایی مانند یک خط مونتاژ با روغن استفاده کنید. زمان چرخه "ساخت -> راه اندازی -> اندازه گیری و سازگاری" یک معیار کلیدی برای اکثر نرم افزارهای تولید شده امروز است. به همین دلیل است که تیم های مهندسی امروز با استفاده از ابزارها و روشهای پیچیده تر و کمتری برای کاهش زمان حمل و نقل استفاده می کنند. اینها شامل فرآیندهای استقرار مداوم ، ساختن ابزارهای اتوماسیون ، دستورالعمل های کدگذاری و ابزارهای تحلیل کد ایستا می باشد. همه اینها برای ایجاد یک محیط قابل کنترل برای چرخه تحویل نرم افزار صاف با ده ها رمزگذار است.

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

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

• دستیابی به سادگی در کد
• ساخت یک بازخورد سریع

در حالی که از زوایای مختلف می توان به آنها دسترسی داشت ، من می خواهم بطور ویژه روی یکی از آنها تمرکز کنم – سیستم عامل های SaaS اول API. [19659010] سازه های API برای اولین بار به جای POC ساده و محکم شما

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

چند ویژگی سخت برای از دست دادن راه حل های مبتنی بر API وجود دارد:

• ارزش اصلی کسب و کار می آید. از [ API و webhooks ، و رابط کاربری (در صورت وجود) نقش ثانویه ایفا می کند ، و بیشتر برای مدیریت حساب استفاده می شود ،
• اسناد توسعه دهنده ،
• آنها تیم هایی اختصاص داده اند تا از امنیت و در دسترس بودن مراقبت کنند.

سود؟ کسب و کار در همان زمان سرعت و انعطاف پذیری کسب می کند. و البته پس انداز به عنوان کاربر چنین خدماتی ، شما معمولاً هزینه واقعی استفاده ، تعداد درخواستها را پرداخت می کنید.

بنابراین چه ارتباطی با 2 هدف از تحویل سریع ذکر کردیم؟ [19659004] مورد اول سر راست است. شما فقط به خطوط كد كمتری نیاز دارید تا راه حل مورد نظر خود را عملی كنید. مطمئناً ، در ابتدا برخی از منحنی های یادگیری وجود دارد ، اما به طور کلی زمانی که برای آشنایی با یک API جدید – معمولاً با اسناد و نمونه های مناسب – صرف می کنید ، کوتاه تر از آن چیزی است که برای ایجاد یک ویژگی با یک روش "آزمایشی و خطا" معمولی کوتاه است.

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

هدف دوم به طور طبیعی از هدف اول ناشی می شود. اگر ویژگی را سریعتر پیاده سازی کنید ، می توانید زودتر آن را با کاربران تست کنید (با تشکر شرلوک). اما برای جمع آوری بازخورد به درستی ، شما همچنین به روشی برای جمع آوری و تجسم داده ها برای متریک پس از تجارت نیاز دارید. سیستم عامل های مبتنی بر API ممکن است در اینجا دوباره مفید باشند زیرا معمولاً آنها آمار دقیق استفاده را ارائه می دهند (همچنین از طریق API در دسترس هستند) و حتی گاهی ماژول های گزارش دهی کامل.

بنابراین ، در کل ، قرار دادن یک ویژگی با سیستم عامل های مبتنی بر API یک است. رویکرد بهتر از اثبات سریع و کثیف مفهوم شما.

خوب ، اجازه دهید یک نمونه را ببینید.

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

اکنون هدف از پروژه پروژه کاهش زمان عاملان ضمن حفظ سودآوری عملکرد تطبیق.

اولین ایده ای که از طرف مدیریت به وجود آمد ، مأموریت دادن به یک الگوریتم یادگیری ماشین و اتصال آن به بستر CRM بود. اما CTO شکاک بود. او می دانست که این یک سوار گران است. در نهایت ، او می ترسید که یک مدتی طول بکشد تا راه حلی را تهیه کند که نتایج مشابه یا بهتر از عوامل داشته باشد. وی یک رویکرد جایگزین را وادار کرد که در کوتاه مدت کار را برای عدم بارگیری تیم عملیاتی متمرکز کند. سپس ، او تصمیم گرفت فاکتور انسانی را با پیامکی جایگزین کند. موتور سفارشات دریافتی را تجزیه و تحلیل کرده و "آیا این کار XYZ را قبول دارید؟" بله / خیر "پیام به چندین تأمین کننده. این فرایند پیام های پیامکی را مطابق با الگویی شامل پارامترهای فوق الذکر ارسال می کند. هرکس که اول قبول کند ، این سفارش را به دست آورد.

این سریع اجرا شد و خیلی خوب کار کرد! البته ، راه حل 100٪ موارد را پوشش نمی داد ، اما تلاش تیم گزینه را به میزان قابل توجهی 60٪ کاهش داد و منابع بیشتری را برای سایر کارهای عملیاتی بدست آورد. این موضوع چند روز بود ، نه هفته ها یا ماه ها .

اکنون بخش اصلی این است که تحویل سریع بدون کمک سیستم عامل های API-اول صورت نمی گرفت.

اول ، به جای ساختمان دروازه پیامکی ، آنها برای Twilio رفتند. دوم ، آنها به جای اجرای یک عملکرد شبیه به cron ، از EasyCron استفاده کردند. سوم ، برای محاسبه فاصله های جغرافیایی ، آنها به API Google Maps ضربه زدند. کل راه حل در واقع فقط یک حلقه و یک سری ifs و چندین درخواست HTTP بود.

به طور خلاصه ، آنها به سرعت توانستند یک ویژگی مهم را به صورت زنده دریافت کنند و در هیچ زمان و به اهداف تجاری دست نیابند. مهمتر از آن ، کد مسئول این عملکرد فوق العاده ساده بود و بنابراین برای تغییرات (که بعداً انجام دادند – خودکار 90٪ تخصیص سفارش) را باز کرد.

اما بسترهای نرم افزاری API-first موارد احتیاطی خود را نیز داشته باشید:

• مهمترین چیزی که شما باید به عنوان بخشی از تحقیقات SaaS خود تأیید کنید محدودیت هاست. فروشندگان اولین API ، آستانه هایی را برای صرفه جویی در هزینه و همچنین برای محافظت از خدمات خود در برابر ترافیک زیاد غیرمنتظره تحمیل می کنند. اطمینان حاصل کنید که محدوده ها با بودجه مورد استفاده شما مطابقت دارند.
• مورد دوم یک برنامه برگشت ناپذیر است – بسته به تأثیر تأثیر در تجارت ، سیستم شما باید مطابق با سیستم عامل فروشنده یا مال شما آماده شود. ویژگی هایی از قبیل هشدار سیستم / هشدارهای سیستم و وب سایتهایی که درخواستهای ناموفق را تکرار می کنند در چنین مواردی کمک می کند.
• اطمینان حاصل کنید که ارائه دهنده مورد نظر شما یک سیاست پشتیبانی را ارائه می دهد که همراه با پرونده تجاری شما باشد.
• هیچ شرکت بزرگتری اجازه ادغام را نمی دهد. اگر دارای ویژگی های شخص ثالث نباشد ، دارای سیستم شخص ثالث است. لیستی از آنچه در ارگان خود لازم است تهیه کنید.

خواندن توصیه می شود:

برنامه های کسب و کار کپی و چسباندن-و-تغییر یک چیز است

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

Salesforce به عنوان یک راه حل SaaS CRM آغاز شد. آنها یکی از اولین بازیکنان در بازار بودند و اوج فروش آنها در آن زمان "NO SOFTWARE" بود. آنها با هدف جذب شرکت هایی که سعی در اتوماسیون فرایندهای فروش خود دارند که از نرم افزارهای ضعیف و پیش فرض تغذیه شده تغذیه می شدند. پیشنهاد SaaS آنها موفقیت بزرگی بود.

اما سریع به دهه دوم قرن بیست و یکم ، می بینیم که Salesforce دیگر "NO SOFTWARE" نیست. در واقع امروز ، آنها ادعا می کنند که 50٪ از سود آنها ناشی از استفاده از API Salesforce است. چه اتفاقی برای "NO نرم افزاری" افتاد؟

خوب ، SF فهمید که اگرچه 80٪ برنامه های CRM به همین شکل کار می کنند ، شرکت ها هنوز هم نیاز به خدمات نرم افزاری برای ادغام سایر سیستم ها و شخصی سازی جریان داده دارند.

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

آنها گزینه های پیکربندی را با اضافه کردن:

• گسترش دادند. محیط نرم افزاری قابل برنامه ریزی با زبان اختصاصی خود به نام APEX
• ایجاد چارچوب UI Lightning برای ایجاد نماهای جدید درست در Salesforce
• API و عملکردهای شبیه به webhook ها را برای اتصال سیستمهای خارجی قرار داده است.

به عبارت دیگر – آنها بر روی نرم افزار شرط می بندند.

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

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

و ما در آنجا بوده ایم. از مثال قبلی ، شرکت بازار آنلاین در حال رشد سریع به یاد دارید؟ آنها تقریباً از روز اول در Salesforce شرط می بندند. آنها پس از 3 ماه دویدن در Google Spreadsheets ، بخش های کوچک خود را به SF منتقل کردند و هرگز از این تصمیم پشیمان نشدند. در ضمن ، SF به آنها اجازه داد تا برای 3 سال آینده رشد کنند. چگونه کار کرد؟

Salesforce به عنوان یک منبع حقیقت واحد رفتار می شود ، هیچ پایگاه داده ای غیر از آن وجود ندارد. بخشی از عملکرد با APEX و Lightning در Salesforce و بخش دیگر با استفاده از سیستم خارجی در Node.js متصل به API توسعه داده شده است. با اتصال سایر سیستم عامل های مبتنی بر API از طریق API ، آنها به بهره وری توسعه دهنده بسیار بالایی دست یافتند.

سایر ویژگی های Salesforce که منجر به سرعت بالا در ارائه نرم افزار شد:

• وقتی شرکت مدل کسب و کار را تغییر می دهد و ، در به نوبه خود ، مدل پایگاه داده ، آنها می توانند با صادرات داده ها از طریق Data Loader ، واکنش مجدد آنها در Excel (!) و قرار دادن آنها با اطمینان (با فرمت مناسب) به Salesforce به سرعت واکنش نشان دهند.
• آیا تجزیه و تحلیل هزینه و فایده در مورد چگونگی پیشبرد ویژگی ها – یا افزایش سهمیه یا مشخص کردن اثری از آن انجام شده است. به عنوان مثال ، هنگامی که پرس و جوهای تجزیه و تحلیل داده ها شروع به استفاده از بخش بزرگی از سهمیه کردند ، آنها پایگاه داده داخلی را به عنوان مثال Postgresql (از طریق Heroku Connect) همانندسازی کردند و منبع داده را بر این اساس تغییر دادند.
• هر وقت تجارت از ویژگی جدیدی درخواست کرد ، آنجا وجود دارد. شانس بالایی بود که بازار AppExchange راه حلی برای حل آن داشته باشد

اما Salesforce همه زنگ و سوت نیست. به طور مشابه با MS Sharepoint ، تجربه توسعهدهنده SF چیز دلخواه زیادی را برای شما باقی می گذارد. IDE دست و پا گیر ، پشتیبانی ضعیف از محیط های چند توسعه دهنده ، ادغام فن آوری های کنترل منبع ضعیف ، استقرار طولانی – همه اینها باعث می شود تا یک توسعه دهنده نرم افزار لبه دار شود. خوشبختانه ، آنها متوجه موارد بد آنها شده اند و آن را با Salesforce DX برطرف کرده اند.

خواندن توصیه می شود:

برنامه های داخلی سریع و نه چندان کثیف

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

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

یکی از راه های پیش رو این است که به SaaS مانند Metabase ، Redash یا Retool ضربه بزنید. آنچه آنها ارائه می دهند ، دسترسی قابل کنترل به پایگاه داده شما با گزارش های خارج از جعبه و قابلیت های نمودار است. رابط کاربری آنها بصری و مستعد خطا نسبت به صفحه گسترده است. و هنگامی که اکسل به سادگی به عنوان یک لیست آنلاین استفاده می شود ، می توانید آن را با ابزارهایی که درست به همین دلیل ساخته می شوند ، مانند Smartsheet Airtable یا پیشرفته تر جایگزین کنید.

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

ابر اینجاست ، از آن استفاده کنید

نقش شما به عنوان یک رهبر CTO / tech / حتی سازنده معمولی حل مشکلات تجاری با بهترین و در عین حال مقرون به صرفه ترین ابزارهایی است که در آنجا پیدا می کنید. امروزه ، ابزارهای SaaS به اندازه کافی بالغ شده و مناسب برای توسعه دهنده هستند تا بتوانند آنها را در قالب ابزار شما قرار دهند. بسته به میزان تصمیم گیری در شرکت و ویژگی های مشکل ، می توانید از راه حل برای طعم مناسب SaaS برون سپاری کنید. شما کد ساده تر و قابل حفظتری را خواهید داشت که منجر به آزمایش سریعتر ویژگی ها و در نهایت به بهره وری بهتر در تیم شما خواهد شد – امیدوارم که از مدیریت بهتر پاداش بگیرید:)