Бағдарламалар

Жақсы бағдарламалаудың үш ережесі. Бағдарламалау және автоматтандыру ережелері Бағдарламалаушының тоғызыншы ережесі

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

пікірлер - кодқа түсініктемелер қосуды әдетке айналдыру керек. Тіпті анық көрінетін сызықтар осы сәт, бір айдан кейін оларға оралсаңыз, түсініксіз болуы мүмкін;

айнымалы атаулар - мақсатын көрсететін айнымалы атауларды қолдану. Олар түсініктемелерді толықтырады және кейінірек қайта оралған кезде кодты түсінуге көмектеседі;

функция атаулары – жоғарыда айтылғандардың барлығы функция атауларына да қатысты. Олар орындайтын әрекеттерін сипаттауы керек;

неғұрлым қысқа болса, соғұрлым жақсы – Flash-те функцияның ұзақтығына шектеу жоқ. Дегенмен, ұзындығы 100 жолды құрайтын функцияны жазсаңыз, оны кейінірек өңдеу сізге қиын болады. Функцияны тапсырмаларға бөліп, әрбір тапсырманы бөлек функцияға қойған дұрыс;

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

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

жақсы ұйымдастыру – жақсы бағдарламашы, әрине, бағдарламаның әртүрлі элементтерін ұйымдастыра білуі керек. Мысалы, функциялар әртүрлі кадрларға емес, фильміңіздің бір кадрына орналастырылуы керек. Сонымен қатар, функцияларды орындайтын тапсырмаларға сәйкес топтастыруға тырысыңыз.

Түзету

Барлық бағдарламашылар өздері жасаған бағдарламаларды жөндеуі керек. Бағдарламаны бірінші рет іске қосқанда мінсіз жұмыс істеу мүмкін емес. Жақсы маман бағдарламаны жөндеуге қабілетті болуы керек.

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

Бағдарлама туралы ақпаратты Trace командасы арқылы Output терезесінде де орналастыруға болады. Бұл бағдарламаның белгілі бір нүктелерін және сол нүктелердегі белгілі бір айнымалылардың мағынасын қадағалауға көмектеседі.

Түзету бағдарламасын пайдаланғыңыз келсе, Flash MX нұсқаулығындағы сәйкес ақпаратты зерделеуге кеңес береміз. Түзеткіш - бұл Flash фильмін ойнату кезінде айнымалы мәндерді көрсетуге мүмкіндік беретін қарапайым құрал. Алайда ол ғажайыптар жасай алмайды; жөндеу бағдарламасы тек жеке жобаңызды анықтауға көмектеседі.

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

Ең басты мақсат – оңай жету оқуға болатын бағдарламақарапайым құрылым болуы мүмкін. Сайып келгенде, барлық бағдарламалау технологиялары дәл осы мақсатқа жетуге бағытталған, өйткені бұл бағдарламаның сенімділігіне және оны өзгертудің қарапайымдылығына жетудің жалғыз жолы.

· Бағдарлама бір-бірімен интерфейстер арқылы ғана қосылған ең оқшауланған бөліктерден тұруы керек.Ішкі бағдарламаның немесе модульдің интерфейсін оның орындалуынан нақты бөліп, оларды пайдалану үшін қажет емес ақпаратқа қол жеткізуді шектеу керек.

· Әрбір аяқталған әрекет ішкі бағдарлама түрінде орындалады.Ішкі бағдарламаның өлшемі әртүрлі болуы мүмкін, ол нақты әрекетке байланысты, бірақ оның корпусы бір немесе екі экранға сәйкес келетіні жөн: бірнеше ауқымды функцияларды және жүздеген ішкі бағдарламалардың шашырауын қамтитын бағдарламаны түсіну бірдей қиын. әрқайсысы бірнеше жолдармен. Егер операторлардың кез келген тізбегі кемінде екі рет пайдаланылса, оны ішкі бағдарлама ретінде де жазу керек.

· Ішкі бағдарлама мен шақырушы бағдарлама арасында алмасатын барлық мәндер оған параметрлер арқылы берілуі керек.Кіріс параметрлерін тұрақтылар ретінде берген дұрыс. Әдетте, параметрлер тізімінде алдымен барлық кіріс параметрлерін, содан кейін барлық шығыс параметрлерін жазыңыз. Егер ішкі бағдарлама бір мәнді қайтарса, оны функция ретінде, егер бірнеше болса - процедура ретінде орналастырған дұрыс.

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

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

· Айнымалы атаулар олардың мағынасын көрсетуі керек.Дұрыс таңдалған атаулар бағдарламаны өзін-өзі құжаттайды. Жаман есімдер, керісінше, проблемалардың көзі болып табылады. Қысқартулар оқылуды нашарлатады және сіз белгілі бір сөздің қалай қысқартылғанын ұмытып кетуіңіз мүмкін. Жалпы тенденцияайнымалының ауқымы неғұрлым үлкен болса, оның атауы соғұрлым ұзағырақ. Мұндай атаудың алдында тип префиксін қоюға болады (айнымалының түрін анықтауға болатын бір немесе бірнеше әріптер). Қысқа циклдардың есептегіштері үшін, керісінше, i немесе k сияқты бір әріпті атаулармен жұмыс істеу жақсы.

· Бағдарламада анық сандарды пайдаланбаңыз.Тұрақтылардың const декларациясы бөлімінде берілген мағыналы атаулары болуы керек. Символдық атау бағдарламаны түсінікті етеді, сонымен қатар тұрақтының мәнін өзгерту қажет болса, бағдарламаны тек бір жерде өзгерту керек. Әрине, бұл кеңес 0 және 1 тұрақтыларына қолданылмайды.

· Алгоритмнің әрбір фрагментін жазу үшін тілдің ең қолайлы құралдарын пайдалану қажет.Мысалы, бүтін айнымалының мәні бойынша бірнеше бағытта тармақталу бірнеше if емес, case операторымен әдемірек жазылады. Массив арқылы қайталау үшін for циклін қолданған дұрыс. goto операторы өте сирек қолданылады, мысалы. бірнеше кірістірілген циклдардан шығуға мәжбүрлеу үшін және басқа да көптеген жағдайларда үзіліс немесе шығу процедуралары сияқты басқа тіл мүмкіндіктерін қолданған дұрыс.

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

· Бір жолға көп мәлімдемелерді қоймаңыз. Орысша айтқандай, тыныс белгілерінен кейін бос орындар қойылады:

· Кірістірілген блоктар 3-4 таңбаға шегінуі керек,сонымен қатар, бірдей ұя деңгейіндегі блоктар тігінен туралануы керек. Мәтінді бағандарға пішімдеумүмкіндігінше.

· Ұзын құрмалас сөйлемнің соңын белгілеңіз.

· Циклдерді ұйымдастыру үшін ең қолайлы операторды пайдаланыңыз.Қайталау циклі денені міндетті түрде кем дегенде бір рет орындау қажет болатын жағдайларда ғана қолданылады, мысалы, енгізуді тексеру кезінде. цикл үшінқайталану саны алдын ала белгілі болса және параметр реттік типте болса, while циклі қалған барлық жағдайларда қолданылады. Итеративті циклдарды жазу кезінде (шығу жағдайын тексеру үшін цикл денесінде қалыптасқан айнымалылардың қатынасы пайдаланылады) қажет. авариялық шығуды қамтамасыз етіңізалдын ала белгіленген мәнге жеткенде максималды саныитерациялар. Циклды оқуды жеңілдету үшін біз инициализацияны, шығу жағдайын тексеруді және арттыруды бір жерде біріктіруге тырысуымыз керек.

Салалық мәлімдемелерді жазуға арналған кейбір кеңестер:

· Бұтақ соғұрлым қысқа болса, үстіне жақсырақ орналасады,әйтпесе бәрі басқару құрылымыэкранға сәйкес келмеуі мүмкін, бұл жөндеуді қиындатады.

· Теңдік тексеруді пайдаланудың мағынасы жоқрас немесежалған.

· Қажетсіз шартты тексерулерден аулақ болыңыз.

· if операторының бірінші тармағында басқаруды беру болса, басқасын пайдаланудың қажеті жоқ:

егер i > 0 болса, шығыңыз; (мұнда мен<= 0 }

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

Сапа кодын жазудың 15 ережесі

Нашар кодты жазудың көптеген жолдары бар. Бақытымызға орай, сапа кодының деңгейіне көтерілу үшін 15 ережені сақтау жеткілікті. Оларды бақылау сізді шебер етпейді, бірақ оған сенімді түрде еліктеуге мүмкіндік береді.

1-ереже. Кодтау стандарттарын орындаңыз.

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

Мысалы, кодтың осы бөлігінде стандартқа сәйкес 12 қате бар:

үшін(i=0;i

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

Көптеген ұйымдар стандарттарды өздерінің нақты қажеттіліктеріне сәйкес келтіреді. Мысалы, Google 12-ден астам бағдарламалау тілдерінің стандарттарын әзірледі. Олар жақсы ойластырылған, сондықтан Google бағдарламалау бойынша көмек қажет болса, оларды тексеріңіз. Стандарттар тіпті стильді ұстануға көмектесетін өңдегіш параметрлерін және кодтың осы стильге сәйкестігін тексеруге арналған арнайы құралдарды қамтиды. Оларды пайдаланыңыз.

2-ереже.Сипаттаушы атауларды көрсетіңіз.

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

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

Бірдеңені атамас бұрын ұзақ ойлану маңыздырақ. Аты нақты ма? Сіз ең жоғары бағаны немесе ең жақсы бағаны білдірдіңіз бе? Атау мағынасы жағынан ұқсас нысандар үшін басқа контексте қолданылмау үшін жеткілікті түрде ерекше ме? getBest орнына getBestPrice әдісін шақырған дұрыс емес пе? Бұл басқа ұқсас атауларға қарағанда жақсырақ сәйкес келеді ме? ReadEventLog әдісі болса, басқа NetErrorLogRead шақырмауыңыз керек. Егер сіз функцияны шақырсаңыз, оның атауы қайтарылатын мәнді сипаттай ма?

Соңында, бірнеше қарапайым атау ережелері. Класс және түр аттары зат есім болуы керек. Әдіс атауында етістік болуы керек. Егер әдіс объект туралы кейбір ақпараттың ақиқат немесе жалған екенін анықтаса, оның аты «is» деп басталуы керек. Нысан қасиеттерін қайтаратын әдістер "get" деп басталуы керек, ал сипат мәндерін орнататын әдістер "set" деп басталуы керек.

3-ереже. Түсініктеме және құжат.

Әрбір әдіс пен процедураны түсініктемедегі әдіс немесе процедура не істейтіні, параметрлер, қайтарылатын мән және ықтимал қателер мен ерекшеліктермен бастаңыз. Түсініктемелерде әрбір файл мен сыныптың рөлін, әрбір сынып өрісінің мазмұнын және күрделі кодтың негізгі қадамдарын сипаттаңыз. Кодты әзірлеу кезінде түсініктемелер жазыңыз. Оларды кейін жазамын деп ойласаңыз, өзіңізді алдайсыз.

Бұған қоса, қолданбаңызда немесе кітапханаңызда кодтың не істейтінін түсіндіретін, оның тәуелділіктерін анықтайтын және оны құру, сынау, орнату және пайдалану нұсқауларын беретін нұсқаулық бар екеніне көз жеткізіңіз. Құжат қысқа және ыңғайлы болуы керек; README файлы жиі жеткілікті.

4-ереже. Өзіңізді қайталамаңыз.

Ешқашан кодты көшіріп, қоймаңыз. Оның орнына, жалпы бөлікті әдіске немесе сыныпқа (немесе қажет болса, макрос) шығарып, оны сәйкес параметрлермен пайдаланыңыз. Ұқсас деректер мен код бөліктерін пайдаланудан аулақ болыңыз. Сондай-ақ келесі әдістерді қолданыңыз:

Javadoc және Doxygen көмегімен түсініктемелерден API сілтемелерін жасаңыз.
Аннотацияларға немесе атау конвенцияларына негізделген бірлік сынақтарын автоматты түрде жасау.
Бір белгілеу көзінен PDF және HTML жасаңыз.
Дерекқордан сынып құрылымын алу (немесе керісінше).

Ереже 5. Қателерді тексеріңіз және оларға әрекет жасаңыз.

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

Ереже 6. Кодты қысқа, бөлек бөліктерге бөліңіз.

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

Сонымен қатар, әрбір сынып, модуль, файл немесе процесс белгілі бір тапсырма түрін орындауы керек. Егер код бөлігі мүлдем ұқсамайтын тапсырмаларды орындаса, оны сәйкесінше бөліңіз.

7-ереже. API интерфейсін және үшінші тарап кітапханаларын пайдаланыңыз.

Framework API арқылы қандай мүмкіндіктер қолжетімді екенін біліңіз. сонымен қатар кеңейтілген үшінші тарап кітапханалары не істей алады. Егер кітапханаларға жүйелік пакет менеджері қолдау көрсетсе, олар жақсы таңдау болуы мүмкін. Дөңгелекті қайта ойлап табудан сақтайтын кодты пайдаланыңыз (пайдасыз шаршы пішіні бар).

8-ереже. Дизайнды асыра пайдаланбаңыз.

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

9-ереже: дәйекті болыңыз.

Дәл сол әрекеттерді дәл осылай жасаңыз. Функционалдылығы бұрыннан бар әдіске ұқсас әдісті жасап жатсаңыз, ұқсас атауды, ұқсас параметр ретін және ұқсас дене құрылымын пайдаланыңыз. Бұл сабақтарға да қатысты. Ұқсас өрістер мен әдістерді жасаңыз, оларға ұқсас интерфейстер беріңіз және ұқсас сыныптардағы бар жаңа атауларды салыстырыңыз.

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

10-ереже Қауіпсіздік мәселелеріне жол бермеңіз.

Қазіргі код сирек оқшауланып жұмыс істейді. Оның шабуылдардың нысанасына айналу қаупі бар. Олар интернеттен келудің қажеті жоқ; шабуыл қолданбаңызды енгізу арқылы болуы мүмкін. Бағдарламалау тілі мен доменіңізге байланысты сізге буфердің толып кетуі, сайттар аралық сценарийлер, SQL инъекциясы және басқа да осындай мәселелер туралы алаңдау қажет болуы мүмкін. Осы мәселелерді зерттеп, оларды кодыңызда болдырмаңыз. Бұл қиын емес.

11-ереже Деректердің тиімді құрылымдары мен алгоритмдерін пайдаланыңыз.

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

12-ереже: бірлік сынақтарын пайдаланыңыз.

Заманауи бағдарламалық жасақтаманың күрделілігі оны орнатуды қымбаттатады және сынақтан өткізуді қиындатады. Өнімді тәсіл әрбір код бөлігін оның жұмысының дұрыстығын тексеретін сынақтармен сүйемелдеу болады. Бұл тәсіл жөндеуді жеңілдетеді, себебі ол қателерді ертерек анықтауға мүмкіндік береді. Python және JavaScript сияқты динамикалық терілген тілдерде бағдарламалау кезінде бірлікті тестілеу өте маңызды, өйткені олар тек орындау уақытында кез келген қателерді ұстайды, ал Java, C# және C++ сияқты статикалық терілген тілдер олардың кейбірін орындау уақытында ұстай алады. Бірлік сынағы да кодты сенімді түрде қайта өңдеуге мүмкіндік береді. Тесттерді жазуды жеңілдету және олардың орындалуын автоматтандыру үшін XUnit қолданбасын пайдалануға болады.

13-ереже: Кодты тасымалданатын етіп сақтаңыз.

Арнайы себеп болмаса, тек белгілі бір платформада қолжетімді функционалдылықты пайдаланбаңыз. Белгілі бір ұзындыққа (мысалы, 32 бит) ие болу үшін белгілі бір деректер түрлеріне (мысалы, бүтін сандар, көрсеткіштер және уақыт белгілері) сенбеңіз, себебі бұл параметр платформаларда әр түрлі болады. Бағдарлама хабарламаларын кодтан және қатты код мәдениетіне тән параметрлерден бөлек сақтаңыз (мысалы, ондық және бүтін бөлгіштер немесе күн пішімі). Код әртүрлі елдерде жұмыс істей алатындай келісімдер қажет, сондықтан локализацияны мүмкіндігінше ауыртпалықсыз етіңіз.

14-ереже: Кодыңызды құрастыруға болатын етіп жасаңыз.

Қарапайым пәрмен сіздің кодыңызды таратуға дайын пішінге құрастыруы керек. Пәрмен қажетті сынақтарды жылдам құруға және іске қосуға мүмкіндік беруі керек. Бұған қол жеткізу үшін Make , Apache Maven немесе Ant сияқты автоматтандырылған құрастыру құралын пайдаланыңыз. Ең дұрысы, код өзгерген сайын оны тексеретін, құрастыратын және сынайтын интеграциялық жүйені орнату керек.

15-ереже: Барлығын нұсқаны басқаруға қойыңыз.

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

Қорытынды.

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

Менде бағдарламалау бойынша нұсқаулықтар бар, тіпті бағдарламаны құрастыру және әзірлеу бойынша, сонымен қатар 1С-те, мұнда бір нәрсе жарияланған.

Мен институтта доцент болып жұмыс істедім (бірақ сабақ бергенге дейін мен әкімші болдым, 1С-пен айналыстым, франшизада аздап жұмыс істедім, бірақ көп ақша таппадым). 5 жыл ұстаздық еткен соң, қазір 6 жыл кәсіби 1Сник. Алты жылдан кейін бұл басылым мені бір нәрсе қосуға шабыттандырды.

Мен әртүрлі студенттер мен мұғалімдерді, бағдарламашылар мен бастықтарды көрдім. Мен өзім бала кезімнен бағдарламалау негіздерін тізе бүгіп үйрендім, курстарды аяқтамадым, бірақ осылай оқыдым - мен Интернеттен оқулықтар мен мақалаларды құрастырдым, барған сайын дайын болсам да, видео курстарды көрдім, көрсеттім және жасадым. -тәжірибелік тапсырмаларды орындады. Мамандығы бойынша программист колледжден кейін және жаста көп нәрсені үйренуге ерекше мүмкіндік жоқ, сондықтан мен траншеядан шыққан бағдарламашымын, басында мен операциялық қызметпен көбірек айналыстым, мен көп пайдаланушы болдым. қолдау, әсіресе пайдалы емес, мен үйреткен және үйреткенім, өйткені бірінші кезекте тіпті сапа емес, дамудың көлемі мен жылдамдығы, сәйкесінше 100 пайыз жағдайда оң нәтижеге қол жеткізу мүмкіндігі. . Егер сіз күнделікті жұмыста қателессеңіз де - пайдаланушы жазады немесе қоңырау шалып, өзін көрсетеді, мұның бәрі жұмыс режимінде қиындықсыз жойылады. Bitrix-ті қолдау бойынша жұмысты ұйымдастыруда, АТ қосымшаларымен құжаттарды басқаруда өте пайдалы нәрсе. Енді жобаның әдіснамасын әзірлеу дұрыс болмаса немесе толық ойластырылмаған болса, мәселе дәл осы жерде болуы мүмкін.

Әйтеуір, олар менен құрметті сертификаттарды сұрамағаны белгілі болды, бірақ 1Сник бөлімінің бірінші меңгерушісі менің бас әріпті әзірлеушім болды, ол пән саласын терең білуімен және барлық қажетті нәрсені жасай білуімен ерекшеленді. жұмыс, тіпті әкімші бөлігінде де, барлығы оны қатты құрметтейтін. Кәсіпорында оның шеше алмаған бірде-бір мәселесі болған жоқ.

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

Жобалық іс-шараларда IDEF модельдеу негіздерін білу және SAP ARIS оқу бәрінен де көмектеседі (бірақ ARIS диаграммаларын салу қиын). Кез келген жағдайда, ең алдымен, жақсы ойластырылған техникалық спецификациясы бар жобаларды бастау өте маңызды, өйткені онсыз жобаның тапсырыс берушісін түсіну және онымен байланысу өте қиын.

Ал программалау, не бар, 7 оператор және объектілік модель... Мақаланың қысқа болуы да орынды. Ең бастысы, мені 1Snika ретінде мақсатты мақсатым үшін пайдалану қажет болды - кәсіпорында қолданылатын конфигурацияларды білу, қызметкерлерге қалай көмектесу керектігін білу, бухгалтерлерге көмектесу, кодты түсіну, бухгалтерлік есепте қателерді іздеу ... Және, әрине, бағдарламалау саласындағы өндірісте, тіпті операциялық қызметте, әсіресе әдетте, бірнеше жүйелер (бухгалтерлік есеп, қойма, көлік, ...), күрделі міндеттер.

Шамамен 5-7 жыл бұрын мен жобалармен жұмыс істегенде (негізінен кәсіпорынды басқаруды автоматтандыру) басшылыққа алатын ережелер жинағын тұжырымдадым, сонымен қатар мен бағыныштыларға (жоба менеджері ретінде) үйретуге тырыстым. Бүгін мен осы ережелерге тап болдым, оларды оқыдым, көз жасымды төктім :) Уақыт өте келе көзқарастар өзгереді және мен кейбір ережелермен мүлдем келіспеймін, бұл тағы да мұндай тізімдерді жасау алғыссыз жұмыс екенін көрсетеді. Дегенмен, сіз тақырыптық аймақта болған кезде (еске сала кетейін - кәсіпорынды автоматтандыру), сіз күнделікті дизайн қателеріне тап боласыз, содан кейін бұл ережелер өте орынды, түсінікті және нақты жағдайларда қолдануға болады. Бағдарламашы емес немесе басқа саладағы бағдарламашы тұрғысынан кейбір ережелер аянышты, қарапайым немесе мағынасыз болып көрінетіні сөзсіз. Сондықтан бәрі түсінетініне сенімді емеспін, бірақ бәрібір жариялаймын.

Программисттің бірінші ережесі

Бөліңіз және басқарыңыз.
(© Болжам бойынша Гай Юлий Цезарь)

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

Бағдарламалаушының екінші ережесі

Бір күнді жоғалтқан жақсы, бірақ бес минутта ұшады.
(© «Қанат, аяқ, құйрық» фильмінен қыран)

Жақсы программисттің белгісі - өз қызметін автоматтандыру.
(© Ibigdan)

Барлығын дұрыс жасауға ақша мен уақыт ешқашан жетпейді. Бірақ оны кейінірек қайта жасау үшін уақыт та, ақша да табылады.
(© Хеопс заңы)

Мағынасы: тапсырманы сәтті орындау жеткіліксіз, одан жаңа багажмен шығу керек. Соңғы шешімдерді ғана емес, сонымен қатар әдістер + құралдарды жасаңыз - мұның бәрі осы және болашақ жобаларда пайдалы болады. Уақытты қысып қалсаңыз да жасаңыз, өйткені сіз өспей жатсаңыз, сіз артта қаласыз. Тапсырыс беруші мен бастыққа бәрібір, сіз де ойламайсыз.

Бағдарламалаушының үшінші ережесі

«Нұсқаулықты» оқыңыз
(© үмітсіз жүйе әкімшісі)

Белгілі бір принциптерді білу белгілі бір фактілерді білмеудің орнын толтырады.
(© Гельвеций)

Қиял білімнен маңыздырақ. Білім шектеулі. Қиял бүкіл әлемді қамтиды.
(© А.Эйнштейн)

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

Бағдарламалаушының төртінші ережесі

Түбірге қараңыз.
(© Козьма Прутков)

Субъектілер соншалықты көп емес, олар туралы көзқарастар бар. Мәні – шешімнің негізі, оған қарау – нақты тапсырма үшін нақтылау.
(© Ibigdan)

Мағынасы: мысалы, «директор» - бұл адам емес, ол адам ұстай алатын (немесе ешкім ұстай алмайтын) лауазым. Ал «Иванов Петр Сидорович» – адам емес, тегі, аты және әкесінің аты, яғни адамның атрибуттары. Адам - дене, тірі немесе өлі, көптеген атрибуттары бар :) Әдетте, жобалау мұндай нюанстарға түспейді, сондықтан автоматтандырылған басқару жүйелерінің көпшілігі өте икемді емес.

Бағдарламашының бесінші ережесі

«Бұл не?» Деген сұраққа жауап беріңіз. - Термин алыңыз. «Неге?» деген сұраққа жауап беріңіз. - мағынасы бар. Мүмкін, «мұны істеудің ең жақсы жолы қандай?» Деген сұрақ туындауы мүмкін. енді жауап берудің қажеті жоқ.
(© Ibigdan)

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

Мағынасы: Барлық бағдарламалау талдау мен синтезді алмастыруға негізделген. Сонымен қатар, талдау математикалық, функционалдық, объектілік - кез келген болуы мүмкін. Ал синтез тілі де маңызды емес. Бұл екі кезеңді түсіну және сауатты орындау ғана маңызды.

Программисттің алтыншы ережесі

Мағынасы: егер нысан автоматтандырылған жүйеде бірнеше рет пайда болса, онда сіз жобалау кезінде қатты бұрмаланғансыз. Мысалы: «Иванов Петр Сидорович, лауазымы: дәрігер, жұмыс орны: урологиялық бөлімше». Сосын оның жүрегі ауырып, уау! - № 2 нысан: «Иванов Петр Сидорович, пациент, кардиология бөлімі». Шындығында, бұл бір адам, бірақ жүйе екі түрлі, бір-бірімен байланыссыз деп көрсетілген. Сонымен қатар, бұл әдеттегі және қарапайым дизайн қатесі, бірақ әлдеқайда күрделілері бар. Көптеген CMS толық емес осындай қателерден тұрады.

Программисттің жетінші ережесі

Мағынасы: Көп мағыналы. Табылған шешімге қуануға асықпаңыз, мүмкін ол субъектілерді ескереді, бірақ байланыстарды ескермейді. Ескі шешімдер басқа ауқымдағы жаңа тапсырмаларда жұмыс істемеуі мүмкін. Жалпы, сіз масштабтау мәселелері туралы айта алмайсыз.

Бағдарламалаушының сегізінші ережесі

Белгілі бір пәндік аймақты модельдейтін бағдарламалық өнім физикалық тұрғыдан осы пәндік аймақтан қарапайым болуы мүмкін емес.
(© Ibigdan)

Нәтиже: әмбебап бағдарламалық өнім мамандандырылғанға қарағанда бірнеше рет күрделірек, өйткені ол өзара байланысты салалар тобын қамтиды.
(© Ibigdan)

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

Программисттің тоғызыншы ережесі

Компьютерлерді пайдалану негізінде ұйымдық басқаруды автоматтандыру кезінде оның табысының негізгі кепілі ұйымдық басқарудың дәстүрлі технологиясын түбегейлі өзгерту екенін есте ұстаған жөн.
(© В.М. Глушков)

Автоматтандыру өз алдына мақсат емес, кәсіпорын қызметін оңтайландыру құралы болып табылады. Егер автоматтандыру оңтайландырылмаса, онда оның қажеті жоқ.
(© Ibigdan)

Мағынасы: қағаздағы жұмыс процесін автоматтандырудан, оның дәл көшірмесін компьютерде жасаудан асқан ақымақтық жоқ. Кейбір бағдарламашылар «пайдаланушыға таныс» интерфейс жасағысы келетіні сонша, олар экранға қағаз парақтарын салады, оларға сызықтар мен белгілерді қағаз шот-фактураларындағыдай етіп орналастырады және т.б. Маркетинг тұрғысынан бұл орынды, бірақ оның автоматтандыруға еш қатысы жоқ – бұрын қағазда хаос болатын, қазір компьютерлік желіде хаос. Құжат субъекті емес, оның «бухгалтерлік көрінісі», субъект - шот-фактурада көрсетілген тауарлар, бұл нақты объект, онымен операциялар автоматтандырылуы керек екенін ұмытпау керек. Қағаздағы жұмыс процесі сізден жүз жыл бұрын және компьютерлер пайда болғанға дейін жасалған «автоматтандыру» әрекеті ғана, оны автоматтандырудың қажеті жоқ, оны ауыстыру қажет. Үлгі болды, мұндай сәттер қай салада да жетерлік.