(Бұл мақала NEPLS-тің 2002 жылғы күзгі жиналысында жасалған баяндамаға негізделген.)
Бұл елге келген қонақтар америкалықтардың әңгімені көбіне «немен айналысасыз?» деген сұрақтан бастайтынына жиі таңғалады. Маған бұл сұрақ ешқашан ұнаған емес. Оған ешқашан нақты әрі жатық жауабым да болмаған. Бірақ ақыры бұл мәселенің шешімін тапқан сияқтымын. Қазір біреу менен немен айналысатынымды сұраса, көзіне тура қарап: «Lisp-тің жаңа диалектісінің дизайнын жасап жатырмын», — деймін. Немен айналысатынын сұрағанды ұнатпайтындардың бәріне осы жауапты ұсынамын. Әңгіме бірден басқа тақырыпқа ауысып кетеді.
Мен өзімді бағдарламалау тілдері бойынша ғылыми зерттеу жасап жүрмін деп санамаймын. Біреу ғимараттың, орындықтың немесе жаңа қаріптің дизайнын жасағандай, мен жай ғана тіл дизайнын жасап жатырмын. Мен қандай да бір жаңа нәрсе ашуға тырысып жатқан жоқпын. Мен тек бағдарлама жазуға ыңғайлы тіл жасағым келеді. Қайсыбір жағынан, мұндай көзқарас өмірді әлдеқайда жеңілдетеді.
Дизайн мен зерттеу арасындағы айырмашылық жаңа мен жақсының арасындағы мәселе сияқты. Дизайн міндетті түрде жаңа болуы шарт емес, бірақ ол жақсы болуы керек. Зерттеу міндетті түрде жақсы болуы шарт емес, бірақ ол жаңа болуы керек. Бұл екі жол ең биікте бір-бірімен тоғысады деп ойлаймын: үздік дизайн жаңа идеяларды пайдалана отырып, өзінен бұрынғылардан асып түседі, ал үздік зерттеу тек жаңа ғана емес, шынымен де шешуге тұрарлық мәселелерді шешеді. Сондықтан, сайып келгенде, біз бір ғана межеге ұмтыламыз, тек оған әртүрлі бағыттан келеміз.
Бүгін мен сіздердің нысаналарыңыз сырт көзге қалай көрінетіні туралы айтамын. Бағдарламалау тілдеріне зерттеу тақырыбы емес, дизайн мәселесі ретінде қараған кезде нені басқаша жасайсыз?
Ең үлкен айырмашылық — қолданушыға көбірек көңіл бөлесіз. Дизайн мына сұрақтардан басталады: бұл кім үшін және оларға бұдан не қажет? Мәселен, жақсы сәулетші өз дизайнын жасап алып, оны қолданушыларға таңудан бастамайды, керісінше, болашақ қолданушыларды зерттеп, оларға не қажет екенін түсінуден бастайды.
Байқасаңыздар, мен «олар не қалайды» емес, «оларға не қажет» дедім. Мен дизайнер ретінде жұмыс істеу клиенттің айтқанын ғана жасайтын аспаз болу дегенді білдіреді деген әсер қалдырғым келмейді. Бұл өнердің әр саласында әртүрлі, бірақ ешбір салада ең үздік туындыларды тұтынушылардың айтқанын бұлжытпай орындайтын адамдар жасайды деп ойламаймын.
Тұтынушы әрқашан дұрыс, бірақ ол тек жақсы дизайнның өлшемі қолданушы үшін қаншалықты тиімді жұмыс істейтінінде ғана. Егер сіз бәрінің зығырданын қайнататын роман жазсаңыз немесе отыруға сұмдық ыңғайсыз орындық жасасаңыз, онда сіз жұмысыңызды нашар орындадыңыз, бітті. Бұл роман немесе орындық ең озық теориялық қағидаларға сәйкес жасалған деп ақталудың еш мәні жоқ.
Десе де, қолданушыға тиімді дүние жасау жай ғана қолданушының айтқанын орындау дегенді білдірмейді. Қолданушылар қандай таңдаулар бар екенін толық білмейді және өздерінің шынымен нені қалайтыны туралы жиі қателеседі.
Бұл парадокстың шешімі, меніңше, мынада: сіз қолданушы үшін дизайн жасауыңыз керек, бірақ оның айтқан қалауын емес, оған шынымен не қажет екенін жасауыңыз тиіс. Бұл дәрігер болуға өте ұқсайды. Сіз науқастың тек симптомдарын ғана емдей алмайсыз. Науқас өзінің симптомдарын айтқан кезде, оның шын мәнінде неден ауырып тұрғанын анықтап, соны емдеуіңіз керек.
Қолданушыға осылайша көңіл бөлу — жақсы дизайн практикасының басым бөлігі туындайтын және көбіне дизайн мәселелері тоғысатын өзіндік бір аксиома.
Егер жақсы дизайн қолданушыға қажет нәрсені істеуі керек болса, онда қолданушы кім? Мен дизайн қолданушылар үшін жасалуы тиіс дегенде, жақсы дизайн қандай да бір ең төменгі ортақ бөлгішке бағытталуы керек дегенді меңзеп тұрған жоқпын. Қолданушылар тобын қалауыңызша таңдай аласыз. Мысалы, егер сіз құралдың дизайнын жасап жатсаңыз, оны жаңадан бастаушылардан бастап сарапшыларға дейінгі кез келген аудиторияға арнап жасай аласыз, ал бір топ үшін жақсы болған дизайн екінші топ үшін нашар болуы мүмкін. Ең бастысы, қандай да бір қолданушылар тобын таңдауыңыз керек. Меніңше, белгілі бір көзделген қолданушыға сүйенбейінше, дизайнның жақсы немесе жаман екендігі туралы тіпті сөз қозғау мүмкін емес.
Егер көзделген қолданушылар қатарында дизайнердің өзі болса, онда жақсы дизайн шығу ықтималдығы ең жоғары болады. Өзіңіз кірмейтін топ үшін бірдеңе жасағанда, оны өзіңізден гөрі қарапайым, талғамы төмен адамдар үшін жасауға бейім боласыз.
Бұл үлкен мәселе, себебі қолданушыға мейіріммен болса да жоғарыдан төмен қарау, сөзсіз, дизайнерді бүлдіретін сияқты. АҚШ-тағы әлеуметтік тұрғын үй кешендерінің ішінде өздері сол жерде тұрамын деп жоспарлаған сәулетшілер жасаған жобалар өте аз деп ойлаймын. Осы жағдайды бағдарламалау тілдерінен де көруге болады. C, Lisp және Smalltalk олардың өз авторлары пайдалануы үшін жасалған. Ал Cobol, Ada және Java басқа адамдар қолдану үшін жасалған.
Егер сіз бірдеңені ақымақтар үшін жасап жатырмын деп ойласаңыз, тіпті сол ақымақтардың өздері үшін де жақсы нәрсе шығармау ықтималдығыңыз жоғары.
Дегенмен, тіпті ең талғампаз қолданушылар үшін бірдеңе жасасаңыз да, сіз бәрібір адамдар үшін дизайн жасап жатырсыз. Зерттеуде жағдай басқаша. Математикада сіз абстракцияларды адамдарға түсіну оңай болғандықтан таңдамайсыз; дәлелдеуді неғұрлым қысқартатын нұсқаны таңдайсыз. Меніңше, бұл тұтастай ғылымға тән. Ғылыми идеялар эргономикалық болуға арналмаған.
Ал өнерде бәрі мүлдем басқаша. Дизайн түгелдей адамға қатысты. Адам денесі — біртүрлі нәрсе, бірақ орындық жасағанда сіз сол үшін жасайсыз және одан аттап кете алмайсыз. Барлық өнер адамдардың қызығушылықтары мен шектеулеріне бейімделуге мәжбүр. Кескіндемеде, мысалы, басқа шарттар бірдей болған кезде, адамдары бар сурет адамдары жоқ суретке қарағанда әрқашан қызықтырақ болады. Қайта өрлеу дәуірінің ұлы туындыларының адамдарға толы болуы жай ғана тарихтың кездейсоқтығы емес. Егер олай болмағанда, бейнелеу өнері бүгінгідей беделге ие болмас еді.
Ұнаса да, ұнамаса да, бағдарламалау тілдері де адамдарға арналған, және адамның миы да оның денесі сияқты күрделі әрі өзіндік қыңырлығы бар деп ойлаймын. Кейбір идеяларды адамдарға түсіну оңай, ал кейбіреулерін оңай емес. Мысалы, біздің детальдармен жұмыс істеу қабілетіміз өте шектеулі сияқты. Бағдарламалау тілдерін ең басынан жақсы идея етіп тұрған да — осы факт; егер біз детальдарды оңай игере алсақ, жай ғана машина тілінде код жаза берер едік.
Сондай-ақ мынаны есте ұстаңыз: тілдер ең алдымен дайын бағдарламалардың формасы емес, олар бағдарламаларды әзірлейтін орта. Өнер саласындағы кез келген адам бұл екі жағдай үшін әртүрлі материалдар қажет болуы мүмкін екенін айтып бере алады. Мәселен, мәрмәр — аяқталған идеялар үшін тамаша, төзімді материал, бірақ жаңа идеяларды дамыту үшін тым икемсіз.
Бағдарлама, дәлелдеу сияқты, бұрын жан-жаққа бұтақталған қате бағыттары кесіп тасталған ағаштың ықшамдалған нұсқасы. Сондықтан тілдің сынағы — ондағы дайын бағдарламаның қаншалықты ұқыпты көрінетінінде ғана емес, сонымен бірге дайын бағдарламаға дейінгі жолдың қаншалықты таза болғанында. Мінсіз дайын бағдарламаларды беретін дизайн таңдауы мінсіз әзірлеу процесін қамтамасыз етпеуі мүмкін. Мысалы, мен қазір қарағанда шағын жауһарлардай көрінетін, іштей кірістірілген кері апострофтарға толы макрос анықтайтын бірнеше макрос жаздым, бірақ оларды жазу үшін сағаттар бойы сәтсіз сынақтар мен қателерден өтуге тура келді, және шынымды айтсам, олардың дұрыстығына әлі күнге дейін толық сенімді емеспін.
Біз көбінесе тілдің сынағы ондағы дайын бағдарламалардың қаншалықты жақсы көрінуінде деп жатамыз. Екі түрлі тілде жазылған бір бағдарламаны көріп, бір нұсқасы әлдеқайда қысқа болған кезде, бұл өте сенімді болып көрінеді. Мәселеге өнер тұрғысынан келген кезде, сіз мұндай сынаққа аса арқа сүйемейтін боласыз. Мәрмәр сияқты бағдарламалау тіліне тап болғыңыз келмейді ғой.
Мысалы, бағдарламалық жасақтаманы әзірлеу кезінде интерактивті жоғарғы деңгейдің (Lisp-те read-eval-print циклі деп аталатын) болуы үлкен ұтыс болып табылады. Ол болған кезде, бұл тілдің дизайнына айтарлықтай әсер етеді. Бұл, мысалы, айнымалыларды қолданбас бұрын оларды жариялауды талап ететін тіл үшін жақсы жұмыс істемейді. Жоғарғы деңгейде өрнектерді жай ғана теріп жатқанда, x мәніне бір мәнді меншіктеп алып, содан кейін x-пен әртүрлі әрекеттер жасай бастағыңыз келеді. Сіз алдымен x-тің түрін жариялап отырғыңыз келмейді. Сіз осы алғышарттардың кез келгенімен келіспеуіңіз мүмкін, бірақ егер ыңғайлы болу үшін тілде жоғарғы деңгей болуы керек болса, ал міндетті түр жариялаулары жоғарғы деңгеймен үйлеспесе, онда түрлерді жариялауды міндеттейтін ешбір тіл бағдарламалау үшін ыңғайлы бола алмайды.
Тәжірибеде жақсы дизайнға қол жеткізу үшін қолданушыларыңызға жақын болуыңыз және олармен әрдайым тығыз байланыста қалуыңыз керек. Идеяларыңызды нақты қолданушылар арқылы үнемі, әсіресе бастапқы кезде, тексеріп, түзетіп отыруыңыз қажет. Джейн Остиннің романдарының керемет болуының бір себебі — ол оларды отбасына дауыстап оқып берген. Сондықтан ол ешқашан табиғат көріністерін шектен тыс көркемдеп суреттеуге немесе даңғой пәлсапаға салынбайды. (Пәлсапа бар, бірақ ол затбелгі сияқты жапсырылмай, оқиғаның өн бойына өрілген.) Егер қарапайым «әдеби» романды ашып, оны өзіңіз жазған дүние ретінде достарыңызға дауыстап оқып беріп жатқаныңызды елестетсеңіз, мұндай нәрсенің оқырманға қаншалықты ауыртпалық екенін жан-тәніңізбен сезінесіз.
Бағдарламалық жасақтама әлемінде бұл идея «Нашар болғаны жақсырақ» (Worse is Better) деген атаумен белгілі. Шындығында, «Нашар болғаны жақсырақ» тұжырымдамасында бірнеше идея араласып кеткен, сондықтан адамдар нашардың шынымен жақсырақ немесе жақсырақ еместігі туралы әлі күнге дейін дауласып келеді. Бірақ сол қоспаның басты идеяларының бірі — егер сіз жаңа нәрсе жасап жатсаңыз, прототипті қолданушыларға мүмкіндігінше тезірек ұсынуыңыз керек.
Балама тәсілді «Тәуекелге бел буу» (Hail Mary) стратегиясы деп атауға болады. Прототипті жылдам шығарып, оны біртіндеп жетілдірудің орнына, сіз бір ғана ұзақ тачдаун пасы арқылы толық, аяқталған өнім жасауға тырысасыз. Менің білуімше, бұл — апатқа апаратын төте жол. Интернет көпіршігі кезінде сансыз көп стартаптар осылай өздерін құрдымға жіберді. Мен мұның сәтті шыққан бірде-бір жағдайын естіген емеспін.
Бағдарламалық жасақтама әлемінен тыс адамдар «Нашар болғаны жақсырақ» ұстанымының бүкіл өнер саласында кездесетінін байқамауы мүмкін. Мысалы, сурет салуда бұл идея Қайта өрлеу дәуірінде ашылған. Қазір сурет салу пәнінің кез келген мұғалімі дәл сурет салудың дұрыс жолы — нысанның контурын асықпай бойлап сызу емес екенін айтады, себебі қателіктер жинақталып, соңында сызықтардың бір-бірімен түйіспей қалғанын көресіз. Оның орнына шамамен дұрыс жерлерге бірнеше жылдам сызық салып, содан кейін осы бастапқы нобайды біртіндеп нақтылау керек.
Көптеген салаларда прототиптер дәстүрлі түрде басқа материалдардан жасалған. Металда ойылатын қаріптер бастапқыда қағазға қылқаламмен салынған. Қоладан құйылатын мүсіндер балауыздан модельденген. Гобелендерге кестеленетін өрнектер қағазға сұйық сиямен салынған. Тастан салынатын ғимараттар кішірейтілген масштабта ағаштан сыналған.
Он бесінші ғасырда майлы бояу алғаш танымал болған кезде адамдарды еліктіргені — дайын туындыны тікелей прототиптің өзінен жасауға болатындығы еді. Қаласаңыз, алдын ала сурет сала аласыз, бірақ оған байланып қалмайсыз; суретті аяқтау барысында барлық детальдарды өңдеп, тіпті үлкен өзгерістер енгізе аласыз.
Мұны бағдарламалық жасақтамада да жасауға болады. Прототип міндетті түрде жай ғана макет болуы шарт емес; оны жетілдіре отырып, дайын өнімге айналдыруға болады. Мүмкіндік болса, әрқашан осылай істеу керек деп ойлаймын. Бұл жол бойында туындаған жаңа түсініктерді пайдалануға мүмкіндік береді. Бірақ, бәлкім, одан да маңыздысы — бұл жігерді жаниды.
Дизайнда жігер мен көңіл-күй шешуші рөл атқарады. Адамдардың бұл туралы неге көп айтпайтынына таңғаламын. Менің алғашқы сурет мұғалімдерімнің бірі: егер бірдеңенің суретін салып жатқанда ішіңіз пысса, салған суретіңіз де іш пыстырарлық болып шығады деген еді. Мысалы, сізге ғимараттың суретін салу керек делік, және сіз әр кірпішті жеке-жеке салуды ұйғардыңыз. Қаласаңыз, бұлай істей аласыз, бірақ жол ортасына келгенде жалығып кетіп, әр кірпішті бақылап отырудың орнына оларды механикалық түрде сала бастасаңыз, сурет кірпіштерді жай ғана тұспалдап салғаннан әлдеқайда нашар көрінетін болады.
Прототипті біртіндеп жетілдіру арқылы бірдеңе жасау адамды сергек ұстайды, сондықтан жігерді жаниды. Бағдарламалық жасақтамада менің ережем мынадай: код әрқашан жұмыс істеп тұруы керек. Егер сіз бір сағаттан кейін сынай алатын нәрсені жазып жатсаңыз, онда сізді ынталандыратын жылдам нәтиженің болашағы бар. Өнерде де, әсіресе майлы бояумен сурет салуда да дәл солай. Көптеген суретшілер бұлдыр нобайдан бастап, оны біртіндеп нақтылайды. Егер осылай жұмыс істесеңіз, онда теория жүзінде күнді ешқашан аяқталмаған болып көрінетін нәрсемен аяқтамайсыз. Шынында да, суретшілер арасында тіпті мынадай сөз бар: «Сурет ешқашан аяқталмайды, тек онымен жұмыс істеуді тоқтатасың». Бұл идея бағдарламалық жасақтамамен айналысқан кез келген адамға жақсы таныс болады.
Талғамы қарапайым қолданушы үшін бірдеңе жасаудың қиын болуының тағы бір себебі — жігердің болмауы. Өзіңізге ұнамайтын нәрсеге деген қызығушылықты сақтап қалу қиын. Жақсы бірдеңе жасау үшін: «О, мынау шынымен тамаша екен» деп ойлауыңыз керек, «мынау не деген қоқыс; мына ақымақтарға осы да жарайды» деп емес.
Дизайн дегеніміз — адамдар үшін заттар жасау. Бірақ адам тек қолданушы ғана емес. Дизайнер де адам.
Осы уақыт бойы мен «дизайнер» туралы жекеше түрде айтып келе жатқаныма назар аударыңыз. Дизайн жақсы болуы үшін, әдетте, ол бір ғана адамның бақылауында болуы керек. Дегенмен, зерттеу жобасында бірнеше адамның бірлесіп жұмыс істеуі әбден мүмкін сияқты. Бұл маған зерттеу мен дизайн арасындағы ең қызықты айырмашылықтардың бірі болып көрінеді.
Өнерде ынтымақтастықтың әйгілі мысалдары болған, бірақ олардың көпшілігі ядролық синтезден гөрі молекулалық байланысқа көбірек ұқсайды. Операда бір адамның либреттосын, ал екінші адамның музыкасын жазуы қалыпты жағдай. Ал Қайта өрлеу дәуірінде итальяндық картиналардың артқы фонындағы пейзаждарды салу үшін көбінесе Солтүстік Еуропадан келген шеберлер жалданатын. Бірақ бұл нағыз ынтымақтастық емес. Олар көбіне Роберт Фросттың «жақсы қоршаулар жақсы көршілерді жасайды» деген сөзіне көбірек ұқсайды. Сіз жақсы дизайнның үлгілерін бір-біріне жалғай аласыз, бірақ әрбір жеке жобаның ішінде бір адам бақылауда болуы керек.
Мен жақсы дизайн үшін бәрін бір адам ойлап табуы керек деп отырған жоқпын. Түсінігі мен талғамына сенетін адамның кеңесінен құнды ешнәрсе жоқ. Бірақ барлық әңгіме біткеннен кейін, не істеу керектігі туралы шешім бір адамда қалуы тиіс.
Неліктен зерттеуді бірлесіп жасауға болады, ал дизайнды бірлесіп жасауға болмайды? Бұл қызық сұрақ. Мен оның жауабын білмеймін. Мүмкін, дизайн мен зерттеу тоғысатын болса, ең үздік зерттеу де жақсы дизайн болып табылады және іс жүзінде оны бірлесіп жасау мүмкін емес шығар. Ең танымал ғалымдардың көбі жалғыз жұмыс істеген сияқты. Бірақ бұл жерде заңдылық бар деп айту үшін менің білімім жеткіліксіз. Мүмкін, көптеген танымал ғалымдар бірлесіп жұмыс істеу сирек кездесетін заманда жұмыс істегендіктен ғана солай болған шығар.
Ғылымдағы жағдай қалай болса да, өнерде шынайы ынтымақтастық өте сирек кездесетін сияқты. Комитеттің дизайн жасауы — нашар дизайнның синонимі. Неге олай? Бұл шектеуді жеңудің қандай да бір жолы бар ма?
Менің ойымша, оның жолы жоқ — жақсы дизайн диктаторды талап етеді. Бір себебі — жақсы дизайн біртұтас болуы керек. Дизайн жай ғана адамдар үшін емес, жеке адамдар үшін жасалады. Егер дизайн бір адамның басына сыятын идеяны білдірсе, онда ол идея қолданушының басына да сыятын болады.
Қатысты тақырыптар: