داشتن کد باکیفیت مثل یه چاقوی تیز می مونه، باهاش راحت کار می کنی، سریع تر کار رو تمومش می کنی و نتیجه نهایی هم کارآمد تر میشه. فقط هم نباید این فکر رو کرد این امر یه مسئله داخلیه که به تیم مهندسی خودمون مربوطه. کیفیت کد، مستقیم روی کاربرای نهایی هم تاثیر داره! هر چی کدت باکیفیت تر باشه، راحت تر می تونی قابلیت های جدید اضافه کنی و کاربرای خوشحال تری داشته باشی.
خب، پس چطور یه همچین فرهنگی رو تو تیم ترویج بدیم؟ مدیرهای ارشد فناوری و مهندسی (CTO) باید یه سری قوانین نانوشته بذارن، مثلا سبک کد، استانداردها و اینجور چیزا. (یجورایی همون فرهنگ شرکت ) بعدش باید حواسشون باشه به باگ هایی که روی کیفیت تاثیر میذارن، کد رو با همدیگه مرور کنن، آمار کیفیت رو بگیرن و به همدیگه یاد بدن.
این مقاله می خواد به همین موارد بپردازه صرفا اینها مواردی هست که من خودم از روی تجربه و خوندن منابع دیگه نوشتم و لزوما شاید بهترین نباشه
خب، یه تیم باحال چطور کد می نویسه؟ اول از همه، باید یه سری قوانین نانوشته رو با هم بذارین . چی؟ ( همون هایی که فرهنگ یا کالچر یه شرکت میشه ) قوانین نوشتن کد، کامنت گذاشتن و حتی مستندسازی! مثلا همتون باید یه جوری کد بزنین که بقیه فک نکنن از سیاره دیگه‌ای اومدین! اگه همه تو یه قواره باشین، راحت‌تر می‌تونین بهم ایراد بگیرین و کدتون قوی‌تر بشه.
یه سری قلق خاصی هم تو نوشتن کد خوب هستن. مثلا باید:
استفاده از یک کد استیال یدست رو همه ی پروژه های تیم نکته ای خیلی مهم هست. مثلا تو شرکت ما که جاوا کد میزنیم از دیفالت کد استایل خوده 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"، یه اسم با معنی بذارین که معلوم بشه چی کار میکنه.
- خط به خط فاصله بذارین و مرتب باشین.
کد رو با هم مرور کنین (Code Review) : یه نگاهی به کار هم بندازین، ایراد بگیرید، یاد بدین به هم. مثلا بگین "این تیکه چرا این شکلی نوشتی؟" یا "به نظرم میشه اینجا یه جور دیگه نوشت که باحال‌تر باشه!" .
خیلی به فرهنگ اون تیم یا شرکت رو پذیرش این قسمت مهمه! متاسفانه خیلی ها ناراحت میشن.
اینجوری هم کدتون تمیز و مرتب میشه، هم یاد می‌گیرین چطور بهتر بنویسین. البته یادتون باشه این قوانین رو خیلی سخت نکنین. مهم اینه که کد رو بشه خوند و فهمید، نه اینکه همه شبیه هم باشن. اگه سخت‌گیری زیادی کنین، گند می‌زنین به حال تیم‌تون!
حالا یه قدم بریم جلو تر تاحالا "بدهی های فنی " رو شنیدید به احتمال زیاد بله یا اگه نشنیدید با جواب این سوال به معنی اون میرسیم : چطور بدونیم تو کد چه مشکلاتی دارن که باید حلشون کنیم؟ خب، باید یه لیست درست کنیم از کارهایی که gotta fix ‘em! لیست مشکلات کد مثل یه نقشه گنجه، نشون میده باید کجاها رو بگردیم تا کد رو بهتر کنیم.
مشکل اینه که بعضی لیست‌های مشکلات مثل "Jira" زیاد کارا نیستن. آدم وقتی یه کد رو نگاه میکنه، متوجه مشکلاتش میشه شاید خیلی عنوان کردن یه تسک رفیکتور تو همچین ابزازی خیلی کلی باشه و حس و جزییات مشکل رو بین اعضای تیم مشخص نکنه برای بدهی ها فنی ؛ البته این مورد شاید برعکس هم باشه میتونه یه مورد جزئی داخل تسک عنوان شده باشه اما وقتی میری سراغ کد رو نگاه میکنی چیزی سر در نیاری ازش! خبر خوب اینه که ابزارهای باحال‌تری هم هستن ( integrate کردن IDE با Jira). من از یه ابزاری استفاده میکنم که می‌تونم مستقیم تو خود IDE مشکل رو ببینم و حلش کنم. مثلا یه تیکه کد رو انتخاب میکنم، بعدش مشکل مربوط به اون رو گزارش میدم و می‌تونم بعدا هم برگردم و ببینم چی کار کردم. در اصل مشکل های که روی کد میبنیم رو از داخل IDE مواردش رو Jira گزارش میدم!
اینجوری هم راحت‌تر مشکلات رو پیدا می‌کنیم، هم زودتر حلشون می‌کنیم، هم کد رو باحال‌تر می‌کنیم! بازم می‌گم، دنبال بهونه نباشین که ابزار سخته! ( چون خودمم مقاومت داشتم راستش)هرچی راحت‌تر بتونیم مشکلات رو ببینیم و حلشون کنیم، کد تمیزتر و باکیفیت‌تر میشه
خب تا اینجا یه لیست از مشکلات فنی داریم، چطور اولویت‌شون بندی کنیم و حلشون کنیم؟ همون‌طور که می‌دونی، مشکلات تو کد مثل بدهی می‌مونن، هر چی دیرتر صافشون کنی، سخت‌تر میشه و گرون‌تر! پس باید زود بجنبیم. اما جدا ازنو خیلی از این مشکلات توی جلسات اسپرینت بهش شاید بها داده نشه طبیعی هم هست چرا که رسوندن تسک ها اولویت بیشتری داری (تسک ها ی بیزنسی) یا باگ هایی که گزارش میشن . بنظر من هم کل تایم اسپرینت رو داده به بخش های کیفی و فنی کد کار درستی نیست و تیم عقب از اسپرینت و دچار بی برنامگی میشه.
چند تا راه حل ساده و باحال هست:
هر کدوم از این راه‌ها رو انتخاب کنین، مهم اینه که بی‌خیالش نشین. کد تمیز و مرتب یعنی زندگی آروم و باحال! البته یادتون باشه هر پروژه و تیمی فرق داره. شاید یه تیم کوچیک بتونه هفته‌ای یه ذره تمیز کنه، ولی یه تیم بزرگ‌تر نیاز داشته باشه یه دوره کامل بذاره واسه این کار. مهم اینه که بهترین راهکار رو برای خودتون پیداکنید.
پس بریم بدهی کد رو صاف کنیم و از یه زندگی باحال با کدهای باحال‌تر لذت ببریم!
بنظر من یکی از مهم ترین اقداماتی که یه شرکت و یا تیم داره اینکه چقدر به کد ریویو بها میده ،و چه معیار هایی داره . جدا از داکیومنت خوندن ،کتاب خوندن و دیباگ کردن که به ما دولوپرها دانش و یادگیری میاریه به همون اندازه یه کد ریویو خوب هم دانش با خودش میاره. اما خیلی وقتی ها دردسر هم میشه کلا تو این بخش باید خیلیییی انتقاد پذیر باشیم اگه بخواییم کار درست انجام بشه.
آنکل باب (Robert C. Martin) یه جمله باحال دربارهٔ نقد کد گفته: "همیشه طوری کد بزن که انگار قراره یه روانی اونو نگهداری کنه و آدرس خونه‌تو هم بلده!"
کد رو با هم تیمی ها چک کردن خیلی مهمه، ولی اگه الکی الکی ایراد بگیرید، بیشتر دردسر میشه تا فایده! پس چطور یه بررسی کد باحال داشته باشیم؟
اول از همه، باید یه پروسه دقیق داشته باشیم که همه چی توش مشخص باشه. مثلا یه لیست از کارهایی که باید انجام بدین تا کد رو تایید کنین. به این لیست میگن "تعریف تموم شدن" (DoD).البته اگه نقد کد رو الکی و بدون برنامه انجام بدین، فقط وقتتون رو تلف کردین! واسه همین باید یه سری قوانین داشته باشین، مثلا:
نکته مهم دیگه ای که کد ریویو به آدم میده ، اعتماد به نفس هست . اینکه کدت بین بقیه به اشتراک گذاشته میشه و تایید استاندارد هارو تایید میگره ناخودآگاه خوده دولوپر حال خوبی میگیره.
اینجوری نقد کد باحال میشه و به هم کمک می‌کنین کدهای فوق‌العاده‌ای بسازین! یادتون باشه، نقد کد واسه اینه که به هم کمک کنین، نه اینکه ایراد بگیرین و اذیت کنین!
خب تا اینجا کلی کار کردیم، ولی چطور بفهمیم چقدر موفق بودیم؟ مثلا یه تیم فوتبال باید آمار بازی رو نگه داره تا ببینه چقدر پیشرفت کرده. تو دنیای کد هم همین‌طوره، باید آمار کیفیت کد رو داشته باشیم.
چندتا از مهم‌ترین آمارهایی که باید بگیریم اینا هستن:
خیلی ها یه فیچر میزنن به قول خودشون شاید خیلی خفن باشه ، اما وقتی برای فهمیدن یا خوندش یکی دیگه باید کلی زمان بذاره نشون میده یه مشکلی هست! ساده کد زدن و حل کردن یه مسئله بعضی وقتی شاید مشکل تر باشه.
این آمارها مثل یه چراغ قوه هستن که بهمون نشون می‌دن کد چه وضعیتی داره و باید کجاها رو بهتر کنیم. پس بریم آمار باحال جمع کنیم و یه کد فوق‌العاده باکیفیت بسازیم!
با هم یاد گرفتن، با هم رشد کردن
خوب در آخر یه تیم و یا شرکت خوب فقط با داشتن یک سری افراد باحال و یا خفن خوب نمیشه .
جادی تو یکی از مصاحبه هاش میگه : “من هرچقدر بیشتر یاد بدم، خودم بیشتر یاد می‌گیرم و اطرافیانم باسوادتر میشن، من که نمی‌تونم مثل یه سوزن از وسط یه جامعه بزنم بیرون، تو یاد دادن بخیل نباشید.”
مهمه که همه با هم یاد بگیرن و به هم کمک کنن. مثلا تو یه تیم فوتبال، بازیکنای باتجربه به بقیه کمک میکنن تا همشون بهتر بازی کنن. تو دنیای کد هم همین‌طوره، مهندسای باتجربه (سنیور )میتونن به بقیه کمک کنن تا کدهای باکیفیت‌تر بنویسن.
من خودم تو ورک شاپ هایی که میذاشتم با هم تیمی هام بهشون میگفتم قرار نسیت من چیزی بهتون یاد بدم(شماها خودتون استادید!)، قراره باهم دیگه یاد بگیریم...
نتیجه‌گیری:
کد باکیفیت، تیم باحال، زندگی آسون!
با ترویج یه فرهنگ باکیفیت کد تو تیم مهندسی‌تون، می‌تونین عملکرد رو بالاتر ببرین و مطمئن باشین که کدتون و محصولتون تو بلندمدت قوی و باکیفیت می‌مونن.
خیلی از پروژه های بخاطر شلوغی کد و یا همون به قول دولوپر ها اسپاگتی ، مجبورند بعد از بازه ای به علت اینکه دیگه کد زدن و فیچر جدید زدن و یا حتی نگهداری پروژه ی که تمیز و مرتب کد زده نشده ، دوباره همون رو از نوع بنویسن بدون هیج ارزش افزوده ای به لحاظ کاربردی.
