جای خالی Software Craftsmanship در جامعه آی تی ما

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

نتیجه سرچ اون روزم به طور خلاصه این بود؛ حرکت Software Craftsmanship تو سال ۱۹۹۲ با مقاله Jack W. Reeves با موضوع “?What Is Software Design” شروع شد که به این موضوع اشاره میکرد که توسعه نرم افزار بیشتر یه مهارته تا دیسیبلین مهندسی. سال ۲۰۰۱ Pete McBreen با انتشار کتاب Software Craftsmanship دوباره به این موضوع اشاره کرده که توسعه دهندگان نرم افزار نباید خودشون رو تنها با مفاهیم سنتی مهندسی مقایسه کنند و در واقع میشه مفاهیم بیشتری در شکل گیری یک توسعه دهنده نرم‌ افزار نقش داره . سال ۲۰۰۸ Robert C. Martin پیشنهاد به اضافه کردن  "Craftsmanship over Execution" به عنوان اصل پنجم Agile Manifesto کرد . اینم بگم در اینجا توسعه دهنده نرم افزار به منظور برنامه نویس نیست و مفهومی بیشتر از اون داره. در سالهای اخیر مفاهیم DevOps هم وارد این حوزه شده.

اولین بار که اصول Software Craftsmanship رو خوندم برای من که از کشوری میومدم که همه جا پر از شعار و حرف های قشنگ ولی بدون عمل بود به نظرم این اصول خیلی مسخره و شعار زده بود ولی کم کم تو این یه سال یاد گرفتم که چقدر راحت میشه این اصول رو عملی کرد و یک جامعه خوب و پویا از توسعه دهنده های نرم افزار داشت که خودشون باعث رشد خودشون و جامعشون میشن . این مقدمه رو گفتم که اصول Software Craftsmanship رو توضیح بدم. به عنوان یک Software Craftsmen/women وظیفه یادگیری، تمرین و آموزش به سایر توسعه دهندگان جهت بالا بردن سطح حرفه ای این جامعه بر عهده ماست. همچنین این اصول تاکید دارن که:

  1. نباید نرم افزار یا کدی نوشته شود که تنها کار میکند بلکه باید کد با کیفیت بالا و توجه به Best practice های مهندسی نرم افزار تهیه شود .
  2. بهبود نرم افزار نباید تنها در واکنش به عامل بیرونی برای تغییر باشد بلکه به طور پیوسته باید در حال بهبود نرم افزار باشیم .
  3. به جای افراد متخصص یک جامعه متخصص ایجاد کنیم و به اون جامعه متخصص تکیه کنیم .
  4. به جای فقط همکاری با افراد یا تیم هایی که باهاشون کار میکنیم به یک همکاری مولد فکر کنیم.

این یک سال خیلی به این اصول و معانی فکر کردم و اینکه چطور شرکت هایی مثل 8th light با تکیه به این اصول به ظاهر ساده میتونن انقدر تو دنیا موفق باشن و چرا مفهومی به عنوان یه جامعه متخصص که بشه بهشون اتکا کرد، ازشون یاد گرفت و بهشون یاد داد انقد ضعیفه تو ایران. من اول از همه از خودم شروع میکنم اینکه چرا من بعد از یک سال شروع کردم به نوشتن راجع به تجربه های عالیم با جامعه Software Craftsmanship نشون دهنده این ضعف توی یاد دادن و انتقال تجربه هامون به هم دیگست. تو این یک سال یاد گرفتم که با یاد دادن آموخته هام به دیگرانه که اونارو برای خودم عمیق تر میکنم و خیلی وقتا در حین این فرایند چیزای جدیدی یاد میگیرم. نکته مهم بعدی اینه که با بالا بردن سطح جامعه متخصصی که باهاشون در ارتباطیم ناخوداگاه سطح تخصص فردیمون هم بالا میره. خلاصه اینکه نترسید از انتقال دانشتون و نترسید از اینکه گاهی در این فرایند ممکنه به شدت و گاهی بیرحمانه متوجه نقاط ضعفتون بشید. برای من کنار گذاشتن این ترس ماه ها طول کشید، ینی از روزی که تصمیم به نوشتن کردم تا امروز.

شرکت های بزرگی مثل 8th light بهترین مثال هستن برای بالا بردن سطح جامعه متخصصی که باهاش در ارتباط اند، این شرکت ها یه برنامه آموزشی چند ماهِ دارن برای افرادی که برای این دوره اپلای کنن و بتونن مصاحبه های ورودی رو بگذرونن. قسمت جالبش اینه که تو این چند ماه (۳ تا ۱۲ ماه) توسط بهترین متخصص های دنیا آموزش میبینی و بهت به عنوان کارمند جونیور اون شرکت حقوق میدن، بدون گرفتن هیچ تعهدی بابت موندن در اون شرکت بعد از اتمام دوره آموزشیت. الان سالهاست جامعه Software Craftsmanship تو آمریکا و بیشتر کشور های اروپا برای کمک و حمایت از افراد این جامعه شکل گرفته. لندن دهمین سال ایجاد گروه Software Craftsmanship با حدود 4390 عضو رو چند روز پیش تو کنفرانس سالانش، SCLConf جشن گرفت.

در آخر این رو هم بگم که من خیلی اتفاقی و شاید از روی خوش شانسی با این جامعه آشنا شدم؛ وقتی اومدم لندن چون سابقه کار تو اروپا رو نداشتم تصمیم گرفتم برای پوزیشن جونیور اپلای کنم که مسئولیت و استرس سال اول کاریم کمتر باشه تا بتونم بیشتر رو بهبود زبان انگلیسیم تمرکز کنم، بعد شرکت الانم بهم پیشنهاد داد برای پوزیشن آموزشی سه تا شش ماهشون اپلای کنم، راستش منم به دو دلیل قبول کردم اول اینکه خب آموزش بود و اینکه آدمایی که این دوره رو برگزار میکردن جز بهترین ها تو فیلد تخصصیشون بودن و دوم اینکه حقوق یکسانی با پوزیشن های جونیور داشت. فارغ التحصیل شدن از این دوره بین ۳ تا ۶ ماه بود که برای من ۴ ماه طول کشید. بعد از فارغ التحصیلی هم به اندازه یک Mid Developer افزایش حقوق داشتیم. این رو هم بگم که برای فارغ التحصیل شدن باید مراحل مختلفی رو میگذروندی که تو پست های بعدی به مرور راجع به این مراحل توضیح میدم. تو این پست سعی کردم به طور خلاصه از کلیات غیر فنی ماجرا حرف بزنم و قصد دارم در پست های بعدی به مباحث فنی دوره آموزشی ای که گذروندم تا وارد جامعه Software Craftsmanship های لندن بشم، بپردازم؛ که شامل مفاهیم مختلف eXtreme Programming practices و SOLID principles و Classic TDD/Outside-In و Macro Design ها و غیره میشه.