ید).
۸. بیش از حد لازم به کدهای خود شاخ و برگ می‌دهید
ممکن است گاهی‌اوقات آنقدر برای بهینه کردن کدهای خود وقت بگذارید و آنقدر به آن‌ها شاخ و برگ بدهید که ناخواسته به‌جای بهتر شدن، پیچیده‌تر شوند؛ این کار فقط باعث افزایش باگ‌ها و همچنین سردرگمی دولوپرهایی می‌شود که بعد از شما بر روی این کدها کار خواهند کرد. بنابراین به‌دنبال راه‌حل‌های پیچیده نباشید. در بیشتر مواقع، بهترین راه بهینه‌سازی کدها درواقع همان مستقیم‌ترین و ساده‌ترین راهی است که می‌توان با آن مسأله را حل نمود.
۹. نمی‌دانید مشکل کجاست و چه‌طور باید آن را برطرف نمود (نبود ذهن تحلیل‌گر)
بعضی از مواردی که موجب بروز مشکل در اغلب اپلیکیشن‌های امروزی می‌شود عبارتند از:
- پیچیدگی در الگوریتم‌ها
- عملکرد ناکارآمد دیتابیس
- ای‌پی‌آی‌ها
- کوئری‌های زیاد
البته موارد مشکل‌آفرین دیگری نیز وجود دارند اما شما به‌عنوان یک دولوپر باید با ذهنی تحلیل‌گر بتوانید موقعیت ایجاد شده را تجزیه و تحلیل نموده، تشخیص دهید که عامل مشکل‌زا کجا است و چه‌طور می‌توان آن‌را برطرف کرد.
۱۰. به روابط خود با سایر اعضای تیم به اندازهٔ کافی بها نمی‌دهید
درست است که شما برای کدنویسی استخدام شده‌اید، اما لازم است با دیگر اعضای گروه نیز در ارتباط باشید؛ این افراد ممکن است سایر دولوپرهای تیم، افراد غیرمتخصصی که از نزدیک با آن‌ها سروکار دارید و اعضایی از تیم که ارتباط نزدیک با آن‌ها ندارید را شامل شوند. روابط شما با سایر اعضای تیم از نوشتن چند خط کد بیشتر به‌مراتب مهمتر است. بنابراین گاهی لازم است چند خط کد را فدای ساختن و تحکیم روابط خود با اعضای تیم نموده و برای گسترش روابط خود وقت بگذارید.
۱۱- درگیر سیاست‌های شرکت هستید
وقتی به‌عنوان دولوپر در چند شرکت مختلف مشغول کار می‌شوید، تحت‌تأثیر سیاست‌های کلان شرکت‌ها قرار می‌گیرید؛ به این ترتیب ممکن است دیدگاه تیم از «ما باید بهترین باشیم» به «ما باید از تیم فلان شرکت بهتر باشیم» تغییر کند و این موضوع به‌نوبهٔ خود می‌تواند باعث افت عملکرد و کاهش بهره‌وری تیم شود.
۱۲. در شرایط پراسترس نمی‌توانید تصمیم‌گیری کنید
ممکن است تاکنون شرایط پراسترس مختلفی را تجربه کرده باشید؛ مثلاً ممکن است تغییری در یکی از فانکشن‌ها داده باشید که باعث شده باشد آن فانکشن دیگر کار نکند و به این ترتیب زمینهٔ نارضایتی صدها و یا شاید هزاران کاربر را فراهم نموده باشید و یا ممکن است در شرایطی مجبور بوده باشید در مورد انتقال از یک سیستم به سیستم دیگر که مستلزم چندین ساعت Down بودن سایت باشد، تصمیم بگیرید.
وقتی در موقعیت‌هایی قرار می‌گیرید که تصمیم‌گیری شما ممکن است موجب اختلال در کار کاربران شود، استرس زیادی را متحمل می‌شوید و بسیاری از دولوپرها در این شرایط عصبی شده و قدرت تصمیم‌گیری خود را از دست می‌دهند؛ اگر می‌خواهید خود را به‌عنوان یک دولوپر قوی و ارزشمند به دیگران بشناسانید، باید مهارت کار در شرایط پراسترس را به‌دست آورید.
۱۳. نمی‌توانید بپذیرید که بعضی از کدهایتان عالی نباشند
همیشه نمی‌شود کدهای عالی و بی‌نقص نوشت؛ در دنیای واقعی، گاهی لازم است به نوشتن کدهای معمولی و حتی شاید بد هم راضی شوید! گاهی‌اوقات در موقعیت‌هایی که فرصتی تا زمان تحویل کار باقی نمانده، برای برخی بررسی‌ها و همچنین به‌منظور رفع فوری اشکالات لازم است با کدهایی که عالی نیستند هم کنار بیایید. بهتر است ذهنیت کمال‌گرای خود را کنار بگذارید و بدانید که گاهی برای دستیابی به اهداف فوری، لازم است از کدهای معمولی و یا حتی بد استفاده کنید.
۱۴. بیش از حد اهل مهندسی کردن هستید
اغلب مشکلات ساده، راه‌حل‌های ساده‌ای هم دارند؛ اگر بیش از حد اهل مهندسی کردن باشید، ممکن است یک مشکل ساده را به یک مشکل پیچیده و دشوار تبدیل کنید. البته گاهی‌اوقات ارائهٔ راه‌حل‌های پیچیده برای مشکلات ساده می‌تواند جالب و لذت‌بخش باشد و نکات جدیدی را برای شما آشکار کند اما دولوپرهای خوب معمولاً از ارائهٔ پاسخ‌های پیچیده برای سوالات ساده خودداری می‌کنند.
۱۵. بیشتر از آن‌که لیدر باشید، رئیس هستید
رئیس بودن شما کمک زیادی به پیشرفت تیم نخواهد کرد! شما باید یاد بگیرید که به جای ریاست، تیم را رهبری کنید و کسی باشید که سایر اعضای تیم برای راهنمایی گرفتن، رفع مشکلات و اظهارنظر به او مراجعه می‌کنند. البته رسیدن به چنین جایگاهی به تلاش و صرف زمان کافی نیاز دارد (برای کسب اطلاعات بیشتر پیرامون تفاوت‌های ریاست و رهبری، میتوانید به مقالهٔ مدیریت یا رهبری: مسئله این است! مراجعه نمایید).
۱۶. از ابزار مناسب استفاده نمی‌کنید
دولوپرهای برتر همواره تلاش می‌کنند تا از تکنولوژی‌ها، زبان‌های برنامه‌نویسی و فریمورک‌های متناسب با کار خود استفاده کنند؛ بنابراین سعی کنید به‌جای این دیدگاه که «من این روش را بلدم پس از همین استفاده می‌کنم»، به دنبال یافتن م
۸. بیش از حد لازم به کدهای خود شاخ و برگ می‌دهید
ممکن است گاهی‌اوقات آنقدر برای بهینه کردن کدهای خود وقت بگذارید و آنقدر به آن‌ها شاخ و برگ بدهید که ناخواسته به‌جای بهتر شدن، پیچیده‌تر شوند؛ این کار فقط باعث افزایش باگ‌ها و همچنین سردرگمی دولوپرهایی می‌شود که بعد از شما بر روی این کدها کار خواهند کرد. بنابراین به‌دنبال راه‌حل‌های پیچیده نباشید. در بیشتر مواقع، بهترین راه بهینه‌سازی کدها درواقع همان مستقیم‌ترین و ساده‌ترین راهی است که می‌توان با آن مسأله را حل نمود.
۹. نمی‌دانید مشکل کجاست و چه‌طور باید آن را برطرف نمود (نبود ذهن تحلیل‌گر)
بعضی از مواردی که موجب بروز مشکل در اغلب اپلیکیشن‌های امروزی می‌شود عبارتند از:
- پیچیدگی در الگوریتم‌ها
- عملکرد ناکارآمد دیتابیس
- ای‌پی‌آی‌ها
- کوئری‌های زیاد
البته موارد مشکل‌آفرین دیگری نیز وجود دارند اما شما به‌عنوان یک دولوپر باید با ذهنی تحلیل‌گر بتوانید موقعیت ایجاد شده را تجزیه و تحلیل نموده، تشخیص دهید که عامل مشکل‌زا کجا است و چه‌طور می‌توان آن‌را برطرف کرد.
۱۰. به روابط خود با سایر اعضای تیم به اندازهٔ کافی بها نمی‌دهید
درست است که شما برای کدنویسی استخدام شده‌اید، اما لازم است با دیگر اعضای گروه نیز در ارتباط باشید؛ این افراد ممکن است سایر دولوپرهای تیم، افراد غیرمتخصصی که از نزدیک با آن‌ها سروکار دارید و اعضایی از تیم که ارتباط نزدیک با آن‌ها ندارید را شامل شوند. روابط شما با سایر اعضای تیم از نوشتن چند خط کد بیشتر به‌مراتب مهمتر است. بنابراین گاهی لازم است چند خط کد را فدای ساختن و تحکیم روابط خود با اعضای تیم نموده و برای گسترش روابط خود وقت بگذارید.
۱۱- درگیر سیاست‌های شرکت هستید
وقتی به‌عنوان دولوپر در چند شرکت مختلف مشغول کار می‌شوید، تحت‌تأثیر سیاست‌های کلان شرکت‌ها قرار می‌گیرید؛ به این ترتیب ممکن است دیدگاه تیم از «ما باید بهترین باشیم» به «ما باید از تیم فلان شرکت بهتر باشیم» تغییر کند و این موضوع به‌نوبهٔ خود می‌تواند باعث افت عملکرد و کاهش بهره‌وری تیم شود.
۱۲. در شرایط پراسترس نمی‌توانید تصمیم‌گیری کنید
ممکن است تاکنون شرایط پراسترس مختلفی را تجربه کرده باشید؛ مثلاً ممکن است تغییری در یکی از فانکشن‌ها داده باشید که باعث شده باشد آن فانکشن دیگر کار نکند و به این ترتیب زمینهٔ نارضایتی صدها و یا شاید هزاران کاربر را فراهم نموده باشید و یا ممکن است در شرایطی مجبور بوده باشید در مورد انتقال از یک سیستم به سیستم دیگر که مستلزم چندین ساعت Down بودن سایت باشد، تصمیم بگیرید.
وقتی در موقعیت‌هایی قرار می‌گیرید که تصمیم‌گیری شما ممکن است موجب اختلال در کار کاربران شود، استرس زیادی را متحمل می‌شوید و بسیاری از دولوپرها در این شرایط عصبی شده و قدرت تصمیم‌گیری خود را از دست می‌دهند؛ اگر می‌خواهید خود را به‌عنوان یک دولوپر قوی و ارزشمند به دیگران بشناسانید، باید مهارت کار در شرایط پراسترس را به‌دست آورید.
۱۳. نمی‌توانید بپذیرید که بعضی از کدهایتان عالی نباشند
همیشه نمی‌شود کدهای عالی و بی‌نقص نوشت؛ در دنیای واقعی، گاهی لازم است به نوشتن کدهای معمولی و حتی شاید بد هم راضی شوید! گاهی‌اوقات در موقعیت‌هایی که فرصتی تا زمان تحویل کار باقی نمانده، برای برخی بررسی‌ها و همچنین به‌منظور رفع فوری اشکالات لازم است با کدهایی که عالی نیستند هم کنار بیایید. بهتر است ذهنیت کمال‌گرای خود را کنار بگذارید و بدانید که گاهی برای دستیابی به اهداف فوری، لازم است از کدهای معمولی و یا حتی بد استفاده کنید.
۱۴. بیش از حد اهل مهندسی کردن هستید
اغلب مشکلات ساده، راه‌حل‌های ساده‌ای هم دارند؛ اگر بیش از حد اهل مهندسی کردن باشید، ممکن است یک مشکل ساده را به یک مشکل پیچیده و دشوار تبدیل کنید. البته گاهی‌اوقات ارائهٔ راه‌حل‌های پیچیده برای مشکلات ساده می‌تواند جالب و لذت‌بخش باشد و نکات جدیدی را برای شما آشکار کند اما دولوپرهای خوب معمولاً از ارائهٔ پاسخ‌های پیچیده برای سوالات ساده خودداری می‌کنند.
۱۵. بیشتر از آن‌که لیدر باشید، رئیس هستید
رئیس بودن شما کمک زیادی به پیشرفت تیم نخواهد کرد! شما باید یاد بگیرید که به جای ریاست، تیم را رهبری کنید و کسی باشید که سایر اعضای تیم برای راهنمایی گرفتن، رفع مشکلات و اظهارنظر به او مراجعه می‌کنند. البته رسیدن به چنین جایگاهی به تلاش و صرف زمان کافی نیاز دارد (برای کسب اطلاعات بیشتر پیرامون تفاوت‌های ریاست و رهبری، میتوانید به مقالهٔ مدیریت یا رهبری: مسئله این است! مراجعه نمایید).
۱۶. از ابزار مناسب استفاده نمی‌کنید
دولوپرهای برتر همواره تلاش می‌کنند تا از تکنولوژی‌ها، زبان‌های برنامه‌نویسی و فریمورک‌های متناسب با کار خود استفاده کنند؛ بنابراین سعی کنید به‌جای این دیدگاه که «من این روش را بلدم پس از همین استفاده می‌کنم»، به دنبال یافتن م
ناسب‌ترین ابزار برای کار خود باشید و اگر لازم است، چیزهای جدیدی را بیاموزید. با این روش در طولانی‌مدت میتوانید دولوپر موفق‌تری باشید.
۱۷. در مورد سؤالات برنامه‌نویسی خود اصطلاحاً دست به سرچ نیستید
در مجموعه ابزارهای برنامه‌نویسان، گوگل و استک اورفلو یکی از قدرتمندترین ابزارها به شمار می‌آیند. در اغلب موارد، وقتی به مشکلی برمی‌خورید و یا نمی‌توانید چیزی را درست درک کنید، با جستجو در گوگل و سایر موتورهای مرتبط میتوانید جواب خود را بیابید و مشکل را برطرف کنید.
۱۸. با ابزارهای مورد استفادهٔ خود آشنایی کامل ندارید
شما به‌عنوان یک دولوپر، ساعت‌های زیادی را صرف کار با تکست ادیتورها، کامندلاین و سایر ابزارهای کدنویسی می‌کنید؛ پس با این حساب، باید بر جنبه‌های مختلف این ابزارها کاملاً مسلط باشید. دولوپرهای برتر، بر ابزارهای مورد استفادهٔ خود و ترفندهای کدنویسی مرتبط با آن‌ها کاملاً آشنا هستند.
۱۹. از ارورها گریزانید
در برنامه‌نویسی معمولاً ارورها اتفاق می‌افتند و این اصلاً چیز بدی نیست؛ ارورها به شما می‌گویند که چه مشکلی وجود دارد، چرا این مشکل ایجاد شده و کدام خط کد این مشکل را ایجاد نموده است؟ بنابراین ارورها می‌توانند به‌عنوان یک ابزار مفید مورد استفاده قرار گیرند و به شما در حل و جلوگیری از تکرار مشکلات کمک کنند.
۲۰. ساعتی کد می‌زنید
دولوپرهای برتر معمولاً از کدنویسی لذت می‌برند؛ این دولوپرها حتی هنگامی که جلوی سیستم خود نیستند نیز در حال فکر کردن به مشکلات و مسائل کدهای خود بوده و در آن غرق می‌شوند و از این رو، اصلاً متوجه گذر زمان نیستند. بنابراین محاسبه تعداد ساعاتی که صرف نوشتن کد نموده‌اند -اگر غیر ممکن نباشد- بسیار دشوار خواهد بود.
۲۱. از اشتباهات خود درس نمی‌گیرید
دولوپرهای برتر نه‌تنها از اشتباه کردن نمی‌ترسند، بلکه بیش از دولوپرهای معمولی اشتباه می‌کنند! این‌که سعی کنید هیچ‌وقت اشتباه نکنید، خود اشتباه دیگری است. وقتی مرتکب اشتباهی می‌شوید، سعی کنید خود را زیاد درگیر آن نکنید و درعوض دنبال پاسخ این ۳ سؤال بگردید:
- دلیل اصلی رخ دادن این اشتباه چه بود؟
- برای جلوگیری از تکرار این اشتباه و اشتباهات مشابه آن در آینده چه اقداماتی باید انجام دهم؟
- چگونه می‌توانم مشکلاتی از این دست را زودتر تشخیص دهم تا اثر آن‌را به حداقل برسانم؟
اگر از اشتباهات خود درس نگیرید، به احتمال زیاد در آینده دوباره آن‌ها را تکرار خواهید کرد و همین مسئله از اعتبار شما به‌عنوان یک دولوپر حرفه‌ای خواهد کاست.
۲۲. از ورژن کنترل استفاده نمی‌کنید
امروزه استفاده از ورژن کنترل در شرکت‌های نرم‌افزاری -و حتی برای دولوپرهای فریلنسر- به یک باید تبدیل شده است؛ خیلی اوقات در برنامه‌نویسی پیش می‌آید که نیاز داریم تا کدهایی که چند ماه پیش و یا حتی چند سال پیش نوشته‌ایم را مورد استفاده قرار دهیم و سیستم‌های ورژن کنترلی همچون گیت، بهترین ابزار برای پاسخگویی به چنین نیازی هستند (برای آشنایی بیشتر با پلتفرم‌هایی که برای این منظور به بازار عرضه شده‌اند، میتوانید به مقالهٔ مقایسهٔ 7 پلتفرم میزبانی و مدیریت سورس‌کد مراجعه نمایید).
۲۳. عاشق ابزارهایی هستید که به استفاده از آن‌ها عادت دارید
یک دولوپر ممکن است عاشق یک تکست ادیتور خاص باشد و دولوپر دیگری از همان تکست ادیتور خاص متنفر بوده و عاشق تکست ادیتور دیگری باشد اما دولوپرهای برتر در مورد هیچ ابزاری عاشقانه و متعصبانه برخورد نمی‌کنند و درعوض سعی می‌کنند تا خود را با شرایط و امکانات محیط وفق دهند.
۲۴. از تعامل با جامعهٔ‌برنامه‌نویسی اجتناب می‌کنید
جوامع و انجمن‌های برنامه‌نویسی در همه‌‌جا وجود دارند؛ حتی اگر نتوانید در دنیای واقعی به یکی از انجمن‌های زبان برنامه‌نویسی مورد علاقهٔ خود دست پیدا کنید، حتماً در دنیای مجازی امکان دسترسی و عضویت در این انجمن‌ها امکان‌پذیر خواهد بود.
پس دیگر هیچ بهانه‌ای برای عدم تعامل با جامعهٔ برنامه‌نویسان زبان مورد نظر خود ندارید؛ با این حال اگر باز هم اصرار دارید از جامعه به دور باشید، لااقل ویدئوهای ضبط شده و یا آنلاین مرتبط با زبان برنامه‌نویسی مورد علاقهٔ خود را دنبال کنید تا از تحولات و آیندهٔ آن با خبر شوید و از دنیا عقب نمانید.
۲۵. اکانت توئیتر ندارید
توئیتر ابزار مفیدی است؛ سازندگان پروژه‌های بزرگ اپن‌سورس در توئیتر حضور دارند و دیدگاه‌های خود را در مورد روندهای دنیای برنامه‌نویسی ارائه می‌دهند؛ ارتباط با این افراد می‌تواند هم در زمینهٔ دانش به شما کمک کند و هم به‌نوعی به شما انگیزه پیشرفت بدهد.
از سوی دیگر داشتن اکانت توئیتر باعث می‌شود تا شما نیز در دسترس سایر افراد قرار بگیرید و دیگران بتوانند با شما تعامل داشته باشند؛ همین ارتباطات کوچک می‌تواند دنیای برنامه‌نویسی را به یک دنیای فوق‌العاده جذاب تبدیل کند.
۲۶. دین خود را به جامعه ادا نمی‌کنید
به‌عنوا
۱۷. در مورد سؤالات برنامه‌نویسی خود اصطلاحاً دست به سرچ نیستید
در مجموعه ابزارهای برنامه‌نویسان، گوگل و استک اورفلو یکی از قدرتمندترین ابزارها به شمار می‌آیند. در اغلب موارد، وقتی به مشکلی برمی‌خورید و یا نمی‌توانید چیزی را درست درک کنید، با جستجو در گوگل و سایر موتورهای مرتبط میتوانید جواب خود را بیابید و مشکل را برطرف کنید.
۱۸. با ابزارهای مورد استفادهٔ خود آشنایی کامل ندارید
شما به‌عنوان یک دولوپر، ساعت‌های زیادی را صرف کار با تکست ادیتورها، کامندلاین و سایر ابزارهای کدنویسی می‌کنید؛ پس با این حساب، باید بر جنبه‌های مختلف این ابزارها کاملاً مسلط باشید. دولوپرهای برتر، بر ابزارهای مورد استفادهٔ خود و ترفندهای کدنویسی مرتبط با آن‌ها کاملاً آشنا هستند.
۱۹. از ارورها گریزانید
در برنامه‌نویسی معمولاً ارورها اتفاق می‌افتند و این اصلاً چیز بدی نیست؛ ارورها به شما می‌گویند که چه مشکلی وجود دارد، چرا این مشکل ایجاد شده و کدام خط کد این مشکل را ایجاد نموده است؟ بنابراین ارورها می‌توانند به‌عنوان یک ابزار مفید مورد استفاده قرار گیرند و به شما در حل و جلوگیری از تکرار مشکلات کمک کنند.
۲۰. ساعتی کد می‌زنید
دولوپرهای برتر معمولاً از کدنویسی لذت می‌برند؛ این دولوپرها حتی هنگامی که جلوی سیستم خود نیستند نیز در حال فکر کردن به مشکلات و مسائل کدهای خود بوده و در آن غرق می‌شوند و از این رو، اصلاً متوجه گذر زمان نیستند. بنابراین محاسبه تعداد ساعاتی که صرف نوشتن کد نموده‌اند -اگر غیر ممکن نباشد- بسیار دشوار خواهد بود.
۲۱. از اشتباهات خود درس نمی‌گیرید
دولوپرهای برتر نه‌تنها از اشتباه کردن نمی‌ترسند، بلکه بیش از دولوپرهای معمولی اشتباه می‌کنند! این‌که سعی کنید هیچ‌وقت اشتباه نکنید، خود اشتباه دیگری است. وقتی مرتکب اشتباهی می‌شوید، سعی کنید خود را زیاد درگیر آن نکنید و درعوض دنبال پاسخ این ۳ سؤال بگردید:
- دلیل اصلی رخ دادن این اشتباه چه بود؟
- برای جلوگیری از تکرار این اشتباه و اشتباهات مشابه آن در آینده چه اقداماتی باید انجام دهم؟
- چگونه می‌توانم مشکلاتی از این دست را زودتر تشخیص دهم تا اثر آن‌را به حداقل برسانم؟
اگر از اشتباهات خود درس نگیرید، به احتمال زیاد در آینده دوباره آن‌ها را تکرار خواهید کرد و همین مسئله از اعتبار شما به‌عنوان یک دولوپر حرفه‌ای خواهد کاست.
۲۲. از ورژن کنترل استفاده نمی‌کنید
امروزه استفاده از ورژن کنترل در شرکت‌های نرم‌افزاری -و حتی برای دولوپرهای فریلنسر- به یک باید تبدیل شده است؛ خیلی اوقات در برنامه‌نویسی پیش می‌آید که نیاز داریم تا کدهایی که چند ماه پیش و یا حتی چند سال پیش نوشته‌ایم را مورد استفاده قرار دهیم و سیستم‌های ورژن کنترلی همچون گیت، بهترین ابزار برای پاسخگویی به چنین نیازی هستند (برای آشنایی بیشتر با پلتفرم‌هایی که برای این منظور به بازار عرضه شده‌اند، میتوانید به مقالهٔ مقایسهٔ 7 پلتفرم میزبانی و مدیریت سورس‌کد مراجعه نمایید).
۲۳. عاشق ابزارهایی هستید که به استفاده از آن‌ها عادت دارید
یک دولوپر ممکن است عاشق یک تکست ادیتور خاص باشد و دولوپر دیگری از همان تکست ادیتور خاص متنفر بوده و عاشق تکست ادیتور دیگری باشد اما دولوپرهای برتر در مورد هیچ ابزاری عاشقانه و متعصبانه برخورد نمی‌کنند و درعوض سعی می‌کنند تا خود را با شرایط و امکانات محیط وفق دهند.
۲۴. از تعامل با جامعهٔ‌برنامه‌نویسی اجتناب می‌کنید
جوامع و انجمن‌های برنامه‌نویسی در همه‌‌جا وجود دارند؛ حتی اگر نتوانید در دنیای واقعی به یکی از انجمن‌های زبان برنامه‌نویسی مورد علاقهٔ خود دست پیدا کنید، حتماً در دنیای مجازی امکان دسترسی و عضویت در این انجمن‌ها امکان‌پذیر خواهد بود.
پس دیگر هیچ بهانه‌ای برای عدم تعامل با جامعهٔ برنامه‌نویسان زبان مورد نظر خود ندارید؛ با این حال اگر باز هم اصرار دارید از جامعه به دور باشید، لااقل ویدئوهای ضبط شده و یا آنلاین مرتبط با زبان برنامه‌نویسی مورد علاقهٔ خود را دنبال کنید تا از تحولات و آیندهٔ آن با خبر شوید و از دنیا عقب نمانید.
۲۵. اکانت توئیتر ندارید
توئیتر ابزار مفیدی است؛ سازندگان پروژه‌های بزرگ اپن‌سورس در توئیتر حضور دارند و دیدگاه‌های خود را در مورد روندهای دنیای برنامه‌نویسی ارائه می‌دهند؛ ارتباط با این افراد می‌تواند هم در زمینهٔ دانش به شما کمک کند و هم به‌نوعی به شما انگیزه پیشرفت بدهد.
از سوی دیگر داشتن اکانت توئیتر باعث می‌شود تا شما نیز در دسترس سایر افراد قرار بگیرید و دیگران بتوانند با شما تعامل داشته باشند؛ همین ارتباطات کوچک می‌تواند دنیای برنامه‌نویسی را به یک دنیای فوق‌العاده جذاب تبدیل کند.
۲۶. دین خود را به جامعه ادا نمی‌کنید
به‌عنوا
کار می‌لنگد.
بنابراین اگر با روش فعلی خود همیشه وقت کم می‌آورید و برای تحویل به‌موقع پروژه چاره‌ای جز نادیده گرفتن کیفیت کدها ندارید، بهتر است چند روزی وقت بگذارید و در روش خود تجدید نظر کنید و روشی را بیابید تا علاوه بر سرعت، کیفیت کدهای شما را نیز نضمین نماید تا دائماً مجبور به عذرخواهی نباشید.
۳۴. برای مرور کدها وقت کافی نمی‌گذارید
همهٔ دولوپرهای تیم باید علاوه بر این‌که کدهای باکیفیتی می‌نویسند، خود را مسئول بررسی کیفیت کدهای سایر اعضا دانسته و مشکلات کدهای دیگران را نیز شناسایی نمایند تا درنهایت استانداردهای یکسانی در مورد کدهای همهٔ اعضا رعایت شود.
اگر این اتفاق نیفتد و به‌جای رعایت استانداردها، اعضا به رفع سطحی مشکلات کدهای یکدیگر بسنده کنند، درنهایت سورس‌کدی که حاصل کار کل تیم خواهد بود کاملاً غیراستاندارد و به‌هم‌ریخته بوده و بعدها نیز امکان ارتقاء آن وجود نخواهد داشت. بنابراین مرور و بررسی کدها همیشه ارزش صرف زمان و انرژی را دارا است.
۳۵. برای نظارت بر کار تازه‌واردهای تیم، وقت کافی صرف نمی‌کنید
تیم شما باید روزبه‌روز بهتر شود، رشد نماید و بیشتر یاد بگیرد؛ به‌عنوان یک دولوپر باتجربه، این وظیفهٔ شما است که برای دولوپرهای تازه‌کار و کم‌تجربه وقت بگذارید، به‌صورت دو‌نفره با آن‌ها کد بزنید و به آن‌ها بیاموزید که چه‌طور از روش‌های مختلف می‌توانند مشکلات را حل کنند. این کار ممکن است ۱ یا ۲ ساعت از وقت شما را در روز بگیرد اما چیزی که درنهایت عاید تیم خواهد شد، ارزشی بیش از این خواهد داشت.
@codefriend
بنابراین اگر با روش فعلی خود همیشه وقت کم می‌آورید و برای تحویل به‌موقع پروژه چاره‌ای جز نادیده گرفتن کیفیت کدها ندارید، بهتر است چند روزی وقت بگذارید و در روش خود تجدید نظر کنید و روشی را بیابید تا علاوه بر سرعت، کیفیت کدهای شما را نیز نضمین نماید تا دائماً مجبور به عذرخواهی نباشید.
۳۴. برای مرور کدها وقت کافی نمی‌گذارید
همهٔ دولوپرهای تیم باید علاوه بر این‌که کدهای باکیفیتی می‌نویسند، خود را مسئول بررسی کیفیت کدهای سایر اعضا دانسته و مشکلات کدهای دیگران را نیز شناسایی نمایند تا درنهایت استانداردهای یکسانی در مورد کدهای همهٔ اعضا رعایت شود.
اگر این اتفاق نیفتد و به‌جای رعایت استانداردها، اعضا به رفع سطحی مشکلات کدهای یکدیگر بسنده کنند، درنهایت سورس‌کدی که حاصل کار کل تیم خواهد بود کاملاً غیراستاندارد و به‌هم‌ریخته بوده و بعدها نیز امکان ارتقاء آن وجود نخواهد داشت. بنابراین مرور و بررسی کدها همیشه ارزش صرف زمان و انرژی را دارا است.
۳۵. برای نظارت بر کار تازه‌واردهای تیم، وقت کافی صرف نمی‌کنید
تیم شما باید روزبه‌روز بهتر شود، رشد نماید و بیشتر یاد بگیرد؛ به‌عنوان یک دولوپر باتجربه، این وظیفهٔ شما است که برای دولوپرهای تازه‌کار و کم‌تجربه وقت بگذارید، به‌صورت دو‌نفره با آن‌ها کد بزنید و به آن‌ها بیاموزید که چه‌طور از روش‌های مختلف می‌توانند مشکلات را حل کنند. این کار ممکن است ۱ یا ۲ ساعت از وقت شما را در روز بگیرد اما چیزی که درنهایت عاید تیم خواهد شد، ارزشی بیش از این خواهد داشت.
@codefriend
ن دولوپر یک زبان برنامه‌نویسی، باید زود‌به‌زود به جامعهٔ آن زبان بازگشته و تجربیات و دانسته‌های جدید خود را در اختیار دیگران قرار دهید و به این ترتیب این جامعه را به‌صورتی که فکر می‌کنید باید باشد، تبدیل کنید.
۲۷. ساعت‌ها برای حل مشکلی وقت می‌گذارید اما هنگامی که موفق شدید، آن‌را مستند نمی‌کنید
این روزها با انجام یک جستجو در وب، تقریباً در زمان کوتاهی می‌توان به راه‌حل هر مشکلی دست یافت زیرا افرادی از قبل با آن مشکلات مواجه شده‌اند، آن‌ها را حل نموده و سپس راه‌حل آن‌ها را در وبلاگ یا وب‌سایت شخصی خود، در انجمن‌ها و تالارهای گفتگو و … در اختیار دیگرن قرار داده‌اند.
با این حال، گاهی ممکن است با مشکلی مواجه شوید که کسی تاکنون راه‌حلی برای آن ارائه نداده است؛ اکنون این وظیفهٔ شما است که پس از صرف ساعت‌ها وقت و یافتن راه‌حل، آن‌را در وبلاگ شخصی خود و یا درجایی دیگر در اختیار دیگرانی قرار دهید که شاید بعدها با این مشکل مواجه شوند.
۲۸. در کامنت نوشتن افراط و تفریط دارید
کامنت‌نویسی برای کدها کار بسیار پسندیده‌ای است؛ کامنت‌ها به دولوپرهایی که در آینده کد شما را می‌بینند کمک می‌کند تا آن‌را بهتر و سریع‌تر درک کنند اما در کامنت‌نویسی هم اندازه نگاه داشتن ضروری است.
اگر برای هر خط از کد خود کامنت بنویسید، نه‌تنها به ساده‌تر شدن درک آن کمکی نمی‌کنید بلکه آن‌را پیچیده‌تر نیز می‌کنید. از سوی دیگر، کامنت‌نویسی در برخی موارد بسیار ضروری است و ننوشتن آن باعث پیچیدگی درک کد می‌شود. بنابراین فقط در جاهایی که فکر می‌کنید نوشتن کامنت ضروری است و یا می‌تواند درک کد را برای دیگران ساده‌تر نماید، کامنت‌گذاری کنید.
۲۹. با مدیر پروژه‌ٔ خود اصطلاحاً سینک نیستید
شرکت‌های حرفه‌ای از یکسری سیستم‌های تیکتینگ برخوردارند که در آن تسک‌های مرتبط با یک پروژه و زمان انجام هر‌کدام مشخص شده و این سیستم‌ها به‌نوعی فصل مشترک مدیر پروژه با دولوپرها هستند.
یکی از ویژگی‌های دولوپرهای غیرحرفه‌ای این است که به چنین سیستم‌هایی اعتقاد نداشته و درصورتی‌که تسک خاصی را به اتمام برسانند، اقدام به آپدیت وضعیت تسک مدنظر نکرده و همین مسئله مدیر پروژه را برای برنامه‌ریزی روزهای آینده دچار سردرگمی می‌کند که درنهایت منجر به ایجاد اختلال در زمان لانچ پروژه می‌شود.
۳۰. عدم توانایی در اولویت‌بندی تسک‌های پروژه
هر پروژه‌ٔ نرم‌افزاری از تعدادی ماژول مختلف تشکیل شده است که برخی از آن‌ها جزو ماژول‌های زیربنایی هستند؛ به‌عبارت دیگر، سایر ماژولها وابسته به این دست ماژولها هستند و تکمیل و دیباگینگ آن‌ها باید در اولویت باشد. درعین‌حال، برخی دولوپرهای مبتدی صرفاً به این دلیل که این ماژول‌های زیربنایی تاحدودی پیچیده هستند و کدنویسی آن‌ها مستلزم صرف زمان بیشتری است، کدنویسی آن‌ها را شروع نکرده و فوراً به‌سراغ کارهای ساده‌تر می‌روند که همین مسئله آن‌ها را در آینده‌ای نه‌چندان دور در فرایند تکمیل چنین پروژه‌ای به دردسر خواهد انداخت.
۳۱. وقتی مشکل غیرمنتظره‌ای پیش می‌آید بلافاصله تصمیم می‌گیرید کل روند طی شده را کنار می‌گذارید
در حین توسعهٔ نرم‌افزارها ممکن است بارها و بارها با مشکلات و موقعیت‌های پیش‌بینی نشده‌ای مواجه شوید؛ در چنین مواقعی، شما به‌عنوان یک دولوپر باید بتوانید موقعیت پیش آمده را مدیریت نموده و مشکل را برطرف کنید اما اگر از ابتدا برنامهٔ مشخصی را برای خود و تیم خود در نظر نگرفته باشید، در چنین موقعیت‌هایی ممکن است تصمیمات کاملاً نادرستی بگیرید و تمام زحمات قبلی را به هدر دهید!
بنابراین همواره سعی کنید برنامه‌ای مدون برای هدایت روند توسعهٔ نرم‌افزار داشته باشید تا با وقوع یک مشکل پیش‌بینی نشده میدان را خالی نکرده و همه‌چیز را رها نکنید؛ مطمئن باشید در مواجهه با مشکلات پیش‌بینی نشده نیز به‌جای نادیده گرفتن کارهای انجام شده، میتوانید واکنش‌های خیلی بهتری از خود نشان دهید.
۳۲. همچنان به اجرای برنامه‌ای که درست کار نمی‌کند چسبیده‌اید
اگر چیزی بدتر از کنار گذاشتن ناگهانی یک فرایند کاری خوب در لحظهٔ آخر وجود داشته باشد، آن چیزی نیست جز ادامه دادن اجرای برنامه و ایده‌ای که خوب کار نمی‌کند! دولوپرهای برتر همواره در هنگام افزودن قابلیت‌های جدید از یک سو و همچنین برطرف نمودن باگ‌ها در مراحل مختلف از سوی دیگر، خود را ارزیابی می‌کنند و از خود می‌پرسند که آیا روش و برنامهٔ درستی را در پیش گرفته‌اند یا نه؟
۳۳. به‌خاطر کدهای بدی که نوشته‌اید دائماً در حال عذرخواهی هستید
قبلاً گفتیم که خیلی آرمان‌گرا نباشید و گاهی برای رسیدن به اهداف خیلی فوری به نوشتن کدهای متوسط و حتی بد راضی شوید؛ به‌عبارت دیگر، کدهایی که خوب نیستند ولی هنوز کار می‌کنند. اما اگر این روش دائمی شما است که کدهایی بنویسید که فقط کار می‌کنند و به خوب و یا عالی بودن آن‌ها اهمیتی نمی‌دهید، معلوم است که یک جای
۲۷. ساعت‌ها برای حل مشکلی وقت می‌گذارید اما هنگامی که موفق شدید، آن‌را مستند نمی‌کنید
این روزها با انجام یک جستجو در وب، تقریباً در زمان کوتاهی می‌توان به راه‌حل هر مشکلی دست یافت زیرا افرادی از قبل با آن مشکلات مواجه شده‌اند، آن‌ها را حل نموده و سپس راه‌حل آن‌ها را در وبلاگ یا وب‌سایت شخصی خود، در انجمن‌ها و تالارهای گفتگو و … در اختیار دیگرن قرار داده‌اند.
با این حال، گاهی ممکن است با مشکلی مواجه شوید که کسی تاکنون راه‌حلی برای آن ارائه نداده است؛ اکنون این وظیفهٔ شما است که پس از صرف ساعت‌ها وقت و یافتن راه‌حل، آن‌را در وبلاگ شخصی خود و یا درجایی دیگر در اختیار دیگرانی قرار دهید که شاید بعدها با این مشکل مواجه شوند.
۲۸. در کامنت نوشتن افراط و تفریط دارید
کامنت‌نویسی برای کدها کار بسیار پسندیده‌ای است؛ کامنت‌ها به دولوپرهایی که در آینده کد شما را می‌بینند کمک می‌کند تا آن‌را بهتر و سریع‌تر درک کنند اما در کامنت‌نویسی هم اندازه نگاه داشتن ضروری است.
اگر برای هر خط از کد خود کامنت بنویسید، نه‌تنها به ساده‌تر شدن درک آن کمکی نمی‌کنید بلکه آن‌را پیچیده‌تر نیز می‌کنید. از سوی دیگر، کامنت‌نویسی در برخی موارد بسیار ضروری است و ننوشتن آن باعث پیچیدگی درک کد می‌شود. بنابراین فقط در جاهایی که فکر می‌کنید نوشتن کامنت ضروری است و یا می‌تواند درک کد را برای دیگران ساده‌تر نماید، کامنت‌گذاری کنید.
۲۹. با مدیر پروژه‌ٔ خود اصطلاحاً سینک نیستید
شرکت‌های حرفه‌ای از یکسری سیستم‌های تیکتینگ برخوردارند که در آن تسک‌های مرتبط با یک پروژه و زمان انجام هر‌کدام مشخص شده و این سیستم‌ها به‌نوعی فصل مشترک مدیر پروژه با دولوپرها هستند.
یکی از ویژگی‌های دولوپرهای غیرحرفه‌ای این است که به چنین سیستم‌هایی اعتقاد نداشته و درصورتی‌که تسک خاصی را به اتمام برسانند، اقدام به آپدیت وضعیت تسک مدنظر نکرده و همین مسئله مدیر پروژه را برای برنامه‌ریزی روزهای آینده دچار سردرگمی می‌کند که درنهایت منجر به ایجاد اختلال در زمان لانچ پروژه می‌شود.
۳۰. عدم توانایی در اولویت‌بندی تسک‌های پروژه
هر پروژه‌ٔ نرم‌افزاری از تعدادی ماژول مختلف تشکیل شده است که برخی از آن‌ها جزو ماژول‌های زیربنایی هستند؛ به‌عبارت دیگر، سایر ماژولها وابسته به این دست ماژولها هستند و تکمیل و دیباگینگ آن‌ها باید در اولویت باشد. درعین‌حال، برخی دولوپرهای مبتدی صرفاً به این دلیل که این ماژول‌های زیربنایی تاحدودی پیچیده هستند و کدنویسی آن‌ها مستلزم صرف زمان بیشتری است، کدنویسی آن‌ها را شروع نکرده و فوراً به‌سراغ کارهای ساده‌تر می‌روند که همین مسئله آن‌ها را در آینده‌ای نه‌چندان دور در فرایند تکمیل چنین پروژه‌ای به دردسر خواهد انداخت.
۳۱. وقتی مشکل غیرمنتظره‌ای پیش می‌آید بلافاصله تصمیم می‌گیرید کل روند طی شده را کنار می‌گذارید
در حین توسعهٔ نرم‌افزارها ممکن است بارها و بارها با مشکلات و موقعیت‌های پیش‌بینی نشده‌ای مواجه شوید؛ در چنین مواقعی، شما به‌عنوان یک دولوپر باید بتوانید موقعیت پیش آمده را مدیریت نموده و مشکل را برطرف کنید اما اگر از ابتدا برنامهٔ مشخصی را برای خود و تیم خود در نظر نگرفته باشید، در چنین موقعیت‌هایی ممکن است تصمیمات کاملاً نادرستی بگیرید و تمام زحمات قبلی را به هدر دهید!
بنابراین همواره سعی کنید برنامه‌ای مدون برای هدایت روند توسعهٔ نرم‌افزار داشته باشید تا با وقوع یک مشکل پیش‌بینی نشده میدان را خالی نکرده و همه‌چیز را رها نکنید؛ مطمئن باشید در مواجهه با مشکلات پیش‌بینی نشده نیز به‌جای نادیده گرفتن کارهای انجام شده، میتوانید واکنش‌های خیلی بهتری از خود نشان دهید.
۳۲. همچنان به اجرای برنامه‌ای که درست کار نمی‌کند چسبیده‌اید
اگر چیزی بدتر از کنار گذاشتن ناگهانی یک فرایند کاری خوب در لحظهٔ آخر وجود داشته باشد، آن چیزی نیست جز ادامه دادن اجرای برنامه و ایده‌ای که خوب کار نمی‌کند! دولوپرهای برتر همواره در هنگام افزودن قابلیت‌های جدید از یک سو و همچنین برطرف نمودن باگ‌ها در مراحل مختلف از سوی دیگر، خود را ارزیابی می‌کنند و از خود می‌پرسند که آیا روش و برنامهٔ درستی را در پیش گرفته‌اند یا نه؟
۳۳. به‌خاطر کدهای بدی که نوشته‌اید دائماً در حال عذرخواهی هستید
قبلاً گفتیم که خیلی آرمان‌گرا نباشید و گاهی برای رسیدن به اهداف خیلی فوری به نوشتن کدهای متوسط و حتی بد راضی شوید؛ به‌عبارت دیگر، کدهایی که خوب نیستند ولی هنوز کار می‌کنند. اما اگر این روش دائمی شما است که کدهایی بنویسید که فقط کار می‌کنند و به خوب و یا عالی بودن آن‌ها اهمیتی نمی‌دهید، معلوم است که یک جای
اپ این اپس (appinapps)
اموزش های متفاوت برنامه نویسی کاملا رایگان
زبان های
جاوا
جاوااسکریپت
پی اچ پی
اندروید
زامارین
سی پلاس پلاس
@appinapps
ادرس سایت
Appinapps.com
اموزش های متفاوت برنامه نویسی کاملا رایگان
زبان های
جاوا
جاوااسکریپت
پی اچ پی
اندروید
زامارین
سی پلاس پلاس
@appinapps
ادرس سایت
Appinapps.com
18 نکتهٔ ضروری برای دولوپرهای تازه‌کاری که نمی‌دانند در چه حوزه‌ای دست‌به‌کار شوند!(قسمت اول)
@codefriend
@codefriend
اگر شمار زیادی از دولوپرها را با تخصص‌های مختلفی می‌بینید و کاملاً سردرگم شده‌اید، این مقاله برای شما نوشته شده است؛ درواقع، این مقاله منتشر شده تا به شما کمک کند که با تحقیق و بررسی به‌سمت کدنویسی بروید و بفهمید که شما در چه‌چیزی از این صنعت بیشتر خواهید درخشید.
@codefriend
1. سعی کنید یک صفحهٔ با HTML و CSS بسازید
ساختن یک صفحۀ ساده وب با این ۲ زبان نسبتاً راحت است؛ این‌ها زیربنای راهی هستند که مرورگرهای وب از طریق آن اطلاعات را به کاربران نشان می‌دهند. کار با HTML و CSS یک تصویر کلی از کدنویسی، کار با ویرایشگرهای متن و آشنایی با روش کار دولوپرها به شما می‌دهد. البته مهمتر از این مسئله، این است که با کار با این تکنولوژی‌ها یک درک کلی از ساختار بلوک‌های وب به‌دست می‌آورید و مهم نیست که در آخر چه حوزۀ تخصصی را انتخاب می‌کنید.
@codefriend
@codefriend
1. سعی کنید یک صفحهٔ با HTML و CSS بسازید
ساختن یک صفحۀ ساده وب با این ۲ زبان نسبتاً راحت است؛ این‌ها زیربنای راهی هستند که مرورگرهای وب از طریق آن اطلاعات را به کاربران نشان می‌دهند. کار با HTML و CSS یک تصویر کلی از کدنویسی، کار با ویرایشگرهای متن و آشنایی با روش کار دولوپرها به شما می‌دهد. البته مهمتر از این مسئله، این است که با کار با این تکنولوژی‌ها یک درک کلی از ساختار بلوک‌های وب به‌دست می‌آورید و مهم نیست که در آخر چه حوزۀ تخصصی را انتخاب می‌کنید.
@codefriend
18 نکتهٔ ضروری برای دولوپرهای تازه‌کاری که نمی‌دانند در چه حوزه‌ای دست‌به‌کار شوند!(قسمت دوم)
@codefriend
@codefriend
2. یک پروژۀ جانبی شروع کنید
یک ایده برای یک پروژه داشته باشید و برنامه‌ریزی برای آن‌را شروع کنید؛ حتی اگر کدنویسی بلد نباشید، میتوانید با ایجاد طوفان فکری (Brain Stroming) یک ایده انتخاب کنید و با کشیدن نمودارها و جدول‌ها نشان دهید که چه‌طور می‌خواهید آن‌را عملی کنید؛ با این کار و کشیدن طرح کلی روی کاغذ، شما انگیزه پیدا می‌کنید تا ایدهٔ‌تان را عملی کنید.
@codefriend
یک ایده برای یک پروژه داشته باشید و برنامه‌ریزی برای آن‌را شروع کنید؛ حتی اگر کدنویسی بلد نباشید، میتوانید با ایجاد طوفان فکری (Brain Stroming) یک ایده انتخاب کنید و با کشیدن نمودارها و جدول‌ها نشان دهید که چه‌طور می‌خواهید آن‌را عملی کنید؛ با این کار و کشیدن طرح کلی روی کاغذ، شما انگیزه پیدا می‌کنید تا ایدهٔ‌تان را عملی کنید.
@codefriend
18 نکتهٔ ضروری برای دولوپرهای تازه‌کاری که نمی‌دانند در چه حوزه‌ای دست‌به‌کار شوند!(قسمت سوم)
@codefriend
@codefriend
3. طراحی Front-End را امتحان کنید
طراحی Front-End شامل کدنویسی چیزی می‌شود که در معرض دید کاربران قرار می‌گیرد؛ وقتی Front-End کار می‌کنید، درواقع از نزدیک با المنت‌های بصری یک اپلیکیشن کار می‌کنید. در بین بقیۀ کارها، دولوپرهای این حوزه وظیفۀ کدنویسی برای ریسپانسیو کردن و یکپارچه کردن صفحه‌های وب را دارند.
میتوانید از دوره های آموزشی فرانت اند سایت کدفرند استفاده کنید
@codefriend
طراحی Front-End شامل کدنویسی چیزی می‌شود که در معرض دید کاربران قرار می‌گیرد؛ وقتی Front-End کار می‌کنید، درواقع از نزدیک با المنت‌های بصری یک اپلیکیشن کار می‌کنید. در بین بقیۀ کارها، دولوپرهای این حوزه وظیفۀ کدنویسی برای ریسپانسیو کردن و یکپارچه کردن صفحه‌های وب را دارند.
میتوانید از دوره های آموزشی فرانت اند سایت کدفرند استفاده کنید
@codefriend
اگر به تازگی قدم به دنیای وب و طراحی وب گذاشته اید حتما یک بار هم که شده نام Google Analytics یا گوگل آنالیتیکس را شنیده اید.در این پست قصد داریم به زبان ساده نحوه نصب Google Analytics در وردپرس را به شما دوستان آموزش دهیم.
ادامه آموزش:
https://goo.gl/07QhEZ
@codefriend
ادامه آموزش:
https://goo.gl/07QhEZ
@codefriend
CodeFriend.ir
آموزش ساده نصب Google Analytics در وردپرس - CodeFriend.ir
در این پست قصد داریم به زبان ساده نحوه نصب Google Analytics در وردپرس را به شما دوستان آموزش دهیم.اگر به تازگی قدم به دنیای وب و طراحی وب گذاشته اید
18 نکتهٔ ضروری برای دولوپرهای تازه‌کاری که نمی‌دانند در چه حوزه‌ای دست‌به‌کار شوند!(قسمت چهارم)
@codefriend
@codefriend
4. به جلسات میت‌آپ برنامه‌نویسی بروید
جلسات Meetup این امکان را به شما می‌دهند تا در دنیای واقعی با دیگر دولوپرها آشنا شوید و با آن‌ها تعامل داشته باشید (جلسات هم‌فکر و لاگ‌ها جزو میت‌آپ‌هایی هستند که در ایران رایج‌اند).
وقتی با یک دولوپر دیگر شخصاً صحبت می‌کنید، این صحبت یک چشم‌انداز و جنبۀ فکری به شما می‌دهد. به جلسات مختلف بروید و ببینید که دولوپرهای دیگر چه طرز فکری دربارۀ دیگر تخصص‌های برنامه‌نویسی دارند. دقت کنید که با چه دولوپری صحبت می‌کنید و زمینۀ کاری وی را جویا شوید و همچنین نقطه نظرات و دیدگاه‌های او را بشنوید.
@codefriend
جلسات Meetup این امکان را به شما می‌دهند تا در دنیای واقعی با دیگر دولوپرها آشنا شوید و با آن‌ها تعامل داشته باشید (جلسات هم‌فکر و لاگ‌ها جزو میت‌آپ‌هایی هستند که در ایران رایج‌اند).
وقتی با یک دولوپر دیگر شخصاً صحبت می‌کنید، این صحبت یک چشم‌انداز و جنبۀ فکری به شما می‌دهد. به جلسات مختلف بروید و ببینید که دولوپرهای دیگر چه طرز فکری دربارۀ دیگر تخصص‌های برنامه‌نویسی دارند. دقت کنید که با چه دولوپری صحبت می‌کنید و زمینۀ کاری وی را جویا شوید و همچنین نقطه نظرات و دیدگاه‌های او را بشنوید.
@codefriend
This media is not supported in your browser
VIEW IN TELEGRAM
روز پنجم فرانت اند:ساخت اسلاید شو با Css3
@codefriend
@codefriend
یکی از کاربردی ترین ابزار های که طراحان وب از آن در ایجاد یک رابط مناسب برای ارتباط با کاربر جهت نمایش محتوای سایت به شکل زیبا و ساده استفاده می کنند اسلاید شو است.
قبل از معرفی Css3 یا سی اس اس سطح 3 بیشتر کارها ساخت یک اسلاید شو با استفاده از جاوا اسکریپت صورت میگرفت،اما امروزه با وجود Css3 تمامی کارها با استفاده از این تکنولوژی انجام می شود.
ادامه آموزش:
https://goo.gl/3QZ429
@codefriend
قبل از معرفی Css3 یا سی اس اس سطح 3 بیشتر کارها ساخت یک اسلاید شو با استفاده از جاوا اسکریپت صورت میگرفت،اما امروزه با وجود Css3 تمامی کارها با استفاده از این تکنولوژی انجام می شود.
ادامه آموزش:
https://goo.gl/3QZ429
@codefriend
CodeFriend.ir
روز پنجم فرانت اند:ساخت اسلاید شو با Css3 - CodeFriend.ir
یکی از کاربردی ترین ابزار های که طراحان وب از آن در ایجاد یک رابط مناسب برای ارتباط با کاربر جهت نمایش محتوای سایت به شکل زیبا استفاده می کنند اسلاید شو است