به لطف این ابزارهای قدرتمند برنامهنویسی با سرعتی فراتر از اونچه فکر میکنیم در حال تغییر و تحوله.
سالها پیش، برنامهنویسها کدهای اسمبلی مینوشتن که سریع و سبک بود. در روز خوبشون، اینقدر بودجه داشتن که یک نفر رو استخدام کنن تا دکمهها و سوییچهای روی دستگاه رو بزنه و کدشون رو وارد کنه. در روز بدشون، باید خودشون این کار رو میکردن. زندگی ساده بود: نرمافزار داده رو از حافظه میخوند، کمی حساب و کتاب میکرد، و بعد پس میفرستاد. همین.
امروز، توسعهدهندهها باید با تیمهایی کار کنن که در چند قاره پراکندهان و آدمها با زبانهای مختلف و کاراکترهای متنوع صحبت میکنن و – از همه بدتر – نسخههای متفاوتی از کامپایلر رو استفاده میکنن. بخشی از کد جدیده، و بخشی شاید از لایبراریهای ده ساله و جا افتاده بیاد که ممکنه همراه کد منبع باشه یا نباشه. ساختن روحیهٔ تیمی و شخم زدن آشفتهبازار وظایف تعریفشده و کدهای نوشتهشده، تازه بخشی از یک روز عادی برای برنامهنویسه.
کاری که امروز برای فهموندن دستور کار به کامپیوترها انجام میدیم تفاوت قابل توجهی با حتی پنج سال پیش داره، و اگر کسی ده سال اخیر رو مثل اصحاب کهف خوابیده باشه، تقریبا نمیتونه در دنیای کامپیوتری امروز کاری از پیش ببره. سرعت تغییر و تحول همه چیز بیشتر شده.
حالا میخوام از ۱۵ فناوری بگم که دارن ذات برنامهنویسی رو تغییر میدن. این فناوریها شیوهٔ کار ما در کنار توسعهدهندههای دیگه، نحوهٔ تعامل ما با مشتری، و حتی شکل کدنویسی ما رو عوض میکنن. مواظب باش پای کنسول خوابت نبره.
ابزار توسعه شماره ۱: یکپارچهسازی پیوسته
قبلا وقتی کدی رو در یک مخزن یا ریپوزیتوری وارد میکردی، معمولا وقت کافی وجود داشت که یه نفسی تازه کنی، یه فنجان قهوه بخوری، و شاید حتی یه ناهاری هم بزنی. دیگه نه – مخازن کد امروز چنان با سامانههای ساخت (build) پیوسته در هم تنیده شدهان که این سامانهها درجا شروع میکنن و کد رو کامپایل میکنن، معماری تو رو بررسی میکنن، صدها تست میگیرن و خطاهای احتمالی کد رو هم پرچم میزنن. قبل از اینکه پنج قدم از میزت دور بشی صدای ایمیلها و پیامهای جدید از گوشیت بلند میشه و سامانه یکپارچهسازی پیوسته بهت میگه که چه چیزهایی رو باید درست کنی. باید برگردی سر کارت سرباز، سامانهٔ ساخت پیوسته برای تو فرامین جدیدی صادر کرده.
ابزار توسعه شماره ۲: Framework
ایستادن بر شانهٔ غولها و استفادهٔ مجدد از کار انجامشدهٔ دیگران شاید چیز جدیدی نباشه، اما هیچوقت مثل امروز متداول نبوده. دیگه این روزها کمتر برنامهنویسی کدش رو از صفر شروع میکنه. روش پرطرفدار – و بعضیها میگن درست – امروز اینه که یه چارچوب یا فریمورک درست گیر بیاری، API اون رو بررسی کنی، و براش کد چسب بنویسی که بخشهای مختلف API رو که بیشتر به درد کارت میخوره رو به هم وصل کنی. صفحههای وب دیگه فقط با HTML و CSS ساخته نمیشه؛ برنامهنویسی حالا از EXT JS، EXpressJS، CakePHP، Laravel یا مجموعه کد دیگهای به عنوان شالودهٔ کار شروع میشه.
بله، تو میتونی دل به دریا بزنی و همه چیز رو از صفر خودت بنویسی، ولی این تقریبا خودکشیه. امکان نداره بتونی خودت رو به اون همه کاری توسط این همه آدم دیگه انجام شده برسونی. تو صنعتگر نیستی – تو چارچوب-انگولک-کنی. اگر توی این فکری که کد رو خودت بنویسی، همین جا بایست و به جاش دنبال فریمورکی بگرد که همون کار رو خیلی راحتتر انجام میده.
ابزار شماره ۳: کتابخانه (Library)
کتابخانه هم پسرعموی فریمورکه، مجموعهای از روتینها که اونقدر دمدستی و پرکاربرد شده که دیگه برنامهنویسها نمیتونن بدون اون زندگی کنن. آیا شدنیه که برای مرورگر کد بنویسی ولی از jQuery استفاده نکنی؟ اصلا کسی یادش میاد که یه فانکشن توکار به اسم GetElementByID هم وجود داره؟ نه، کتابخانههایی مثل jQuery حالا در همهٔ سطحها حکمرانی میکنن.
آدمها دربارهٔ زبان محبوبشون حرف میزنن، اما این حرفها چندان چیزی دربارهٔ شیوهٔ برنامهنویسی اونها نمیگه. اگر دنبال استخدام کسی هستی، باید دربارهٔ دانش کتابخانهایش ازش سوال کنی. آیا برنامهنویس JavaScript که میخوای بگیری از قبیلهٔ Dojo است یا jQuery؟ برنامهنویس بازی ممکنه از C++ استفاده کنه، اما سوال اصلی اینه که آیا Allegro، Unity، Corona یا یکی از گزینههای دیگه رو بلده؟ بلد بودن لایبراری هم درست به اندازهٔ تسلط به خود زبان برنامهنویسی مهمه.
ابزار توسعهٔ شماره ۴: API
قدیمها، یه برنامهنویس همیشه نگران ساختمان داده بود. اون تمام اطلاعاتش رو در بلوکهای بایت جا میداد، بایتها رو دونه به دونه میشمرد، و بعد باید مطمئن میشد که مقادیر در فاصلهٔ درستی از پوینتر قرار گرفته. حالا اما شکر خدا کامپایلر بیشتر این کارها رو برای ما میکنه.
این روزها ما معمولا با رابط سفت و محکمتری با یه اسم باکلاستر کار میکنیم: API. این رابط معمولا روی دستگاه کاملا متفاوتی قرار داره و ممکنه اصلا توسط شرکت دیگهای اداره بشه که مثلا بهازای هر تماس یا ارتباط، حساب ما رو کنتور میاندازه. میخوای یه آدرس و کد پستی رو تبدیل به طول و عرض جغرافیایی کنی؟ این هم API داره، و با خرج کردن چند سنت جوابت رو به دست میاری.
در بیشتر موارد، داده حتی لازم نیست بستهبندی سفتی داشته باشه. بازی قدیمی بایتشماری جای خودش رو به ساختماندادههای قابل تفسیر مثل JSON و XML داده. فقط کافیه نقطه و کامای درست رو در جای درستش قرار بدی، و حتی برای این کار هم خوشبختانه کتابخانهای هست که کار رو مدیریت میکنه.
ابزار توسعه شماره ۵: بستر به عنوان خدمت
دیگه کی این روزها وبسایتش رو خودش میسازه؟ به جای اون، یه حساب روی وبسایت کس دیگهای باز میکنی و وبسایتت رو به دلخواه خودت در میاری. کافیه چند تا کادر توی یه فرم تحت وب پر کنی، و اجی مجی، وبسایت جدیدت هر کاری که میخواستی رو انجام میده. تقریبا به سادگی باز کردن یه وبلاگ.
البته شاید کمی اغراق باشه. بیشتر این گزینههای PaaS (یعنی Platform as a Service یا همون بستر به عنوان خدمت) امروز احتیاج به دانش برنامهنویسی دارن که بدونی چی توی هر فرم وارد کنی. مثلا Azure از شرکت مایکروسافت، ازت میخواد که چند تابع جاوا اسکریپت وارد کنی که تعیین میکنه سایت چطور باید جواب بده. بعد آزور این توابع رو در کتابخانههای مناسب میپیچه و روی Node.js اجرا میکنه.
ابزار توسعه شماره ۶: مرورگر
دورانی بود که مردم برای دسکتاپ نرمافزار مینوشتن، و برای سرور، و برای دستگاه، و همه اینها با هم فرق داشت. هر کدوم از اینها روش خودش رو برای ارتباط با کاربر داشت. حالا همه چیز از طریق مرورگر انجام میشه. وقتی که من توی خونه یه فایل سرورِ لوکال راهاندازی میکنم که روش آهنگ نگهدارم، بعدش برای کار با این سرور فقط یه URL وارد میکنم و با یه وبسایت سروکار دارم. سالها است که ابزارکها یا ویجتهای دسکتاپ Apple با جاوا اسکریپت و HTML نوشته میشه. خیلی از اپهای موبایل چندبستری در قالب HTML و JavaScript شروع میشه که بعدش در کنار Apache Cordova قرار میگیره.
بله، صد البته که موانعی هم هست. بهترین بازیها هنوز دستی نوشته میشه و احتیاج به مرورگر نداره، اما این شرایط داره تغییر میکنه و توسعهدهندههای جاوا اسکریپت بیشتر و بیشتر به دنبال راههایی برای نوشتن screen canvas object هستن. مثلا بازی Angry Birds در یه پنجره مرورگر اجرا میشه.
ابزار توسعه شماره ۷: Application Container
ساختن یه سرور پیشترها کار سختی بود. برنامهنویسها باید کدشون رو اجرا میکردن، بعد یه پیام به تیم نگهداری سرور میفرستادن تا نرمافزار مناسب رو اجرا کنه. گاهی کتابخانههای مناسب رو داشتن و گاهی نداشتن، ولی در نهایت به یه نقطهٔ مشترک میرسیدیم که جواب میداد.
حالا کانتینرهایی مثل Docker به ما امکان میده که با زدن یه دکمه یه ظرف یا کانتینر حاوی کتابخانههای مناسب هم همراه اپلیکیشن خودمون بفرستیم. اگر این بسته روی دستگاه تست ما کار کنه، تقریبا بدون شک روی سرور هم کار میکنه. همه چیز بستهبندی میشه و بیشتر ناسازگاریهای بین دسکتاپ و سرور محو میشه.
ابزار توسعه شماره ۸: خدمات زیرساخت
حرف ادمینهای سرور پیش اومد. اینها قبلا آدمهایی بودن که سر ناهار یا بعد از کار با هم میگشتیم و خوش میگذشت، اما حالا در دل لایهٔ ابر محو شدهان، و در اون طرف سیاره در دیتاسنتر شرکتی کار میکنن که خودش رو در دنیای «ابر چنین است و چنان» پیشتاز میبینه. حالا دیگه کمتر برنامهنویسی لازمه از تیم زیرساخت بخواد که برای یه پروژه جدید یه سرور جدید راهاندازی کنن. به جاش خیلی ساده در یه وبسایت لاگین میکنه، یه دکمه میزنه، و یه دستگاه جدید تحویل میگیره. کار خیلی راحتتره؛ تنها عیبش اینه که این صفحههای مدیریت IaaS یا Infrastructure as a Service چندان خوشمشرب نیستن و نمیشه باهاشون کافه رفت. البته خب خرج آدم هم کمتر میشه.
ابزار توسعه شماره ۹: Node.js و JavaScript
قبل از اینکه بعضی از خوانندههای این مطلب به دنیا بیان، وبسرورها فقط HTML ثابت بیرون میدادن. بعد کسی راهی پیدا کرد که سرورهای دینامیک درست کنه که میتونست با پایگاه داده کار کنه. هر تیمی باید یک نفر میداشت که دیتابیس رو در قالب SQL برنامهریزی کنه، یک نفر که کد سرور رو به PHP یا Java بنویسه، و یک نفر که قالبهای HTML رو طراحی کنه. و وقتی هم همه عاشق AJAX و JavaScript سمت کلاینت شدن، باز سایتها احتیاج به یک نفر دیگه داشتن که به این زبان صحبت کنه.
حالا همهٔ این کارها با JavaScript انجام میشه. مرورگر که خب هنوز به زبان JavaScript صحبت میکنه، اما حالا لایهٔ سرور هم همین کار رو میکنه (Node.js) و همینطور لایهٔ دیتابیس (MongoDB و CouchDB). حتی HTML هم اغلب با کد جاوا اسکریپت برای فریمورکی مثل Ext JS یا jQueryMobile مشخص میشه که HTML رو در سمت کلاینت تولید میکنه.
ابزار توسعه شماره ۱۰: بازارهای ثانویه
اگر بخوای یک بازی بسازی، میتونی برای خودت چند تا طراح و هنرمند استخدام کنی تا برات مجموعهٔ جذابی از مدلهای مختلف طراحی کنن. ممکنه حتی چند برنامهنویس استخدام کنی که برای باحالتر کردن بازی کمی جلوههای ویژه بهش بدن. یا اینکه میتونی سبد خرید رو برداری و در بازارهای ثانویهای مثل Unity Asset Store تمام قطعاتی که لازم داری رو بخری. همین الان که دارم این مطلب رو مینویسم، «کیت کاشی فاضلاب سیاهچال» ۳۳ درصد تخفیف خورده، که به عنوان «یک کیت ماژولار برای ساخت صحنههای بازی فاضلاب از کوچک تا بزرگ» طراحی شده. البته تا وقتی که مطلب رو بخونی دیگه تخفیفش تموم شده و قیمتش به همون ۴۵ دلار برگشته. حالا با این قیمتها دیگه چه کسی احتیاج به استخدام طراح و هنرمند داره؟
بازارهای خوب برای افزونه، پلاگین، کتابخانه، و انواع چیزهای مشابه داره روزبهروز بیشتر میشه. و مثل فریمورک و کتابخانه، اینجا هم کار بیشتر حالت خرید رفتن داره تا خود برنامهنویسی.
ابزار توسعه شماره ۱۱: ماشین مجازی
روزگار نوشتن کد برای مدار و سختافزار واقعی دیگه تقریبا گذشته. بیشتر کدهایی که امروز نوشته میشه روی virtual machine یا ماشینهای مجازی اجرا میشه که دستورات کد رو تبدیل به چیزی میکنه که توسط کامپیوتر قابل درک باشه. ماشین مجازی Java، ماشین مجازی C#.NET، و حالا موتورهای جاوا اسکریپت هدف اصلی بیشتر کدنویسیها هستن.
محبوبیت VM داره کمکم همه چیز رو تحت تاثیر قرار میده. در گذشته اگر کسی میخواست زبان جدیدی ابداع کنه، باید کل استک رو از پیشپردازنده (pre-processor) تا تخصیصدهندهٔ ثبات (register allocator) رو خودش بسازه. اما امروز زبانهای جدید بر پایهٔ ماشینهای مجازی قدیمی بنا میشه. Clojure، Scala، Jython، JRuby – همهٔ اینها بر پشت کار بزرگ شرکت Sun (زیرمجموعهٔ فعلی اوراکل) در ساخت ماشین مجازی سوار شدهان.
همین رفتار داره در دنیای مرورگرها هم پیدا میشه. بله، تو میتونی مرورگر خودت و زبان خودت رو بنویسی، یا اینکه cross‑compile کنی تا در جاوا اسکریپت نمونهسازی بشه. وقتی که ابزارهای تروتمیزی مثل CoffeeScript ساخته میشه دقیقا همین اتفاق میافته. اگر به اندازه کافی گیجکننده نیست، گوگل هم GWT (یا جعبه ابزار وب گوگل) رو ساخته که جاوا رو به جاوا اسکریپت تبدیل میکنه.
ابزار توسعه شماره ۱۲: درگاههای رسانههای اجتماعی
در دوران ابتدایی اینترنت، آدم مجبور بود وبسایتش رو خودش بسازه و بعد دست به دعا برداره تا مردم پیداش کنن. و وقتی که پیدا میکردن، دیگه با خودشون بود که آدرس قشنگت یادشون بمونه یا نه.
افسوس که امروز وب هر چه بیشتر داره جذب سیلوهای بزرگی مثل فیسبوک و تلگرام میشه. اگر برای خودت یه وبسایت بسازی و راهاندازیش کنی، میتونی از صدای جیرجیرک و نسیمی که در سکوت وبسایت میپیچه لذت ببری، چون همهٔ بشریت سرشون به فیسبوک و تلگرام گرمه.
راهکارش هم البته اینه که یه اپ فیسبوک یا بات تلگرام بسازی. اونها با آغوش باز میپذیرنت و اجازه میدن از بسترشون کمک بگیری. اما در نهایت اپ تو یه امکان اضافه است که ممکنه به اندک اشارهای محدود بشه یا به حاشیه بره. چه کار میشه کرد؟ بالاخره یا باید با جریان روز همراه باشی یا از صدای جیرجیرک لذت ببری.
ابزار توسعه شماره ۱۳: ابزارهای devops
روزی روزگاری، ما نرمافزار رو بر روی یک سرور – مفرد – نصب میکردیم. اما حالا دسته دسته سرور اجاره میکنیم، که نیاز به دهها، صدها، یا حتی هزاران دستگاه داره که بیشترش باید برحسب تقاضا بلافاصله تامین بشه، پر از نرمافزار تر و تازه – کاری که دیگه واقعا نمیشه به خوبی دستی انجامش داد.
و در اینجا است که «devops» وارد میشه، و ابزارهای زیرساختی مثل Chef و Puppet که برای نگهداری همین سرورها طراحی شدهان. نرمافزار رو به ابر میفرستی و این ابزارها خودشون کار رو به دست میگیرن تا همهٔ کامپیوترها کد مشابهی رو اجرا کنن. این ابزارها کاری که ما قبلا دستی برای یک دستگاه انجام میدادیم رو خودکار کردهان.
بعضی سرویسها مثل Google App Engine خودش این کار رو انجام میده. تنها کاری که باید بکنی اینه که اپ خودت رو بهش بدی، و تخصیص منابع خودبخود انجام میشه. حتی لازم نیست بدونی که پشت صحنه چه اتفاقی داره میافته؛ فقط باید آخر ماه قبض چرخههای پردازندهٔ مصرفی رو بپردازی.
ابزار توسعه شماره ۱۴: GitHub، SourceForge، و اشتراکگذاری اجتماعی کد
سایتهای اشتراک کد شاید بزرگترین خدمتی باشه که به دنیای متنباز شده. قبل از ظهور سرویسهایی مثل SourceForge، نرمافزار چیزی بود که خودت به تنهایی میساختی و خودت پخش میکردی. اگر کسی یه کپی از کد میخواست، باید میاومد سراغ تو و تو هم اگه حال میکردی یه tarball براش میفرستادی.
حالا اشتراکگذاری کد یه شبکهٔ اجتماعی شده. سایتهایی مثل SourceForge و GitHub تمام کد رو قرار میدن تا همه ببینن و بهروز کنن. فرایند نگهداری، اشتراکگذاری، و نظردهی روی کد در یک جا به شکل راحتی در هم ادغام شده. میتونی کد رو بخونی و تغییراتی پیشنهاد بدی، همه از یک طریق. آیا تعجبی داره که خیلی از پروژهها هر هفته دهها یا حتی صدهاهزار بار دانلود میشه؟ با مدل قدیمی هیچوقت چنین چیزی ممکن نمیشد.
این مدل حالا چنان جا افتاده که بیشتر پروژههای اختصاصی هم همین روش رو دنبال میکنن. سایتهایی مثل GitHub و BitBucket با فروش مخازن غیرعمومی خرج خودشون رو در میارن که همین قدرت اشتراکگذاری رو داره اما دسترسی به کد به گروه خاصی محدود شده.
ابزار توسعه شماره ۱۵: نظارت عملکرد
در ابتدای کار، پیگیری و سنجش قدرت کد کار سادهای بود. زمان شروع کد رو پرینت میزدی و بعد زمان اتمامش رو هم پرینت میزدی. اگر میخواستی خیلی کلاس بگذاری، چند تا محاسبه اضافه میکردی که خودش اختلافش رو هم برات در بیاره.
ولی این دیگه جوابگو نیست. بیشتر مشکلات روی یک دستگاه اتفاق نمیافته. اضافه کردن پروفایلینگ به کد نمیتونه گلوگاههای اصلی رو مشخص کنه؛ مشکلاتی که میتونه ناشی از یه ارتباط عجیب یا کندی دیتابیس باشه. ولی ابزارهای امروزی فراخوانیهای شبکه برای نرمافزار شبکه رو هم مثل عملکرد هر ماژول پیگیری میکنن. این تنها راهیه که میتونی بفهمی چه خبره و چه چیزی داره بد کار میکنه.
این فقط یک نمونه است که چطور مدل برنامهنویسی داره از تکماشینی به شبکهای از ابزارهای متصل تغییر میده که ممکنه اونقدرها هم با هم سازگار نباشن.
منبع : فرانش