مشکلی که رفع می‌کنید، مهم‌تر از کدی است که می‌نویسید

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

۵۰ سال پیش و در سال ۱۹۶۸، یک کنفرانس کاری درباره مهندسی صنعت نرم‌افزار، که توسط کمیته علمی NATO میزبانی شده بود، برگذار شد. در آن زمان، مردم کم کم متوجه شدند که صنعت نرم‌افزار در حال تبدیل شدن به یک بخش اساسی از جامعه بود. گرچه، درک آن هم همینطور سخت‌تر می‌‌شد. پس از آن کنفرانس، برنامه‌نویسی یک صنعت کامل شد. این صنعت کم کم از کنترل افراد مشغول در زمینه کسب و کار دور شد.

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

برای مثال...

یک استارت‌آپ در حال ساخت دستگاهی بود که یک فرد را قادر می‌ساخت تا قفل در خانه خود را با استفاده از بلوتوث باز کند. رابط کاربری مربوط به ارتباط با دستگاه آن‌ها یک ویجت بود، که حتی وقتی تلفن قفل بود هم قابل مشاهده بود. این ویجت تنها یک دکمه به نام «Open the door» داشت.

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

شخصی به جریان کاری این روند نگاه کرد و پرسید:

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

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

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

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

«هر کدی ارزش نوشتن را ندارد.»

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

مبادله کردن شدت و اولویت، من را یاد مدلی که یکی از همکارانم اخیرا به من نشان داد، انداخت. این مدل، «ماتریکس اولویت» نام دارد. یک مدل دو بعدی که می‌تواند برای اولویت‌بندی عیب‌ها، بر پایه تعداد کاربرانی که یک عیب تحت تاثیر قرار می‌دهد و شدت آن استفاده شود.

تصویر بالا، تصویری است که ماتریکس اولویت دو بعدی را توصیف می‌کند. بُعد Y، نمایانگر ستون دارای عنوان «User Affected» (تعداد کاربرانی که تحت تاثیر این عیب قرار گرفته‌اند) می‌باشد، که شامل مقادیر «One» (یک)، «Some» (برخی) و «All» (همه) است. بعد X، نمایانگر ستون دارای عنوان «Severity» (شدت) می‌باشد که شامل مقادیر «Cosmetic» (تنها در ظاهر)، «Inconvenient» (نامناسب) و «Stops Work» (کار را متوقف می‌کند) است. اولویت یک عیب بر حسب موقعیت محور، کم و بیش قابل ملاحظه است. برای مثال اگر یک عیب تنها در ظاهر باشد و یک کاربر را تحت تاثیر قرار دهد، اولویت آن ۴ است. اگر یک عیب کار کسی را متوقف کند و برخی کاربران را تحت تاثیر قرار دهد، اولویت آن ۱ است. اگر یک عیب کار یک شخص دیگر را متوقف کند و همه کاربران را تحت تاثیر قرار دهد، بالاترین اولویت را با مقدار صفر دارد.

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

«هر عیبی ارزش برطرف کردن را ندارد.»

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

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

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

«هر دستوری ارزش اسکریپت کردن را ندارد.»

سال‌ها پیش من بر روی پروژه‌ای کار می‌کردم که از تحویل افزایشی (Incremental Delivery) استفاده می‌کرد. این پروژه، یک سیستم تایید (verification) هویت بود که از کاربران درخواست می‌کرد تا برخی داده‌های شخصی را در آن وارد کنند، تا این داده‌ها توسط یک سیستم جداگانه تایید شوند.

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

علتش این بود که: این روند تایید (verification)، اجباری بود.

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

در بدترین حالت، کاربرانی که نمی‌توانستند خود را تایید کنند، باید با پشتیبانی تماس می‌گرفتند تا به صورت دستی تایید شوند:

«هر امکاناتی ارزش کدنویسی را ندارد.»

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

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

هدف شما و هدف کدی که می‌نویسید، این است که ارزشی را به وجود بیاورید و دنیای فعلی را تبدیل به یک مکان بهتر کنید، نه این که بینش مغرورانه خود از چیزی که دنیا باید باشد را راضی کنید.

از قدیم گفته‌اند: «اگر تنها چیزی که دارید،‌ یک چکش کوچک باشد، هر چیزی به ظاهر یک میخ می‌آید.»

بهتر است اول یک میخ داشته باشید،‌ تا نیاز به یک چکش را درک کنید.

البته، اگر از اول به یک میخ نیاز دارید.

منبع