7 پست با برچسب "Software Engineering"

یکی از سؤال‌هایی که بارها در نقش لید از من پرسیده شده، چیزی شبیه این بوده است:

برای این بخش از کدام راه برویم؟

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

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

در ظاهر داشتم به تیم کمک می‌کردم؛ در عمل داشتم تیمی می‌ساختم که برای جلو رفتن به حضور من نیاز داشت.

اگر برای هر تصمیم معماری باید منتظر تأیید یک نفر بمانیم، احتمالاً با یک معمار قدرتمند طرف نیستیم؛ با یک گلوگاه طرفیم. گلوگاهی که شاید خودش هم آن را آگاهانه نساخته باشد.

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

اما وقتی از جلسه بیرون می‌آیی، هنوز دقیق نمی‌دانی تصمیم چه شد، چه چیزی قرار است عوض شود، چه کسی مالک جلو بردن آن است و کی دوباره بررسی می‌کنیم که بهتر شده یا نه.

به نظرم مشکل این نیست که حرف‌ها غلط بوده‌اند. مشکل این است که نقدها قبل از جلسه به مسئله‌ی قابل حل تبدیل نشده‌اند. وقتی مسئله صورت‌بندی نشده باشد، جلسه خیلی زود تبدیل می‌شود به جایی برای گفتن حس‌ها و نارضایتی‌ها؛ نه جایی برای ساختن تصمیم.

یک جایی در مسیر کار تیمی، فهمیدم چیزی که اسمش را هماهنگی گذاشته‌ایم، همیشه هماهنگی نمی‌سازد.

گاهی فقط همه را در یک اتاق نگه می‌دارد.

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

یک باگ به production می‌رود. کاربر ناراضی می‌شود، پشتیبانی درگیر می‌شود و تیم فنی دنبال علت می‌گردد. در چنین لحظه‌ای معمولاً اولین سؤال این است: «چرا QA این را نگرفت؟»

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

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

پس ایده‌ی اصلی این متن ساده است: کیفیت مسئولیت مشترک تیم است؛ اما مسئولیت مشترک نباید به بی‌مالکیتی تبدیل شود. هر نقش باید مالک کیفیت همان تصمیمی باشد که روی آن اثر می‌گذارد.

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

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

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

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

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

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

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

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