به نام خدا

ایده اصلی TDD ایده حل مسئله به روش تقسیم و غلبه است.اگر فرایند پیاده سازی هر کدی در ذهنمان تبدیل به یک روتین تقریبا ثابت تبدیل شود سربار پیاده سازی برایمان کمتر میشود. آقای کنت بک این ایده تقسیم و غلبه کردن مسائل و پیاده سازی آنها را به خوبی با مثال های فراوان در کتاب TDD by example توضیح داده است.نکته بسیار قابل ملاحظه ی این کتابWrite clean code that works هست که that works اولویت بیشتری به clean code دارد همچنین در راستای رسیدن به روتین ثابت پیاده سازی ابتدا به that works فکر میکنیم و وقتی که با پاس شدن تست ها از این مطمئن شدیم حال به clean code فکر می کنیم.

چند وقت پیش توی مصاحبه با یک Front End Developer بودم که بعد از حال و احوال اون دوست عزیزمون از من پرسید شما که عنوان شغلیتون زده Software Engineer پس چطوری مصاحبه فرانت می خواید بکنید ؟
گفتم مگه فرانت کارا نمیتونن مهندس نرم افزار باشن ؟
گفت آخه عموما به بکند کارا میگن Software Engineer.
به شوخی گفتم این کلاهی بوده که بکندیا رو سر فرانت کارا گذاشتن :))

حالا از شوخی بگذریم مسائل زیادی در توسعه اپلیکیشن سمت موبایل و وب وجود داره که نیاز به دانش عمیق و تسلط کافی روی مباحث مهندسی نرم افزار داره.
مسئله کلان Performance چیزیه که سمت فرانت هم داری باهاش سرو کله میزنی حتی به نوعی پیچیده تر چرا که پرفورمنس رندرینگ به ذات پیچیده است.
یا به طور مثال مسائل پایه ای بهینه سازی پایگاه داده در توسعه کلاینت ها نیز مطرح هست.
هزینه انتشار نسخه و رولبک اون چی ؟ سمت بکند بیشتره یا کلاینت ؟
از این موارد زیاد هست که میشه مثال زد.

به نظرم این مسئله ای است که جای کار زیادی داره همونجور که گوگل هم یک مقاله سی چهل صفحه ای روی معادل SRE در توسعه اپلیکیشن موبایل داده. که خب به نظرم اینکه در بکند بالغ تره میتونه شاهد این باشه که SRE سمت کلاینت خیلی پیچیده تره.

دچار محموله‌پرستی در مهندسی نرم‌افزار نشویم!

محموله‌پرستی یا بارپرستی (Cargo Cult) آیینی نسبتاً جدید مربوط به قرن نوزدهم تا بعد از جنگ جهانی دوم است که در ملانزی اقیانوس آرام و گینه نو پدید آمد. البته در دیگر نقاط جهان نیز رفتارهای مشابهی دیده شده‌است. مردم بومی این مناطق که نمی‌توانستند تصور کنند محموله‌ها و کالاهای لوکس و پیشرفته‌ای که سفیدپوستان و استعمارگران به این نواحی آوردند ساخته دست انسان باشد آن محموله‌ها را فرستاده‌هایی از سوی نیاکان درگذشته خود پنداشتند که سفیدپوستان با روش‌های خود موفق به دست‌یابی به این محموله‌ها شده‌اند. به این خاطر مردم بومی کوشیدند تا با تقلید رفتار سفیدپوستان نظر نیاکان را جلب کنند تا بارها را به جای سفیدپوستان به بومیان تحویل دهند.

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

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

https://en.wikipedia.org/wiki/Cargo_cult

توی https://newsletter.pragmaticengineer.com/p/how-microsoft-does-quality-assurance?r=2qlwp2&utm_campaign=post&utm_medium=web آقای GERGELY OROSZ توضیح میده که شرکت مایکروسافت اپروچش نسبت به تضمین کیفیت چجوری بوده و از سال ۲۰۱۴ به بعد چجوری این قضیه تغییر کرده و به چی رسیده.

توی شرکت مایکروسافت رولی وجود داشته به نام SDET (Software Development Engineer in Test)
اینها توی تیم‌های تست بودند نه توی تیم‌های توسعه. کارشون این بوده که automated test بنویسن. کدی واسه توسعه محصول نمیزنن. ابزارها و زیرساخت واسه تست درست می‌کنن.

اما سال ۲۰۱۴ ایشون به تیم وب اسکایپ اضافه میشه و اونجا میبینه که این تیم داره هر روز نسخه میده نه ماهی یکبار و میره تو کار اینکه این رول رو حذف کنه و به جاش وظیفه تست بیوفته روی دولاپرهای خود تیم. و نتیجه ای که میگیره اینه که این تیم خیلی پروداکتیو تر میشه.
بعد از وسط‌های سال ۲۰۱۴ تیم‌های دیگه‌ی وب مایکروسافت و bing هم میرن سمت همین کار.

قبل و بعد از این که تست نوشتن رو به خود تیم توسعه محول کنند هم توی تصویر اومده که از حجم E2E تست‌‌هاشون کم شده و به حجم UnitTest هاشون اضافه شده است.

جزییات بیشتر در مقاله‌ی بالا :)

#QA
#Software_testing
#Software_engineer_in_test

پدر من یک بنّا است. از کودکی، در تابستان‌ها به همراه پدرم به ساختمان‌ها می‌رفتم. به همین دلیل، تا حدی با ابزارها و فرآیندهای ساخت ساختمان‌ها آشنایی دارم. از سال ۹۳ که به دنیای علوم کامپیوتر وارد شدم، همیشه به تفاوت‌های بین دنیای کامپیوتر و صنعت عمران فکر می‌کردم، زیرا همیشه خودم را در کنار پدرم می‌دیدم.

سال ۹۷ با امین نمدچیان گهگاهی هم‌صحبت می‌شدیم. توی یکی از این صحبت‌ها امین یک نظر جالبی رو مطرح کرد که به شدت برای من الهام بخش بود.

*امین گفت: "مهندسی کامپیوتر هنوز خیلی جوونه کل عمرش ۸۰ ساله، و ما انرژی زیادی رو صرف ابزار می‌کنیم نه حل مسئله. در حالی که در مهندسی عمران که بیشتر از ۱۰۰۰ سال عمر داره، دیگه خیلی کم درگیر ابزار می‌شوند. ابزار ها غالبا بالغ شده اند و نشانه‌ی این بالغ شدن ساده بودن آنهاست."*

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

*ارتباط مهندسی کامپیوتر با مهندسی عمران*
کم و بیش احتمالا شما هم مهندسی کامپیوتر با مهندسی عمران رو مقایسه کرده‌اید یا در مقابل این مقایسه‌ها قرار گرفته‌اید. سم‌نیومن در کتاب Building microservices مثالی می‌زنه که خیلی این مسئله رو خوب شفاف می‌کنه.
وقتی یک مهندسی کامپیوتر می‌خواد یک سیستم نرم‌افزاری را طراحی و پیاده‌سازی کند از نظر سطح پیچیدگی مثل این می‌ماند که یک پروژه‌ی شهرسازی را طراحی و پیاده‌سازی کنه. پس توسعه‌ی یک نرم‌افزار شبیه شهرسازی‌است نه ساختمان‌سازی.

مورد بعدی اینه، ما به عنوان یک مهندس نرم‌افزار که کدزنی هم‌ می‌کنیم، بیشتر شبیه به کارگران ساختمان هستیم یا مهندسان عمران ؟
شاید میشه گفت هر دو. ما مهندسانی هستیم که کارگری هم می‌کنیم، فقط ما کارگر دانش هستیم. (عبارت Knowledge worker رو اولین بار آقای Peter Drucker در سال ۱۹۵۹ مطرحش کرده.)
می‌تونید یک مهندس عمران با کت و شلوار در حال درست کردن ملات سیمان رو تصور کنید ؟
ما در حال حاضر یک همچین شخصی هستیم. مهندسی که حتی ملات درست کردن رو هم خودش انجام میده.
حالا اینجا می‌رسیم به قسمت جذاب داستانمون. هوش مصنوعی چجوری می‌خواد مهندسی نرم افزار رو یک پله بالغ‌تر کنه؟

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

*پس بگذارید ملات سیمان رو هوش مصنوعی براتون درست کنه*

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

در آخر ایکاش آجرها را در ساختمان‌ها ماشین ها می‌چیدند 😞

چند روز پیش‌ تو شرکت بحثی می‌کردیم سر برنامه‌نویسی موازی.حرفم این بود که بچه هایی که برنامه‌نویسی موازی رو با گولنگ یاد میگیرند جدیدا خیلی عمیق نمیشن تو مفاهیم چندنخی.اینو صرفا البته توی برخوردم با یه جامعه ی دور و اطراف خودم میگم.در کل خوبه که مهندسان نرم‌افزار یکبار چندنخی، رویکردهای مختلف، مسائل و چالش های shared state رو عمیق بشن.حالا اینکه در زبان این مفاهیم جوری پوشش داده بشه که با سطح بالاتری باهاشون مواجه بشیم خب خیلی خوب و بدرد بخوره.

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

از کتاب هفت عادت مردمان موثر