Багаар хэрхэн ажиллахаа мэддэг гэдгээ ажил олгогчдод хэрхэн харуулах вэ. Багийн тоглоомууд хүн болгонд байдаггүй

Эртний асуулт: яагаад хүн бүрт хангалттай мэргэжилтнүүд байдаггүй вэ? Найзуудынхаа гэр бүлийн ойн дараа би энэ тухай дахин бодлоо ...
Ийм чухал арга хэмжээг зохион байгуулахын тулд тэд ёслолын мастер эмэгтэй, DJ охиныг урьсан. Ийм үдшийн үеэр тэдний зардал миний DJ-ийн зардлаас 3 дахин бага байсан. Аливаа хямдхан зүйл надад үргэлж сэжиг төрүүлдэг. Мэдээжийн хэрэг, би энэ баярыг өөрөө үнэ төлбөргүй өнгөрөөхөд бэлэн байсан ч тэр даруйдаа "Та зочин байна! Бид бусад мэргэжлийн хүмүүсийг урих болно" гэж хэлсэн.
Үзэгчид маш өөр, эрх чөлөөнд дуртай цугларсан тул эхний минутаас мэргэжлийн хүмүүс төөрч эхлэв. Нэмж дурдахад DJ-ийн тоног төхөөрөмжийг гэрийн караокеноос хассан нь ойлгомжтой: микрофон нь исгэрч, дуугарч, гонгинож, шуугиан тарьж байсан ч зүгээр л ажиллахгүй байв.

Би зочин учраас ажлын явцад саад учруулахгүйн тулд бүх талаараа өөрийгөө хянаж байсан. Одоо миний баяр хүргэх цаг боллоо. Би микрофон аваад, DJ охиноос ард нь ямар нэгэн хөгжмийн зэмсэг уянгалаг зүйл тавихыг хүсэв. Гуравдугаар сард муур муур хайж байх үед л уянгын дуутай төстэй чанга яригчаас юу асгарсан нь тодорхойгүй байв.

За яахав, хаа сайгүй нюансууд байдаг. Би баяр хүргэж эхлэв. Гэтэл микрофоноо уруулдаа ойртуулахад дуугарч, дуугарч эхлэв. Эсрэгээрээ уруулнаас нь салгахад сонсогдохгүй байлаа. Миний тарчлаан зовоож байгааг хараад шарсан талхны мастер эцэст нь "Чи микрофонтой хэрхэн ажиллахаа мэдэхгүй байгаа нь шууд тодорхой харагдаж байна ..." гэсэн гайхалтай хэллэг хэлэв.

Тийм ээ, магадгүй 20 жилийн турш радиод ажиллаж, олон нийтийн баярыг микрофоноор удирдаж байхдаа тэр үүнийг хэрхэн зохицуулахаа хэзээ ч сураагүй: тэр үүнийг илүү сайн мэддэг байсан нь ойлгомжтой ... Хүмүүс юуны талаар бодохгүйгээр дүгнэлт хийх ийм чадварыг хаанаас олж авдаг вэ? чи хэлж байна уу?

Баг нь нэг зорилго бүхий мэргэжилтнүүдийг нэгтгэдэг бөгөөд үүнээс байгууллагын амжилт, багийн гишүүн тус бүрээс хамаардаг. Баг нэг организм шиг ажиллахад бүх гишүүдээсээ илүү ихийг дангаараа хийж чадна. Багаар ажиллах чадвар нь олон ажил олгогчдод үнэ цэнэтэй байдаг ч багаар ажиллах ур чадвартай байх нь юу гэсэн үг вэ?

Хэрэв та багаар хэрхэн ажиллахаа мэддэг

... та өөрийн гэсэн зүйлийг нэгтгэж болнодаалгавар ба ерөнхий

Зөвхөн үүргээ биелүүлэхээс гадна хувийн амбиц, компанийн ашиг сонирхлыг хослуулах чадвартай байх нь чухал юм. Багаар ажиллахын тулд заримдаа генералын төлөө хувийн байдлаасаа татгалздаг. Нийт үр дүнд хүрэх нь бүлгийн гишүүн бүр ажлаа хэр сайн хийж, хамтран ажиллагсдынхаа хүчин чармайлтыг дэмжиж байгаагаас ихээхэн шалтгаална.

… танд туслах гэдэг нь хоосон хэллэг биш юм

Багийн өмнө тулгарч буй үр дүнд хүрэхийн тулд хамт ажиллагсаддаа туслахад бэлэн байхаас гадна тэдний тусламжийг хүлээж авахаас ичдэггүй байх нь чухал юм.

... та дагаж мөрдөх үүрэгтэй

Багаар ажиллахад багийн аль нэг гишүүний үе үе ололт амжилт биш харин зорилго, хугацаатай нийцсэн тогтвортой, төлөвлөсөн ажил чухал байдаг. Хийх замаар хамтарсан төсөлБагийн бүх гишүүд үүрэг даалгавраа цаг тухайд нь биелүүлнэ гэдэгт итгэлтэй байх ёстой.

…мөргөлдөөнтэй нөхцөлд хэрхэн зөв харилцахаа мэддэг

Багийн тоглогч бусадтай үр дүнтэй харилцах чадвартай байх нь чухал зөрчилдөөнтэй нөхцөл байдал: сонсох, итгүүлэх, бүтээлч хэвээр үлдэх, аргументуудыг хайж олох, харилцан буулт хийхийг эрмэлзэх, хувийн шинж чанартай байх биш. Багаар ажиллах гол зүйл бол хамтын ажиллагаа юм.

Багаар ажиллах ур чадвар нь нарийн төвөгтэй, олон талт ажлыг бие даасан мэргэжилтэн шийдэж чадахгүй байгаа хүмүүст онцгой чухал юм. Та багт ямар үүрэг гүйцэтгэдэг болохыг ойлгоход LifeWriter-ийн бүтээгдэхүүн туслах болно. Үүний тусламжтайгаар та хэрхэн багаар ажиллахад илүү үр дүнтэй болохыг олж мэдэх боломжтой.

"Багаар ажиллах чадвар" - ийм үгсийг магадгүй хоёр дахь анкет бүрээс олж болно. Гэсэн хэдий ч багийн тоглогч байх нь юу гэсэн үг вэ, үргэлж шаардлагатай байдаг уу? Хэн ялангуяа багаар ажиллах чадварыг хөгжүүлэх хэрэгтэй вэ, тэдний хэлснээр хэн нь хувь хүний ​​ангилалд ажиллах нь дээр вэ?

Хамтлаг эсвэл баг уу?
IN Зөвлөлтийн жилүүд"баг" гэдэг үг бизнес гэхээсээ илүү спорттой холбоотой байсан. Аж ахуйн нэгжийн ажилчдыг "нэгдэл" гэж ярьдаг заншилтай байсан. Өнөөдөр аль ч багийг баг гэж нэрлэх нь моод болсон (иймээс баг бүрдүүлэх загвар) боловч эдгээр нь ижил ойлголт биш гэдгийг мэргэжилтнүүд тодотгож байна.

Хэрэв баг нь компани эсвэл түүний хэлтэст ажилладаг бүх ажилчид (жишээлбэл, үйлдвэрийн баг) бол баг нь нэг зорилгод нэгтгэгдсэн, түүнд хүрэх үүрэг хариуцлагатай мэргэжилтнүүд юм. Үүний зэрэгцээ, нийтлэг зорилго нь багийн гишүүн бүр, хувь хүний ​​хувьд биелдэг. Албан бус харилцаа холбоо, нөхөрлөл нь баг болон багийн аль алинд нь боломжтой.

Жишээлбэл, борлуулалтын хэлтсийг ихэнх тохиолдолд энэ үгийн тогтсон утгаараа баг гэж үзэх боломжгүй, учир нь менежер бүр өөрийн борлуулалтын төлөвлөгөө, тиймээс өөрийн гэсэн зорилготой байдаг. Гэхдээ орон нутгийн сонгуульд депутатад нэр дэвшигчийг дэмжих сонгуулийн кампанит ажлыг зохион байгуулдаг жижиг PR агентлаг нь зүгээр л нэг баг байх ёстой: ажилчид нийтлэг даалгавартай (сонгуульд нэр дэвшигчийн ялалт), үүрэг даалгавар өгдөг, шаардлагатай бол мэргэжилтнүүд хийх боломжтой. бие биедээ тусал.

Баг нь маш том (зуу, мянган хүн) байж болно, харин баг нь танхимын холбоо юм. Бодит багт 10-15-аас дээш гишүүн оролцох нь ховор байдаг - нэг зорилгод хэт олон хүмүүсийг нэгтгэх нь хэцүү байдаг бөгөөд үүнийг хүн бүр хувь хүн гэж ойлгодог.

Хэний хувьд чухал вэ
Та багаар ажиллах чадвартай байх шаардлагатай юу? Магадгүй, тийм ээ, хэрэв таны ажил ихэвчлэн нийтлэг ажлын нэг хэсэг болж, та түүний шийдлийг сонирхож байгаа бол. Жишээлбэл, компанийн бүтээгдэхүүнийг амжилттай сурталчлах нь бүх маркетингийн хэлтсийн хүчин чармайлтаас хамаардаг бол таны үүрэг (жишээлбэл, бараа бүтээгдэхүүнийг хөгжүүлэх) багийн хувьд маш чухал бөгөөд брэндийг таниулах нь таны хувийн зорилго юм.

Багийн тоглогчийн ур чадвар хэнд чухал биш вэ? Дүрмээр бол ажлын харьцангуй бие даасан байдал, шийдвэр гаргах бие даасан байдал, түүнчлэн хувь хүний ​​үр дүн нь ялангуяа чухал байдаг мэргэжилтнүүдийн хувьд. Эдгээр нь багш нар, борлуулалтын төлөөлөгч ба борлуулалтын менежерүүд, судлаач эрдэмтэд (мэдээжийн хэрэг хэд хэдэн хүн ажилладаг судалгааны төслийн талаар яриагүй бол), эмч нар (гэхдээ мэс засалч, сувилагч нар хамтдаа мэс засал хийдэг баг гэж үзэж болно), сэтгүүлчид (кино багийн бүрэлдэхүүнд ажилладаг телевизийн сэтгүүлчдийг үл хамаарах зүйл гэж үзэж болно) гэх мэт.

Тогтвортой байдал, түүнчлэн харилцан туслалцаа
Жинхэнэ багийн тоглогч болохын тулд өөртөө ямар чанаруудыг хөгжүүлэх хэрэгтэй вэ? Юуны өмнө багаар ажиллахад удаан хугацаанд тогтвортой, үр дүнтэй ажиллах чадвар чухал байдаг. Дүрмээр бол баг нь гишүүдийнхээ нэг удаагийн хөдөлмөрийн мөлжлөг биш, харин тэдний байнгын үр дүнтэй үйл ажиллагаа - спортын хэлээр ярих, олон тооны спринт биш, харин урт марафон гүйлт шаарддаг. Аливаа тогтвортой тогтолцоонд тогтвортой байдал хэрэгтэй байдаг тул ерөнхий төлөвлөгөөний дагуу цагаа төлөвлөж, хуралдаа цагтаа ирж, заасан хугацаандаа амжиж сур. Санаж байгаарай - ажлынхаа хэсгийг оройтож өгснөөр та өөрт найдаж буй хүмүүсийг нухацтай унагадаг.

Багийн тоглогчдод зайлшгүй шаардлагатай хоёрдахь чанар бол заримдаа генералын талд хувийн шинж чанараа орхих чадвар юм. Энэ нь татгалзсан гэсэн үг өөр төрлийнсонирхол татахуйц, хямд карьеризмаас татгалзах. Боломж болгонд нийтлэг үйл хэрэгт өөрийн үүргийг онцолж, хөнжлөө өөртөө татах нь тийм биш юм хамгийн сайн чанарбагийн гишүүний хувьд. Мэдээжийн хэрэг, өөрийгөө сурталчлах хувь зайлшгүй шаардлагатай амжилттай карьерГэсэн хэдий ч багийн төслүүдэд пропорцын мэдрэмж онцгой чухал байдаг.

Үүнээс гадна багаар ажилладаг мэргэжилтэн хамт ажиллагсаддаа туслахад үргэлж бэлэн байх ёстой. "Чи надад - Би чамд" эсвэл "quid pro quo" гэсэн зарчим энд ажиллахгүй. Хэрэв та багаар ажилладаг бол мэдээллээр хангаж, холбоо барих хаягаа хуваалцаж, бусад гишүүдийг үнэ төлбөргүй шуурхай хамгаалж, аюулгүй болго - таны эцсийн зорилго нэг гэдгийг санаарай. Гэсэн хэдий ч энэ нь та өөрийнхөө төлөө болон тэр залуугийн төлөө системтэй, даруухан ажиллах ёстой гэсэн үг биш юм. Хэрэв ийм зүйл тохиолдвол баг дахь үүргийг шинэчилж болно. Гэсэн хэдий ч компани дахь бизнесийн үйл явцыг зөв зохион байгуулснаар ийм асуулт гарч ирэх ёсгүй.

Эцэст нь, багийн тоглогчийн хувьд хүмүүстэй ярилцах чадвар нь маш чухал юм - сонсох, ойлгох, бууж өгөх, итгүүлэх, харилцан буулт хийх. Үүнд хэрхэн хүрэх вэ? Та тусгай сургалтанд хамрагдаж болно, эсвэл бие даан суралцаж, удахгүй болох уулзалт, хэлэлцээрт сайтар бэлдэж, маргааныг эргэцүүлэн бодож болно.

Багаар ажиллах чадвартай байх нь өрсөлдөөний давуу тал
Бараг хоёр дахь анкет бүр багаар ажиллах чадварын талаар хашгирдаг ч туршлагатай элсүүлэгчид итгэлийн талаар үндэслэлгүй мэдэгдэл хийх гэж яардаггүй. Энэ чанарыг өөрийн өрсөлдөх давуу тал болгохын тулд та ярилцлага өгөхдөө үүнийг гол зүйл болгон онцлон тэмдэглэх хэрэгтэй.

Үүнийг хийхийн тулд карьертаа амжилттай ажиллаж байсан тодорхой жишээнүүдийг хэлээрэй, жишээлбэл: "Би алдартай брэндийн бүтээгдэхүүнийг сурталчлах PR багт ажиллаж байсан, олон нийтийн арга хэмжээ зохион байгуулах үүрэгтэй байсан. Бид хамтдаа зургаан сарын хугацаанд борлуулалтаа 50%-иар нэмэгдүүлсэн." Эсвэл: “Манай хэлтэс оны эцэст компанидаа шилдэгээр шалгарсан. Би үүнд хувь нэмрээ оруулсандаа баяртай байна." Гэсэн хэдий ч хүн болгоомжтой байх ёстой бөгөөд зөвхөн ерөнхий үр дүнг төдийгүй тухайн хэрэгт өөрийн үүргийг онцлон тэмдэглэх хэрэгтэй.

Багийн ур чадвараа мөн анкет дээрээ тодотгож өгвөл зүгээр байх. Энэ нь удирдах албан тушаалд өргөдөл гаргагчдад онцгой ач холбогдолтой юм. "Эхнээс нь үр дүнтэй маркетингийн багийг бий болгож байсан туршлагатай"; "Шинэ програм хангамжийг хэрэгжүүлэх төслийн менежмент - үр дүнтэй, үр дүнтэй багийг бий болгох, үүрэг даалгавар өгөх, үүрэг хариуцлагыг хуваарилах, одоогийн хяналт» - CV-ийн холбогдох хэсэгт багаа зохион байгуулах чадварыг онцлон тэмдэглэ.

Багийн ажил хөгждөг гэж мэргэжилтнүүд хэлж байна. Хамтран ажиллагсдынхаа санал бодлыг сонссоноор та мэргэжлийнхээ хүрээг тэлж, сэтгэл хөдлөлийн оюун ухаанаа хөгжүүлдэг.!

Гарчиг нь анхаарал татсан боловч буцалсан. Бид 1С-ийн тухай ярих болно гэдгийг би шууд хэлэх ёстой. Эрхэм 1С хоч нар аа, та гүйлгээтэй хэрхэн ажиллахаа мэдэхгүй байгаа бөгөөд үл хамаарах зүйл юу болохыг ойлгохгүй байна. Би харж байгаад ийм дүгнэлтэд хүрсэн олон тооныДотоодын аж ахуйн нэгжийн зэрлэг байгальд төрсөн 1С код. Ердийн тохиргоонд энэ нь хангалттай сайн боловч өгөгдлийн сантай ажиллах үүднээс асар их хэмжээний захиалгат кодыг чадваргүй бичсэн байдаг. Та "Энэ гүйлгээнд аль хэдийн алдаа гарсан" гэсэн алдааг харж байсан уу? Хэрэв тийм бол нийтлэлийн гарчиг танд хамаарна. Эцэст нь хэлэхэд, 1С-тэй ажиллахдаа гүйлгээ гэж юу болох, тэдгээрийг хэрхэн зөв зохицуулахыг олж мэдье.

Та яагаад сэрүүлэг дуугарах хэрэгтэй байна вэ?

Эхлэхийн тулд "Энэ гүйлгээнд аль хэдийн алдаа гарсан" гэсэн алдаа юу болохыг олж мэдье. Энэ нь үнэндээ маш энгийн зүйл юм: та аль хэдийн буцаасан (цуцлагдсан) гүйлгээ дотор мэдээллийн сантай ажиллахыг оролдож байна. Жишээлбэл, CancelTransaction аргыг хаа нэгтээ дуудсан бөгөөд та үүнийг хийхийг оролдож байна.

Яагаад ийм муу юм бэ? Учир нь энэ алдаа нь асуудал хаана үүссэн талаар юу ч хэлэхгүй. Ийм текст бүхий дэлгэцийн агшин нь хэрэглэгчээс дэмжлэг авахаар ирэхэд, ялангуяа тухайн хүн интерактив байдлаар ажилладаггүй серверийн кодын хувьд энэ нь ... Би "чухал алдаа" бичихийг хүссэн боловч энэ нь шуугиан тарьж байна гэж бодсон. хэн ч үүнийг анхаарахаа больсон .... Энэ бол бөгс. Энэ бол програмчлалын алдаа юм. Энэ бол санамсаргүй бүтэлгүйтэл биш юм. Энэ бол нэн даруй дахин засах шаардлагатай алдаа юм. Учир нь таны арын серверийн процессууд шөнийн цагаар ажиллаж, компани мөнгө хурдан алдаж эхлэх үед "Энэ гүйлгээнд алдаа гарсан байна" гэсэн нь оношилгооны бүртгэлээс харахыг хүссэн хамгийн сүүлийн зүйл юм.

Мэдээжийн хэрэг, серверийн технологийн бүртгэл (та үүнийг үйлдвэрлэлд идэвхжүүлсэн, тийм ээ?) асуудлыг оношлоход ямар нэгэн байдлаар туслах боломжтой, гэхдээ одоо би ямар нэгэн хувилбарыг бодож чадахгүй байна - жинхэнэ шалтгааныг яг яаж олох вэ? дотор нь заасан алдаа. Мөн нэг л бодит шалтгаан бий - программист Вася гүйлгээний дотор үл хамаарах зүйл авч, нэг удаа шийдсэн - karabas биш "бодож байна, энэ нь алдаа байна, -ийн үргэлжлүүлье."

1С дахь гүйлгээ гэж юу вэ

Энгийн үнэний талаар бичих нь ичмээр боловч бага зэрэг хийх хэрэгтэй болно. 1С дахь гүйлгээ нь DBMS дахь гүйлгээтэй ижил байна. Эдгээр нь зарим тусгай "1С" гүйлгээ биш, эдгээр нь DBMS дахь гүйлгээ юм. Гүйлгээний ерөнхий ойлголтын дагуу тэдгээрийг бүхэлд нь гүйцэтгэх эсвэл огт хийхгүй байх боломжтой. Гүйлгээний хүрээнд хийсэн мэдээллийн сангийн хүснэгтэд хийсэн бүх өөрчлөлтийг юу ч болоогүй юм шиг нэг дор буцаах боломжтой.

Цаашилбал, 1С-д үүрлэсэн гүйлгээг дэмждэггүй гэдгийг ойлгох хэрэгтэй. Үнэн хэрэгтээ тэдгээрийг "1С-д" биш дэмждэггүй, гэхдээ огт дэмждэггүй. Наад зах нь 1С ажиллах боломжтой DBMS. Жишээлбэл, MS SQL болон Postgres дээр үүрлэсэн гүйлгээг хийх боломжгүй. StartTransaction руу "оруулсан" дуудлага бүр гүйлгээний тоолуурыг нэмэгдүүлж, "CommitTransaction" руу залгасан дуудлага бүр тоолуурыг багасгадаг. Энэ зан үйлийг олон ном, нийтлэлд дүрсэлсэн боловч энэ зан үйлийн дүгнэлтийг хангалттай дүн шинжилгээ хийгээгүй бололтой. Хатуухан хэлэхэд SQL гэж нэрлэгддэг зүйл байдаг SAVEPOINT, гэхдээ 1C нь тэдгээрийг ашигладаггүй бөгөөд энэ нь нэлээд тодорхой юм.

Процедур Маш ашигтай&ЧухалКод(Лист лавлагааны жагсаалт) Transaction Start(); Лавлах давталтын холбоосын жагсаалтаас холбоос бүрийн хувьд лавлах объект = Reference.GetObject(); ReferenceObject.WhichField = "Би кодыг өөрчилсөн"; DirectoryObject.Write(); Төгсгөлийн мөчлөг; CommitTransaction(); Төгсгөлийн процедур

Англи хэл дээрх код

Үнэхээр биш. Би зөвхөн баяр баясгалан, ариун дайныг хөгжөөн дэмжигчдэд зориулж англи хэл дээрх жишээнүүдийг хуулбарлахыг огт хүсэхгүй байна.

Та мэдээж ийм код бичиж байгаа биз дээ? Өгөгдсөн кодын жишээнд алдаа байна. Дор хаяж гурав. Та юу мэдэх вэ? Эхнийх нь талаар би шууд хэлье, энэ нь объектын түгжээтэй холбоотой бөгөөд гүйлгээтэй шууд ямар ч холбоогүй юм. Хоёр дахь тухай - бага зэрэг дараа. Гурав дахь алдаа нь энэ кодыг зэрэгцүүлэн гүйцэтгэх үед гарах түгжрэл юм, гэхдээ энэ нь тусдаа өгүүллийн сэдэв тул бид кодыг төвөгтэй болгохгүйн тулд үүнийг одоо авч үзэхгүй. Google-ийн түлхүүр үг: гацаа удирдсан түгжээ.

Анхаарна уу, код нь энгийн. Энэ бол таны 1С систем дэх зүгээр л машин юм. Мөн энэ нь нэг дор дор хаяж 3 алдаа агуулдаг. Таны 1С програмистуудын бичсэн гүйлгээтэй ажиллахад илүү төвөгтэй хувилбаруудад хичнээн олон алдаа гардагийг чөлөөт цагаараа бодоорой :)

Объектын түгжээ

Тиймээс эхний алдаа. 1С-д "өөдрөг" ба "гутранги" гэж нэрлэгддэг объектын түгжээ байдаг. Энэ нэр томъёог хэн гаргаж ирсэн, би мэдэхгүй, алах байсан :). Аль нь юуг хариуцаж байгааг санах нь бараг боломжгүй юм. Энэ нь тэдний тухай болон бусад ерөнхий зориулалтын мэдээллийн технологийн уран зохиолын талаар дэлгэрэнгүй бичсэн байдаг.

Асуудлын мөн чанар нь заасан кодын жишээнд өгөгдлийн сангийн объект өөрчлөгдсөн боловч интерактив хэрэглэгч (эсвэл зэргэлдээх арын утас) өөр сессэд сууж болох бөгөөд энэ нь энэ объектыг мөн өөрчлөх болно. Энэ нь та нарын хэн нэгэнд "оруулга өөрчлөгдсөн эсвэл устгагдсан" гэсэн алдаа гарч болзошгүй. Хэрэв энэ нь интерактив сессийн үед тохиолдвол хэрэглэгч толгойгоо маажиж, харааж, маягтыг дахин нээхийг оролдох болно. Хэрэв энэ нь арын хэлхээнд тохиолдвол та үүнийг бүртгэлээс хайх хэрэгтэй болно. Бүртгэлийн бүртгэл, таны мэдэж байгаагаар удаан, манай салбарт 1С бүртгэлийн ELK стекийг цөөн хэдэн хүн тохируулдаг ... (дашрамд хэлэхэд, бид суулгаж, бусдад тохируулахад нь тусалдаг хүмүүсийн нэг юм. ))

Товчхондоо, энэ бол ядаргаатай алдаа бөгөөд үүнийг хийхгүй байх нь дээр. Тиймээс хөгжлийн стандартад объектыг өөрчлөхийн өмнө "хэмжээг" ашиглан объектын түгжээ хийх шаардлагатайг тодорхой заасан байдаг. ReferenceObject.Lock()". Дараа нь зэрэгцээ сесс (үүнийг хийх ёстой) өөрчлөлтийн үйлдлийг эхлүүлэх боломжгүй бөгөөд хүлээгдэж буй хяналттай бүтэлгүйтэлийг авах болно.

Одоо гүйлгээний тухай

Эхний алдааг арилгасны дараа хоёрдугаарт шилжье.

Хэрэв та энэ аргад онцгой байдлын шалгалт өгөөгүй бол үл хамаарах зүйл (жишээлбэл, "Бичлэг ()" арга нь таныг энэ аргаас хасна. гүйлгээг дуусгахгүйгээр. "Бичих" аргын үл хамаарах зүйл нь янз бүрийн шалтгааны улмаас шидэж болно, жишээлбэл, бизнесийн логик дахь зарим програмын шалгалтууд ажиллах эсвэл дээр дурдсан объектын түгжээ үүсэх болно. Ямар ч байсан хоёр дахь алдаа нь: гүйлгээг эхлүүлсэн код нь түүний гүйцэтгэлд хариуцлага хүлээхгүй.

Би энэ асуудлыг ингэж нэрлэх болно. SonarQube дээр суурилсан 1С статик кодын анализатор дээр бид ийм оношилгоог тусад нь суулгасан. Одоо би түүний хөгжүүлэлт дээр ажиллаж байгаа бөгөөд код нь надад дүн шинжилгээ хийхээр ирдэг 1С програмистуудын уран зөгнөл заримдаа намайг цочирдуулж, гайхшруулдаг ...

Яагаад? Учир нь тохиолдлын 90% -д нь гүйлгээний дотор үүссэн үл хамаарах зүйл нь энэ гүйлгээг засахыг зөвшөөрөхгүй бөгөөд алдаа гаргахад хүргэдэг. 1С нь скрипт кодоос платформ кодын түвшинд буцаж ирсний дараа л бүрэн бус гүйлгээг автоматаар буцаана гэдгийг ойлгох хэрэгтэй. Та 1С кодын түвшинд байгаа л бол гүйлгээ идэвхтэй хэвээр байна.

Дуудлагын стекийн нэг түвшинд гарцгаая:

Процедур ImportantCode() LinkList = GetWhereToLinkList(); Маш ашигтай, чухал код (Лавлах жагсаалт); Төгсгөлийн процедур

Юу болохыг хараарай. Манай асуудлын аргагадаах хаа нэгтээгээс, стекээс дээш дуудлаа. Энэ аргын түвшинд маш ашигтай, чухал кодын аргын дотор ямар нэгэн гүйлгээ хийх эсэхийг хөгжүүлэгч мэдэхгүй. Хэрэв тэд ингэвэл тэд бүгд дуусгавар болох уу ... Бид бүгд энх тайван, хамрах хүрээний төлөө энд байна, тийм үү? "Чухал код" аргын зохиогч түүний дуудсан аргын дотор яг юу болж байгааг бодох ёсгүй. Гүйлгээ буруу хийгдсэн нэг. Үүний үр дүнд гүйлгээ дотроос онцгой тохиолдол гаргасны дараа мэдээллийн сантай ажиллах оролдлого нь өндөр магадлалтайгаар "Энэ гүйлгээнд бла бла ..." гэсэн дүгнэлтэд хүргэнэ.

Гүйлгээг аргуудаар гүтгэх

"Гүйлгээний аюулгүй" кодын хоёр дахь дүрэм: аргын эхэнд болон төгсгөлд гүйлгээний лавлагааны тоо ижил утгатай байх ёстой. Та гүйлгээг нэг аргаар эхлүүлж, өөр аргаар дуусгах боломжгүй. Та энэ дүрмийн үл хамаарах зүйлийг олж мэдэх боломжтой, гэхдээ энэ нь илүү чадварлаг хүмүүсийн бичсэн зарим төрлийн доод түвшний код байх болно. Ер нь ингэж бичиж болохгүй л дээ.

Жишээлбэл:

Процедур ImportantCode() LinkList = GetWhereToLinkList(); Маш ашигтай, чухал код (Лавлах жагсаалт); CommitTransaction(); // Там руу явах тасалбар, бидний хөдөлмөрийн хүнд хэцүү харилцааны талаар зохиолчтой хийсэн ноцтой яриа. Төгсгөлийн процедур

Дээрх нь хүлээн зөвшөөрөгдөхгүй новшийн код юм. Аргуудыг дууддаг хүн дуудаж буй бусад аргуудын хүрээнд хийж болох (эсвэл магадгүй - хэн мэдэх) гүйлгээг санаж, хянаж байхаар бичиж болохгүй. Энэ нь эрүүл саруул байдлыг хадгалахын зэрэгцээ битүүмжлэл, спагетти кодын өсөлтийг зөрчсөн явдал юм.

Бодит код нь 3 мөрийн синтетик жишээнүүдээс хамаагүй том гэдгийг санах нь ялангуяа хөгжилтэй байдаг. Зургаан түвшний үүрлэх гүйлгээг эхлүүлэх, дуусгахыг хайж олох нь зохиогчидтой зүрх сэтгэлээсээ яриа өрнүүлэхэд шууд түлхэц болдог.

Кодоо засах гэж оролдож байна

Анхны арга руугаа буцаж очоод үүнийг засахыг хичээцгээе. Жишээ кодыг хүндрүүлэхгүйн тулд бид объектын түгжээг хараахан засахгүй гэдгийг би шууд хэлэх ёстой.

Ердийн 1С хочны анхны хандлага

Ихэвчлэн 1С програмистууд бичихдээ үл хамаарах зүйл тохиолдож болно гэдгийг мэддэг. Тэд бас үл хамаарах зүйлээс айдаг тул бүгдийг нь барьж авахыг хичээдэг. Жишээлбэл, иймэрхүү:

Процедур Маш ашигтай&ЧухалКод(Лист лавлагааны жагсаалт) Transaction Start(); Лавлах давталтын холбоосын жагсаалтаас холбоос бүрийн хувьд лавлах объект = Reference.GetObject(); ReferenceObject.WhichField = "Би кодыг өөрчилсөн"; ReferenceObject.Write(); Exception Log.Error("%1 элементийг бичиж чадсангүй", Лавлагаа); Үргэлжлүүлэх; оролдлогын төгсгөл; Төгсгөлийн мөчлөг; CommitTransaction(); Төгсгөлийн процедур

За, сайхан болсон, тийм үү? Эцсийн эцэст одоо бичлэг хийх боломжтой алдаануудыг боловсруулж, бүр бүртгэж байна. Объектыг бичихэд үл хамаарах зүйлүүд цаашид хаягдахаа болино. Бүртгэлээс ч гэсэн харж болно - тэр ямар ч объект дээр тэр хэтэрхий залхуу биш байсан, "Лавлах оруулах алдаа" гэсэн товчлолын оронд зурваст холбоосыг харуулсан, үргэлж яарч байдаг хөгжүүлэгчид ихэвчлэн бичих дуртай байдаг. Өөрөөр хэлбэл, хэрэглэгч болон ур чадварын өсөлтөд санаа зовдог.

Гэсэн хэдий ч туршлагатай 1С хоч нь "үгүй ээ, энэ нь дээрдсэнгүй" гэж хэлэх болно. Үнэн хэрэгтээ юу ч өөрчлөгдөөгүй, магадгүй бүр дорддог. "Write()" аргын хувьд 1С платформ өөрөө бичих гүйлгээг эхлүүлэх бөгөөд энэ гүйлгээ нь манайхтай холбоотой аль хэдийн үүрлэгдсэн байх болно. Хэрэв мэдээллийн сантай ажиллах үед 1С гүйлгээгээ буцаах юм бол (жишээлбэл, бизнесийн логикийн үл хамаарах зүйл тохиолдвол) манай дээд түвшний гүйлгээ "муухай" гэж тэмдэглэгдсэн хэвээр байх бөгөөд үүнийг хийх боломжгүй болно. засаарай. Үүний үр дүнд энэ код нь асуудалтай хэвээр байх бөгөөд таныг үйлдэх гэж оролдох үед "алдаа аль хэдийн гарсан" гэж харуулах болно.

Одоо бид жижиг аргын тухай биш, харин хамгийн доод хэсэгт хэн нэгэн өөрийн аргаас эхэлсэн гүйлгээг авч, "сулласан" гүнзгий дуудлагын стекийн тухай ярьж байна гэж төсөөлөөд үз дээ. Дээд түвшний журамд хэн нэгэн доод талын гүйлгээ хийж эхэлсэн тухай ойлголтгүй байж болно. Үүний үр дүнд бүхэл бүтэн код нь тодорхойгүй алдаатай гацсан бөгөөд үүнийг зарчмын хувьд судлах боломжгүй юм.

Гүйлгээг эхлүүлэх код нь үүнийг дуусгах эсвэл буцаахад шаардлагатай.Ямар ч үл хамаарах зүйлээс үл хамааран. Арга нь гүйлгээ хийх эсвэл цуцлахгүйгээр гарах эсэхийг шалгахын тулд кодын зам бүрийг шалгах хэрэгтэй.

1С дахь гүйлгээтэй ажиллах арга

Ерөнхийдөө 1С нь бидэнд ажиллах гүйлгээг өгдөг гэдгийг санах нь илүүц байх болно. Эдгээр нь алдартай аргууд юм:

• Гүйлгээг эхлүүлэх()
• Гүйлгээ хийх()
• Цуцлах Гүйлгээ()
• TransactionActive()

Эхний 3 арга нь ойлгомжтой бөгөөд тэдний нэр дээр хэлсэн зүйлийг хийдэг. Сүүлийн арга нь гүйлгээний тоо тэгээс их байвал Үнэнийг буцаана.

Мөн нэг сонирхолтой онцлог бий. Гүйлгээнээс гарах аргууд (Commit and Cancel) нь гүйлгээний тоо тэг байвал үл хамаарах зүйлүүдийг гаргадаг. Өөрөөр хэлбэл, хэрэв та тэдгээрийн аль нэгийг нь гүйлгээний гадна дуудвал алдаа гарна.

Эдгээр аргуудыг хэрхэн зөв ашиглах вэ? Маш энгийн: та дээр дурдсан дүрмийг унших хэрэгтэй.

Та энэ дүрмийг хэрхэн дагаж мөрдөх вэ? Оролдоод үзье:

DoSomething арга нь аюултай байж болзошгүйг дээр бид аль хэдийн ойлгосон. Энэ нь зарим төрлийн үл хамаарах зүйлийг хаяж болох бөгөөд гүйлгээ нь бидний аргаас "мөлхөх" болно. За, боломжит үл хамаарах зохицуулагчийг нэмье:

Start Transaction(); DoSomething оролдлого(); Үл хамаарах зүйл // энд юу бичих вэ? оролдлогын төгсгөл; CommitTransaction();

Гайхалтай, бид гарсан алдааг олж мэдсэн, гэхдээ үүнийг яах вэ? Бүртгэлд мессеж бичих үү? Магадгүй алдааны бүртгэлийн код яг энэ түвшинд байх ёстой бөгөөд бид энд алдааг хүлээж байна. Тэгээд үгүй ​​бол? Хэрэв бид энд ямар нэгэн алдаа гарна гэж бодоогүй бол? Дараа нь бид дээрх үл хамаарах зүйлийг зүгээр л давж, архитектурын өөр давхарга нь тэдгээрийг шийдвэрлэх ёстой. Энэ нь "CauseException" операторын тусламжтайгаар ямар ч аргументгүйгээр хийгддэг. Таны эдгээр java sippluses-д энэ нь throw хэллэгтэй яг адилхан хийгддэг.

Start Transaction(); DoSomething оролдлого(); Exception ThrowException; оролдлогын төгсгөл; CommitTransaction();

Тэгэхээр, түр хүлээнэ үү... Хэрэв бид үл хамаарах зүйлийг цааш нь хаях юм бол яагаад Try гэж ерөөсөө байдаг юм бэ? Яагаад гэвэл: дүрэм нь бидний эхлүүлсэн гүйлгээг дуусгахыг шаарддаг.

Start Transaction(); DoSomething оролдлого(); Exception CancelTransaction(); ThrowException; оролдлогын төгсгөл; CommitTransaction();

Одоо бол гоё юм шиг байна. Гэсэн хэдий ч бид DoSomething() кодонд итгэдэггүй гэдгээ санаж байна. Гэнэт түүний зохиогч энэ нийтлэлийг уншаагүй бөгөөд гүйлгээтэй хэрхэн ажиллахаа мэдэхгүй байна уу? Гэнэт тэр үүнийг тэнд аваачиж, CancelTransaction аргыг дуудаж, эсвэл эсрэгээр нь зассан уу? Энэ нь бидний хувьд маш чухал юм Онцгой байдлын зохицуулагч шинэ онцгой тохиолдол гаргаагүй, эс тэгвээс анхны алдаа алдагдаж, асуудлыг судлах боломжгүй болно. Хэрэв гүйлгээ байхгүй бол Commit болон Cancel аргууд нь онцгой тохиолдол гаргаж болно гэдгийг бид санаж байна. Энд TransactionActive арга хэрэг болно.

эцсийн хувилбар

Эцэст нь бид зөв, "гүйлгээний аюулгүй" кодыг бичиж болно. Тэр энд байна:

Start Transaction(); DoSomething оролдлого(); Үл хамаарах зүйл бол TransactionActive() Дараа нь CancelTransaction(); EndIf; ThrowException; оролдлогын төгсгөл; CommitTransaction();

Хүлээгээрэй, энэ нь зөвхөн "CancelTransaction" биш алдаа гаргадаг. Яагаад "CommitTransaction" нь "TransactionActive"-тэй ижил нөхцөлд ороогүй байна вэ? Дахин хэлэхэд ижил дүрмийг баримтална: гүйлгээг эхлүүлсэн код нь түүнийг дуусгах үүрэгтэй байх ёстой.Бидний гүйлгээ нь эхнийх нь байх албагүй, үүнийг үүрлэх боломжтой. Хийсвэрлэлийн түвшинд бид зөвхөн гүйлгээгээ анхаарч үзэхийг шаарддаг. Бусад бүх зүйл бидэнд сонирхолгүй байх ёстой. Тэд танихгүй хүмүүс, бид тэдний өмнөөс хариуцлага хүлээх ёсгүй. Яг ҮГҮЙ. Гүйлгээний тоолуурын бодит түвшинг мэдэхийг оролдох ёсгүй. Энэ нь дахин капсулыг эвдэж, гүйлгээний удирдлагын логикийг "түрхэхэд" хүргэнэ. Бид зөвхөн онцгой тохиолдлын зохицуулагчийн үйл ажиллагааг шалгасан бөгөөд зөвхөн өөрийн зохицуулагчийг баталгаажуулахын тулд хуучин нэгийг нь "нуух" шинэ үл хамаарах зүйл үүсгэхгүй.

Дахин засварлах шалгах хуудас

Кодод хөндлөнгөөс оролцох шаардлагатай хамгийн нийтлэг тохиолдлуудыг авч үзье.

Загвар:

Start Transaction(); Ямар нэг юм хий(); CommitTransaction();

Try, Keep alive гэсэн "аюулгүй" бүтээцийг боож, үл хамаарах зүйлийг хая.

Загвар:

Хэрэв TransactionActive() биш бол Transaction() EndIf-ийг эхлүүлнэ үү

Шинжилгээ ба рефакторинг. Зохиогч юу хийж байгаагаа мэдэхгүй байсан. Оруулсан гүйлгээг эхлүүлэх нь аюулгүй. Та нөхцөлийг шалгах шаардлагагүй, зөвхөн үүрлэсэн гүйлгээг эхлүүлэх хэрэгтэй. Модулийн доор, Тэр магадгүй одоо ч гэсэн тэдний засах тэнд perverts. Энэ нь баталгаатай hemorrhoids юм.

Ойролцоогоор ижил төстэй сонголт:

Хэрэв TransactionActive() бол CommitTransaction() EndIf

үүнтэй адил: нөхцөлөөр гүйлгээ хийх нь хачирхалтай. Яагаад нөхцөл байдаг вэ? Юу вэ, өөр хэн нэгэн энэ гүйлгээг аль хэдийн хийсэн байж болох уу? Шүүхийн маргаан үүсгэх шалтгаан.

Загвар:

StartTransaction() While Selection.Next() Loop // объектыг лавлагаагаар унших // EndCycle объект бичих; CommitTransaction();

1. мухардлаас зайлсхийхийн тулд удирдаж буй түгжээг нэвтрүүлэх
2. Block дуудлагын аргыг оруулна уу
3. дээр үзүүлсэн шиг "оролдох" гэж боож өгнө

Загвар:

StartTransaction() While Selection.Next() Loop Attempt Object.Write(); Онцгой байдлын тайлан("Бичиж чадсангүй"); оролдлогын төгсгөл; Төгсгөлийн мөчлөг; CommitTransaction();

Онцгой тохиолдолд энэ гүйлгээг цаашид хийхгүй. Циклийг үргэлжлүүлэх нь утгагүй юм. Анхны даалгавартай холбогдуулан кодыг дахин бичих шаардлагатай. Сонголтоор илүү мэдээлэлтэй алдааны мессеж өгнө үү.

Эцэст нь

Би, магадгүй та аль хэдийн таамаглаж байсанчлан, 1С платформ, түүн дээр хөгжүүлэлт хийх дуртай хүмүүст харьяалагддаг. Мэдээжийн хэрэг, платформ, ялангуяа Highload орчинд гомдол байдаг, гэхдээ ерөнхийдөө энэ нь маш өндөр чанартай корпорацийн програмуудыг хямд, хурдан боловсруулах боломжийг олгодог. Хайрцагнаас гаргаж өгөх, ORM, GUI, вэб интерфэйс, тайлан гаргах гэх мэт. Хабре дээрх сэтгэгдэл дээр тэд ихэвчлэн ихэмсэг зүйл бичдэг тул 1С-ийн экосистемийн гол асуудал бол платформ эсвэл борлуулагч биш юм. Энэ бол компьютер, өгөгдлийн сан, клиент-сервер, сүлжээ гэх мэт юу болохыг ойлгодоггүй хүмүүст энэ салбарт нэвтрэх боломжийг олгодог хэтэрхий бага босго юм. 1С нь аж ахуйн нэгжийн хэрэглээний програмыг хөгжүүлэхэд хэтэрхий хялбар болгосон. 20 минутын дотор би уян хатан тайлан, вэб клиент бүхий худалдан авалт / борлуулалтын нягтлан бодох бүртгэлийн системийг бичиж чадна. Үүний дараа би өөрийнхөө тухай бодоход хялбар байдаг, та том хэмжээний хувьд ижил аргаар бичиж болно. Ямар нэгэн байдлаар 1С бүх зүйлийг өөрөө хийх болно, би яаж хийхээ мэдэхгүй байна, гэхдээ үүнийг хийх байх. Би "Гүйлгээг эхлүүлэх ()" гэж бичнэ ....

Мөн та мэднэ - хамгийн чухал зүйл бол энэ нь гайхалтай юм. 1С-ийг хөгжүүлэхэд хялбар байдал нь бизнесийн санааг шууд хэрэгжүүлэх, компанийн үйл явцад нэгтгэх боломжийг олгодог. Дараа нь та үргэлж refactor хийж болно, гол зүйл бол яаж гэдгийг ойлгох явдал юм. Хэрэв гэнэт "удаан 1С"-ээ аудит хийхэд тусламж хэрэгтэй бол оновчлолын мэргэжилтнүүдтэй холбоо барина уу. Тэр огт удаан биш.

Ажилтан бүр өөрийн байрандаа байж, хамт ажиллагсадтайгаа чадварлаг харилцдаг багийн бүтээмж нь Крыловын хэлснээс хамаагүй өндөр байдаг. "Нөхдүүдийн дунд тохиролцоо байхгүй". Бараг бүх ажил олгогч өргөдөл гаргагчийг "багаар ажиллах" чадвартай байхыг хүсдэг.

Багийн гишүүн байх нь юу гэсэн үг вэ, ажил хайж байхдаа үүнийг хэрхэн өөртөө ашигтайгаар ашиглах талаар ярилцдаг.

Ямар амьтан бэ?

Эхлээд түүнийг ямар багийн тоглогч болохыг олж мэдье.

Мэдээжийн хэрэг, та намтартаа хамт ажиллагсадтайгаа хэр сайн, нийтэч, түүнээс ч илүү байж чаддаг гэдгээ тодорхойлсон. "Эхнээс нь баг бий болгох", "хариуцлагыг хуваарилах", "даалгавар тавих, хянах".

Гэхдээ асуулт бол: Ярилцлагын үеэр багийн тоглогч олох талаар санаа зовж буй ажил олгогчийг та түүнд яг хэрэгтэй хүн гэдэгт хэрхэн итгүүлэх вэ?

Энд бусад ур чадварын тухай үлгэрийн нэгэн адил баримтаар ажилла. Борлуулалтыг нэмэгдүүлэхийн тулд нийт хэлтэст хүрсэн үү? - Агуу их! Тэд хамтдаа компани эсвэл бүтээгдэхүүнийг зах зээлд танигдахуйц болгож чадсан уу? - Гайхалтай! Та вэбсайт эсвэл програмын кодын хэсгийг бичсэн үү? - За, энд байна!

Нэмж дурдахад, та юунд хүрч чадсан тухайгаа ярихдаа монологт зөвхөн төлөөний үг биш байгаа эсэхийг шалгаарай. "Би"- ашиглах "Бид"Тэгээд "манай". Жишээлбэл, "Бид даалгавраа өндөр чанартай гүйцэтгэж, үйлчлүүлэгч бидний ажлын үр дүнд сэтгэл хангалуун байсан"эсвэл “Манай хэлтэс тайлант хугацааны үр дүнг дүгнэж шилдэгээр шалгарлаа”.

Гэхдээ өөрийнхөө тухай бүү март. Гэсэн хэдий ч та ажил олж, амжилттай карьераа бий болгохын тулд өөрийгөө сурталчлахын тулд хувь нэмэр оруулах шаардлагатай. Тиймээс нийтлэг үйл хэрэгт ямар хувь нэмэр оруулснаа тайлбарла. Тиймээс та хувийн амжилтынхаа талаар боловсон хүчний ажилтанд мэдэгдэх боломжтой болно. Та хэрхэн хамтран ажиллахаа мэддэг гэдгээ онцолж, мэргэжлийн багийн сайн зохицуулалттай ажлын ач холбогдлыг ойлгох боломжтой болно.

Багийн тоглоомууд хүн болгонд байдаггүй

Гэсэн хэдий ч, багийн тоглогч байхын тулд хүн бүр ижил чадвартай байх шаардлагагүй. Эцсийн эцэст, бие даасан шийдвэр гаргах, бие даасан үр дүнд хүрэх шаардлагатай ажил нь тодорхой бие даасан байдалтай холбоотой хүмүүс байдаг.

Энэ ангилалд судлаач эрдэмтэд (мэдээжийн хэрэг хэд хэдэн хүн ажилладаг судалгааны төслийн тухай яриагүй бол), (гэхдээ мэс засалч, сувилагч нарыг хамтад нь мэс засал хийдэг баг гэж үзэж болно), (үл хамаарах зүйл) Зураг авалтын багийн бүрэлдэхүүнд ажиллаж буй телевизийн сэтгүүлчдийг тоолж болно) гэх мэт.

Та багийн тоглогчдын ангилалд хамаарах эсэхээ өөрөө ойлгох нь чухал юм. Магадгүй та ур чадвараа дээшлүүлэх явцдаа хамт ажиллагсадтайгаа өрсөлдөхөөр зэхэж буй ганц мэргэжилтэн байж магадгүй юм. Яг ийм ажилчдыг илүүд үздэг ажил олгогчдын тодорхой ангилал байдаг. Үүнийг ойлгосноор та өөртөө хамгийн тохь тухтай ажлын байрыг сонгох боломжтой бөгөөд үүний зэрэгцээ зөрчилдөөний оролцогч болохгүй.

Хэрэв гэнэт мөрөөдлийн ажил тань таныг дүрээ өөрчлөхийг шаардах юм бол ажлын хэв маягаа өөрчлөхөд хэзээ ч оройтдоггүй.