لکه څنګه چې دوی وايي، که تاسو د خپل زوړ کوډ څخه شرم نه لرئ، نو تاسو د پروګرامر په توګه وده نه کوئ - او زه د دې نظر سره موافق یم. ما 40 کاله دمخه د ساتیرۍ لپاره برنامه پیل کړه ، او په مسلکي توګه 30 کاله دمخه ، نو زه ډیری غلطۍ لرم. ډېر. د کمپیوټر ساینس د پروفیسور په توګه، زه خپلو زده کونکو ته درس ورکوم چې له تیروتنو څخه زده کړي - د دوی، زما او نورو څخه. زه فکر کوم چې دا وخت دی چې د خپلو غلطیو په اړه وغږیږم ترڅو زما حیا له لاسه ورنکړي. زه امید لرم چې دوی به د یو چا لپاره ګټور وي.

دریم ځای - د مایکروسافټ C کمپیلر

زما د ښوونځي ښوونکي په دې باور وو چې رومیو او جولیټ یوه تراژیدي نه ګڼل کیدی ځکه چې کرکټرونو هیڅ غمجنه ګناه نه درلوده - دوی په ساده ډول د ناپوهۍ چلند کوي، لکه څنګه چې ځوانان باید. زه هغه مهال له هغه سره موافق نه وم، مګر اوس زه د هغه په ​​​​نظر کې د معقولیت یوه ذره وینم، په ځانګړې توګه د پروګرام کولو په اړه.

په هغه وخت کې چې ما په MIT کې خپل سوفومور کال پای ته ورساوه، زه ځوان او بې تجربه وم، دواړه په ژوند او پروګرام کولو کې. په اوړي کې، ما په مایکروسافټ کې د C کمپیلر ټیم کې داخل شوم. په لومړي سر کې ما معمول کارونه لکه د پروفایل کولو مالتړ ترسره کړل، او بیا ما ته د کمپیلر په خورا ساتیرۍ برخه کې کار کولو دنده وسپارل شوه (لکه څنګه چې ما فکر کاوه) - backend optimization. په ځانګړې توګه، ما باید د شاخ بیانونو لپاره x86 کوډ ته وده ورکړي.

د هرې ممکنې قضیې لپاره د غوره ماشین کوډ لیکلو هوډ وکړ، ما خپل ځان د حوض سر ته وغورځاوه. که د ارزښتونو د توزیع کثافت لوړ و، ما دوی ته داخل کړل د لیږد میز. که دوی یو عام ویشونکی درلود، ما دا د میز سخت کولو لپاره کارولی و (مګر یوازې هغه وخت چې ویش د کارولو سره ترسره کیدی شي لږ بدلون). کله چې ټول ارزښتونه د دوو قوتونو وو، ما یو بل اصلاح وکړه. که د ارزښتونو سیټ زما شرایط پوره نه کړي ، ما دا په څو مطلوبو قضیو ویشلي او دمخه مطلوب کوډ یې کارولی.

دا یو خوب و. ډیری کلونه وروسته ما ته وویل شول چې هغه پروګرامر چې زما کوډ یې په میراث کې دی زما څخه نفرت کوي.

درس زده کړل

لکه څنګه چې ډیویډ پیټرسن او جان هینسي د کمپیوټر آرکیټیکچر او کمپیوټر سیسټمونو ډیزاین کې لیکي ، د معمارۍ او ډیزاین یو له اصلي اصولو څخه دا دی چې عموما شیان ژر تر ژره کار وکړي.

د عامو قضیو ګړندی کول به د نادرو قضیو د اصلاح کولو په پرتله په مؤثره توګه فعالیت ته وده ورکړي. په حیرانتیا سره، عام قضیې اکثرا د نادرو په پرتله ساده دي. دا منطقي مشوره فرض کوي چې تاسو پوهیږئ کوم قضیه عام ګڼل کیږي - او دا یوازې د محتاط ازموینې او اندازه کولو پروسې له لارې ممکنه ده.

زما په دفاع کې، ما هڅه وکړه چې معلومه کړم چې د څانګو بیانات په عمل کې څه ډول ښکاري (لکه څومره څانګې شتون لري او څومره ثابت ویشل شوي)، مګر په 1988 کې دا معلومات شتون نلري. په هرصورت، زه باید ځانګړې قضیې اضافه نه کړم کله چې اوسنی کمپیلر نشي کولی د مصنوعي مثال لپاره غوره کوډ تولید کړي چې زه ورسره راغلی یم.

ما اړتیا درلوده چې یو تجربه لرونکي پراختیا کونکي ته زنګ ووهم او د هغه سره یوځای د دې په اړه فکر وکړم چې عام قضیې څه وې او په ځانګړي ډول ورسره معامله وکړئ. زه به لږ کوډ ولیکم، مګر دا یو ښه شی دی. لکه څنګه چې د Stack Overflow بنسټ ایښودونکی جیف اتوډ لیکلي، د پروګرام کونکي ترټولو بد دښمن پخپله پروګرامر دی:

زه پوهیږم چې تاسو ښه نیت لرئ، لکه څنګه چې موږ ټول. موږ پروګرامونه جوړوو او د کوډ لیکلو سره مینه لرو. په دې توګه موږ جوړ شوي یو. موږ فکر کوو چې هره ستونزه د ډیک ټیپ ، د کور جوړ شوي کرچ او د کوډ یو چټک سره حل کیدی شي. څومره چې دا د اعتراف کولو لپاره کوډر درد کوي ، غوره کوډ هغه کوډ دی چې شتون نلري. هره نوې کرښه ډیبګ کولو او ملاتړ ته اړتیا لري، دا باید پوه شي. کله چې تاسو نوی کوډ اضافه کړئ، تاسو باید دا په زړه پورې او کرکه سره وکړئ ځکه چې نور ټول اختیارونه ختم شوي. ډیری پروګرام کونکي ډیر کوډ لیکي، دا زموږ دښمن جوړوي.

که ما ساده کوډ لیکلی وای چې عام قضیې پکې پوښلي ، نو د اړتیا په صورت کې به تازه کول خورا اسانه وو. ما یو خندا پریښوده چې هیڅوک نه غوښتل ورسره معامله وکړي.

دوهم ځای: په ټولنیزو شبکو کې اعلانونه

کله چې ما په ګوګل کې د ټولنیزو رسنیو اعلاناتو کې کار کاوه (مایسپیس په یاد ولرئ؟)، ما په C++ کې داسې یو څه لیکلي:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

پروګرام کونکي ممکن سمدلاسه تېروتنه وګوري: وروستی دلیل باید j وي، نه i. د واحد ازموینې تېروتنه ونه کړه، او نه زما بیاکتونکي. لانچ ترسره شو، او یوه شپه زما کوډ سرور ته لاړ او د ډیټا مرکز کې ټول کمپیوټرونه یې خراب کړل.

هیڅ بد ندی پیښ شوی. د هیچا لپاره هیڅ شی مات نه شو ، ځکه چې د نړیوال لانچ دمخه کوډ په یوه ډیټا مرکز کې ازمول شوی و. پرته لدې چې د SRE انجینرانو د یو څه وخت لپاره د بلیرډ لوبې بندې کړې او یو څه رول بیک یې وکړ. بل سهار ما د کریش ډمپ سره بریښنالیک ترلاسه کړ ، کوډ یې سم کړ او د واحد ازموینې یې اضافه کړې چې خطا به ونیسي. له هغه ځایه چې ما پروتوکول تعقیب کړ - که نه نو زما کوډ به په ساده ډول په چلولو کې پاتې راشي - نورې ستونزې شتون نلري.

درس زده کړل

ډیری ډاډه دي چې دا ډول لویه تېروتنه به یقینا د مجرم ګوښه کولو لګښت ولري، مګر دا داسې نه ده: لومړی، ټول پروګرام کونکي غلطي کوي، او دویم، دوی په ندرت سره ورته غلطي دوه ځله کوي.

په حقیقت کې، زه یو پروګرامر ملګری لرم چې یو تکړه انجنیر و او د یوې غلطۍ کولو لپاره له دندې ګوښه شوی و. له هغې وروسته، هغه په ​​​​ګوګل کې وګمارل شو (او ډیر ژر یې وده ورکړه) - هغه په ​​​​صداقت سره د هغه غلطی په اړه خبرې وکړې چې په مرکه کې یې کړې، او دا وژونکي نه ګڼل کیږي.

دا هغه څه دي ووایه د IBM افسانوي مشر توماس واټسن په اړه:

د شاوخوا یو ملیون ډالرو په ارزښت د حکومت امر اعلان شو. د IBM کارپوریشن - یا بلکه، توماس واټسن سینیر په شخصي توګه - واقعیا غوښتل چې دا ترلاسه کړي. له بده مرغه، د پلور استازی ونه توانید چې دا کار وکړي او IBM داوطلبي له لاسه ورکړه. بله ورځ، دا کارمند د ښاغلي واټسن دفتر ته راغی او د هغه په ​​میز کې یې یو لفافه کېښوده. ښاغلي واټسن حتی دې ته د کتلو زحمت هم ونه کړ - هغه د یو کارمند په تمه و او پوهیده چې دا د استعفا لیک و.

واټسن وپوښتل چې څه غلط شوي.

د پلور نماینده د داوطلبۍ د پرمختګ په اړه په تفصیل سره خبرې وکړې. هغه د هغو تېروتنو نومونه واخیستل چې کیدای شي مخنیوی یې وشي. په پای کې، هغه وویل، "ښاغلی واټسن، مننه چې ما ته یې تشریح کړه. زه پوهیږم چې موږ دې امر ته څومره اړتیا لرو. زه پوهیږم چې هغه څومره مهم و، "او د وتلو لپاره چمتو شو.

واټسن په دروازه کې هغه ته نږدې شو، سترګو ته یې وکتل او لفافه یې په دې ټکي سره بیرته راستانه کړه: "زه څنګه کولی شم چې تاسو پریږدم؟ ما یوازې ستاسو په تعلیم کې یو ملیون ډالر پانګونه کړې.

زه یو ټی شرټ لرم چې وايي: "که تاسو واقعیا له تیروتنو زده کړئ ، نو زه دمخه ماسټر یم." په حقیقت کې، کله چې د غلطیو خبره راځي، زه د ساینس ډاکټر یم.

لومړی ځای: د اپلیکیشن اختراع API

په ریښتیا ناوړه غلطیان د کاروونکو لوی شمیر اغیزه کوي، عامه پوهه کیږي، د سمولو لپاره ډیر وخت نیسي، او د هغو کسانو لخوا رامینځ ته کیږي چې نشي کولی دوی جوړ کړي. زما لویه تېروتنه د دې ټولو معیارونو سره سمون لري.

څومره چې بد وي هغومره ښه

ما لوستل د ریچارډ ګابریل لخوا مقاله د دې تګلارې په اړه په نولسمه لسیزه کې د یو فارغ شوي زده کونکي په توګه، او زه دا خورا خوښوم چې زه یې له خپلو زده کونکو څخه وپوښتم. که مو ښه په یاد نه وي، خپل حافظه مو تازه کړئ، دا کوچنۍ ده. دا مقاله په ډیری لارو کې د "دا سم ترلاسه کولو" او "بدتر غوره" طریقې سره توپیر لري، په شمول د سادگي.

دا باید څنګه وي: ډیزاین باید په پلي کولو او انٹرفیس کې ساده وي. د انٹرفیس سادگي د پلي کولو سادگي څخه ډیر مهم دی.

بدتر، ښه: ډیزاین باید په تطبیق او انٹرفیس کې ساده وي. د پلي کولو سادگي د انٹرفیس له سادګۍ څخه خورا مهم دی.

راځئ چې د یوې دقیقې لپاره دا هیر کړو. له بده مرغه، ما د ډیرو کلونو لپاره د هغې په اړه هیر کړی.

د ایپ اختراع کونکی

په ګوګل کې د کار کولو پرمهال، زه د ټیم برخه وم د ایپ اختراع کونکی, د انډرایډ پراختیا غوښتونکو لپاره د آنلاین پراختیا چاپیریال د ډریګ او ډراپ. دا د 2009 کال و، او موږ په بیړه کې وو چې د الفا نسخه په وخت سره خپره کړو ترڅو په دوبي کې موږ وکولی شو د ښوونکو لپاره ماسټر ټولګي جوړ کړو چې کولی شي د مني په وخت کې د تدریس پرمهال چاپیریال وکاروي. ما په رضاکارانه ډول د سپرایټس پلي کولو لپاره کار وکړ، د دې لپاره چې څنګه ما په TI-99/4 کې لوبې لیکلې، نوسټالیژیک. د هغو کسانو لپاره چې نه پوهیږي، سپریټ یو دوه اړخیز ګرافیکي څیز دی چې کولی شي حرکت وکړي او د نورو سافټویر عناصرو سره اړیکه ونیسي. د سپریټونو په مثالونو کې سپیس شپونه، اسټروایډونه، ماربلونه او ریکټونه شامل دي.

موږ په جاوا کې د اعتراض پر بنسټ اپلیکیشن اختراع پلي کړ، نو هلته یوازې د شیانو یوه ډله شتون لري. څرنګه چې بالونه او سپریټونه ډیر ورته چلند کوي، ما د ځانګړتیاوو (فیلډونو) X، Y، سرعت (سرعت) او سرلیک (لارښود) سره د خلاصې سپریټ ټولګي رامینځته کړه. دوی د ټکرونو کشف کولو ، د سکرین څنډې ته اچولو او داسې نورو لپاره ورته میتودونه درلودل.

د بال او سپریټ تر مینځ اصلي توپیر هغه څه دي چې واقعیا رسم شوي - یوه ډکه دایره یا راسټر. څرنګه چې ما لومړی sprites تطبیق کړ، نو دا منطقي وه چې د پورتنۍ کیڼ اړخ x- او y- همغږي مشخص کړئ چیرې چې عکس موقعیت لري.

یوځل چې سپریټس کار کاوه ، ما پریکړه وکړه چې زه کولی شم د بال توکي د خورا لږ کوډ سره پلي کړم. یوازینۍ ستونزه دا وه چې ما ترټولو ساده لاره ونیوله (د پلي کونکي له نظره) ، د بال چوکاټ کولو د کنټور د پورتنۍ کیڼ کونج x- او y- همغږي په ګوته کوي.

په حقیقت کې، دا اړینه وه چې د حلقې د مرکز x- او y- همغږي په ګوته کړي، لکه څنګه چې د ریاضیاتو په هر درسي کتاب کې تدریس شوي او کومې بلې سرچینې چې حلقې ته اشاره کوي.

زما د تیرو تیروتنو برعکس، دا نه یوازې زما همکاران، بلکې په میلیونونو د اپلیکیشن اختراع کونکي کاروونکي هم اغیزمن کړي. ډیری یې ماشومان وو یا په بشپړ ډول د پروګرام کولو لپاره نوي وو. دوی باید ډیری غیر ضروري مرحلې ترسره کړي کله چې په هر غوښتنلیک کار کوي چیرې چې بال شتون درلود. که په خندا سره خپلې نورې تېروتنې را په یاد کړم، نو نن هم دا خویندي.

ما په نهایت کې دا بګ یوازې پدې وروستیو کې ، لس کاله وروسته پیچ کړ. "پیچ شوی"، نه "ثابت شوی"، ځکه چې لکه څنګه چې جوشوا بلوچ وايي، APIs ابدي دي. د هغو بدلونونو په کولو کې ناتوانه شوي چې په موجوده برنامو اغیزه وکړي، موږ د OriginAtCenter ملکیت په زړو برنامو کې د غلط ارزښت سره اضافه کړ او په راتلونکو ټولو کې ریښتیا. کاروونکي ممکن منطقي پوښتنه وکړي: چا حتی د مرکز څخه پرته بل چیرې د پیل ټکي ځای په ځای کولو فکر کاوه. چاته؟ یو پروګرامر ته چې لس کاله دمخه د نورمال API جوړولو لپاره ډیر سست و.

درسونه زده کړل

کله چې په APIs کار کول (کوم چې نږدې هر پروګرامر ځینې وختونه باید ترسره کړي) ، تاسو باید د جوشوا بلوچ ویډیو کې بیان شوي غوره مشورې تعقیب کړئ "څنګه یو ښه API جوړ کړئ او ولې دا خورا مهم دی"یا په دې لنډ لیست کې:

• یو API کولی شي تاسو ته لوی ګټې او لوی زیان دواړه راوړي.. یو ښه API تکرار پیرودونکي رامینځته کوي. بد ستاسو ابدي خوبونه کیږي.
• عامه APIs، لکه الماس، د تل لپاره پای ته رسیږي. دا خپل ټول ورکړئ: هیڅکله به د هرڅه سم کولو لپاره بل فرصت شتون ونلري.
• د API توضیحات باید لنډ وي - یو پاڼه د ټولګي او میتود لاسلیکونو او توضیحاتو سره، د یوې کرښې څخه زیات نه اخلي. دا به تاسو ته اجازه درکړي چې API په اسانۍ سره تنظیم کړئ که چیرې دا لومړی ځل بشپړ نه وي.
• د کارونې قضیې تشریح کړئد API پلي کولو دمخه یا حتی د دې مشخصاتو باندې کار کول. پدې توګه تاسو به د بشپړ غیر فعال API پلي کولو او مشخص کولو څخه مخنیوی وکړئ.

که ما د مصنوعي سکریپټ سره حتی یو لنډ لنډیز هم لیکلی وای، ډیر احتمال به ما غلطی په نښه کړی وای او اصلاح به یې کړی وای. که نه، نو زما یو همکار به خامخا دا کار کوي. هره پریکړه چې لیرې پایلې لري باید لږترلږه د یوې ورځې لپاره فکر وشي (دا نه یوازې په برنامه پلي کیږي).

د ریچارډ ګابریل د مقالې سرلیک، "بدتر ښه دی،" هغه ګټې ته اشاره کوي چې بازار ته د لومړي کیدو لپاره ځي - حتی د یو نامناسب محصول سره - پداسې حال کې چې بل څوک د بشپړ محصول تعقیب لپاره تل پاتې وي. د سپرایټ کوډ په پام کې نیولو سره، زه پوهیږم چې ما حتی د دې د سمولو لپاره نور کوډ لیکلو ته اړتیا نه درلوده. هرڅه چې یو څوک ووایی، زه په کلکه غلط وم.

پایلې

پروګرام کونکي هره ورځ تېروتنې کوي، که دا د بګی کوډ لیکل وي یا نه غواړي چې یو څه هڅه وکړي چې د دوی مهارت او تولید ته وده ورکړي. البته، تاسو کولی شئ د داسې جدي غلطیو کولو پرته پروګرامر شئ لکه څنګه چې ما کړې. مګر دا ناشونې ده چې ستاسو د غلطیو پیژندلو او له دوی څخه زده کړې پرته یو ښه پروګرامر شئ.

زه په دوامداره توګه د زده کونکو سره مخ کیږم چې داسې احساس کوي چې دوی ډیرې غلطۍ کوي او له همدې امله د پروګرام کولو لپاره نه پریښودل کیږي. زه پوهیږم چې په آی ټي کې څومره عام امپوسټر سنډروم دی. زه امید لرم چې تاسو به هغه درسونه زده کړئ چې ما لیست کړي دي - مګر اصلي په یاد ولرئ: موږ هر یو غلطي کوو - شرمنده، مسخره، ډارونکي. زه به حیران او خپه شم که په راتلونکي کې زه د مقالې دوام لپاره کافي مواد ونه لرم.

سرچینه: www.habr.com