آنچه توسعه دهندگان ارشد می دانند

آیا شما یک توسعه دهنده جوان خوب هستید که می خواهید یک توسعه دهنده ارشد شوید؟ این چهار مورد را درک کنید.

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

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

توسعه دهندگان ارشد متوجه می شوند که شفافیت پادشاه است

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

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

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

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

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

توسعه دهندگان ارشد می دانند که پیچیدگی منبع اکثر مشکلات کد است

جلوگیری از پیچیدگی برای کد خوب بسیار مهم است. و کلید اجتناب از پیچیدگی در کد شما ساده و سرراست است: هرگز چیزی که پیچیده است ننویسید. به نظر می رسد یک اکسیمورون است، اما اینطور نیست.

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

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

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

توسعه‌دهنده‌های ارشد در برابر وسوسه حرکت سریع مقاومت می‌کنند

“آهسته صاف است و صاف سریع است” یکی از شعارهای نیروی دریایی SEAL است. این افراد باید در شرایط پرفشار تصمیمات مرگ یا زندگی بگیرند. به نظر خلاف واقع می رسد، اما وقتی در نظر گرفته شود کاملاً منطقی است. ایده این است که هنگام عجله، ممکن است اشتباه کند – هر چه بیشتر عجله کند، اشتباهات بیشتری خواهد داشت. اشتباهات زمان زیادی می برد. آهسته پیش رفتن – عجله نکردن – باعث کاهش یا حذف خطاها می شود و اشتباه نکردن، روند کلی را سریعتر می کند. 

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

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

توسعه دهندگان ارشد برای سود طولانی مدت درد کوتاه مدت را تحمل می کنند

همه ما این کار را انجام دادیم. ما در آخر هفته برخی از ویژگی‌های جدید را معرفی کرده‌ایم، همه آن‌ها را با هم هک کرده‌ایم و باعث می‌شویم با بی‌اعتنایی کامل نسبت به کیفیت کاری که انجام می‌دهیم عمل کند. دلایل زیادی برای این وجود دارد، اما همه آنها تجارت محور هستند، درست است؟ مشتری بدون آن قراردادی را امضا نمی کند، یا اگر صبح دوشنبه آن را نداشته باشد به سراغ رقیب می رود. یا یک نسخه آزمایشی برای ارائه در یک کنفرانس باید تکمیل شود، و آن نسخه آزمایشی به ویژگی واقعی تبدیل می‌شود.

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

یک توسعه‌دهنده ارشد خوب می‌داند که تا آنجا که ممکن است در مقابل آن مقاومت کند و در صورت وقوع آسیب را محدود کند.

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