Өз кодымен қарқынды жұмыс істейтін жақсы бағдарламашы оны математик өзі шешіп жатқан есепті санасында қалай ұстаса, дәл солай баста ұстай алады. Математиктер сұрақтарға мектеп оқушыларына үйреткендей қағазға сызып-жазып жауап бермейді. Олар көбірек нәрсені бастарында істейді: олар есеп кеңістігін жақсы түсінуге тырысатыны сонша, оны бойлай өзің өскен үйдің естелігін шарлағандай емін-еркін кезе алады. Ең үздік деңгейінде бағдарламалау да дәл сондай. Сіз бүкіл бағдарламаны басыңызда ұстайсыз және оны өз қалауыңызша өзгерте аласыз.
Бұл, әсіресе, жобаның басында өте құнды, өйткені бастапқыда ең маңызды нәрсе — не істеп жатқаныңызды өзгерте алу қабілеті. Есепті басқа жолмен шешу ғана емес, дәл сол шешіп жатқан есебіңіздің өзін өзгерте білу маңызды.
Сіздің кодыңыз — бұл өзіңіз зерттеп жатқан мәселені түсінуіңіз. Сондықтан бағдарлама кодын басыңызда толық ұстағанда ғана сіз мәселені шынайы түсінесіз.
Бағдарламаны басыңа толық «жүктеп алу» оңай емес. Егер сіз жобаны бірнеше айға қалдырып кетсеңіз, оған қайта оралғанда бәрін қайтадан шынымен түсіну үшін бірнеше күн кетуі мүмкін. Тіпті бағдарламамен белсенді жұмыс істеп жүргеннің өзінде, күн сайын жұмысты бастаған кезде оны басқа сыйғызуға жарты сағат кетуі мүмкін. Және бұл ең жақсы жағдайда. Әдеттегі кеңсе жағдайында жұмыс істейтін қарапайым бағдарламашылар бұл күйге ешқашан кірмейді. Немесе өткірлеу айтсақ, әдеттегі кеңсе жағдайында жұмыс істейтін қарапайым бағдарламашылар өздері шешіп жатқан мәселелерді ешқашан терең түсінбейді.
Тіпті ең үздік бағдарламашылардың да басында өздері жұмыс істеп жатқан бүкіл бағдарлама үнемі толық жүктеліп тұрмайды. Бірақ бұған көмектесетін бірнеше амал бар:
Алаңдататын нәрселерден аулақ болыңыз. Алаңдату жұмыстың көптеген түрлеріне зиян, бірақ бағдарламалау үшін әсіресе қауіпті, себебі бағдарламашылар өздері меңгере алатын егжей-тегжейлердің ең шегінде жұмыс істеуге бейім.
Алаңдаудың қауіптілігі оның қанша уақытқа созылғанына емес, миыңызды қаншалықты шатастырғанына байланысты. Бағдарламашы кеңседен шығып, басындағы кодты жоғалтпай-ақ сэндвич алып келе алады. Бірақ орынсыз бір кедергі 30 секундтың ішінде басыңыздағының бәрін өшіріп тастауы мүмкін.
Бір қызығы, алдын ала жоспарланған алаңдатулар кенеттен пайда болғандардан да жаман болуы мүмкін. Егер бір сағаттан кейін жиналыс болатынын білсеңіз, сіз тіпті күрделі бірдеңені бастамайсыз да.
Ұзақ уақыт бойы үзіліссіз жұмыс істеңіз. Бағдарламамен жұмысты бастаған сайын белгілі бір уақыт шығыны болатындықтан, көптеген қысқа сессияларға қарағанда бірнеше ұзақ сессиямен жұмыс істеген әлдеқайда тиімдірек. Әрине, шаршағандықтан ойлау қабілетіңіз төмендейтін сәт келеді. Бұл адамнан адамға өзгереді. Мен 36 сағат бойы үздіксіз код жазатын адамдар туралы естідім, бірақ менің қолымнан келген ең көбі шамамен 18 сағат болды және мен 12 сағаттан аспайтын кезеңдерде ең жақсы нәтиже көрсетемін.
Оңтайлы шек — бұл физикалық тұрғыдан шыдай алатын шегіңіз емес. Жобаны бөліп-бөліп жасаудың шығынымен қатар өз артықшылығы да бар. Кейде тынығып алған соң есепке қайта оралсаңыз, бейсанаңыз сізді күтіп тұрған дайын жауап қалдырғанын байқайсыз.
Ықшам тілдерді қолданыңыз. Неғұрлым қуатты бағдарламалау тілдері бағдарламаларды қысқарақ етеді. Ал бағдарламашылар, шамасы, бағдарламалар туралы тым болмағанда ішінара оларды жазу үшін қолданатын тілінде ойлайтын сияқты. Тіл неғұрлым ықшам болса, бағдарлама соғұрлым қысқа болады және оны басқа жүктеп, сақтап тұру соғұрлым оңайырақ.
Сіз қуатты тілдің тиімділігін «төменнен жоғарыға» (bottom-up) бағдарламалау стилін қолдану арқылы арттыра аласыз, мұнда сіз бағдарламаларды бірнеше қабатпен жазасыз, ал төменгі қабаттар жоғарғы қабаттар үшін бағдарламалау тілі ретінде қызмет етеді. Егер мұны дұрыс істесеңіз, басыңызда тек ең жоғарғы қабатты ғана ұстау жеткілікті болады.
Бағдарламаңызды қайта-қайта жазып отырыңыз. Бағдарламаны қайта жазу көбінесе одан да таза дизайнға әкеледі. Бірақ бұлай болмаған күннің өзінде де оның артықшылығы болар еді: бағдарламаны қайта жазу үшін оны толықтай түсінуіңіз керек, сондықтан оны басқа жүктеудің бұдан асқан жақсы жолы жоқ.
Қайта оқуға ыңғайлы код жазыңыз. Барлық бағдарламашылар түсінікті, оқылатын код жазудың жақсы екенін біледі. Бірақ сіздің ең басты оқырманыңыз — өзіңізсіз. Әсіресе бастапқыда; прототип — бұл өзіңізбен-өзіңіз сөйлесу. Ал өзіңіз үшін жазғанда басымдықтарыңыз басқаша болады. Егер сіз басқа адамдар үшін жазып жатсаңыз, кодты тым тығыз еткіңіз келмеуі мүмкін. Бағдарламаның кейбір бөліктері кіріспе оқулық сияқты, бәрін жайып салсаңыз, оқуға ең оңай болуы мүмкін. Ал егер сіз кодты басыңызға қайта жүктеуді жеңілдету үшін жазып жатсаңыз, қысқалықты таңдаған дұрыс шығар.
Шағын топтарда жұмыс істеңіз. Бағдарламаны санаңызда басқарған кезде, сіздің көзқарасыңыз өзіңізге тиесілі кодтың шекарасында тоқтайды. Басқа бөліктерді сіз онша жақсы түсінбейсіз және ең бастысы, оларды еркін өзгерте алмайсыз. Сондықтан бағдарламашылар саны неғұрлым аз болса, жоба соғұрлым толық өзгере алады. Егер жалғыз ғана бағдарламашы болса, көбінесе басында солай болады, сіз барлығын қамтитын түбегейлі өзгерістер жасай аласыз.
Бір код бөлігін бірнеше адамға өңдетпеңіз. Сіз басқа адамдардың кодын ешқашан өзіңіздікіндей жақсы түсінбейсіз. Оны қаншалықты мұқият оқысаңыз да, сіз оны жай ғана оқыдыңыз, жазған жоқсыз. Сондықтан егер бір код бөлігін бірнеше автор жазса, олардың ешқайсысы оны жалғыз автор сияқты жақсы түсінбейді.
Және, әрине, басқа адамдар жұмыс істеп жатқан нәрсені қауіпсіз түрде қайта жобалай алмайсыз. Бұл тек рұқсат сұрау керек деген сөз емес. Сіз тіпті өзіңізге ондай нәрселерді ойлауға да мүмкіндік бермейсіз. Бірнеше автор жазған кодты қайта жобалау заңдарды өзгертумен бірдей; ал өзіңіз ғана басқаратын кодты қайта жобалау екіұшты кескіннің екінші мәнін көру сияқты жеңіл.
Егер жобаға бірнеше адамды жұмылдырғыңыз келсе, оны құрамдас бөліктерге бөліп, әрқайсысын бір адамға беріңіз.
Кішкентайдан бастаңыз. Бағдарламамен танысқан сайын оны баста ұстау оңайырақ болады. Бөлшектерді толық зерттегеніңізге сенімді болғаннан кейін, оларға «қара жәшік» ретінде қарай бастай аласыз. Бірақ жобамен жұмыс істеуді жаңа бастағанда, сіз бәрін көруге мәжбүр боласыз. Егер тым үлкен мәселеден бастасаңыз, оны ешқашан толық қамти алмауыңыз мүмкін. Сондықтан, егер үлкен, күрделі бағдарлама жазу керек болса, бастаудың ең жақсы жолы — оған арнап спецификация жазу емес, мәселенің белгілі бір бөлігін ғана шешетін прототип жазу болуы мүмкін. Жоспарлаудың қандай артықшылықтары болса да, олар көбінесе бағдарламаны баста ұстай алудың артықшылықтарынан асып түсе алмайды. Бағдарламашылардың кездейсоқ түрде осы сегіз тармақтың бәрін дәл табатыны таңғалдырады. Біреудің жаңа жоба туралы идеясы туады, бірақ ол ресми түрде бекітілмегендіктен, ол онымен жұмыстан тыс уақытта айналысуға мәжбүр болады — бұл уақыт одан да өнімді болып шығады, өйткені ешкім алаңдатпайды. Жаңа жобаға деген құлшынысына ерік беріп, ол онымен тоқтаусыз ұзақ сағаттар бойы жұмыс істейді. Бастапқыда бұл жай ғана тәжірибе болғандықтан, «өндірістік» тілдің орнына ол жай ғана «скрипттік» тілді қолданады — ол шын мәнінде әлдеқайда қуатты болып шығады. Ол бағдарламаны бірнеше рет басынан бастап толық қайта жазады; бұл ресми жоба үшін ақталмас еді, бірақ бұл жан қалауымен істелген жұмыс және ол оның мінсіз болғанын қалайды. Және оны өзінен басқа ешкім көрмейтіндіктен, ол өзіне арналған қысқа түртіп алулардан басқа кез келген түсініктемелерді жазбай тастап кетеді. Ол амалсыздан шағын топта жұмыс істейді, өйткені ол идея туралы басқа ешкімге әлі айтқан жоқ немесе бұл сондай үмітсіз болып көрінгендіктен, онымен басқа ешкімнің жұмыс істеуіне рұқсат берілмеген. Тіпті топ болған күннің өзінде, олар бір кодты бірнеше адам болып түзете алмас еді, өйткені ол бұған мүмкіндік бермейтіндей тым жылдам өзгереді. Және жоба кішкентайдан басталады, өйткені идеяның өзі бастапқыда шағын болады; оның тексеріп көргісі келетін бір ғана тамаша тәсілі бар.
Ресми бекітілген жобалардың барлық сегіз нәрсені қате істеуге қалай үлгеретіні одан да қатты таңғалдырады. Шындығында, егер көптеген ұйымдарда бағдарламалық жасақтаманың қалай жазылатынына қарасаңыз, олар әдейі бәрін қате істеуге тырысып жатқан сияқты болып көрінеді. Белгілі бір мағынада, бұл солай да. Мұндай нәрсе пайда болғалы ұйымдардың айқындаушы қасиеттерінің бірі — жеке адамдарға бірін-бірі алмастыратын бөлшектер ретінде қарау болды. Бұл соғыс жүргізу сияқты параллель жүргізуге болатын тапсырмалар үшін жақсы жұмыс істейді. Тарихтың көп бөлігінде кәсіби сарбаздардан құралған жақсы жаттыққан армия, қаншалықты батыр болса да, жеке жауынгерлерден тұратын армияны жеңе алатынына сенім артуға болатын еді. Бірақ тың идеялар табу параллельдендіруге аса көнбейді. Ал бағдарламалар дегеніміз — бұл идеялар.
Ұйымдардың жеке данышпандыққа тәуелді болу идеясын ұнатпайтыны жай ғана шындық емес, бұл — тавтология. Бұлай істемеу — ұйым анықтамасының бір бөлігі. Әйтеуір біздің ұйым туралы қазіргі түсінігіміз бойынша солай.
Мүмкін біз адамдардан бірін-бірі алмастыруды талап етпей-ақ, олардың күш-жігерін біріктіретін ұйымның жаңа түрін анықтай алармыз. Нарықты ұйымдасудың осындай түрі деуге болады, бірақ нарықты тоқырау жағдайы — яғни ұйымдасу мүмкін болмаған кезде әдепкі бойынша пайда болатын нәрсе ретінде сипаттаған дұрысырақ шығар.
Қолымыздан келетін ең жақсы нәрсе — ұйымның бағдарламалаумен айналысатын бөліктерін қалғандарынан басқаша жұмыс істейтіндей ету сияқты қандай да бір амал-айла шығар. Бәлкім, үлкен компаниялар үшін ең оңтайлы шешім — өз ішінде идеяларды дамытуға тырыспай, оларды жай ғана сатып алу шығар. Бірақ шешім қандай болса да, бірінші қадам — мәселенің бар екенін түсіну. «Бағдарламалық жасақтама компаниясы» деген сөз тіркесінің өзінде қайшылық бар. Бұл екі сөз екі қарама-қарсы бағытқа тартып тұр. Ірі ұйымдағы кез келген жақсы бағдарламашы онымен қарама-қайшылыққа тап болады, өйткені ұйымдар бағдарламашылар ұмтылатын нәрсеге кедергі жасау үшін құрылған.
Қалай болғанда да, жақсы бағдарламашылар көп нәрсені тындырып үлгереді. Бірақ бұл көбінесе өздерін жұмысқа алған ұйымдарға қарсы іс жүзінде бүлік жасауды талап етеді. Егер көбірек адам бағдарламашылардың бұл әрекеттері олардың атқаратын жұмысының талаптарынан туындайтынын түсінсе, бұл көмектесер еді. Олар басқа барлық міндеттемелерді жиып қойып, алдымен спецификация жазудың орнына бірден бағдарламалауға бас қоятын және әлдеқашан жұмыс істеп тұрған кодты қайта жазатын ұзақ сессиялармен жауапсыз болғандықтан жұмыс істемейді. Олар жалғыз жұмыс істеуді ұнататындығы немесе сәлемдесу үшін есіктен басын сұққан адамдарға ашуланатындығы олардың дөрекілігінен емес. Бұл бір қарағанда кездейсоқ болып көрінетін жағымсыз әдеттердің бір ғана түсіндірмесі бар: бағдарламаны өз басында ұстай білудің күші.
Мұны түсіну ірі ұйымдарға көмектесе ме, жоқ па, бірақ бұл олардың бәсекелестеріне сөзсіз көмектесе алады. Үлкен компаниялардың ең әлсіз жері — олар жеке бағдарламашыларға керемет жұмыс істеуге мүмкіндік бермейді. Сондықтан егер сіз кішкентай стартап болсаңыз, оларға дәл осы жерден соққы беру керек. Бір ғана үлкен мида шешілуі керек болатын мәселелерді шешуге кірісіңіз.
Осы мәтіннің нобайларын оқып шыққандары үшін Сэм Альтман, Дэвид Гринспен, Аарон Иба, Джессика Ливингстон, Роберт Моррис, Питер Норвиг, Лиза Рэндалл, Эмметт Шир, Сергей Царев және Стивен Вольфрамға алғыс білдіремін.