کد میراث کدام است؟ آیا این برای شما خوب هست؟ – یادداشت های مهندس

کار با کد میراث. آیا برای شما خوب است؟

بله تجربه با کد میراث باید باشد هر کس قادر به کار در محیط تازه ای است که در آن همه چیز جدید و براق است، اما کار با میراث یک کار بسیار دشوار است که ذهن های جدیدی را ایجاد می کند و مغز را دوباره می کند.

100 درصد از توسعه دهندگان من به آن صحبت کرده ام، متنفرم! آنها نمی توانند کدهای میراثی را حفظ کنند و اگر علامت فاز تعمیر و نگهداری باشند، در جهت مخالف مانند آتش سوزی اجرا خواهند شد. انتظار می رود که قابل درک باشد. کار با کد میراث آسان نیست.

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

نرم افزار ویرایش مجدد برنامه های مختلف متفاوت است از refactoring کلاس خود را که شما یک هفته پیش نوشت. این مورد است که در آن توجه شدید به جزئیات لفظی (توسط بسیاری از ستایش …) می تواند بینایی تونل ایجاد کند و در واقع آسیب برساند. این جایی است که شما یاد خواهید گرفت که چگونه بینش بزرگتر یک سیستم به طور کلی (با در نظر گرفتن نزدیکترین نقطه مقصد refactoring، نزدیکترین نقطه عطف) و جزئیات کوچک، تغییرات کوچک، تمرکز کنید. شما فقط می توانید بر روی یک بخش از سیستم تمرکز کنید که نیاز به یادگیری و شناختن تمامی API های داخلی و خارجی و مسیرهای ارتباطی را از داخل دارد. چرا؟ به خاطر شکنندگی. حتی یک تغییر کوچک در کد میراث، به ویژه کد که شما نا آشنا هستید، می تواند موجب واکنش های ناپیوستگی آبشارها شود.

اما این یک مورد شدید با بسیار قدیمی است (آخرین نسخه اصلی 10+ سال پیش) و سیستم های ضعیف حفظ شده . اگر با یک برنامه تازه کار کار می کنید، هنوز برای یادگیری بسیار مهم است و از رضایت از آن لذت می برید. اگر به وضوح یک کد قدیمی را مشاهده کنید که توسط شما نوشته شده است، این یک نشانه واضح از پیشرفت شخصی و تکامل شماست، برای من کاملا رضایت بخش است. و هنگامی که با سیستم های بزرگتر کار می کنید، می توانید تصمیمات مهندسی کاملا پیچیده ای را که در آن زمان ساخته شده اند، تشخیص دهید و الگوهای آنها را ببینید و هماهنگی خود را با روند فعلی ترسیم کنید.

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

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

برنامه نویسی جفت – یادداشت های مهندس

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

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

برنامه نویسی زوج بسیار سخت است برای فروش به مدیریت (پروژه / بالا) از ناظم، به شخص از خارج از آن به نظر می رسد مانند زباله، زباله منابع.

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

در طول برنامه های جفت گیری دو نفر در یک داستان یا کار کار می کنند و کاملا منطقی است نتیجه گیری کنید که بیشتر اگر این دو شخص هوشمند هر یک از مشکلات جداگانه را برداشته باشند، کار ممکن است انجام شود. [1965،9006] این دیدگاه منطقی است و بسیار مفید است که آن را آگاه کنیم و همچنین لازم است توجه داشته باشیم که این دیدگاه محدود است و با مديريت آن، مديريت نشان مي دهد كه تمركز بر برنده شدن در دوران كودكي است نه استراتيژي بلند مدت.

يكي از شرايطي كه روش برنامه نويسي جفتي در خارج از آن تأثير نمي گذارد،

چرا من طولانی ترین کار را برای جذب این تکنیک خاص انجام دادم و مزایا را می بینم؟

خوب، اول از همه من یک توسعه دهنده نرم افزاری هستم و تحت تأثیر اخیر "ورود به منطقه" tr پایان دادن به این که نیروها "من را به تنهایی" (به رسمیت شناختن "افسران باز") ایده ها (نگرش ها) را بر همه می گذارند.

من خوشحالم که با اطمینان می توانم ثابت کنم که من از آن حرفه ای رشد کردم.

58٪ از کارکنان با کارایی بالا می گویند که آنها نیاز به فضای کاری آرام تر دارند. "- کاملا مقالهای با استدلال است، من به شدت توصیه می کنم آن را بخوانید.

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

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

خمیر لاستیکی

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

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

قیچی لاستیکی یک برنامه نویسی برای یک مرد ضعیف است

Newbies

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

جنبه های اجتماعی با استخدام های جدید وجود دارد. برنامه نویسی جفتی بهترین راه برای شناختن همه در طول چرخش جفت است.

افرادی که هرگز این تکنیک را انجام نمی دهند، ابتدا ناراحت کننده می شوند، اما بسیار سریع تنظیم می شوند و جایزه نهایی برای پروژه یا یک شرکت ارتباط بهتر، راحتی و روحیه تیم.

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

افزایش سرعت

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

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

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

توسعه ویلای JavaScript در سال 2018 – یادداشت های مهندس

TL؛ DR: عناصر HTML مانند متغیرهای شیء را در صورت استفاده از document.getElementById () ، document.getElementsByName () یا هر یک از دیگر document.getElement .. () روش ها یا انتخابگرها، کد شما به شدت کنترل فاقد کنترل است و شما آن را اشتباه انجام می دهید.

مقدمه

هنگام استفاده از وانیلا جاوا اسکریپت در سال 2018، باید کنترل کامل داشته باشید هر عنصر DOM در هر زمان، با توانایی به صورت پویا و برنامه نویسی وضعیت هر عنصر را با توجه به منطق کسب و کار شما و الگوریتم های داخلی تغییر می دهد.

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

به عنوان مثال، id ویژگی به سادگی یک ویژگی میراث است، میراث بی فایده است که باید تمیز شود و قطعا در مدرن نرم افزار

یک ظاهر طراحی تنها باید با استفاده از کلاسها انجام شود، یک روش را انتخاب کنید (به عنوان مثال BEM) و به صورت داینامیک با element.classList object property به عنوان متغیر برنامه شما

مثال

برای یک پروژه یا انتصاب کوچک فکر نمی کنم کسی فکر کند که همه کتابخانه ها (React، Vue et cetera) و حتی اشاره به چارچوب ها (Angular، Ember، …) از نظر در نظر گرفته نشده است، وانیلا جاوا اسکریپت را به عنوان انتخاب واضح ارائه می دهد.

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

19659011] برای اهداف تظاهرات اجازه می دهد یک برنامه بسیار ساده با یک شمارنده ایجاد کنید و مقدار آن را 1 بار در هر ثانیه افزایش دهید. این چیزی است که باید آن را تقریبا شبیه:

 کلاس App {
     سازنده () {
این.app = document.createElement ('div')؛
this.startCounter ()؛
این [
)
     شروع کن () {
const counterContainer = document.createElement ('p')؛
const counter = document.createTextNode ('')؛
let initialCounterValue = 0؛
         counterContainer.appendChild (ضد)؛ 

     render () {{19459023}} {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{ 
document.body.appendChild (this.app)؛
}
} 
 برنامه جدید ()؛ 

counter به عنوان یک عنصر HTML با آنچه که در واقع دارد رفتار میکند یک متغیر شی: ما از لحاظ برنامه نویسی آن را ایجاد می کنیم، در مورد آن می دانیم و با خواندن خواص آن با موفقیت تغییر می کنیم:

نتیجه اجرای برنامه

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

 کلاس Counter {
     سازنده () {
این.counterValue = 0؛
این. شمارنده = document.createTextNode ('')؛
}
     getElement () {
if (this.counterContainer)
return this.counterContainer؛
         this.counterContainer = document.createElement ('p '(19459023) {19659028} شروع (initialValue) {
if (initialValue)
this.counterValue (19459023) این [
این.counterContainer.appendChild (this.counter)؛
         return this.counterContainer؛ 
(19459023)}

     stop () {[
) این [تعریف شده است]
اگر (this.interval)
clearInterval (this.interval)؛
}
} 
 export default Counter؛ 

این کلاس ماژول Counter را با 3 روش API در معرض نمایش می دهد: getElement ( ) – عنصر HTML را بازمیگرداند، در این مورد پاراگراف که حاوی یک گره متنی است، ویژگی ارزش که ما از نظر برنامه نویسی کنترل می کنیم.

start (initialValue) – یک روش عمل که شروع می شود و دوباره شروع می شود

stop () – شمارنده ما متوقف می شود، حفظ نقطه توقف، مقدار شمارنده

این بازنویسی برنامه اصلی ما، با استفاده از ما کلاس جدید Counter:

 import counter از './counter'؛ 
 برنامه کلاس {
     constructor () {
this.app = document.createElement (' div ')؛
این. counter ()؛
    } 
     startCounter () {
این).
this.startCounter ()؛
this.stopAndStartCounterAfter3seconds ()؛
     counter.start (1)؛ 
}
     stopAndStartCounterAfter3seconds () {
setTimeout (() => {
this.counter.stop ()؛
this.counter.start (200) ؛
}، 3000)
}
     render () {
this.app.appendChild (this.counter.getElement ())؛
document.body.appendChild (this.app)؛
}
} 
 برنامه جدید ()؛ 
برنامه بازنویسی شده با ماژول Counter جدید

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

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

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

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

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

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

بیایید نگاهی به کار نمونه، رویکرد سنتی و رویکرد با نوع اجبار

وظیفه

ما باید تغییر دینامیک عرض عناصر DOM در یک ظرف بسته به تعداد عناصر وجود دارد، تا اطمینان حاصل شود که آنها تمام عرض کانتینر را جمع می کنند.

حداکثر عناصر 3. اگر ما فقط 2 عنصر داشته باشیم، پس هر یک از آن ها نیاز به عرض 50٪، اگر ما 3 عنصر داشته باشیم، عرض هر عنصر باید 33٪ باشد. البته عنصر تک باید 100٪ عرض را داشته باشد.

ما می دانیم که عنصر توسط پرچم مربوط Boolean وجود دارد.

راه حل CSS زیبا ترین خواهد بود، درست است؟ اما به عنوان مثال، اجازه می دهد تا تصور کنید CSS در سال 1996 گیر کرده است.

رویکرد سنتی

این در مورد زشت است!

آنجا شما بروید:

 بولی  FIRST_ELEMENT؛ 
بولین SECOND_ELEMENT؛
بولی THIRD_ELEMENT؛

رشته عرض؛

// اگر تمام عناصر موجود باشد
اگر (FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
width = '33٪ '؛
}

// اگر 2 عنصر موجود باشد
اگر (FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT) {
width = '50٪'؛
}

اگر (FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
width = '50٪؛
}

if (! FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
width = '50٪ '؛
}

// اگر تنها یک عنصر وجود داشته باشد
اگر (! FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
width = '100٪'؛
}

اگر (FIRST_ELEMENT &&! SECOND_ELEMENT &&! THIRD_ELEMENT) {
width = '100٪'؛
}

if (! FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT) {
width = '100٪'؛
}

این کد کار را انجام می دهد. اما آه پسر .. چیزی که درون من افتاد وقتی وارد آن شدم.

آیا می توانیم با رویکرد سنتی بهتر عمل کنیم؟ من هم اینچنین فکر میکنم. به طور پیش فرض و خلاص شدن از آخرین 3 شرایط:

 رشته  width = '100٪'؛ 

// اگر همه عناصر حضور داشته باشند
اگر (FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
width = '33٪ '؛
}

// اگر 2 عنصر موجود باشد
if (FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT {19459019] width = '50٪ '؛
}

if (FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
width = '50٪؛

اگر (! FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
width = '50٪ '؛
}

این کد هنوز بوی خاصی دارد. ما می توانیم با «بهینه سازی» بیشتر، XOR بیتی را معرفی کنیم، منطق بیشتری اضافه کنیم، مقدار شرایط را کاهش دهیم. سوال این است: آیا قابل خواندن است؟ یا این یکی از آن چیزهایی است که شما را مجبور به نظر دادن برای نسل های آینده می کند تا بدانند که در واقع چه اتفاقی می افتد؟ هنوز هم به نظر می رسد بد است

اکنون اجازه می دهد یکی از ابزارهای موجود در جعبه ابزار ما را ببینید و ببینید که آیا آن را می تواند مفید باشد در اینجا: نوع کوک.

Type Coercion

نوع اجبار یک ویژگی است که به ما امکان تبدیل یک متغیر از یک نوع به دیگری به صورت پویا تحت شرایط خاص است.

در این مورد خاص، ما می توانیم اجباری نوع جاوا اسکریپت را در هنگام انجام عملیات حساب جبرانی بولین به اعداد صحیح بدست آوریم.

تبدیل غلط به 0؛

تبدیل واقعی به 1؛ [19659041] این چگونگی آن در این مثال خاص مفید است:

 رشته  width = '100٪'؛ 
اینتر TOTAL_ELEMENTS = FIRST_ELEMENT + SECOND_ELEMENT + THIRD_ELEMENT؛

if TOTAL_ELEMENTS == 2) {
width = '50٪ '؛
}

if (TOTAL_ELEMENTS == 3) {
width = '33٪'؛
}

قابلیت خوانایی به طور قابل توجهی بهبود یافته است

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

بر خلاف قانون Betteridge از سرفصلها، این را نمی توان با کلمه "نه" پاسخ داد.