ساخت یک فرهنگ کیفیت کد قوی در تیم

داشتن کد باکیفیت مثل یه چاقوی تیز می مونه، باهاش راحت کار می کنی، سریع تر کار رو تمومش می کنی و نتیجه نهایی هم کارآمد تر میشه. فقط هم نباید این فکر رو کرد این امر یه مسئله داخلیه که به تیم مهندسی خودمون مربوطه. کیفیت کد، مستقیم روی کاربرای نهایی هم تاثیر داره! هر چی کدت باکیفیت تر باشه، راحت تر می تونی قابلیت های جدید اضافه کنی و کاربرای خوشحال تری داشته باشی.خب، پس چطور یه همچین فرهنگی رو تو تیم ترویج بدیم؟ مدیرهای ارشد فناوری و مهندسی (CTO) باید یه سری قوانین نانوشته بذارن، مثلا سبک کد، استانداردها و اینجور چیزا. (یجورایی همون فرهنگ شرکت ) بعدش باید حواسشون باشه به باگ هایی که روی کیفیت تاثیر میذارن، کد رو با همدیگه مرور کنن، آمار کیفیت رو بگیرن و به همدیگه یاد بدن.این مقاله می خواد به همین موارد بپردازه صرفا اینها مواردی هست که من خودم از روی تجربه و خوندن منابع دیگه نوشتم و لزوما شاید بهترین نباشه۱. ایجاد سبک ها و استانداردهاخب، یه تیم باحال چطور کد می نویسه؟ اول از همه، باید یه سری قوانین نانوشته رو با هم بذارین . چی؟ ( همون هایی که فرهنگ یا کالچر یه شرکت میشه ) قوانین نوشتن کد، کامنت گذاشتن و حتی مستندسازی! مثلا همتون باید یه جوری کد بزنین که بقیه فک نکنن از سیاره دیگه‌ای اومدین! اگه همه تو یه قواره باشین، راحت‌تر می‌تونین بهم ایراد بگیرین و کدتون قوی‌تر بشه.یه سری قلق خاصی هم تو نوشتن کد خوب هستن. مثلا باید:.استفاده از یه کد استایل (Code Style Guides):استفاده از یک کد استیال یدست رو همه ی پروژه های تیم نکته ای خیلی مهم هست. مثلا تو شرکت ما که جاوا کد میزنیم از دیفالت کد استایل خوده Intellij استفاده میکنم ولی شخصا خودم کدم استایل Google رو ترجیح میدم. کد استایل های زیادی هستن که انتخابش سلیقه ای و طرفداری های خودشون رو دارن : Airbnb, Idiomatic, Google، //first format if(condition){ Statement */ ... /* } // second format if(condition) { Statement */ ... /* } // There are tow types of people , Programmers will know.استفاده از یک کد استایل خوب روی IDE این موارد رو بصورت پیش فرض مرتب میکنه مانند نام‌گذاری(naming)، فاصله‌گذاری(spacing) و تورفتگی (indentation) البته که نه همچیو برامون درست میکنن خیلی موارد باز به عهده دولوپره مانند: - اسما رو شیک و مرتب انتخاب کنین: مثلا به یه متغیر نگین "x"، یه اسم با معنی بذارین که معلوم بشه چی کار می‌کنه. - خط به خط فاصله بذارین و مرتب باشین.کامنت یادتون نره: ولی الکی و بی‌معنی هم کامنت نذارین! توضیح بدین چی کار کردن و چرا. یادتون باشه "TODO" یه کلمه بد هست، از شرش خلاص شین و نباید برنچ develop برسه!کد رو با هم مرور کنین (Code Review) : یه نگاهی به کار هم بندازین، ایراد بگیرید، یاد بدین به هم. مثلا بگین "این تیکه چرا این شکلی نوشتی؟" یا "به نظرم میشه اینجا یه جور دیگه نوشت که باحال‌تر باشه!" . خیلی به فرهنگ اون تیم یا شرکت رو پذیرش این قسمت مهمه! متاسفانه خیلی ها ناراحت میشن.اینجوری هم کدتون تمیز و مرتب می‌شه، هم یاد می‌گیرین چطور بهتر بنویسین. البته یادتون باشه این قوانین رو خیلی سخت نکنین. مهم اینه که کد رو بشه خوند و فهمید، نه اینکه همه شبیه هم باشن. اگه سخت‌گیری زیادی کنین، گند می‌زنین به حال تیم‌تون!۲.پیگیری مسائل با کیفیت بالاحالا یه قدم بریم جلو تر تاحالا "بدهی های فنی " رو شنیدید به احتمال زیاد بله یا اگه نشنیدید با جواب این سوال به معنی اون میرسیم : چطور بدونیم تو کد چه مشکلاتی دارن که باید حلشون کنیم؟ خب، باید یه لیست درست کنیم از کارهایی که gotta fix ‘em! لیست مشکلات کد مثل یه نقشه گنجه، نشون می‌ده باید کجاها رو بگردیم تا کد رو بهتر کنیم. مشکل اینه که بعضی لیست‌های مشکلات مثل "Jira" زیاد کارا نیستن. آدم وقتی یه کد رو نگاه می‌کنه، متوجه مشکلاتش میشه شاید خیلی عنوان کردن یه تسک رفیکتور تو همچین ابزازی خیلی کلی باشه و حس و جزییات مشکل رو بین اعضای تیم مشخص نکنه برای بدهی ها فنی ؛ البته این مورد شاید برعکس هم باشه میتونه یه مورد جزئی داخل تسک عنوان شده باشه اما وقتی میری سراغ کد رو نگاه میکنی چیزی سر در نیاری ازش! خبر خوب اینه که ابزارهای باحال‌تری هم هستن ( integrate کردن IDE با Jira). من از یه ابزاری استفاده می‌کنم که می‌تونم مستقیم تو خود IDE مشکل رو ببینم و حلش کنم. مثلا یه تیکه کد رو انتخاب می‌کنم، بعدش مشکل مربوط به اون رو گزارش می‌دم و می‌تونم بعدا هم برگردم و ببینم چی کار کردم. در اصل مشکل های که روی کد میبنیم رو از داخل IDE مواردش رو Jira گزارش میدم!اینجوری هم راحت‌تر مشکلات رو پیدا می‌کنیم، هم زودتر حلشون می‌کنیم، هم کد رو باحال‌تر می‌کنیم! بازم می‌گم، دنبال بهونه نباشین که ابزار سخته! ( چون خودمم مقاومت داشتم راستش)هرچی راحت‌تر بتونیم مشکلات رو ببینیم و حلشون کنیم، کد تمیزتر و باکیفیت‌تر می‌شه۳.اولویت بندی و رفع مشکلات فنی خب تا اینجا یه لیست از مشکلات فنی داریم، چطور اولویت‌شون بندی کنیم و حل‌شون کنیم؟ همون‌طور که می‌دونی، مشکلات تو کد مثل بدهی می‌مونن، هر چی دیرتر صافشون کنی، سخت‌تر می‌شه و گرون‌تر! پس باید زود بجنبیم. اما جدا ازنو خیلی از این مشکلات توی جلسات اسپرینت بهش شاید بها داده نشه طبیعی هم هست چرا که رسوندن تسک ها اولویت بیشتری داری (تسک ها ی بیزنسی) یا باگ هایی که گزارش میشن . بنظر من هم کل تایم اسپرینت رو داده به بخش های کیفی و فنی کد کار درستی نیست و تیم عقب از اسپرینت و دچار بی برنامگی میشه.چند تا راه حل ساده و باحال هست:یه تیکه از وقت هر دوره رو بذار واسه بدهی کد: مثلا تو هر دوره‌ای که کار می‌کنین، 15-20 درصد از وقت تیم مهندسی رو بذارین واسه اینکه اون تیکه‌های خراب کد رو درست کنین.یه دوره کامل رو بذار واسه بدهی کد: مثلا هر چند وقت یه بار، یه دوره کامل رو بذارین کنار و فقط به تمیز کردن کد توجه کنین.هفته‌ای یه ذره تمیز کن: اگه وقت ندارین، می‌تونین هر هفته یه ذره از بدهی کد رو صاف کنین. مثل قسط دادن می‌مونه، کم‌کم بدهی رو کم کنین.هر کدوم از این راه‌ها رو انتخاب کنین، مهم اینه که بی‌خیالش نشین. کد تمیز و مرتب یعنی زندگی آروم و باحال! البته یادتون باشه هر پروژه و تیمی فرق داره. شاید یه تیم کوچیک بتونه هفته‌ای یه ذره تمیز کنه، ولی یه تیم بزرگ‌تر نیاز داشته باشه یه دوره کامل بذاره واسه این کار. مهم اینه که بهترین راهکار رو برای خودتون پیداکنید.پس بریم بدهی کد رو صاف کنیم و از یه زندگی باحال با کدهای باحال‌تر لذت ببریم!۴. بررسی های دقیق(Code Review)بنظر من یکی از مهم ترین اقداماتی که یه شرکت و یا تیم داره اینکه چقدر به کد ریویو بها میده ،و چه معیار هایی داره . جدا از داکیومنت خوندن ،کتاب خوندن و دیباگ کردن که به ما دولوپرها دانش و یادگیری میاریه به همون اندازه یه کد ریویو خوب هم دانش با خودش میاره. اما خیلی وقتی ها دردسر هم میشه کلا تو این بخش باید خیلیییی انتقاد پذیر باشیم اگه بخواییم کار درست انجام بشه.آنکل باب (Robert C. Martin) یه جمله باحال دربارهٔ نقد کد گفته: "همیشه طوری کد بزن که انگار قراره یه روانی اونو نگه‌داری کنه و آدرس خونه‌تو هم بلده!"کد رو با هم تیمی ها چک کردن خیلی مهمه، ولی اگه الکی الکی ایراد بگیرید، بیشتر دردسر می‌شه تا فایده! پس چطور یه بررسی کد باحال داشته باشیم؟اول از همه، باید یه پروسه دقیق داشته باشیم که همه چی توش مشخص باشه. مثلا یه لیست از کارهایی که باید انجام بدین تا کد رو تایید کنین. به این لیست میگن "تعریف تموم شدن" (DoD).البته اگه نقد کد رو الکی و بدون برنامه انجام بدین، فقط وقتتون رو تلف کردین! واسه همین باید یه سری قوانین داشته باشین، مثلا:چک لیست داشته باشین: یه لیست از چیزهایی که باید تو کد باشه (مثلا تست واحد، کامنت، و اینجور چیزا). اینجوری همه می‌دونن دنبال چی بگردن. خیلی هاش توافقی هست ، همون قانون های نانوشته.قوانین رو رعایت کنین: مثلا همه باید قوانین مربوط به نوشتن کد و پیام‌های کامیت رو رعایت کنن. مثلا: یکی بودن Code Style ها.ابزارهای باحال استفاده کنین: یه سری ابزار هستن که بهتون کمک می‌کنن راحت‌تر ایرادهای کد رو پیدا کنین. مثلا Snyk Code که مشکلات امنیتی رو نشون می‌ده یا ESLint که کد رو مرتب می‌کنه. من خودم روی IDE شرکتم Sonarqube رو استفاده میکنم.نکته مهم دیگه ای که کد ریویو به آدم میده ، اعتماد به نفس هست . اینکه کدت بین بقیه به اشتراک گذاشته میشه و تایید استاندارد هارو تایید میگره ناخودآگاه خوده دولوپر حال خوبی میگیره.اینجوری نقد کد باحال می‌شه و به هم کمک می‌کنین کدهای فوق‌العاده‌ای بسازین! یادتون باشه، نقد کد واسه اینه که به هم کمک کنین، نه اینکه ایراد بگیرین و اذیت کنین!۵. معیارهای کیفیت کد را پیگیری کنیدخب تا اینجا کلی کار کردیم، ولی چطور بفهمیم چقدر موفق بودیم؟ مثلا یه تیم فوتبال باید آمار بازی رو نگه داره تا ببینه چقدر پیشرفت کرده. تو دنیای کد هم همین‌طوره، باید آمار کیفیت کد رو داشته باشیم.چندتا از مهم‌ترین آمارهایی که باید بگیریم اینا هستن:پیچیدگی کد: هر چی کد پیچیده‌تر باشه، فهمیدنش سخت‌تره. پس باید حدی از سادگی رو حفظ کنیم.خیلی ها یه فیچر میزنن به قول خودشون شاید خیلی خفن باشه ، اما وقتی برای فهمیدن یا خوندش یکی دیگه باید کلی زمان بذاره نشون میده یه مشکلی هست! ساده کد زدن و حل کردن یه مسئله بعضی وقتی شاید مشکل تر باشه.تعداد کامنت‌ها به ازای هر هزار خط کد: اگه تعداد کامنت‌ها زیاد بشه، یعنی فهمیدن کد سخت‌تره و باید بیشتر روش توضیح بدیم.همبستگی کد: هر چی کد منظم‌تر باشه، فهمیدنش، تغییر دادنش و نگه‌داریش راحت‌تره.این آمارها مثل یه چراغ قوه هستن که بهمون نشون می‌دن کد چه وضعیتی داره و باید کجاها رو بهتر کنیم. پس بریم آمار باحال جمع کنیم و یه کد فوق‌العاده باکیفیت بسازیم!۶.راهنمایی و حمایت یک دیگر با هم یاد گرفتن، با هم رشد کردنخوب در آخر یه تیم و یا شرکت خوب فقط با داشتن یک سری افراد باحال و یا خفن خوب نمیشه . جادی تو یکی از مصاحبه هاش میگه : “من هرچقدر بیشتر یاد بدم، خودم بیشتر یاد می‌گیرم و اطرافیانم باسوادتر میشن، من که نمی‌تونم مثل یه سوزن از وسط یه جامعه بزنم بیرون، تو یاد دادن بخیل نباشید.”مهمه که همه با هم یاد بگیرن و به هم کمک کنن. مثلا تو یه تیم فوتبال، بازیکنای باتجربه به بقیه کمک می‌کنن تا همشون بهتر بازی کنن. تو دنیای کد هم همین‌طوره، مهندسای باتجربه (سنیور )می‌تونن به بقیه کمک کنن تا کدهای باکیفیت‌تر بنویسن.حرف زدن و تبادل اطلاعات: مهندسای باتجربه می‌تونن تجربه‌شون رو تو جلسات و کارگاه‌ها و یا ورک شاپ ها با بقیه به اشتراک بذارن. این باعث می‌شه بقیه هم با شرایط کسب و کار و تصمیم‌های فنی بیشتر آشنا بشن. من خودم تو ورک شاپ هایی که میذاشتم با هم تیمی هام بهشون میگفتم قرار نسیت من چیزی بهتون یاد بدم(شماها خودتون استادید!)، قراره باهم دیگه یاد بگیریم...نقد کد با هم: همون‌طور که قبلا هم گفتیم، نقد کد یه راه عالی برای یادگیری و تبادل فکره. سعی کنین موقع نقد کد با مهندسای کم‌تجربه‌تر کنار هم بشینین و با هم کد رو بررسی کنین. این‌جوری هم یادگیری عملی می‌شه، هم راهکارهای عملی ارائه می‌تونین بدین.کد رو با هم بنویسین: برنامه‌نویسی دونفره یه روش عالی برای یادگیریه. تو این روش، با یه مهندس کم‌تجربه‌تر همزمان کد می‌نویسین و مشکل رو با هم حل می‌کنین. این‌جوری می‌تونین همون لحظه به هم دیگه هم ایراد بگیرین و یاد بگیرین؛ صرفا نباید یکی از طرفین جونیور یا کم تجربه باشه ، تو مواردی دونفر که سنیور هم هستن دانششون تو بعضی از مباحث عمیق تره میتونن بصورت دونفره هم کد بزنن .نتیجه‌گیری: کد باکیفیت، تیم باحال، زندگی آسون!با ترویج یه فرهنگ باکیفیت کد تو تیم مهندسی‌تون، می‌تونین عملکرد رو بالاتر ببرین و مطمئن باشین که کدتون و محصولتون تو بلندمدت قوی و باکیفیت می‌مونن.خیلی از پروژه های بخاطر شلوغی کد و یا همون به قول دولوپر ها اسپاگتی ، مجبورند بعد از بازه ای به علت اینکه دیگه کد زدن و فیچر جدید زدن و یا حتی نگهداری پروژه ی که تمیز و مرتب کد زده نشده ، دوباره همون رو از نوع بنویسن بدون هیج ارزش افزوده ای به لحاظ کاربردی.