۱۰ اشتباه مهندسان فول استک که باید از آن ها اجتناب کنید | راهنمای کاربردی

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

فهرست نکاتی که در ادامه این مقاله ارائه شده‌اند، حاصل ده سال تجربه برنامه‌نویسی آقای «پرانای سورِش» (Pranay Suresh) است. این فهرست با نکات مربوط به فرانت‌اند آغاز می‌شود، در ادامه نکاتی در مورد بک‌اند ارائه شده و نهایتاً ترفندهایی در خصوص API-ها و پایگاه‌های داده مطرح گشته است.

سطح خصوصیت CSS

اغلب کدنویس‌ها این اشتباه را مرتکب می‌شوند که وقتی می‌بینند کد CSS آن‌ها اعمال نشده است، تصمیم می‌گیرند از important! استفاده کنند. توجه کنید که کاربرد important! می‌بایست به موارد بسیار خاصی محدود شود، زیرا این عملگر کل سلسله مراتب CSS را به هم می‌ریزد تا یک استایل خاص را اعمال کند. بنابراین به جای استفاده از important!، تلاش کنید تا با مفهومی به نام «سطح خصوصیت» (Specificity) در CSS آشنا شوید.

فیلم آموزش سی اس اس – طراحی وب سایت با CSS – مقدماتی در فرادرس

کلیک کنید

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

اگر در موقعیتی مشاهده کردید که CSS نوشته شده روی مقصد مورد نظر اعمال نشده است، این مسئله به سطح خصوصیت در CSS مربوط می‌شود. این یک مشکل کاملاً رایج در پروژه‌های بزرگ است که پیش‌پردازشگر‌هایی مانند SCSS به همراه سلسله‌مراتب‌های پیچیده CSS مورد استفاده قرار می‌گیرند. درک سطح خصوصیت در CSS به شما کمک می‌کند که تنها در موارد کاملاً نادری از important! استفاده کنید که چاره دیگری باقی نمانده باشد. برای نمونه زمانی که بخواهید کتابخانه‌های CSS را باطل کنید و یا iframe-هایی داشته باشید که استایل‌بندی میزبان را نقش می‌کنند، می‌توانید از important! بهره بگیرید.

تقدم سلکتورها به طور کلی به ترتیب به صورت سلکتورهای ID < سلکتورهای کلاس < سلکتورهای نوع است. important! و خصوصیت‌های درون‌خطی (in-line) استایل همه کدهای CSS را باطل می‌کنند. هر CSS که روی یک عنصر اعمال شود، می‌توان به سهولت درک کرد که کدام استایل اعمال شده است. برای نمونه اگر HTML فوق را در مرورگر بارگذاری کنید:

در این مثال، سلکتور ID بر سلکتور نوع تقدم دارد. اگر سلکتورهای متصادم CSS تقدم یکسانی داشته باشند، در این صورت آن سلکتوری اعمال خواهد شد که پس از دیگری بیاید. در نهایت بخش DevTools در مرورگرها، ترتیب سطح خصوصیت را مانند تصویر فوق نمایش می‌دهد. اگر موفق به اعمال CSS خود روی عنصر نشدید، باید ترتیب سطح خصوصیتی که مرورگر استفاده می‌کند را بررسی کنید و سپس سلکتور خاص‌تری را اضافه کنید تا CSS خصوصیت بیشتری پیدا کند و بتواند به مرورگر نشان بدهد که کدام عنصر باید انتخاب شود. اگر از انجام دستی این کار خوشتان نمی‌آید، می‌توانید از این ابزار محاسبه‌گر سطح خصوصیت (+) بهره بگیرید.

طراحی حالت بر اساس سلسله مراتب کامپوننت

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

توجه کنید که مدیریت ناصحیح حالت Redux ممکن است موجب ایجاد سردرگمی در میان توسعه‌دهندگان و منجر به بروز باگ شود. اگر از ری‌اکت و از ریداکس برای سازمان‌دهی اپلیکیشن‌های فرانت‌اند استفاده می‌کنید، در این صورت باید این تکنیک بصری‌سازی را برای ساخت سلسله مراتب حالت و Reducer از روی سلسله مراتب کامپوننت‌های UI داشته باشید. این تکنیک سه گام دارد:

• بصری‌سازی UI در یک وایرفریم
• بصری‌سازی سلسله مراتب حالت برای انعکاس UI
• ساخت سلسله مراتب reducer برای انعکاس سلسله مراتب حالت

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

گام 1: بصری‌سازی UI در یک وایرفریم

گام 2: بصری‌سازی سلسله مراتب حالت برای انعکاس UI

نمودار متناظر سلسله مراتب حالت به صورت زیر است:

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

گام 3: ساخت سلسله مراتب Reducer برای انعکاس سلسله مراتب حالت

این یک مثال ساده اما قدرتمند است که شیوه سازمان‌دهی سلسله مراتب حالت و reducer را برای تطبیق یافتن با UI نمایش می‌دهد. این فرایند‍‍ به سادگی می‌تواند برای اپلیکیشن‌های پیچیده و تیم‌های بزرگ مقیاس‌‌بندی شود. در نهایت می‌توانید اکشن‌ها و لایه ارائه را بر مبنای این ساختار بسازید.

سازمان‌دهی بک‌اند

اشتباه رایجی که توسعه‌دهندگان بک‌اند انجام می‌دهند، این است که ساختار کدبیس یک‌اند را به درستی متوجه نمی‌شوند و تلاش می‌کنند فایل‌ها را به جاهای مختلف پروژه اضافه کنند.

در این بخش برای توصیف وضعیت کدبیس بک‌اند از استعاره پاستای ایتالیایی استفاده می‌کنیم. چنان که می‌دانید پاستای ایتالیایی، انواع مختلفی از اسپاگتی تا لازانیا و راویولی دارد.

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

لازانیا چنین است:

• معماری لایه‌بندی‌شده دارد.
• معماری تمیز دارد
• عملیات I/O در لایه‌های بیرونی و ساختمان‌های داده‌ای محض در لایه‌های درونی‌تر قرار دارند.
• وابستگی‌ها به سمت داخل تزریق می‌شوند.
• لایه‌های درونی روی لایه‌های بیرونی تأثیر ندارند.
• ترکیب‌بندی بر وراثت اولویت دارد.

راویولی چنین است:

• معماری Screaming دارد.
• به جای لایه‌بندی، ساختار برش‌یافته دارد.
• از دسترسی محلی برای فایل‌ها و‍ پوشه‌ها استفاده می‌کند
• می‌تواند میکروسرویس باشد.

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

کاربرد عملی Postgres

بعضی توسعه‌دهندگان بک‌اند گاهی اوقات از خود می‌پرسند این کوئری چرا کند است؟ احتمالاً مشکل از Postgres است. باید آن را Shrad کنم یا شاید هم اشکال از ORM است. شاید هم به یک دیتابیس متفاوت نیاز دارم، چون Postgres برای من مناسب نیست.

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

بهترین ابزار برای رسیدگی به مشکلات مختلف Postgres ابزاری به نام pgbadger (+) است. pgbadger یک ابزار خط فرمان مبتنی بر Perl است که لاگ‌های پستگرس (در صورتی که از AWS استفاده می‌کنید از لاگ‌های RDS استفاده می‌کند) را به عنوان ورودی می‌گیرد و آن‌ها را به یک گزارش تبدیل می‌کند. البته این گزارش معجزه نمی‌کند و صرفاً به مقداری از اطلاعاتی که در لاگ‌های پستگرس وجود دارند، آگاهی‌بخش خواهد بود. بنابراین در گام نخست باید این لاگ‌ها را تا حد امکان فعال کنید.

1log_checkpoints = on
2log_connections = on
3log_disconnections = on
4log_lock_waits = on
5log_temp_files = 0
6log_autovacuum_min_duration = 0
7log_error_verbosity = default
8log_min_duration_statement = 1s

به علاوه باید pg_stat_statements را نیز فعال کنید تا کوئری‌ها به صورت زنده آنالیز شوند و auto_explain به صورت خودکار برای توضیح شیوه اجرای کوئری‌ها در لاگ اضافه شود.

با اجرای گزارش به خروجی زیر دست می‌یابیم:

pgbadger --prefix '%m%u@%d%p%r%a: ' /pglog/postgresql.log

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

این گزارش می‌تواند به صورت مرتب اجرا شود و به این ترتیب همواره در مورد مشکلات جدید آگاه خواهید بود. همچنین برای این که این ابزار را درک کرده و اطلاعات بیشتری در مورد آن کسب کنید می‌توانید از این ابزار آنلاین (+) کمک بگیرید. این ابزار JSON توصیفی و کوئری اصلی را به عنوان ورودی می‌گیرد و خروجی را به صورت یک گراف درخت بصری مانند زیر ارائه می‌کند:

چنان که می‌بینید، گره‌ها، تگ‌هایی برای بزرگ‌ترین، کندترین، پرهزینه‌ترین و مواردی از این دست دارند. به این ترتیب می‌توانید کوئری را بر مبنای شیوه اجرای پستگرس بهینه‌سازی کنید.

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

به کندی حرکت و همه چیز را تست کنید

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

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

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

در نهایت باید اشاره کرد که کند بودن در صورتی که قرار باشد کد مناسبی تولید شود، هیچ مشکلی ندارد.

سرمایه‌گذاری روی خودکارسازی

اشتباه دیگر مهندسان فول استک این است که توزیع را در موارد نیاز به مراحل staging و sandbox اجرا می‌کنند. همچنین کد پروداکشن را به صورت دستی و تنها یک بار در روز توزیع می‌کنند.

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

• آموزش اعضای تیم در مورد شیوه انجام مرور کد. ممکن است مجموعه مهارت‌های متنوعی در تیم داشته باشید و شاید همه افراد با شیوه صحیح انجام مرور کد آشنا نباشند. صرف وقت برای آموزش بهترین رویه‌های مرور کد در این موارد یک ضرورت ناگزیر است.
• از سیستم‌های خودکار مرور کد مانند peril و hound استفاده کنید. Peril می‌تواند تغییرهای کد را بررسی کند و هشدارها و بیلد‌های شکست‌خورده را بر مبنای تنظیمات پیکربندی‌شده، فلگ کند. برای نمونه می‌توانید در صورتی که یک فایل میگریشن دیتابیس فاقد statement_timeout باشد و یا شامل DEFAULT NULL غیر ضروری باشد، درخواست pull را لغو کنید. امکان نوشتن بررسی‌های مختلف و قواعد خاص تیم از این دست وجود دارد و Peril این تغییرات را دروازه‌بانی می‌کند. قواعد خاص تیم نیز می‌تواند کارهای مشابهی انجام دهد و قواعد آن کاملاً قابل پیکربندی هستند.

• یک CI/CD pipeline با راهبرد ارتقای خودکار را با بهره‌گیری از ابزارهایی مانند CircleCI طراحی کنید. در طی زمان، پایپلاین‌‌های بیلد و دیپلوی را بهینه‌سازی کنید.

بر ابزارهای خود تسلط پیدا کنید

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

توجه کنید که عدم اطلاع از شیوه استفاده از ابزارها، موجب می‌شود که بهره‌وری نداشته باشید. آیا می‌توان خیاطی را تصور کرد که مهارت کار با ماشین چرخ خیاطی را نداشته باشد؟ این موضوع نه تنها روی خروجی کد شما، بلکه بر روی میزان کارآمدی ساخت نرم‌افزار تأثیر می‌گذارد.

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

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

موارد مهم دیگری که مهندسان فول استک به طور روزمره با آن‌ها سروکار دارند و باید در کسب مهارت در موردشان بکوشند، ترمینال، داکر، tableplus/pgadmin و دیگر UI-های کلاینت دیتابیس و chrome dev tools هستند.

MVP

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

پیش از ساخت یک چیز باید مطمئن شویم که آن چه می‌خواهیم بسازیم، چیز درستی است. اینجا است که MVP مطرح می‌شود.

یک MVP ایده‌آل باید کمترین سطح تماس را با هر لایه داشته باشد و نه این که روی توسعه کامل یک لایه متمرکز شود. این یک تمرین برای رفع ریسک است. بهتر است که شما همه لایه‌ها را در سطح کمینه بسازید تا این که یک لایه منفرد را با کیفیت ممتاز ایجاد کنید. MVP به معنی ایجاد بدهی فنی یا کدنویسی بد یا نبود تست نیست. کد MVP یک کد دورانداختنی محسوب نمی‌شود.

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

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

توسعه مبتنی بر تحقیق

نهمین اشتباه یک توسعه‌دهنده فول استک این است که فکر کند می‌تواند صرفاً بر مبنای نظر و تجربه شخصی خود در مورد مسیر توسعه اپلیکیشن تصمیم‌گیری کند.

در فرایند توسعه اپلیکیشن در پس هر ادعایی باید یک تحقیق و پژوهش قوی وجود داشته باشد. به جای این که از شهود خود پیروی کنید، یک مطالعه کاربر را اجرا کنید. نیازهای کاربر را از طریق مصاحبه کردن با آن‌ها به صورت شخصی یا در ویدئو، اجرای پیمایش و بررسی لاگ‌ها بشناسید. این مسئله به شما کمک می‌کند که کاربران خود را بهتر درک کنید. سپس می‌توانید فرضیه‌هایی تشکیل داده و آن‌ها را بر اساس آزمایش‌ها بیازمایید. در زمان تشکیل فرضیه از ابزار inversion (+) برای راستی‌آزمایی ادعاهایتان استفاده کنید. روی فریمورک تست A/B زمان بگذارید تا امکان اجرای آزمایش‌ها را داشته باشید.

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

دیباگ علمی

آخرین اشتباه مهندسان فول استک که در این راهنما بررسی می‌کنیم مواردی است که مهندسی یک باگ یافته است و تلاش می‌کند آن را به یک تغییر کد نسبت دهد. او فایل‌ها را بررسی می‌کند و یا شاید آن را به مشکلات حافظه نسبت دهد و یا فکر کند که ترکیبی از هر دو مسئله است.

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

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

• به دانش قبلی نیاز ندارد.
• سیستماتیک است.
• متدی است که می‌توانیم مطمئن باشیم با آن علت اصلی را یافته و خطا را بازتولید کنیم.

استفاده از متد علمی برای دیباگ کردن مشکلات یک روش بدون سوگیری برای توسعه نظریه‌هایی در مورد بروز یک شکست در نرم‌افزار است. مراحل دیباگ کردن علمی به شرح زیر هستند:

1. بازتولید خطا (غالباً ترکیبی از زمان، تاریخ، کاربر، سیسم عامل و دیباگر است).
2. مشاهده واقعیت‌ها (مطالعه دقیق لاگ‌ها، ردگیری خطاها و غیره).
3. نوشتن صریح فرضیه‌ها در یک کتابچه لاگ به جای اجرای ذهنی این فرایند.
4. اگر بخشی از برنامه را شناسایی کردید که دارای باگ است، از یک رویکرد سازمان‌یافته مانند جستجوی دودویی برای محدود ساختن حیطه باگ استفاده کنید.
5. فرضیه‌ها را با استفاده از لاگ‌ کردن، Breakpoint-ها و asset-ها تست کنید.
6. اگر فرضیه‌ها تأیید شدند، اصلاحیه را به کار بگیرید و مطمئن شوید که هیچ مورد خطای جدیدی وجود ندارد.
7. اگر فرضیه‌ها رد شدند، گام‌های 3 تا 6 فوق را تکرار کنید.

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

نکات اضافی

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

اشتراک آموخته‌ها و خدمت به دیگران

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

لینک‌های مفید را هر روز در اسلک به اشتراک بگذارید، نشست‌های غیررسمی آموزشی برگزار کنید، دمو داشته باشید، افراد دیگر را به رفتار مثبت تشویق کنید، تصمیم‌های غیر روشن را به چالش بکشید و در مواردی که فکر می‌کنید یک فرد یا تصمیم باید متفاوت باشند، بازخورد سازنده‌ای ارائه دهید. برای ارائه بازخورد در مورد چیزهای مختلف از ساختار «به خاطر فلان چیز متشکرم .... و امیدواریم بهمان چیز...» استفاده کنید که نسبت چیزهایی که از آن‌ها تشکر می‌کنید به نسبت چیزهایی که درخواست می‌کنید، 3 به 1 باشد.

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

دنیای خود را بسازید

شما مجبور نیستید، دنیا را آن چنان که هست بپذیرید، شما می‌توانید دنیا را آن طور که دوست دارید شکل بدهید.

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

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

ملاقات با افراد مختلف

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

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

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

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

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

سخن پایانی

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