جوئل اسپلوسکی | Joel Spolsky

1-در هفته 40 ساعت یا کمتر کار می کنید؟

راحت ترین راه برای اینکه مطمئن شویم افراد خوشحال هستند این است که زمانی را در اختیار آن ها قرار دهیم تا از زندگی خودشان لذت برده و سلامتی خود را حفظ کنند. مطالعات زیادی  درمورد تاثیر منفی کار بیش از حد روی سلامتی وجود دارد و همه ما موافقیم که کارمند سالم خوشحال تر و سازنده تر است. در سال های اخیر شرکت های بزرگی مثل Microsoft داشتن تنها 4 روز کاری در هفته را مورد آزمایش قرار داده و نتایج خوبی در افزایش سازندگی به دست آوردند. البته همه سازمان ها نمی توانند اینگونه عمل کنند اما نبود اجبار برای اضافه کاری، از نشانه های سلامت سازمان است.

2-در محل کار زمانی را به یادگیری اختصاص می دهید؟

توسعه دهنده خوب بودن با توسعه دهنده خوب ماندن دو مسئله متفاوت است. برای اینکه توسعه دهنده خوب بمانید باید به طور مداوم مهارت های جدید کسب کنید و مهارت های فعلی خود را به روز نگه دارید. با اینکه یادگیری همه چیز غیر ممکن است اما بهترین تیم های توسعه دهنده نرم افزار بخشی از زمان کاری خود را به یادگیری اختصاص می دهند. این زمان می تواند صرف مشارکت در پروژه های متن باز (open-source)، مشاهده آموزش و خواندن مطالب وبلاگ های مختلف شود. البته نیازی نیست یک روز کامل را صرف انجام این کارها کنید. موارد دیگری مانند ترویج Pair programming، اختصاص زمانی برای تحقیق حین انجام وظایف روزانه و برگزاری جلسات داخلی با تمام افراد تیم نیز می توانند راه هایی برای یادگیری باشند.

3-ابزار مورد نیاز برای کار در اختیار دارید؟

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

4-لیست اولویت بندی شده ای از کارهایی که باید انجام شوند دارید؟

اولویت بندی کردن کارها به طور منظم اهمیت ویژه ای دارد. کار کردن روی مسئله درست، بهتر از انجام کار خیلی خوب روی مسئله اشتباه است. بنابراین مطمئن شوید که تیم شما به طور مرتب وظایف موجود را اولویت بندی کرده و توسعه دهنده ها، وظایفی با اولویت بالاتر را انجام می دهند.

5-هنگامی که پیاده سازی قابلیت های جدید بیش از انتظار طول می کشد زمان پروژه را زیاد تر یا قابلیت مورد نظر را کوچک تر می کنید؟

از آنجایی که تخمین زمان تحویل پروژه (Deadline) صرفا یک حدس از اتفاقاتی است که در آینده خواهد افتاد، اکثر مواقع کمکی به پروژه نمی کند. تولید نرم افزار فرآیندی پیچیده و غیر قابل پیش بینی دارد. همچنین، نیازمندی ها و اولویت ها همیشه درحال تغییر اند. مهلتی که برای تحویل پروژه در نظر گرفته می شود، از اصلی ترین دلایل اضافه کاری است. خیلی از تیم ها برای رسیدن به مهلت تحویل، تحت فشار زیادی قرار می گیرند که باعث در خطر قرار گرفتن سلامت جسمی و روانی اعضای آن می شود.
به جای تخمین زدن و وانمود کردن به اینکه از آینده با خبر هستیم، بهتر است هر روز بهترین کاری که می توانیم را انجام دهیم و با مشتریان پروژه ها ارتباط را حفظ کنیم، تا آن ها نیز از آخرین وضعیت پروژه با خبر شوند. اگر مشتریان، هدف خاصی را تعیین کرده اند، برای اینکه مطمئن شویم نسخه ای ساده و قابل استفاده از خواسته آن ها در زمان معین آماده می شود با آن ها صحبت کنیم تا وسعت قابلیت خواسته شده را محدود کنند (طرفداران متدولوژی agile با این تاکتیک آشنایی دارند).
محدود کردن قابلیت خواسته شده اکثر اوقات باعث می شود محصول زودتر آماده استفاده شده و بازخورد کاربران واقعی را زودتر دریافت کنیم تا زمان زیادی را صرفه جویی کنیم و از توسعه قابلیت های پیچیده ای که کاربران نیاز ندارند، جلوگیری کنیم.

6-پروژه هایی که انجام می دهید مستند های به روز دارند؟

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

7-پیام های Commit و Pull request های شما در Git سازمان، مناسب کاری که انجام می دهید است؟

برخلاف پروژه های فردی، در پروژه های تیمی تاریخچه Git اهمیت زیادی دارد. برای شخصی که به تازگی وارد یک پروژه شده است پیام های Commit منبع ارزشمندی هستند تا بدون داشتن دانش عمیق از حوزه فعالیت پروژه، به درک مناسبی از دلیل تغییر های ایجاد شده و ارتباط آن ها با یک دیگر برسد.
فهمیدن کد های موجود معمولا زمانبر ترین بخش توسعه نرم افزار است. در یک تیم توسعه نرم افزار صرف زمان برای حل کردن چالشی که از قبل توسط سایر اعضای تیم حل شده، کار بیهوده ای است. این دقیقا همان اتفاقیست که وقتی شما پیام Commit یا توضیح (pull request) PR خود را خالی می گذارید رخ می دهد. زمانی که شما یک PR را ثبت می کنید، بیشتر از هرکسی درمورد آن اطلاعات دارید. پس بهتر است تا آن اطلاعات را از یاد نبرده اید، بنویسید. با انجام این کار در زمان سایر هم تیمی های شما نیز صرفه جویی می شود. کسانی که PR شما را بازبینی می کنند، توسعه دهندگان جدیدی که در آینده به تیم اضافه می شوند و تاریخچه Git را مطالعه می کنند و خود شما در آینده، همه جزئیات را مانند اکنون به یاد نخواهید داشت.

8-تمام کد ها تست اتوماتیک دارند؟

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

9-کد ها توسط شخصی به جز نویسنده آن بازبینی می شود؟ (کد ها به صورتpair programming نوشته می شوند؟)

یکی از راه های مطمئن شدن از کیفیت کد، بازبینی آن توسط شخصی با دیدگاه تازه است.
تا جای ممکن بهتر است در تیم های دو نفره ای کار کنید که هر توسعه دهنده، PR های توسعه دهنده دیگر را قبل از merge شدن بازبینی می کند. ایجاد فرهنگ Pair programming در سازمان نیز اهمیت ویژه ای دارد. در pair programming دو توسعه دهنده با استفاده از ابزارهایی مانند Zoom صفحه نمایش خود را با دیگری به اشتراک گذاشته و به صورت همزمان روی یک کد کار می کنند.
پیاده سازی قابلیت های بزرگ و پیچیده با Pair programming نسبت به روش انفرادی، موجب ایجاد کد بهتر می شود. این تکنیک نه تنها باعث می شود خطا ها قبل از انجام Commit پیدا شوند بلکه به توسعه دهنده ها این امکان را می دهد تا نسبت به یک بازبینی عادی کد، بیشتر و عمیق تر درمورد طراحی پروژه فکر کنند. همچنین Pair programming علاوه بر اینکه کار جالبی است به عنوان راه خوبی برای یادگیری از یک دیگر شناخته می شود.
به طور کلی هنگامی که کیفیت کد برای سازمان اهمیت دارد، بازبینی دو نفر بهتر از یک نفر است.

10-محیط توسعه شما و سرور محصول عرضه شده تا جای ممکن با یک دیگر شباهت دارند؟

توسعه دادن تحت نسخه های متفاوتی از فریم ورک، زبان، دیتابیس یا سیستم عامل به احتمال زیاد باعث می شود تا جمله ای مثل “روی سیستم من کار می کند” را از اعضای تیم بشنوید. محدود کردن تفاوت بین محیط ها در اصل محدود کردن زمانیست که برای رفع خطاهای ایجاد شده توسط اختلاف نسخه ها صرف می کنید. اگر از ابزار های مدیریت Dependency (وابستگی های پروژه) مانند Composer استفاده می کنید می توانید به راحتی نسخه جدیدی از کتابخانه یا فریم ورکی که استفاده می کنید را روی همه محیط ها داشته باشید. همچنین با استفاده از ابزاری مثل Docker می توانید محیط توسعه و نصبی کاملا مشابه یک دیگر داشته باشید.

11-از خطا های پروژه های عرضه شده به طور خودکار با خبر می شوید؟

هیچ کس کد بدون باگ نمی نویسد و شما نمی توانید خطایی را که از وجود آن خبر ندارید، برطرف کنید. مطمئن شوید خطا هایی که پس از عرضه رسمی پروژه رخ می دهد را در جایی نگه داری می کنید که تمام اعضای تیم قادر به دیدن آن هستند. تعداد زیادی از برنامه های قدیمی که با زبان PHP نوشته شدند به طور کلی گزارش خطا را خاموش کرده اند! به یاد داشته باشید که خاموش کردن گزارش خطاها باعث نمی شود آن ها از بین بروند.

12-حداقل هفته ای یک بار کد های نوشته شده را در محصول عرضه شده بارگذاری (deploy) می کنید؟

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