برنامه نویس
مهمترین درس هایی که بعد از سال ها کار با React یاد گرفتم
شروع یک تکنولوژی جدید نسبتا دردسر داره. یهو میبینی وسط اقیانوسی از دوره های آموزشی و مقالات، و میلیون ها نظر شخصی داری غرق میشی. و همشونم ادعا میکنن که "بهترین و صحیح ترین راه" رو پیدا کردن.
اینجاست که با خودت میگی نکنه این دوره آموزشی وقتمو هدر کنه.
قبل از همه اینا، باید مفاهیم بنیادی یک تکنولوژی رو درک کنیم. بعدش باید ذهنیت خودمون رو به سمت تکنولوژی سوق بدیم. اگه میخوایم React یاد بگیریم، اول مثل React فکر کنیم. اونوقته که میتونیم چندین ذهنیت رو با هم ترکیب کنیم.
در این مقاله درس هایی که از تجربیات شخصیم با React گرفتم رو پوشش میدیم. از روزهایی که شرکت بودم و شب هایی که روی پروژه های شخصیم کار میکردم برات تعریف میکنم.
بزن بریم!
کتابخونه React در حال تکامله، پس باید بروز باشی
تیم اصلی React و تمام مشارکت کنندگان برای بهبود این تکنولوژی خیلی زحمت میکشن.
پس اگه میخوای بهترین باشی، باید با اتفاقاتی که در این جامعه میفته بروز باشی.
بدونی که چی چجوری کار میکنه و چرا همچین چیزی رو اضافه کردن. یاد بگیری مشکلات چجوری حل میشن و نسخه جدید چه کمکی کرده. خیلی بهت کمک میکنه.
از اینکه کدت رو تیکه تیکه کنی نترس
ساختار React بر پایه کامپوننت هاست. پس باید از این اهرم استفاده کنی و از اینکه تیکه های بزرگ کدت رو به تیکه های کوچیکتر تقسیم کنی نترسی.
گاهی اوقات یک کامپوننت ساده با چهار پنج خط کد میتونه ساخته بشه، و در بعضی موارد، هیچ ایرادی نداره.
بطوریکه اگه یک نفر جدید کد رو بخونه، لازم نیست چند روز وقت بذاره تا بفهمه.
return (
[
<ChangeButton
={this.changeUserApprovalStatus}
text="Let’s switch it!"
/>,
<UserInformation status={status} />
]
);
مجبور نیستی کامپوننت هایی بسازی که همشون منطق پیچیده ای دارن. میتونن فقط نمایشی باشن. اگه با این کار خوانایی و تست کد بهتر بشه، به نفع تمام اعضای تیم توسعه ست.
import ErrorMessage from './ErrorMessage';
const NotFound = () => (
<ErrorMessage
title="Oops! Page not found."
message="The page you are looking for does not exist!"
className="test_404-page"
/>
);
در مثال بالا، مشخصه ها همگی ثابت هستن. پس میتونیم کامپوننتی داشته باشیم که فقط و فقط وظیفه نمایش پیام خطای 404 رو به عهده بگیره.
همچنین، اگه دلت نمیخواد همه جا از کلاس های CSS استفاده کنی، پیشنهاد میکنم از کامپوننت های styled استفاده کنی. خوانایی کد رو خیلی بالا میبره.
const Number = styled.h1`
font-size: 36px;
line-height: 40px;
margin-right: 5px;
padding: 0px;
`;
//..<Container>
<Number>{skipRatePre}</Number>
<InfoName>Skip Rate</InfoName>
</Container>
اگه میترسی کامپوننت بیشتر بسازی که یوقت ساختار پوشه ها و فایل هات شلوغ نشه، ساختاربندی پروژه رو تغییر بده. من از ساختار فراکتال استفاده میکنم و راضیم.
به مفاهیم ابتدایی بسنده نکن — حرفه ای شو
شاید گاهی اوقات فکر کنی که هنوز آمادگیشو نداری به سمت مفاهیم پیشرفته خیز برداری. اما اغلب اوقات نباید نگران باشی — خودت رو به چالش بکش و نشون بده که اشتباه میکردی.
با مطالعه مفاهیم پیشرفته و اینکه به خودت سختی بدی، میتونی مفاهیم ابتدایی رو بیشتر درک کنی و بفهمی که چجوری برای مقاصد بزرگتر استفاده میشن.
به این الگوها میتونی سرک بکشی:
- کامپوننت های ترکیبی
- کامپوننت های مرتبه بالا یا Higher Order
- پراپ های رندر
- کامپوننت های باهوش و نادان
- مفاهیمی مثل Profiling
وقتی بفهمی اینا کجا و چجوری استفاده میشن، با React بیشتر خو میگیری.
render() {
const children = React.Children.map(this.props.children,
(child, index) => {
return React.cloneElement(child, {
: () => this.props.onTabSelect(index)
});
});
return children;
}
همچنین، از اینکه چیزای جدیدی سر کار امتحان کنی نترس — با محدودیت های خاص، البته! فقط روی پروژه های شخصی آزمایش نکن.
ممکنه سوال پیچت کنن، که خب طبیعیه. باید با دلیل و منطق از کارت دفاع کنی.
هدفت باید این باشه که مشکلات رو حل کنی، روند توسعه رو آسون تر کنی، یا پیچیدگی های کد رو بگیری. حتی اگه پیشنهادات رد بشن، بازم نسبت به اینکه ساکت باشی بیشتر یاد میگیری.
کد رو خیلی پیچیده نکن
در هر موقعیت باید تعادل رو برقرار کنیم. نباید خیلی درگیر مهندسی بشیم. باید عملی باشیم. کدی بنویسیم که نه تنها کارش رو بدرستی انجام میده بلکه درکش هم ساده باشه.
اگه به Redux نیاز نداری، و نمیدونی دقیقا هدفش چیه ولی صرفا چون بقیه ازش استفاده میکنن میخوای ازش استفاده کنی، نکن.
گاهی اوقات ممکنه فکر کنی که اگه از آخرین تکنولوژی ها استفاده کنی و هرچقدر کدت پیچیده تر باشه به جهان میگی: "من مبتدی نیستم، دارم حرفه ای میشم. ببینین چه چیزایی بلدم!"
ولی به مرور زمان میفهمی کدی که به رخ کشیده نشه و کارشو انجام بده خیلی بیشتر به دل میشینه. چرا؟ چون
- همکارات میتونن روی پروژه کار کنن و به تنهایی وظیفه توسعه / اشکال زدایی / تست رو بر عهده نداری.
- تیم میفهمه بقیه چکار کردن و نیازی به جلسات طولانی و فرسایشی نیست.
- وقتی دو هفته میری مرخصی، بقیه میتونن کارتو انجام بدن.
مردم به کسی که زندگیشون رو راحت تر میکنه احترام میذارن. بنابراین اگه میخوای احترام داشته باشی، پیشرفت کنی، و بهتر بشی، هدفت این باشه برای تیم کد بزنی نه برای خودت.
اینجوری عضو مورد علاقه هر تیمی میشی.
اصلاح کن، اصلاح کن و اصلاح کن
نظرت بارها عوض میشه، نظر مدیر محصول بیشتر از تو عوض میشه. بقیه از کدت ایراد میگیرن، خودتم از کدت ایراد میگیری. در نتیجه، مجبوری بارها و بارها کدت رو عوض کنی.
ولی نگران نباش، روند یادگیری همینه. بدون اشتباه و خطا بهتر نمیشیم.
هرچی بیشتر زمین میخوریم، بلند شدنمون راحت تر میشه.
مطلبی دیگر از این انتشارات
علوم کامپیوتر از نوع شریف!
مطلبی دیگر از این انتشارات
اهداف الگوهای طراحی
مطلبی دیگر از این انتشارات
برنامه هایی که با زبان پایتون نوشته شده اند