پرزنتیشن جادی در اولین همایش PHP ایران: آیا ما حرفه ای هستیم؟

پرزنتیشن جادی در اولین همایش PHP ایران: آیا ما حرفه ای هستیم؟

بالاخره اولین کنفرانس پی اچ پی ایران هم با کیفیت بسیار عالی در 29 مرداد ماه ۱۳۹۴ در شهر تهران برگزار شد و سکان آکادمی هم یکی از حامیان رسانه ای این رویداد جالب بود. یکی از سخنرانان این کنفرانس جادی میرمیرانی بود که همچون همیشه، ارائه ی منحصر به فردی ارائه داد با این عنوان که «آیا ما حرفه‌ای هستیم؟» در‌ واقع وی چک لیستی ۱۲ آیتمی را ارائه کرد که در برگیرنده ی مواردی بود که شرکت های نرم افزاری حرفه‌ای بلا استثناء می بایست از آن‌ها برخوردار باشند تا بتوان لقب حرفه‌ای را به ایشان اطلاق کرد. در این مقاله با سکان آکادمی همراه باشید تا با ارائه ی زیبای جادی بیشتر آشنا گردید.

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

مدیران یا بهتر بگوییم رهبران شرکت های نرم افزاری برای سنجش وضعیت خود، می بایست به سوال ها با «بله» یا «خیر» جواب دهند و در نهایت کشف کنند که از ۱۲ سوال مطرح شده، چند تای آنها از ایشان جواب «بله» گرفته اند. اگر بیش از ۱۰ جواب بله دارید بدانید که در شرکتی با کیفیت جهانی کار می کنید و اگر کمتر از 3 امتیاز گرفتید، قبل از نوشتن کد جدیدی، برخی پروسه هایتان را اصلاح کنید.

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

به گفته ی جادی، اگر شما جزو شرکت هایی -یا برنامه نویسانی- هستید که برای اشتراک گذاری پروژه ها از دراپ باکس، ایمیل، فلش و … استفاده می‌کنید شکی به خود راه ندهید که شما حرفه‌ای نیستید (ایشان به برخی شرکت ها اشاره می‌کند که فولدرهای انتقال پروژه ها به سایر اعضا را final یا final-2 و … نامگذاری می‌کنند که با قهقهه ی حضار رو به رو می شود!)

۲- آیا در یک قدم Build می کنید؟
فرض کنید آخرین اسنپ شات کد را در دست دارید؛ حاﻻ برای رسیدن به برنامه قابل عرضه چند قدم باید طی شود؟ در یک پروژه منظم این عدد باید برابر ۱ باشد. یک اسکریپت باید کل سورس ها را دریافت کند، ریبیلد کند، فایل های اجرایی بسازد و هر کار ﻻزم دیگر حتی امضا کردن برنامه ها یا ساختن ایزوهای سی دی عرضه شونده به بازار. برای عرضه یک نرم افزار به بازار باید بتوانید در یک قدم همه اینکارها را انجام دهید چون در غیر این صورت احتمال اشتباه زیاد بوده، اصلاح باگ های لحظه آخری معموﻻ با دردسرهای بزرگ همراه خواهد شد و بسیاری چالش های دیگر!

۳- آیا Daily Build دارید؟
وقتی پروژه ای از سورس کنترل استفاده می کند، ممکن است یک برنامه نویس با یک سورس خراب کل بیلد را خراب کند. برای مثال ممکن است شما یک فایل کد را بر روی کامپیوتر خود ایجاد کنید ولی فراموش کنید آن را پوش کنید و در نتیجه برنامه روی کامپیوتر شما به خوبی کمپایل شود ولی بیلد اصلی شکست بخورد. شکستن بیلد روی سروز اصلی آنقدر بد حساب می شود که ﻻزم است در هر پروژه شبانه یک بیلد گرفته شود تا خراب شدن این بیلد به هیچ وجه ندیده نماند. بد نیست برای چنین کاری، مجازاتی جدی و جالب در نظر بگیرید! مثلا خوراکی برای کل تیم! در تیم اکسل مایکروسافت هر کس بیلد اصلی را خراب کند مسوولیت بازرسی کل بیلدهای بعدی را بر عهده خواهد داشت تا زمانی که نفر بعدی بیلدی را خراب کند و این مسوولیت را بر عهده بگیرد (گویی این کار آنقدر مزخرف است که به مراتب تاثیر آن از جریمه مالی بیشتر است.)

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

۵- آیا باگ ها را پیش از نوشتن کد جدید حل می کنید؟
در تاریخ نرم افزار یکی از شوخی های بزرگ «مایکروسافت ورد» است. برنامه ای که نسخه اولش یکی از فجایع مدیریت نرم افزاری بود. برنامه نویس ها روی این پروژه شبانه روز کار می کردند و پروژه عقب و عقبتر می افتاد. در نهایت وقتی برنامه منتشر شد مایکروسافت همه تیم را به ساحل Cancun فرستاد -جهت تشویق- و بعد جلسه ای تشکیل شد برای بررسی مشکل دلیور شدن این پروژه. نتیجه بررسی ها این بود که تمرکز بر روی رسیدن به تاریخ های مقرر برای انتشار باعث شده برنامه نویس ها کدی بسیار بد تحویل دهند و هیچ زمانی را صرف حل باگ ها نکنند چون حل باگ بخشی از زمانبندی اولیه نبود.

برای مثال برنامه نویسی که مسئول نوشتن تابع محاسبه ارتفاع یک خط متنی در صفحه ورد بود تنها نوشته بود: 12 return و در واقع برنامه نویس ها مشغول نوشتن باگ هایی بودند که فکر می کردند سر فرصت آن ها را به کد تبدیل خواهند کرد. برای حل این مشکل مایکروسافت متد برنامه نویسی Methodology Defects Zefor را کشف کرد: قبل از توسعه هر کد جدید انتظار می رود باگ های موجود حل شوند چرا که هرچقدر از زمان تولید یک باگ بگذرد، هزینه حل آن باﻻتر می رود.

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

۷- آیا مستندات هر پروژه کامل و مشخص است؟
پیش از شروع هر پروژه باید در مورد ابعاد آن تصمیم گرفت. اسناد کار سختی هستند مثل ورزش کردن. همه قبول داریم که باید ورزش کرد ولی هیچ کس برایش وقت نمی گذارد. قبل از هر پروژه باید تحلیلگرها درک دقیق از نیازها پیدا کنند و طول انجام پروژه باید مستندات دقیق و مفصلی تولید شود و در انتهای پروژه باید مدیرها بتوانند با بستن اسکوپ پروژه، آن را تحویل دهند و در غیر این صورت، پروژه ها سال ها طول خواهند کشید و هنوز «چند تغییر جزیی باقی خواهد ماند!» شعار ما «هیچ کدی بدون مستندات نوشته نمی شود» است. به طور خلاصه، مستند سازی همواره در آینده به برنامه نویس کمک می کند تا مشکلات آتی را به حداقل رساند.

۸- آیا محیط کاری برنامه نویس ها مناسب است؟
تحقیقات زیادی در این مورد موجود است و تقریبا همه توافق دارند که محیط کاری مناسب یک برنامه نویس می بایست ساکت، خصوصی و با فضای کافی باشد. برنامه نویس ها ﻻزم است در «فضای برنامه نویسی» قرار بگیرند و ایجاد این فضا کار راحتی نیست! ساختن این فضا گاهی اصلی ترین چالش یک تیم برنامه نویسی است، درست مانند ساختن یک خانه شیشه ای که هر کسی با یک سنگ می تواند آن را خراب کند. این سنگ از «سلام چطوری؟» شروع می شود و تا «فلان سیستم خراب شده، می تونی کمک کنی؟» ادامه دارد.

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

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

۹- آیا از بهترین ابزارهای ممکن استفاده می کنید؟
ابزارها برای حل مسائل ساخته شده اند و ابزارهای خوب باعث بهتر شدن نتایج می شوند. اگر کمپایل برنامه ها بیشتر از ۱۵ ثانیه طول بکشد، برنامه نویس های شما سراغ کارهای دیگر خواهند رفت و درست بعد از کمپایل به کار ادامه نخواهند دارد و احتماﻻ وبلاگ جادی یا بقیه جاها را شروع به خواندن خواهند کرد و تا مدت ها به ادیتور خود برنخواهند گشت! نوشتن برنامه در دو مانیتور بسیار ساده تر است و قیمت یک مانیتور منطقا کمتر از یک چهارم هزینه ماهانه ای است که شما برای یک برنامه نویس می کنید!

من در جایی کار کرده ام که کشمکش روزمره آی تی و کارمندان «پر شدن صندوق ایمیل» بود و جای دیگری که پیدا کردن یک تبدیل یو اس بی به آر اس ۲۳۲ اصلیترین دردسر در هنگام خرابی دستگاهی قدیمی که از این پورت استفاده می کرد بود در حالی که خریدن یک لپ تاپ با پورت آر اس ۲۳۲ هزینه ای کمتر از هزینه یک روز کار آن تیم داشت.

مدیران و شرکت های حرفه ای، اعضای تیم شان را به خاطر ۱۶۰ تومان رم یا حتی ۶۰۰ تومان هارد اس اس دی یا یک مانیتور اضافه که همه به دارایی های شرکت اضافه می شوند، شکنجه نمی کنند. در ضمن این نکته را نیز فراموش نکنید که دادن ابزارهای جذاب به بسیاری برنامه نویس ها به شکل بامعنایی رضایت شغلی آن ها را باﻻ می برد (جادی به گفتن این جمله که مدیران می بایست بهترین لپ تاپ، بهترین میز، بهترین خوراکی و به طور کلی بهترین ها را برای برنامه نویسان خود فراهم سازند، حضار را با جیغ، کف و صوت به وجد آورد.)

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

۱۱- آیا روند استخدامی شما شامل کدنویسی و مهارت های غیر برنامه نویسی نیز هست؟
استخدام یکی از اصلی ترین مراحل ساخت یک تیم است و متاسفانه بخصوص در ایران این پروسه معموﻻ به شکل حرفه ای دنبال نمی شود. فرض کنید می خواهید شعبده بازی را استخدام کنید ولی در مصاحبه از او نمی خواهید یکی از چشمه هایش را برایتان انجام دهد یا آشپزی را استخدام کنید بدون اینکه ﻻزم بدانید دستپخت اش را بچشید. همین طور است استخدام برنامه نویس بدون اینکه بخواهید برایتان برنامه ای بنویسد.

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

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

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

نکته ی دیگری که جادی در این جا به آن اشاره می کند Away from Keyboard است. به عبارت دیگر، وقتی برنامه نویسی پست میز کدزنی خود نیست چه جور شخصیتی دارد؟ آیا به قول معروف آدم باحالی است یا خیر، آیا آدمی هست که به راحتی با سایر آدم ها کنار بیاید یا آدمی است که خودش را برای همه می گیرد و … آدم خفن شرکت بودن مهم نیست، بلکه آدم خوب شرکت بودن مهم است و به طور کلی برنامه نویس خوب کسی است که در شرکت به بقیه انرژی می دهد.

ایشان یک تکنیک دوست یابی هم برای برنامه نویسان معرفی می کند. از حضار پرسید که کسی در این همایش هست که با وایرلس مشکل داشت باشد و خیلی از شرکت کنندگان گفتند آری! ایشان توصیه می کند که یک راه سر صحبت باز کردن با سایر افراد در چنین همایش هایی این است که از بغل دستی بپرسید پسورد وایرلس چیه؟ تو هم مشکل داری؟ سرعت تو هم پایینه و سوالاتی از این دست.

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

منبع


بهزاد مرادی