#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. سرویسی برای به روز رسانی لحظه‌ای بخش‌های HTML و JavaScript نرم‌افزارهای موبایل

https://t.iss.one/SoftwarePhilosophy/1110

۲. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی

https://t.iss.one/SoftwarePhilosophy/1112

۳. آشنایی با قانون حیاتی که تیم برنامه‌نویسی «آزمایشگاه نیروی متحرکه جت» ناسا

https://t.iss.one/SoftwarePhilosophy/1058

۴. چگونه تمام ستاره‌ها را در یک آسمان جمع کنیم؟ (فلسفه دیزاین)

https://t.iss.one/SoftwarePhilosophy/1115

۵. معرفی ۱۰ کتابخانه جذاب روی GitHub را که برای React

https://t.iss.one/SoftwarePhilosophy/1116

۶. چگونه حذف ویژگی های اضافی در محصول موجب متمایز بودن آن در بازار می شود؟! (Agile Product Management)

https://t.iss.one/SoftwarePhilosophy/1117

ـــــــــــ

@SoftwarePhilosophy

#پست_مجدد این پست تا به حال بیش از ۲۵۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

عنوان URLs are UI، عنوانی بسیار جذاب برای مقاله جدید scott hanselman است. نکته خیلی جالبی که بسیاری از برنامه‌های امروزی ندارند. او در این مقاله توضیح می‌دهد که خود URL ها به قسمتی از UI برنامه تبدیل شده‌اند و خوانا بودن آن و قابل خواندن بودن آنها بسیار مهم است.
برای مثال لینک یک فایل در OneDrive شبیه
https://onedrive.live.com/?id=CD0633A7367371152C%21172&cid=CD06A73371152C
است. در حالیکه لینک یک فایل مشابه در DropBox شبیه
https://www.dropbox.com/home/Games
است.
در مقاله زیر توضیح داده شده‌است که برای مثال مدلی که در StackOverflow استفاده می‌شود چقدر خوب و خلاقانه است.
https://stackoverflow.com/users/1831530/mehrandvd
در این مدل هم از کد و هم از نام استفاده شده ولی قسمت نام بی‌اثر است و با حذف آن هنوز لینک کار می‌کند.

https://www.hanselman.com/blog/URLsAreUI.aspx

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/YHoU30e1jDD

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۲۳۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

امنیت یکی از دغدغه‌های مهم نرم‌افزارهای large scale است. این دغدغه نه تنها به خود نرم‌افزار بر می‌گردد، بلکه بیشتر به تیم‌هایی برمی‌گردد که در حال توسعه این سیستم‌ها هستند. اینکه تیم برنامه‌نویسی بتواند یک ویژگی امنیتی مانند لاگین را بنویسد بسیار تفاوت دارد با اینکه بتواند یک کد را امن بنویسد. «توانایی کد نویسی امن» یک مهارت است که مخصوصا برنامه‌نویسان سیستم‌های large scale مانند سیستم‌های بانکی یا ERP باید از آن برخوردار باشند.
یکی از مهمترین تعارضات تیم‌های برنامه‌نویس با دپارتمان‌های امنیت، این طرز تفکر است که امنیت «یک تست نهایی» است که باید در انتها انجام شود. این رویکرد اشتباه غالبا باعث می‌شود ریسک‌های امنیتی زیادی متوجه سازمان شود. در تیم‌های حرفه‌ای امنیت یک کار روزانه است که همه هر روز در حال انجام آن هستند.
اخیرا دپارتمان امنیت «بهسازان» در بانک ملت پروژه جالبی را به نام «مسابقه CTF» یا Capture The Flag را اجرا کرده‌است. طی این رویداد با برگزاری یک سری مسابقات جذاب برنامه‌نویسی امنیتی، به طور ناخودآگاه دانش امنیتی تمام افراد سازمان، مخصوصا برنامه نویسان بالا رفته‌است. نکته جالبه پلتفرم بهسازان این بود که آن را طوری طراحی کرده‌اند که می‌توانند در اختیار سایر سازمان‌ها نیز قرار دهند تا متناسب با بیزنس خود آن را پیکربندی کنند و موجب آموزش این مهارت‌ها به سازمان خود شوند.

https://mehrandvd.me/2017/05/23/capture-flag-secure-software/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/p03w30cbHdO

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۲۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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

در مقاله زیر فریم‌ورک‌های معروف Mapper از لحاظ عملکرد و سرعت با یکدیگر مقایسه شده‌اند.

https://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

تکنیک‌های جذاب برای پیش از بارگذاری تصاویر

هیچوقت معرفی شدن HTML5 را فراموش نمی‌کنم، در خوابگاه بالا و پایین می‌پریدم و از پتانسیل‌های آن و نمونه‌هایی که از استفاده‌هایش در اینترنت دیده بودم برای هم اتاقی‌هایم می‌گفتم. آن‌ها هم چون رشته‌های مرتبط با کامپیوتر نداشتند، با نگاهی سرشار از تعجب و «خُب که چی؟» من را نگاه می‌کردند.
از یک جایی به بعد، وب با سرعتی سرسام‌آوری روی به پیشرفت آورد. دریچه‌هایی را به روی تمامی انسان‌های خلاق گشود که سرعت حرکت و وقوع اتفاقات جدید را در آن چند برابر کردند.
مقاله امروز هم درباره یک ایده جدید در وب است.

قبل از شروع صحبت، اجازه بدهید دو مفهوم زیر را برایتان تعریف کنم.
Placeholderها: همان عناصری هستند که تا زمان بارگذاری تصاویر، جای آن‌ها را برایشان نگه‌داشته و کاربرها را سرگرم می‌کنند.
و SVG: پسوند مربوط به تصاویر برداری (Vector) که به دلیل حجم کم و چند ویژگی دیگر، در وب جایگاه بسیار محبوبی پیدا کرده است.
قبل‌ترها از عکس‌های ثابت، رنگ‌ها و اینطور چیز‌ها به عنوان Placeholder استفاده می‌شد، ولی امروزه سرویس‌های مختلف حرکتی را آغاز کردند تا هرچقدر که می‌توانند Placeholder یک تصویر را به خود تصویر نزدیک کنند.
تلاش Google Image Search در این جهت، مرتبط بودن رنگ هر Placeholder به عکسی که بعدا در آن بارگذاری می‌شود، و تلاش Instagram، نمایش یک نسخه تار شده از عکس‌ها قبل از بارگذاری آن‌ها است.

امروز پیشنهاد جذاب و هوشمندانه یکی از برنامه‌نویسان Frontend شرکت Spotify را بررسی می‌کنیم. ایشان می‌گویند: مگر نه اینکه SVGها بسیار کم حجم هستند؟ پس چرا یک نسخه ساده شده بُرداری از تصاویر را قبل از بارگذاری‌شان نمایش ندهیم؟
هیجان‌انگیز است، نه؟
به نظر من که ایده بسیار جذابی‌ست. پیشنهاد می‌کنم جزئیات ایده ایشان را از زبان خودشان بخوانید:

https://medium.freecodecamp.org/using-svg-as-placeholders-more-image-loading-techniques-bed1b810ab2c

(زمان حدودی مطالعه، ۱۲ دقیقه)

#معرفی #ایده #طراحی_رابط‌کاربری
@Dexign فلسفه دیزاین

___

🔴 7 روش برای مقابله با جلسات برنامه ریزی خسته کننده


1- با شکم خالی جلسه برگزار نکنید

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

2- قبل از جلسه برنامه ریزی، جلسه باید آماده شده باشد

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

3- انرژی محدود است پس اولویت بندی لازم است

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

4- تایم باکس باشیم

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

5- ما در طول اسپرینت هم در حال برنامه ریزی هستیم

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

6- Swarm کنید

شاید در طول اسپرینت نیاز به یک کار فکری باشد و این هم نیاز به خرد جمعی باشد، بهترین کار این است که یک جلسه با حضور همه یا بخشی از نفرات تیم برگزار شود، این جلسه نیز باید 1- تایم باکس باشد 2- فقط حول و حوش یک موضوع خاص باشد 3- زمانبدی شروع خوبی داشته باشد

7- جلسه نیاز به تسهیل گر دارد

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

https://goo.gl/Fz9Kb1

@iranagile

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. استاندارد طراحی URL از لحاظ UX

https://t.iss.one/SoftwarePhilosophy/1120

۲. امنیت در سیستم‌های large scale با راهکار تیم امنیت بهسازان بانک ملت

https://t.iss.one/SoftwarePhilosophy/1122

۳. مقایسه عملکرد فریم‌ورک‌های مشهور Mapper از لحظا سرعت و عملکرد

https://t.iss.one/SoftwarePhilosophy/1124

۴. تکنیک‌های جذاب برای پیش از بارگذاری تصاویر (فلسفه دیزاین)

https://t.iss.one/SoftwarePhilosophy/1125

۵. هفت روش برای مقابله با جلسات برنامه ریزی خسته کننده (Iran Agile)

https://t.iss.one/SoftwarePhilosophy/1126

ـــــــــــ

@SoftwarePhilosophy

#پست_مجدد این پست تا به حال بیش از ۵۸۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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

ولی تجربه نشان می‌دهد بیشترین علت «افزونگی کد» برنامه‌نویسان نیستند! بلکه این مشکل بیشتر به خاطر «معماری بد نرم‌افزار» است. معمار نرم‌افزار کسی است که هنگام معماری باید «فضاهای» کد را طوری معماری کند تا احتمال به خطا افتادن برنامه‌نویسان کمتر شود.

لینک زیر توضیح می‌دهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود.


https://mehrandvd.me/2016/02/28/growing-redundancy-an-architectural-disease/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۶۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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


https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۲۵۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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

در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature‌ ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی می‌شوند. سپس این Feature ها به Backlog Item ها شکسته می‌شوند. یک Backlog Item در حقیقت یک نیازمندی‌است است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.

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

https://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/3NGm30b5IjZ

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۶۷۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

محصولی مانند BMW واقعا چگونه در ذهن ما به عنوان یک محصول با کیفیت شکل گرفته است؟ آیا ما تخصص بررسی عملکرد موتور و گیربکس آن را داریم؟ آیا مقایسه‌ای فنی روی آن انجام داده‌ایم تا بفهمیم ماشین BMW یک محصول با کیفیت است؟
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف می‌کند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه می‌کند. یک نقطه تماس می‌تواند لحظاتی باشد که مشتری با آن کار می‌کند، یا لحظاتی که مشتری پوستر محصول را می‌بیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن می‌شوند.

ما برنامه نویس‌ها عادت کردیم برنامه بنویسیم! و البته دوست داریم مشتریان برای این عادت ما ارزش قائل شوند و برای آن پول پرداخت کنند. اما حقیقت این است که مشتریان چیزی از زیبایی معماری نرم‌افزار ما نمی‌بینند همانطور که چیزی از جزئیات گیربکس یک BMW نمی‌دانند.
در حقیقت بهترین معماری و برنامه‌نویسی زمانی اتفاق می‌افتد که آنقدر همه چیز درست کار کند که مشتری اصلا نفهمد برنامه نویسی انجام شده، همانطور که یک گیربکس عالی گیربکسی است که مشتری هیچ‌وقت متوجه وجودش نشود و فقط مطمئن باشد که دنده به درستی عمل می‌کند.
بنابر این در اکثر مواقع توضیح اینکه برنامه چقدر خوب نوشته شده ارزشی برای مشتریان ندارد.
مقاله زیر به طور خلاصه مفهوم Touch Point و نقش آن در تعریف محصولات نرم‌افزاری را شرح داده‌است.

https://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

فُــرم‌ها را بهتر دیزاین کنیم

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

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

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

فرم‌ها می‌توانند نجات‌دهنده باشند، این مقاله را از دست ندهید.

https://uxplanet.org/3-best-form-design-practices-for-your-design-process-383510b31613

(زمان حدودی مطالعه، ۸ دقیقه)

#بررسی #نمونه_موفق #طراحی_فرم
@Dexign فلسفه دیزاین

___

⭕ با باگ‌ها چه کنیم؟

“هشتاد و پنج تا باگ از واحد تست گزارش شده، لیستش را ایمیل کردم برای همه. باگ‌های هرکس به تفکیک مشخص شده. تا شنبه ظهر باید همه باگ‌ها رفع شده باشد!”

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

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

آیا این وضعیت برای شما هم آشنا است؟

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

ببینیم در خصوص چنین رویدادی چه رویکردهایی قابل اتخاذ است:

همینه که هست!

بسیاری از افراد اعم از مدیر یا برنامه نویس، هستند که این شرایط را طبیعی می‌دانند : “باگ جزیی از نرم افزار است و از آن راه گریزی نیست”. “از ما بزرگترها، مایکروسافت و گوگل هم نرم‌افزارهای‌شان باگ دارد. ما که جای خود داریم!” . “گروه تست، کارش همین است که باگ‌های کار ما را پیدا کند”.

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

فرصتی برای بهبود

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

خوشبختانه قبل از ما خیلی‌ها دنبال پاسخ این پرسش‌ها رفته‌اند و راهکارهایی نیز ارائه کرده‌اند:

✅ استفاده از روال‌های تست اتوماتیک و استقرار CI و CD  – Continuous Delivery : این کار مستلزم ایجاد Unit Test های مناسب است که به صورت روزانه یا به ازای هر Commit کد اجرا شده و اشکالات و خطاها را به توسعه دهنده اطلاع دهند. شما را نمی‌دانم اما برای من پیش آمده که وقتی کدی را تغییر داده ام در جای دیگری از برنامه که در مخیله‌ام نمی‌گنجید منجر به خطا شده. وجود Unit Test بسیار به این موضوع کمک میکند. اگر هم که با رویکرد TDDانجام شود که چه بهتر. چون تست هایی که نوشتن آنها به بعد موکول می‌شود، ممکن است مشمول فراموشی، سهل انگاری یا کمبود وقت شوند و هرگز نوشته نشوند.

✅توجه بیشتر به تست و همکاری تسترها در زمان توسعه نرم افزار

✅بررسی باگ‌ها و شناسایی دلایل رخداد آن. مثلا پاسخ به سوالاتی از این دست: اکثریت باگ ها مربوط به کدام بخش از برنامه است و آیا نمی‌شود با تقویت Unit Testها ، تغییر معماری یا راهکارهای دیگر، باگ‌های مربوط به آن را کاهش داد؟

✅ مرور کد: اینکه کدهای نوشته شده، توسط سایر اعضا یا دست کم توسط نرم افزارهای مربوطه Review شوند. البته بعضی برنامه نویسان دوست ندارند کسی به کدی که نوشته‌اند نگاه چپ بکند و خطایی در آن پیدا کند. این برنامه نویسان به هر حال باید بین حس همکاری و اعتماد به هم تیمی‌ها یا پنجشنبه و جمعه سرکار آمدن و باگ رفع کردن یکی را انتخاب کنند.

✅ رفاکتورینگ: کدهای تمیز، خوانا ، متدهای کم حجم و به دور از کدهای Duplicate منطقا احتمال باگ کمتری دارند.

✅ پرهیز از اضافه کاری: خود اضافه کاری و کد زدن در شرایط خستگی، فشار و استرس نیز در بروز کدهای بی‌کیفیت‌تر و باگ‌های بیشتر بی‌تاثیر نیست.

https://goo.gl/tCXLN6

@iranagile

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود

https://t.iss.one/SoftwarePhilosophy/1129

۲. مفهوم فضا و تاثیر آن در معماری نرم‌افزار

https://t.iss.one/SoftwarePhilosophy/1131

۳. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی

https://t.iss.one/SoftwarePhilosophy/1133

۴. مفهوم Touch Point و نقش آن در تعریف محصولات نرم‌افزاری

https://t.iss.one/SoftwarePhilosophy/1135

۵. فُــرم‌ها را بهتر دیزاین کنیم (فلسفه دیزاین)

https://t.iss.one/SoftwarePhilosophy/1136

۶. با باگ‌ها چه کنیم؟ (Iran Agile)

https://t.iss.one/SoftwarePhilosophy/1137

ـــــــــــ

@SoftwarePhilosophy


ـــــــــ