۶ روشی که اتوماسیون توسعه دهندگان نرم افزار را تحت تأثیر قرار می دهد

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

• جمع آوری زباله
• کد تفسیر شده
• هوش مصنوعی
• پرسمان‌های پایگاه داده
• سکوهای کم کد و بدون کد
• اتوماسیون گردش کار (RPA)
• اتوماسیون صفر

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

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

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

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

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

جمع آوری زباله

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

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

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

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

کد تفسیر شده

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

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

زمانی که برنامه نویسان فهمیدند چگونه از قدرت پیاده سازی های زمان اجرا جایگزین یا کامپایلرهای مناسب به موقع (JIT) استفاده کنند، سرعت بهتر شده است. توسعه دهندگان پایتون به مواردی مانند سایتون، Jython، Numba، PyPy، Pyston، و اکنون Pyjion برای اجرای سریعتر. اما هنوز محدودیت هایی برای کارهایی که یک مترجم می تواند انجام دهد وجود دارد.

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

هوش مصنوعی

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

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

به نظر می‌رسد بهترین استفاده از هوش مصنوعی به عنوان دستیار نه چندان باهوشی برای انسان‌های باهوش‌تر و چابک‌تر است که می‌توانند نابغه خودکار را روی یک افسار محکم نگه دارند.

پرسش‌های پایگاه داده

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

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

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

سکوهای کم کد و بدون کد

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

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

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

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

اتوماسیون گردش کار (RPA)

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

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

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

اتوماسیون صفر

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

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