مالکیت واقعی یعنی چی؟
خلاصهٔ کاملتر
این مطلب در اصل یه پیام Slack داخلیه که تورستن بال بعد از یه گفتوگو با یکی از همتیمیهاش تو تیم Amp نوشته و بعداً تصمیم گرفته منتشرش کنه. نویسنده میگه بارها از کلمهی «مالکیت» (ownership) استفاده میکنه ولی مدتها بود توضیح نداده بود دقیقاً منظورش چیه، برای همین این بار نشسته و کامل بازش کرده.
به گفتهی نویسنده، وقتی ازت میپرسه «میتونی مالک این کار بشی؟»، منظورش اینه که حل یه مشکل رو از اول تا آخر به عهده بگیری؛ از لحظهای که «یه مشکل داریم» تا جایی که «دیگه لازم نیست بهش فکر کنیم». یعنی نباید فرض کنی یکی دیگه اون چیزایی که تو بهشون فکر نکردی رو انجام میده.
مهمترین بخش حرفش یه چکلیست ذهنیه. اول اینکه واقعاً مشکل چیه؟ نویسنده میگه خیلی وقتا آدم به جای مشکل، یه راهحل رو میگه؛ مثلاً «باید از X به Y مهاجرت کنیم» راهحله، مشکل احتمالاً چیزیه مثل «کارایی بده» یا «برای فلان مشتری کار نمیکنه». باید راهحلهای دیگه و trade-offهاشون رو هم سبکسنگین کنی.
بعدش باید به حالتهای خاص (edge case)، خطاها (مثل قطعی شبکه که حتمیه و باید تکلیف retry و تعدادش معلوم باشه) و جریان داده فکر کنی: چقدر داده درگیره، لازمه مهاجرت یا پاکسازی بشه، و چه فرضهایی دربارهی شکل داده داری که هنوز تأیید نکردی.
نویسنده تأکید میکنه کارو با دقت و بدون سرهمبندی انجام بده و قبل از merge از خودت بپرس بهش افتخار میکنی یا نه. تست دستی رو جدی میگیره: با اینکه تست خودکار هست، تو ۹۹٪ موارد میتونی خودت اجراش کنی و مطمئن شی واقعاً کار میکنه. بعدش هم باید مطمئن شی توی production درست کار میکنه، feature flag فعاله و واقعاً deploy شده.
بخش دیگهش دربارهی خبررسانیه: اگه همتیمیها، مشتری یا حتی دنیای بیرون باید از این تغییر خبردار بشن، بهشون بگو. نویسنده میگه دونستن اینکه دیروز فلانی رفتار Z رو عوض کرده، ممکنه امروز سه ساعت از وقت دیباگ یکی دیگه رو نجات بده.
دربارهی تازهکارها هم میگه انتظار نداره همهی اینها رو از همون اول انجام بدن، ولی باید لیست رو بخونن و آرزو کنن یه روز بتونن؛ تا اون موقع هم راحت کمک بخوان. حتی اضافه میکنه از هیچکس انتظار نداره همیشه همهی اینها رو برای هر کاری انجام بده — این فقط یه چکلیست ذهنیه، و توی شرکتهای خیلی بزرگ شاید اصلاً به دردت نخوره؛ حرفش بیشتر برای تیمهای کوچیکه.
نکات کلیدی:
- مالکیت یعنی حل یه مشکل از اول تا آخر، بدون اینکه فرض کنی یکی دیگه کارای فکرنشده رو انجام میده
- اول مشکل واقعی رو پیدا کن، نه اینکه مستقیم بپری سراغ یه راهحل
- حالتهای خاص، خطاها و جریان داده رو از قبل در نظر بگیر
- تست دستی و مطمئنشدن از کارکرد توی production بخشی از کاره
- به همتیمیها، مشتری و بقیه از تغییرات مهم خبر بده
