Олар айтқандай, егер сіз ескі кодыңыздан ұялмасаңыз, онда сіз бағдарламашы ретінде өспейсіз - мен бұл пікірмен келісемін. Мен 40 жылдан астам уақыт бұрын және кәсіби түрде 30 жыл бұрын қызық үшін бағдарламалауды бастадым, сондықтан менде қателіктер көп. өте көп. Информатика пәнінің профессоры ретінде мен студенттерімді қателіктерден үйренуге үйретемін – олардың, менікі және басқалардың қателерінен. Қарапайымдылығымды жоғалтпау үшін қателіктерімді айтатын кез келді деп ойлаймын. Олар біреуге пайдалы болады деп үміттенемін.

Үшінші орын – Microsoft C компиляторы

Менің мектептегі мұғалімім Ромео мен Джульеттаны трагедия деп санауға болмайтынына сенді, өйткені кейіпкерлердің қайғылы кінәсі жоқ - олар жасөспірімдер сияқты ақымақтық жасады. Мен ол кезде онымен келіспеген едім, бірақ қазір оның пікірінен, әсіресе бағдарламалауға қатысты ұтымдылықтың дәнін көремін.

Мен MIT-тің екінші курсын бітірген кезде мен өмірде де, бағдарламалауда да жас әрі тәжірибесіз едім. Жазда мен Microsoft корпорациясында, C компиляторлар тобында тағылымдамадан өттім.Алғашында профильді қолдау сияқты күнделікті істермен айналыстым, содан кейін маған компилятордың ең қызықты бөлігімен (мен ойлағандай) жұмыс істеуді сеніп тапсырдым - серверді оңтайландыру. Атап айтқанда, мен филиалдық мәлімдемелер үшін x86 кодын жақсартуға тура келді.

Әрбір ықтимал жағдай үшін оңтайлы машина кодын жазуды шешіп, мен өзімді бассейнге тастадым. Егер мәндердің таралу тығыздығы жоғары болса, мен оларды енгіздім ауысу кестесі. Егер олардың ортақ бөлгіші болса, мен оны кестені қатайту үшін қолдандым (бірақ бөлуді пайдалану арқылы жасауға болатын болса ғана) бит жылжу). Барлық мәндер екінің күші болғанда, мен тағы бір оңтайландыру жасадым. Егер мәндер жинағы менің шарттарымды қанағаттандырмаса, мен оны бірнеше оңтайландырылған жағдайларға бөліп, оңтайландырылған кодты қолдандым.

Бұл қорқынышты түс болды. Көптеген жылдар өткен соң маған кодты мұраға алған бағдарламашы мені жек көретінін айтты.

Сабақ алды

Дэвид Паттерсон мен Джон Хеннесси «Компьютерлік архитектура және компьютерлік жүйелерді жобалау» кітабында жазғанындай, сәулет пен дизайнның негізгі принциптерінің бірі - заттарды мүмкіндігінше тезірек жұмыс істеу.

Жалпы істерді жылдамдату сирек жағдайларды оңтайландырудан гөрі өнімділікті тиімдірек арттырады. Бір қызығы, жиі кездесетін жағдайлар сирек кездесетін жағдайларға қарағанда оңайырақ. Бұл логикалық кеңес қай жағдайдың жалпы болып саналатынын білуіңізді болжайды - бұл тек мұқият тексеру және өлшеу процесі арқылы мүмкін болады.

Мен өзімді қорғауда салалық операторлардың іс жүзінде қандай болатынын анықтауға тырыстым (мысалы, қанша тармақ бар және тұрақтылар қалай таралады), бірақ 1988 жылы бұл ақпарат жоқ болды. Дегенмен, ағымдағы компилятор мен ойлап тапқан жасанды мысал үшін оңтайлы кодты жасай алмаған кезде арнайы жағдайларды қоспауым керек еді.

Маған тәжірибелі әзірлеушіге қоңырау шалып, онымен бірге жалпы жағдайлардың не екенін ойлап, олармен арнайы айналысу керек болды. Мен азырақ код жазар едім, бірақ бұл жақсы нәрсе. Stack Overflow негізін қалаушы Джефф Этвуд жазғандай, бағдарламашының ең қас жауы – бағдарламашының өзі:

Білемін, бәріміз сияқты сіздің де ниетіңіз жақсы. Біз бағдарламалар жасаймыз және код жазғанды ​​жақсы көреміз. Біз осылай жаратылғанбыз. Кез келген мәселені скотчпен, қолдан жасалған балдақпен және бір шымшым кодпен шешуге болады деп ойлаймыз. Кодерлерге оны мойындау қаншалықты қиын болса да, ең жақсы код - жоқ код. Әрбір жаңа жолды түзету және қолдау қажет, оны түсіну керек. Жаңа кодты қосқанда, мұны қалаусыз және жиіркенішпен жасауыңыз керек, өйткені барлық басқа опциялар таусылды. Көптеген бағдарламашылар тым көп код жазады, бұл оны біздің жауымызға айналдырады.

Егер мен жалпы жағдайларды қамтитын қарапайым кодты жазған болсам, қажет болған жағдайда жаңарту әлдеқайда оңай болар еді. Мен артымда ешкіммен айналысқысы келмейтін бейберекеттік қалдырды.

Екінші орын: әлеуметтік желілердегі жарнама

Мен Google-да әлеуметтік медиа жарнамасында жұмыс істегенімде (Myspace есіңізде ме?), Мен 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)) {
  }
}

Бағдарламашылар қатені бірден көруі мүмкін: соңғы аргумент i емес, j болуы керек. Бірлікті тестілеу қатені ашпады және менің шолушым да ашпады. Іске қосу жүзеге асырылды және бір түнде менің кодым серверге түсіп, деректер орталығындағы барлық компьютерлерді бұзды.

Жаман ештеңе болған жоқ. Ешкімге ештеңе бұзбады, өйткені жаһандық іске қосу алдында код бір деректер орталығында сынақтан өтті. Егер SRE инженерлері біраз уақытқа бильярд ойнауды тоқтатып, аздап кері қайтпаса. Келесі күні таңертең мен ақаулық қалдығы бар электрондық хат алдым, кодты түзетіп, қатені анықтайтын бірлік сынақтарын қостым. Мен хаттаманы ұстанғандықтан - әйтпесе менің кодым орындалмай қалады - басқа проблемалар болмады.

Сабақ алды

Көптеген адамдар мұндай үлкен қателік кінәлі жұмыстан босатылатынына сенімді, бірақ олай емес: біріншіден, барлық бағдарламашылар қателеседі, екіншіден, олар бір қатені екі рет сирек жасайды.

Шындығында, менің тамаша инженер болған және бір қателік жібергені үшін жұмыстан шығарылған бағдарламашы досым бар. Осыдан кейін ол Google-ға жұмысқа қабылданды (және көп ұзамай көтерілді) - ол сұхбатында жіберген қателігі туралы шынайы айтты және бұл өлімге әкелетін деп саналмады.

Міне, бұл айту IBM компаниясының аты аңызға айналған басшысы Томас Уотсон туралы:

Бір миллион долларға жуық мемлекеттік тапсырыс жарияланды. IBM корпорациясы - дәлірек айтсақ, Томас Уотсон аға - оны шынымен алғысы келді. Өкінішке орай, сату өкілі мұны істей алмады және IBM ұсынысты жоғалтты. Келесі күні бұл қызметкер Уотсон мырзаның кеңсесіне келіп, оның үстеліне конверт қойды. Мистер Уотсон оған қарап әуре болған жоқ – ол қызметкерді күтіп, оның жұмыстан кету туралы хат екенін білді.

Уотсон не болғанын сұрады.

Сауда өкілі тендердің барысы туралы егжей-тегжейлі айтып берді. Ол болдырмауға болатын қателіктерді атады. Соңында ол: «Уотсон мырза, маған түсіндіруге рұқсат бергеніңіз үшін рахмет. Бұл тапсырыс бізге қаншалықты қажет екенін білемін. Мен оның қаншалықты маңызды екенін білемін», - деді де, кетуге дайындалды.

Уотсон есікке жақындап, оның көзіне қарап, конвертті қайтарып берді: «Мен сені қалай жібере аламын? Мен сіздің біліміңізге миллион доллар салдым.

Менің футболкам бар: «Егер сіз шынымен қателіктерден сабақ алсаңыз, мен қазірдің өзінде шебермін». Негізі, қателіктерге келсек, мен ғылым докторымын.

Бірінші орын: App Inventor API

Шынымен қорқынышты қателер көптеген пайдаланушыларға әсер етеді, жалпыға мәлім болады, түзетуге көп уақыт кетеді және оларды жасай алмағандар жасайды. Менің ең үлкен қателігім осы критерийлердің барлығына сәйкес келеді.

Неғұрлым нашар болса, соғұрлым жақсы

Мен оқыдым Ричард Габриэльдің эссесі Бұл тәсіл туралы тоқсаныншы жылдардағы аспирантура және маған ұнағаны сонша, оны студенттеріме де сұраймын. Есіңізде жақсы болмаса, жадыңызды жаңартыңыз, ол кішкентай. Бұл эссе көптеген жолдармен, соның ішінде қарапайымдылықты қоса алғанда, «дұрыс алуға» деген ұмтылысты және «жаманырақ - жақсы» көзқарасты салыстырады.

Бұл қалай болуы керек: дизайн іске асыру және интерфейсте қарапайым болуы керек. Интерфейстің қарапайымдылығы іске асырудың қарапайымдылығынан маңыздырақ.

Неғұрлым нашар болса, соғұрлым жақсы: дизайн іске асыруда және интерфейсте қарапайым болуы керек. Іске асырудың қарапайымдылығы интерфейстің қарапайымдылығынан маңыздырақ.

Мұны бір минутқа ұмытайық. Өкінішке орай, мен оны көп жылдар бойы ұмытып кеттім.

Қолданба өнертапқышы

Google-да жұмыс істеген кезде мен команданың бір бөлігі болдым Қолданба өнертапқышы, Android әзірлеушілеріне арналған сүйреп апаратын онлайн әзірлеу ортасы. Бұл 2009 жыл еді, жазда күзде сабақ бергенде ортаны пайдалана алатын мұғалімдерге шеберлік сабағын өткізу үшін альфа нұсқасын дер кезінде шығаруға асықтық. Мен TI-99/4-те ойын жазғаныма сағынышпен спрайттарды енгізуге ерікті болдым. Білмейтіндер үшін спрайт екі өлшемді графикалық нысан болып табылады, ол қозғала алады және басқа бағдарламалық жасақтама элементтерімен өзара әрекеттеседі. Спрайттардың мысалдарына ғарыш кемелері, астероидтар, мәрмәр және ракеткалар жатады.

Біз Java-да нысанға бағытталған App Inventor бағдарламасын іске асырдық, сондықтан онда бірнеше нысандар бар. Шарлар мен спрайттардың әрекеті өте ұқсас болғандықтан, мен X, Y, Жылдамдық (жылдамдық) және Тақырып (бағыт) қасиеттері (өрістері) бар дерексіз спрайт класын жасадым. Оларда соқтығысуды, экранның шетінен серпілуді және т.б. анықтау әдістері бірдей болды.

Доп пен спрайттың негізгі айырмашылығы - дәл сызылған нәрсе - толтырылған шеңбер немесе растр. Мен алдымен спрайттарды іске асырғандықтан, кескін орналасқан жердің жоғарғы сол жақ бұрышының x және y координаталарын көрсету қисынды болды.

Спрайттар жұмыс істегеннен кейін, мен өте аз кодпен доп нысандарын жүзеге асыра аламын деп шештім. Жалғыз мәселе, мен шарды жақтайтын контурдың жоғарғы сол жақ бұрышының x және y координаттарын көрсете отырып, ең қарапайым жолды (орындаушының көзқарасы бойынша) қабылдадым.

Шындығында, кез келген математика оқулығында және шеңберлер туралы кез келген басқа дереккөздерде үйретілгендей, шеңбер центрінің х және у координаталарын көрсету қажет болды.

Менің бұрынғы қателіктерімнен айырмашылығы, бұл менің әріптестеріме ғана емес, сонымен қатар миллиондаған App Inventor пайдаланушыларына әсер етті. Олардың көпшілігі балалар немесе бағдарламалауға мүлдем жаңадан келген. Олар доп бар әрбір қолданбада жұмыс істегенде көптеген қажетсіз қадамдарды орындауға мәжбүр болды. Басқа қателіктерімді күліп есіме алсам, бүгінде осы қателігім мені терлейді.

Мен бұл қатені жақында ғана, он жылдан кейін түзетіп қойдым. Джошуа Блох айтқандай, API интерфейстері мәңгілік болғандықтан, «түзетілген» емес, «жамалған». Қолданыстағы бағдарламаларға әсер ететін өзгертулер енгізу мүмкін болмады, біз OriginAtCenter сипатын ескі бағдарламаларда false және болашақтағылардың барлығында true мәнімен қостық. Пайдаланушылар логикалық сұрақ қоюы мүмкін: кім тіпті бастапқы нүктені орталықтан басқа жерде орналастыруды ойлады. Кімге? Он жыл бұрын қалыпты API құруға жалқау болған бір бағдарламашыға.

Алынған сабақтар

API интерфейстерімен жұмыс істегенде (кейде кез келген бағдарламашы істеуге тура келеді), сіз Джошуа Блохтың бейнесіндегі ең жақсы кеңестерді орындауыңыз керек «Жақсы API қалай жасауға болады және ол неге маңызды«Немесе осы қысқа тізімде:

• API сізге үлкен пайда да, үлкен зиян да әкелуі мүмкін.. Жақсы API қайталанатын тұтынушыларды жасайды. Жаман адам сіздің мәңгілік қорқынышыңызға айналады.
• Алмаз сияқты жалпыға ортақ API интерфейстері мәңгілікке созылады. Барлығыңызды беріңіз: бәрін дұрыс істеуге басқа мүмкіндік ешқашан болмайды.
• API контурлары қысқаша болуы керек — бір жолдан аспайтын сынып және әдіс қолтаңбалары мен сипаттамалары бар бір бет. Бұл бірінші рет мінсіз болып шықпаса, API құрылымын оңай қайта құруға мүмкіндік береді.
• Қолдану жағдайларын сипаттаңызAPI енгізгенге дейін немесе тіпті оның спецификациясымен жұмыс істемес бұрын. Осылайша сіз толық жұмыс істемейтін API енгізуден және көрсетуден аулақ боласыз.

Егер мен тіпті жасанды сценариймен қысқаша конспект жазған болсам, мен қатені анықтап, оны түзететін едім. Әйтпесе, менің әріптестерімнің бірі мұны міндетті түрде жасайтын еді. Ауқымды салдары бар кез келген шешімді кем дегенде бір күн ойлану керек (бұл тек бағдарламалауға ғана қатысты емес).

Ричард Габриэльдің «Неғұрлым нашар болса, жақсырақ» эссесінің тақырыбы нарыққа бірінші болып шығудың артықшылығын білдіреді, тіпті жетілмеген өнім болса да, басқа біреу мәңгілік мінсізді қуып өтеді. Спрайт коды туралы ойлана отырып, мен оны дұрыс алу үшін қосымша код жазудың қажеті жоқ екенін түсіндім. Біреу не десе де, мен қатты қателесіппін.

қорытынды

Бағдарламашылар қате кодты жазуда немесе олардың шеберлігі мен өнімділігін арттыратын нәрсені көргісі келмесе де, күн сайын қателеседі. Әрине, мен сияқты өрескел қателіктер жібермей-ақ бағдарламашы бола аласыз. Бірақ қателіктеріңді мойындамай, одан сабақ алмай жақсы бағдарламашы болу мүмкін емес.

Мен үнемі тым көп қателік жіберетіндей сезінетін, сондықтан бағдарламалауға дайын емес студенттерді кездестіремін. Мен IT-да алдамшы синдромның қаншалықты жиі кездесетінін білемін. Сіз мен санап өткен сабақтарды үйренесіз деп үміттенемін - бірақ бастысын есте сақтаңыз: әрқайсымыз қателесеміз - ұятсыз, күлкілі, қорқынышты. Болашақта мақаланы жалғастыруға материал жетпесе, таң қаламын және ренжітемін.

Ақпарат көзі: www.habr.com