اولین کنفرانس PHP ایران در 29 مرداد ۱۳۹۴ در شهر تهران برگزار شد که یکی از سخنرانان این کنفرانس، امیر میرمیرانی معروف به جادی بود که همچون همیشه، ارائهٔ منحصر به فردی داشت با این عنوان که «آیا ما حرفه‌ای هستیم؟». در واقع، وی چک‌لیستی دوازده آیتمی ارائه کرد که دربرگیرندهٔ مواردی بود که شرکت‌های نرم‌افزاری حرفه‌ای بلااستثناء می‌بایست از آن‌ها برخوردار باشند تا بتوان لقب حرفه‌ای را به ایشان داد.
به گفتهٔ جادی، «حرفه‌ای بودن» یک تجمل نیست! ما به دنبال برچسب حرفه‌ای و آماتور زدن به آدم‌ها و شرکت‌ها به منظور طبقه‌بندی آن‌ها نیستیم، بلکه می‌خواهیم تلنگری باشیم برای اینکه صنعت نرم‌افزار و محصول تولیدی و خدمات عرضه شده ارتقاء پیدا کنند.
جادی در این پرزنتیشن با پرسیدن چند سؤال به شما فرصت می‌دهد تا از یک طرف بسنجید در کجای طیف کیفی ایستاده‌اید و از طرف دیگر راهنمایی باشد برای یادگیری چیزهای جدید و معرفی مسیر حرکت آینده! مشخص است که این تنها راه حرفه‌ای شدن نیست اما وی سعی کرد که این بررسی را با تمرکز زیاد روی تست جوئل و با کمی تغییرات به منظور بومی کردن و ملموس کردن هرچه بیشتر این تست ارائه دهد.
مدیران یا بهتر بگوییم رهبران شرکت‌های نرم‌افزاری برای سنجش وضعیت خود، می‌بایست به سؤال‌ها با بله/خیر جواب دهند و در نهایت کشف کنند که از دوازده سؤال مطرح شده، چند مورد آن‌ها از ایشان جواب «بله» گرفته‌اند. اگر بیش از ده جواب بله دارید، بدانید که در شرکتی باکیفیت جهانی کار می‌کنید و اگر کمتر از سه امتیاز گرفتید، قبل از نوشتن کد جدیدی، برخی پروسه‌هایتان را اصلاح کنید!
آیا از سورس کنترل استفاده می‌کنید؟
تا وقتی از یک سورس کنترل استفاده نکرده‌اید، یعنی مشغول نوشتن کد در دنیای طبیعی یک برنامه‌نویس نیستید و از همین رو شما هرگز یک برنامه‌نویس یا بهتر بگوییم یک شرکت برنامه‌نویسی حرفه‌ای به معنای واقعی کلمه نیستید.
تفاوت خاصی ندارد که از گیت استفاده کنید یا از سی‌وی‌اس یا فسیل یا هر چیز دیگر، ولی اگر از هیچ نوعی سورس کنترل استفاده نمی‌کنید، یک منفی بزرگ به خود بدهید و سریع به سراغ یادگیری گیت بروید. بدون سورس کنترل، برنامه‌نویس‌ها نمی‌توانند بسیاری باگ‌های ایجاد شده در پروسهٔ توسعه را پیدا کنند، نمی‌توانند گروهی کار کنند و نمی‌توانند خودشان را برنامه‌نویس حرفه‌ای قلمداد کنند.
به گفتهٔ جادی، اگر شما جزو شرکت‌هایی -یا برنامه‌نویسانی- هستید که برای اشتراک‌گذاری پروژه‌ها از دراپ‌باکس، ایمیل، فلش و … استفاده می‌کنید، شکی به خود راه ندهید که شما حرفه‌ای نیستید (وی به برخی شرکت‌ها اشاره کرد که فولدرهای انتقال پروژه‌ها به سایر اعضاء را Final یا Final-2 و … نامگذاری می‌کنند که با قهقههٔ حضار روبه‌رو شد).
آیا در یک قدم Build می‌کنید؟
فرض کنید آخرین اِسنپ‌شات کد را در دست دارید؛ حال برای رسیدن به برنامهٔ قابل عرضه، چند قدم باید طی شود؟ در یک پروژهٔ منظم این عدد باید برابر یک باشد. یک اسکریپت باید کل سورس‌ها را دریافت کند، ریبیلد کند، فایل‌های اجرایی بسازد (و هر کار ﻻزم دیگر حتی امضاء کردن برنامه‌ها یا ساختن ایزوهای سی‌دی عرضه شونده به بازار).
برای عرضهٔ یک نرم‌افزار به بازار، باید بتوانید در یک قدم همهٔ این کارها را انجام دهید زیرا در غیر این صورت احتمال اشتباه زیاد بوده، اصلاح باگ‌های لحظهٔ آخری معموﻻً با دردسرهای بزرگ همراه خواهد شد و بسیاری چالش دیگر!
آیا Daily Build دارید؟
وقتی پروژه‌ای از سورس کنترل استفاده می‌کند، ممکن است یک برنامه‌نویس با یک سورس خراب کل بیلد را خراب کند. برای مثال، ممکن است شما یک فایل کد را بر روی کامپیوتر خود ایجاد کنید ولی فراموش کنید آن را پوش کنید و در نتیجه برنامه روی کامپیوتر شما به خوبی کامپایل شود ولی بیلد اصلی شکست بخورد.
شکستن بیلد روی سرور اصلی آن‌قدر بد محسوب می‌شود که ﻻزم است در هر پروژه، شبانه یک بیلد گرفته شود تا خراب شدن این بیلد به هیچ وجه ندیده نماند. بد نیست برای چنین کاری، مجازاتی جدی و جالب در نظر بگیرید (مثلاً خوراکی برای کل تیم!)
در تیم اکسل مایکروسافت، هر کس بیلد اصلی را خراب کند، مسئولیت بازرسی کل بیلدهای بعدی را بر عهده خواهد داشت تا زمانی که نفر بعدی بیلدی را خراب کند و این مسئولیت را بر عهده بگیرد (گویی این کار آن‌قدر مزخرف است که به مراتب تأثیر آن از جریمهٔ مالی بیشتر است).
آیا همهٔ باگ‌ها در دیتابیس خودشان پیگیری می‌شوند؟
شک نداشته باشید که اگر همهٔ باگ‌های دیده شده را در یکجا منظم و مرتب جمع‌آوری نکنید، کیفیت برنامهٔ ارائه شده افت خواهد کرد! حتی اگر در تیمی یک نفره هستید، نگاه داشتن فهرست باگ‌ها در ذهنتان پاسخگو نخواهد بود. علاوه بر این، نگاه داشتن چیزهایی در مغز که می‌توان به کاغذ، گوگل داکس و ... منتقل کرد، از نظر بهره‌وری کاری بسیار اشتباه است.
یک لیست ساده از باگ‌ها هم ممکن است کار شما یک نفر را راه بیاندازد ولی برای سیستم‌های بزرگ‌تر این برنامه باید روش ایجاد دوبارهٔ باگ، رفتار مشاهده شده، رفتار مورد انتظار، اینکه چه کسی روی باگ کار می‌کند و اینکه حل شده یا خیر را نگهداری کند (در این مورد، ترلو را چندان جدی نگیرید! ترلو برای تمرکز روی کارهای جاری خوب است اما به گذشته برگشتن در آن، کار راحتی نیست).
آیا باگ‌ها را پیش از نوشتن کد جدید حل می‌کنید؟
در تاریخ نرم‌افزار، یکی از شوخی‌های بزرگ، «مایکروسافت ورد» است. برنامه‌ای که نسخهٔ اولش یکی از فجایع مدیریت نرم‌افزاری بود. برنامه‌نویس‌ها روی این پروژه شبانه‌روز کار می‌کردند و پروژه عقب و عقب‌تر می‌افتاد. در نهایت وقتی برنامه منتشر شد، مایکروسافت همهٔ تیم را به ساحل Cancun -جهت تشویق- فرستاد و بعد جلسه‌ای تشکیل شد برای بررسی مشکل دلیور شدن این پروژه.
نتیجهٔ بررسی‌ها این بود که تمرکز بر روی رسیدن به تاریخ‌های مقرر برای انتشار، باعث شده برنامه‌نویس‌ها کدی بسیار بد تحویل دهند و هیچ زمانی را صرف حل باگ‌ها نکنند؛ چون حل باگ بخشی از زمانبندی اولیه نبود.
برای مثال، برنامه‌نویسی که مسئول نوشتن تابع محاسبهٔ ارتفاع یک خط متنی در صفحهٔ ورد بود تنها نوشته بود 12 return و در واقع برنامه‌نویس‌ها مشغول نوشتن باگ‌هایی بودند که فکر می‌کردند سر فرصت آن‌ها را به کد تبدیل خواهند کرد.
برای حل این مشکل، مایکروسافت متد برنامه‌نویسی Methodology Defects Zefor را کشف کرد بدین صورت که قبل از توسعهٔ هر کد جدیدی، انتظار می‌رود باگ‌های موجود حل شوند چرا که هر چقدر از زمان تولید یک باگ بگذرد، هزینهٔ حل آن باﻻتر می‌رود.
آیا برنامهٔ زمانبندی واقعی است؟
در هر شرکتی باید بخشی به اسم «بیزینس» باشد که وظیفهٔ پول درآوردن از کدی که شما می‌نویسید را داشته باشد. حتی اگر خودتان تنها کارمند شرکت باشید و قرار است این بخش کار کند و کد شما به پول برسد، باید زمانبندی محصول خود را بدانید.
درست است که ما برنامه‌نویس‌ها دوست داریم بگوییم «هر وقت آماده شد، خبر می‌دیم»، ولی در دنیای واقعی کارهای زیادی باید انجام شود مثل تبلیغات، بسته‌بندی، پشتیبانی و غیره. همچنین داشتن یک برنامهٔ زمانبندی باعث می‌شود شما بتوانید در مورد اندازه‌های پروژه تصمیم بگیرید.
آیا مستندات هر پروژه کامل و مشخص است؟
پیش از شروع هر پروژه، باید در مورد ابعاد آن تصمیم گرفت. به طور کلی، تهیهٔ مستندات کار سختی است درست مثل ورزش کردن! همه قبول داریم که باید ورزش کرد، ولی هیچ کس برایش وقت نمی‌گذارد.
قبل از هر پروژه، باید تحلیلگرها درک دقیقی از نیازها پیدا کنند و در طول انجام پروژه باید مستندات دقیق و مفصلی تولید شود و در انتهای پروژه باید مدیرها بتوانند با بستن اِسکوپ پروژه، آن را تحویل دهند که در غیر این صورت، پروژه سال‌ها طول خواهند کشید و کماکان چند تغییر جزیی باقی خواهد ماند!
در همین راستا، شعار حرفه‌ای‌ها باید «هیچ کدی بدون مستندات نوشته نمی‌شود» باشد. به عبارت دیگر، مستندسازی همواره در آینده به برنامه‌نویس کمک می‌کند تا مشکلات آتی را به حداقل رسانند.
آیا محیط کاری دولوپرها مناسب است؟
تحقیقات زیادی در این مورد موجود است و تقریباً همه توافق دارند که محیط کاری مناسب یک برنامه‌نویس می‌بایست ساکت، خصوصی و با فضای کافی باشد. برنامه‌نویس ها ﻻزم است در «فضای برنامه‌نویسی» قرار بگیرند و ایجاد این فضا کار راحتی نیست! ساختن این فضا گاهی اصلی‌ترین چالش یک تیم برنامه‌نویسی است؛ درست مانند ساختن یک خانهٔ شیشه‌ای که هر کسی با یک سنگ می‌تواند آن را خراب کند (این سنگ از «سلام چطوری؟» شروع می‌شود و تا «فلان سیستم خراب شده، می‌تونی کمک کنی؟» ادامه دارد).
بعضی تحقیقات حاکی از آنند که هر دولوپری برای رسیدن به بهره‌وری بالا، حداقل به ۱۵ دقیقه زمان نیاز دارد. این مسأله اهمیت آرام و خصوصی بودن محیط برنامه‌نویس‌ها را کاملاً نشان می‌دهد. اگر هر ۱۵ دقیقه یک نفر مزاحم تمرکز برنامه‌نویس‌ها شود، یعنی برنامه‌نویس‌های شما هرگز با حداکثر تمرکز خود کار نمی‌کنند.
تصاویر فانتزی مربوط به دفاتر شلوغ و پر از داد و بیداد و استرس را فراموش کنید. کد خوب از فضای آرام بیرون می‌آید؛ انتخاب موزیک بلند و غیره وابسته به خود آدم‌ها و هدفون‌هایشان است است ولی در محیط کار باید فضا آرام و کاملاً خصوصی باشد.
در این زمینه جادی مثال جالبی می‌زند. فرض کنیم که شما در شرکت خود برنامه‌نویسی به نام حسن دارید و یکی از پرسنل هم پسورد دیتابیس را فراموش کرده است. وی با عجله به سمت حسن آمده و می‌پرسد «حسن، حسن، حسن، پسورد دیتابیس رو می‌دونی؟» و همین مسئله منجر به این می‌گردد که حسن آقا تمرکزش را از دست بدهد.
رهبران شرکت‌های نرم‌افزاری می‌بایست حتماً مواظب این قضیه باشند و از اینکه حسن پاسخ همکارش را بدهد خیلی خوشحال نشوند زیرا همکاری که پسورد را فراموش کرده با مراجعه به حسن، تمرکز یک آدم گران را خراب کرده است و هزینهٔ چنین کاری برای شرکت‌های نرم‌افزاری در دراز مدت بسیار گزاف خواهد بود.
آیا از بهترین ابزارهای ممکن استفاده می‌کنید؟
ابزارها برای حل مسائل ساخته شده‌اند و ابزارهای خوب باعث بهتر شدن نتایج می‌شوند. اگر کامپایل برنامه‌ها بیشتر از ۱۵ ثانیه طول بکشد، برنامه‌نویس‌های شما سراغ کارهای دیگر خواهند رفت و درست بعد از کامپایل به کار ادامه نخواهند داد و احتماﻻً وبلاگ جادی یا بقیهٔ جاها را شروع به خواندن خواهند کرد و تا مدت‌ها به ادیتور خود بر نخواهند گشت! و یا نوشتن برنامه در دو مانیتور بسیار ساده‌تر است و قیمت یک مانیتور منطقاً کمتر از یک چهارم هزینهٔ ماهانه‌ای است که شما برای یک برنامه‌نویس می‌کنید!
جادی اشاره کرد که وی در جایی کار کرده است که کشمکش روزمرهٔ آی‌تی و کارمندان «پُر شدن صندوق ایمیل» بود و جای دیگری که پیدا کردن یک تبدیل یو‌اس‌بی به آراس ۲۳۲، اصلی‌ترین دردسر در هنگام خرابی دستگاهی قدیمی بود که از این پورت استفاده می‌کرد در حالی که خرید یک لپ‌تاپ با پورت آراس ۲۳۲، هزینه‌ای به مراتب کمتر از هزینهٔ یک روز کار آن تیم داشت.
مدیران و شرکت‌های حرفه‌ای، اعضای تیم‌شان را به خاطر یک رَم، هارد اس‌اس‌دی یا حتی یک مانیتور اضافه که همه به دارایی‌های شرکت اضافه می‌شوند، شکنجه نمی‌کنند. در ضمن، این نکته را نیز فراموش نکنید که دادن ابزارهای جذاب به برنامه‌نویس‌ها، به شکل بامعنایی رضایت شغلی آن‌ها را باﻻ می‌برد (جادی به گفتن این جمله که مدیران می‌بایست بهترین لپ‌تاپ، بهترین میز، بهترین خوراکی و به طور کلی بهترین‌ها را برای برنامه‌نویسان خود فراهم سازند، حضار را با جیغ، کف و صوت به وَجد آورد).
آیا تسترها همه چیز را زیر نظر دارند؟
در صورتی که سیستم‌ها و آدم‌ها مشغول تست تمام برنامه‌ها نباشند، این بدان معنا است که مشغول عرضهٔ کدهایی با باگ‌هایی هستند که می‌توانستند قبل از ریلیس حل شوند. یک شرکت حرفه‌ای بدون شک از تسترهایی با قیمت بسیار پایین‌تر از برنامه‌نویس‌هایش استفاده می‌کند که در غیر این صورت، شکی به خود راه ندهد که زمان برنامه‌نویس‌ها صرف کار تست می‌شود.
جادی به قراردادی که با یکی از بانک‌ها بسته شده بود و چیزی در حدود ۲۰۰ میلیون ضرر داده شد اشاره کرد. دکمهٔ تکمیل تراکنش که برای زیباسازی آن از جاوااسکریپت استفاده شده بود، باگ داشت. در واقع، افزودن انیمیشن به این دکمه باعث شده بود که اگر کاربری خیلی سریع دو بار روی دکمه کلیک می‌کرد، تراکنش دو بار انجام می‌شد و همین دو بار ارسال ریکوئست برای سرور، منجر به جریمهٔ گزافی برای شرکت نرم‌افزاری شد.
از قول جادی، یک تستر واقعی کسی است که هیچ پیش‌فرضی را در ذهن خود قرار نداده و اصلاً هم به حرف برنامه‌نویسان گوش ندهد و هر آنچه که به ذهن‌اش می‌رسد را باید تست کند.
آیا روند استخدامی شما شامل کدنویسی و مهارت‌های غیر برنامه‌نویسی نیز هست؟
استخدام یکی از اصلی‌ترین مراحل ساخت یک تیم است و متأسفانه به خصوص در ایران این پروسه معموﻻً به شکلی حرفه‌ای دنبال نمی‌شود. فرض کنید می‌خواهید شعبده‌بازی را استخدام کنید ولی در مصاحبه از او نمی‌خواهید یکی از چشمه‌هایش را برایتان انجام دهد؛ یا آشپزی را استخدام کنید بدون اینکه ﻻزم بدانید دست‌پخت‌اش را بچشید. همین طور است استخدام برنامه‌نویس بدون اینکه بخواهید برایتان برنامه‌ای بنویسد.
شرکت‌های حرفه‌ای بدون شک در پروسهٔ استخدام باید از افراد درخواست نوشتن کد کنند (حال چه روی تخته، چه با سرچ در وب و چه با هر روش دیگری) و این در حالی است که استخدام برنامه‌نویس بدون نوشتن کد کاملاً اشتباه است.
علاوه بر این، باید اضافه کرد که تمرکز صرف بر روی مهارت‌های برنامه‌نویسی نیز کاری اشتباه است. اگر شرکتی به دنبال ایجاد یک تیم حرفه‌ای است، باید به دنبال افرادی باشد که شخصیت سالم و خوبی داشته باشند. در نوکیا فرض بر این است که مهارت‌ها قابل یادگیری هستند ولی شخصیت افراد را به سختی می‌توان تغییر داد؛ پس بهتر است آدم‌های با توان فنی متوسط ولی شخصیت سالم را به شرکت بیاوریم تا افرادی خودرأی ولی خیلی باسواد که کار کردن با ایشان بسیار دشوار است!
آیا با دنیای واقعی تعامل دارید؟
اگر کسی فکر کند موجود «خفنی» است که از جهان واقعی جدا شده و فقط کافیین را به کد تبدیل می‌کند، احتماﻻً هنوز برای حرفه‌ای بودن خیلی ناپخته است (در همین راستا، توصیه می‌کنیم به مقالهٔ خودگیک‌پنداری، خود‌خَفَن‌پنداری و خودآس‌پنداری: سندرمی که برخی دولوپرها به آن دچار می‌شوند! مراجعه نمایید). آدم‌های حرفه‌ای به دیگران کمک می‌کنند، محصوﻻتشان را در همان اوایل به آدم‌ها نشان می‌دهند تا فیدبک بگیرند تا سه ماه بعد را روی چیزی که خریداری ندارد صرف نکنند، برای بقیه احترام قائل هستند و سعی می‌کنند به دیگران برای پیش رفتن کمک کنند که از این طریق خودشان هم پیش خواهند رفت.
با جهان واقعی در رابطه باشید، محصول نهایی خود و کارکرد آن را بشناسید و با دوستان غیر برنامه‌نویس حشر و نشر کنید و کتاب‌های غیرفنی بخوانید تا به عنوان شخصیتی چندبُعدی، به عنوان یک حرفه‌ای در صنعت نرم‌افزار شناخته شوید.
نکتهٔ دیگری که جادی در اینجا به آن اشاره می‌کند، Away from Keyboard است. به عبارت دیگر، وقتی برنامه‌نویسی پشت میز کدزنی خود نیست، چه‌جور شخصیتی دارد؟ آیا به قول معروف آدم باحالی است یا خیر، آیا آدمی هست که به راحتی با سایر آدم‌ها کنار بیاید یا آدمی است که خودش را برای همه می‌گیرد و کارهایی از این دست. در واقع، آدم خفن شرکت بودن مهم نیست، بلکه آدم خوب شرکت بودن مهم است و به طور کلی برنامه‌نویس خوب کسی است که در شرکت به بقیه انرژی می‌دهد (برای آن دسته از کاربرانی که علاقمند به مشاهدهٔ پرزنتیشن اصلی هستند، توجه ایشان را به لینک پرزنتیشن آیا ما حرفه‌ای هستیم؟ در پروفایل گیت‌هاب جادی جلب می‌کنیم).