Работодатели любят спрашивать о стрессоустойчивости, а вы так хотите получить новую работу, что тут же готовы подтвердить готовность вкалывать в ситуации аврала. Но не спешите сразу говорить «да» - это может навредить вашей карьере и здоровью.
Не стоит говорить на собеседовании, что лучше всего вы действуете в экстренных ситуациях. Такое заявление, особенно в однозначно жесткой форме, может насторожить работодателя. Он подумает, что в иных условиях вы чувствуете себя дискомфортно. Обычно не следует затрагивать эту тему без соответствующего вопроса со стороны рекрутера или потенциального начальника. Но если в ходе собеседования вам становится ясно, что в компании авралы являются обычным делом, то упомянуть свой успешный опыт работы в экстренных ситуациях можно и нужно.
Когда работодатель подбирает себе сотрудника, он часто выясняет, сможет ли претендент работать в условиях пиковых нагрузок, есть ли у него опыт подобной деятельности и может ли его это испугать. В некоторых сферах (строительство, туризм, сбыт некоторых продуктов питания и другие) есть сезонные пики. Авралы могут быть связаны с временем суток или определенными днями (ресторанный бизнес, розничная торговля). Или, например, у бухгалтеров - с периодом подготовки сдачи отчетности.
Соискателю всегда проще, если работодатель напрямую спрашивает, как человек чувствует себя в условиях высокой загруженности. Тогда стоит сказать, что у вас есть такой опыт и вы спокойно относитесь к подобным ситуациям. Но нельзя говорить, что в этих условиях вы работаете лучше всего. Ваш интервьюер может подумать, что размеренная офисная деятельность по плану очень быстро может вам наскучить. Лучше представлять себя универсалом с этой точки зрения. Поэтому ответьте, например, так: «Конечно, мне нравится работать, когда все четко и по плану, но если аврал случается, то ничего страшного, без этого в бизнесе нельзя».
Для иллюстрации приведу пример, взятый из интервью с претендентом на должность менеджера направления в туристическое агентство.
- В нашем бизнесе бывают разные периоды и ситуации. В какой обстановке вам работается лучше?
- В период отпусков, перед новогодними и майскими праздниками, перед детскими каникулами нагрузки бывают пиковые. В это время работать интереснее всего. Важно не упустить ни одного клиента - четкое планирование всех контактов, повышение интенсивности, переработки.
- А если затишье?
- Всегда есть такая работа, которую можно и нужно делать в такие периоды. Важно поддерживать контакты со старыми клиентами, собирать и готовить информацию для очередного горячего сезона, разрабатывать новые предложения. Если человек знает и любит свое дело, ему всегда есть чем заняться.
У нанимателя должно сложиться впечатление, что вы всегда готовы работать в режиме, которого требует ситуация.
Есть два психологических портрета человека. Кого из них вы бы взяли к себе в команду?
Первый портрет: покладистый, улыбчиво-приветливый, нескандальный, готовый уступать, неконфликтный, ставит общие интересы выше своих, готов ради общего дела пойти против личных амбиций, «не высовывается», всегда открыт к общению.
Второй портрет: принципиальный и амбициозный, имеет и отстаивает по любому вопросу свое мнение, непослушный и своенравный, всегда готов к конфликту, экспертный и знает об этом, яркий и эгоцентричный, не готов идти на ущерб личных интересов, не умеет уступать.
Кого выберете вы? Какой ответ правильный?
Прежде чем его озвучить, позвольте задать вспомогательные вопросы.
- В чем специфика командного взаимодействия?
- Для чего нужна команда?
- Кто нужен команде?
- Чем отличается команда от любого другого коллектива, группы, отдела, бригады?
И коллектив, и группа, и отдел, и бригада, и команда решают какие-то бизнес-цели. Они могут быть краткосрочными или долгосрочными. Но отличие команды в том, что у нее всегда есть свои внутренние цели, связанные с развитием команды в целом и каждого ее участника лично.
Зачем это надо команде? А дело в том, что настоящая команда и ее лидер ставят такие цели, которые невозможно достичь без развития всех ее членов. Поэтому команды бывают либо развивающимися, либо мертвыми.
Отсюда ответ на вопрос: «кто нужен команде»? Тот, кто будет способствовать ее развитию. За счет чего развиваются команда и бизнес? За счет качественных, продуманных, взвешенных и своевременных решений.
Способен ли один человек принимать постоянно по всем вопросам лучшие решения? Нет. Потому что каким бы он разносторонним ни был, его взгляд все равно ограничен его компетенциями и его представлениями о мире.
Для качественного решения нужны разные, порой полярные мнения, нужны хорошие сомнения и несогласия, нужен горячий обмен суждениями. И для этого нужны люди со своей позицией, готовые отстаивать и не соглашаться.
Если вы в команде думаете одинаково, согласны друг с другом, быстро находите консенсус, ловите на лету, находитесь «на одной волне» - значит, все, кроме одного, в ней лишние. Они - бесполезные клоны.
Но ведь это чревато постоянными конфликтами. Не будет ли это разрушать команду?
Конфликт - это столкновение противоречивых мнений. Может ли столкновение мнений само по себе что-то разрушить? Могут ли фразы, слова, буквы сами по себе обладать деструктивным действием? Нет! Их таковыми делают люди. Деструктивный конфликт происходит не от того, что люди о чем-то спорят, а от того, как они спорят.
И умение работать в команде по большому счету состоит из умения конфликтовать, не разрушая себя и других. Сами посудите, что может быть сильнее команды, в которой очень разные и очень сильные люди умеют вместе искать сильные решения, становясь каждый раз сильнее?
В таком случае возникает логичный вопрос: а что значит «уметь конфликтовать»?
Умение конфликтовать - это умение спорить, доказывать, не соглашаться, оставаясь конструктивным, не вызывая у других желания защищаться и нападать, не обижая чувств другого человека, помня о целях этой дискуссии, не теряя своего достоинства и не умаляя достоинства других. Все это называется одним словом: «Уважение».
Командный игрок - это человек, способный проявлять уважение к другим и вызывать уважение к себе. Уважение - двустороннее явление.
Как протестировать способность человека к уважению?
Это проявляется в том, как человек с вами не соглашается, как реагирует на несогласие с ним, как отзывается о других и соблюдает правила.
Понятно, что заставить уважать кого-либо силой невозможно. Также невозможно измерить степень уважения друг к другу. И то, что для одного кажется верхом уважения, другому может показаться оскорблением.
Но также возможно создать в команде общую культуру взаимоуважения, основанную на принятых правилах. Эти правила формируются сообща из ответов на вопрос: «Что нам мешает чувствовать взаимное уважение»?
Ответов будет много: мы опаздываем на совещания, перебиваем друг друга, не слушаем, отвлекаемся на посторонние вопросы, не пытаемся понять точку зрения другого, а стараемся продавить свою, перехватываем инициативу, не даем слова тихоням. Из этих ответов и формируются правила.
И каков же правильный ответ на вопрос о том, кого бы взяли в команду?
Есть люди удобные, а есть люди полезные. Редко это совмещается. Если вы хотите работать в комфорте и без конфликтов, то вам не нужна взаимодополняющая развивающаяся команда.
Если же от ваших целей и амбиций у вас захватывает дух, то вам нужны хорошие решения и отличные помощники. Лучшие помощники - это люди, несогласные с вами и готовые с уважением отстаивать свою точку зрения, не обижая вас. Они будут находить изъяны в ваших решениях, открывать для вас другие ракурсы, позволять смотреть на ситуацию с разных сторон, видеть подводные камни и заранее обращать внимание на детали.
Говоря об умении работать в команде, я вспоминаю притчу о том, как человек по дороге в рай попросил показать ему ад. И он был очень удивлен, потому что увидел красивое изобильное место, полные столы с нетронутыми яствами и злых голодных людей. На вопрос, почему они голодные, ему ответили, что здесь можно кушать только трехметровыми палочками. Человек посочувствовал и оказался в раю. Там он увидел точно такую же картину, только люди были сытые и довольные. Он первым делом спросил, чем они тут кушают, и ему ответили, что трехметровыми палочками. Он удивился еще сильнее, пока ему не объяснили, что здесь, в раю, люди научились кормить друг друга.
Приветствую Вас, дорогой друг! Сегодня я хочу спросить Вас, что Вы знаете о презентациях? Умеете ли Вы их создавать и пользоваться программой PowerPoint?
Могу с уверенностью сказать, что примерно только 45% пользователей знают все фишки программы PowerPoint и умеют создавать такие презентации глядя на которые, можно просто любоваться!
В основном люди создают слайдоменты. Что это такое спросите Вы? Чем отличаются слайдоменты от простых презентаций?
Все очень просто, слайдоментами называют презентацию, которая содержит только текстовую информацию. Нет картинок, анимации, переходов и других фишек программы.
Когда-то давно, около 12 лет назад я тоже не знала об этой программе и совершенно не умела ею пользоваться. Хотя вроде бы была студенткой университета и училась на специальности прикладная математика. Нас учили программировать, составлять коды и делать программы.
Но вот элементарному Wordу и тем более PowerPointу нас не обучали. Только на 4 курсе университета нам поступили «крутые» по тем временам компьютеры типа Pentium 2. И в них был установлен Windows 98, а также Office 1997. На туда запускали только на 3 часа в неделю и успели мы познакомиться только с программами Word и Excel.
До программ PowerPoint руки у преподавателей не дошли. Да в то время еще не было так развито создавать презентации и делать крутые выступления со слайдами! Это сейчас без слайдов ни один оратор выступать не будет, начиная от учащегося и заканчивая президентом.
В общем пришла я в среднюю школу преподавать информатику. Вся такая очень молодая и неопытная. И тут меня ждал огромный сюрприз! Оказывается, что нашим ученикам преподают информатику только с 10 класса и ни о каком программировании речи не идет!
То есть все, чему меня обучали в университете 4 года, оказалось не нужным! Учащимся нужно было преподавать Word, Excel, PowerPoint.
И вот тут мне пришлось вооружиться книгами и начать самообразование, это после четырех лет обучения в университете! Буквально за месяц я изучила программу PowerPoint во всех деталях, научилась создавать слайды, вставлять картинки, менять дизайн, настраивать анимацию. Всего этого вполне хватило, чтобы я преподавала прекрасные уроки.
Но со временем когда стали появляться интерактивные доски, проекторы и в каждом доме появился компьютер и интернет, информатику преподавать стали в 7-го класса. Мои университетские знания пригодились, стали вводить программирование, потом объектно-ориентированное программирование. То есть мой диплом и все мои знания ПРИГОДИЛИСЬ! Это очень хорошо. Но речь не об этом.
Сейчас, когда без презентации не обходится ни одно выступление и учащиеся умеют сами прекрасно все это сделать меня удивляет один момент. Наше взрослое поколение, более старшего возраста, чем я, и даже мои ровесники до сих пор не владеют этой программой!
Некоторые не умеют вообще элементарно создать презентацию, написать текст, не говоря уже о том, чтобы вставить картинку или диаграмму, настроить анимацию и выставить автоматическую смену слайдов.
А ведь все это делается в 2-3 клика! Я не говорю уже о том, что можно самостоятельно настроить любой цветовой фон, или же своими руками создать шаблон для презентации. Именно такой, какой нужен Вам, под ВАШИ нужды, а не то, который стоит в стандартных загрузках программы или скаченные из интернета.
Многие не умеют скачать эти шаблоны с интернета и загрузить их в программу. А ведь все это легко делается, быстро и бесплатно!
Расскажу еще про одну фишку. При помощи презентации можно сделать очень интересны мультики. И мы с ребятами на уроках делали эти мультфильмы. Им очень понравилось, так увлекательно и интересно! Фантазия у них развита, а если еще прикрепить эту фантазию к техническим моментам вроде бы обычной программы PowerPoint? То они просто в восторге! За 1-2 урока мы успеваем сделать мультик на 10-15 секунд. Это мало, но это сделано их руками и их мозгами. Вот что сейчас очень ценят дети.
Я могу еще много рассказывать про преимущества программы PowerPoint. И то, что с ее помощью можно создавать тесты, как обучающие, так и контролирующие. Создавать кроссворды, которые можно сразу же заполнять и выводить результат.
Ну а в интернете без программы PowerPoint просто никуда. Если Вы смотрели мой видеоурок по созданиям видеороликов, то наверное помните, что начинается каждый урок со слайда и надписи. Так вот, это сделано тоже в программе PowerPoint. Потом с помощью другой программы Campasia записана с экрана и наложен звук. Таким образом и сделан весь курс.
Без знания программы PowerPoint сейчас никуда. В школе, университете, в офисе, на семинарах, выступлениях, в интернете, везде нужна презентация. Без нее никуда!
Я училась всем этим фишкам и нюансам почти 12 лет. Теперь могу с уверенностью сказать, что смогу обучить любого.
А как думаете Вы, нужна ли эта программа и нужно ли вообще забивать ей голову? Напишите в комментариях, что Вы думаете по этому поводу.
Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку "В данной транзакции уже происходили ошибки"? Если да - то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.
Почему надо бить тревогу
Для начала, давайте разберемся, что же такое представляет собой ошибка "В данной транзакции уже происходили ошибки". Это, на самом деле, предельно простая штука: вы пытаетесь работать с базой данных внутри уже откаченной (отмененной) транзакции. Например, где-то был вызван метод ОтменитьТранзакцию, а вы пытаетесь ее зафиксировать.
Почему это плохо? Потому что данная ошибка ничего не говорит вам о том, где на самом деле случилась проблема. Когда в саппорт от пользователя приходит скриншот с таким текстом, а в особенности для серверного кода, с которым интерактивно не работает человек - это… Хотел написать "критичная ошибка", но подумал, что это buzzword, на который уже никто не обращает внимания…. Это задница. Это ошибка программирования. Это не случайный сбой. Это косяк, который надо немедленно переделывать. Потому что, когда у вас фоновые процессы сервера встанут ночью и компания начнет стремительно терять деньги, то "В данной транзакции уже происходили ошибки" это последнее, что вы захотите увидеть в диагностических логах.
Есть, конечно, вероятность, что технологический журнал сервера (он ведь у вас включен в продакшене, да?) как-то поможет диагностировать проблему, но я сейчас навскидку не могу придумать вариант - как именно в нем найти реальную причину указанной ошибки. А реальная причина одна - программист Вася получил исключение внутри транзакции и решил, что один раз - не карабас "подумаешь, ошибка, пойдем дальше".
Что такое транзакции в 1С
Неловко писать про азбучные истины, но, видимо, немножго придется. Транзакции в 1С - это то же самое, что транзакции в СУБД. Это не какие-то особенные "1С-ные" транзакции, это и есть транзакции в СУБД. Согласно общей идее транзакций, они могут либо выполниться целиком, либо не выполниться совсем. Все изменения в таблицах базы данных, выполненные внутри транзакции, могут быть разом отменены, как будто ничего не было.
Далее, нужно понимать, что в 1С не поддерживаются вложенные транзакции. Собственно говоря, они не поддерживаются не "в 1С", а вообще не поддерживаются. По-крайней мере, теми СУБД, с которыми умеет работать 1С. Вложенных транзакций, например, нет в MS SQL и Postgres. Каждый "вложенный" вызов НачатьТранзакцию просто увеличивает счетчик транзакций, а каждый вызов "ЗафиксироватьТранзакцию" - уменьшает этот счетчик. Данное поведение описано в множестве книжек и статей, но выводы из этого поведения, видимо, разобраны недостаточно. Строго говоря, в SQL есть т.н. SAVEPOINT, но 1С их не использует, да и вещь это достаточно специфичная.
Процедура ОченьПолезныйИВажныйКод(СписокСсылокСправочника) НачатьТранзакцию(); Для Каждого Ссылка Из СписокСсылокСправочника Цикл ОбъектСправочника = Ссылка.ПолучитьОбъект(); ОбъектСправочника.КакоеТоПоле = "Я изменен из программного кода"; ОбъектСправочника.Записать(); КонецЦикла; ЗафиксироватьТранзакцию(); КонецПроцедуры
Код на английском
На самом деле, нет. Мне совершенно не хочется дублировать примеры на английском только ради того, чтобы потешить любителей холиваров и священных войн.
Вы же наверняка пишете такой код, да? Приведенный пример кода содержит ошибки. Как минимум, три. Знаете какие? Про первую я скажу сразу, она связана с объектными блокировками и не имеет отношения непосредственно к транзакциям. Про вторую - чуть позже. Третья ошибка - это deadlock, который возникнет при параллельном исполнении этого кода, но это тема для отдельной статьи, ее рассматривать сейчас не будем, дабы не усложнять код. Ключевое слово для гугления: deadlock управляемые блокировки .
Обратите внимание, простой ведь код. Такого в ваших 1С-системах просто вагон. И он содержит сразу, как минимум, 3 ошибки. Задумайтесь на досуге, сколько ошибок есть в более сложных сценариях работы с транзакциями, написанных вашими программистами 1С:)
Объектные блокировки
Итак, первая ошибка. В 1С существуют объектные блокировки, так называемые "оптимистические" и "пессимистические". Кто придумал термин, не знаю, убил бы:). Совершенно невозможно запомнить, какая из них за что отвечает. Подробно про них написано и , а также в прочей IT-литературе общего назначения.
Суть проблемы в том, что в указанном примере кода изменяется объект базы данных, но в другом сеансе может сидеть интерактивный пользователь (или соседний фоновый поток), который тоже будет менять этот объект. Здесь один из вас может получить ошибку "запись была изменена или удалена". Если это произойдет в интерактивном сеансе, то пользователь почешет репу, ругнется и попробует переоткрыть форму. Если это произойдет в фоновом потоке, то вам придется искать это в логах. А журнал регистрации, как вы знаете, медленный, а ELK-стек для журналов 1С у нас в отрасли настраивают единицы… (мы, к слову, входим в число тех, кто настраивает и другим помогает настраивать:))
Короче говоря, это досадная ошибка и лучше, чтобы ее не было. Поэтому, в стандартах разработки четко написано, что перед изменением объектов необходимо ставить на них объектную блокировку методом "ОбъектСправочника.Заблокировать() ". Тогда параллельный сеанс (который тоже должен так поступить) не сможет начать операцию изменения и получит ожидаемый, управляемый отказ.
А теперь про транзакции
С первой ошибкой разобрались, давайте перейдем ко второй.
Если не предусмотреть проверку исключения в этом методе, то исключение (например, весьма вероятное на методе "Записать()") выбросит вас из данного метода без завершения транзакции . Исключение из метода "Записать" может быть выброшено по самым разным причинам, например, сработают какие-то прикладные проверки в бизнес-логике, или возникнет упомянутая выше объектная блокировка. Так или иначе, вторая ошибка гласит: код, начавший транзакцию, не несет ответственность за ее завершение.
Именно так я бы назвал эту проблему. В нашем статическом анализаторе кода 1С на базе SonarQube мы даже отдельно встроили такую диагностику. Сейчас я работаю над ее развитием, и фантазия программистов 1С, чей код попадает ко мне на анализ, порой приводит меня в шок и трепет…
Почему? Потому что выброшенное наверх исключение внутри транзакции в 90% случаев не даст эту транзакцию зафиксировать и приведет к ошибке. Следует понимать, что 1С автоматически откатывает незавершенную транзакцию только после возвращения из скриптового кода на уровень кода платформы. До тех пор, пока вы находитесь на уровне кода 1С, транзакция остается активной.
Поднимемся на уровень выше по стеку вызовов:
Процедура ВажныйКод() СписокСсылок = ПолучитьГдеТоСписокСсылок(); ОченьПолезныйИВажныйКод(СписокСсылок); КонецПроцедуры
Смотрите, что получается. Наш проблемный метод вызывается откуда-то извне, выше по стеку. На уровне этого метода разработчик понятия не имеет - будут ли какие-то транзакции внутри метода ОченьПолезныйИВажныйКод или их не будет. А если будут - то будут ли они все завершены… Мы же все тут за мир и инкапсуляцию, верно? Автор метода "ВажныйКод" не должен думать про то, что именно происходит внутри вызываемого им метода. Того самого, в котором некорректно обрабатывается транзакция. В итоге, попытка поработать с базой данных после выброса исключения изнутри транзакции, с высокой вероятностью приведет к тому, что "В данной транзакции бла-бла…"
Размазывание транзакций по методам
Второе правило "транзакционно-безопасного" кода: счетчик ссылок транзакций в начале метода и в его конце должен иметь одно и то же значение . Нельзя начинать транзакцию в одном методе и завершать ее в другом. Из этого правила, наверное, можно найти исключения, но это будет какой-то низкоуровневый код, который пишут более компетентные люди. В общем случае так писать нельзя.
Например:
Процедура ВажныйКод() СписокСсылок = ПолучитьГдеТоСписокСсылок(); ОченьПолезныйИВажныйКод(СписокСсылок); ЗафиксироватьТранзакцию(); // Путевка в ад, серьезный разговор с автором о наших сложных трудовых отношениях. КонецПроцедуры
Выше - неприемлемый говнокод. Нельзя писать методы так, чтобы вызывающая сторона помнила и следила за возможными (или вероятными - как знать) транзакциями внутри других методов, которые она вызывает. Это нарушение инкапсуляции и разрастание спагетти-кода, который невозможно трассировать, сохраняя рассудок.
Особенно весело вспомнить, что реальный код намного больше синтетических примеров из 3-х строчек. Выискивать начинающиеся и завершающиеся транзакции по шести уровням вложенности - это прям мотивирует на задушевные беседы с авторами.
Пытаемся исправить код
Вернемся к исходному методу и попытаемся его починить. Сразу скажу, что объектную блокировку мы чинить пока не будем, просто, чтобы не усложнять код примера.
Первый подход типичного 1С-ника
Обычно программисты 1С знают, что при записи может быть выдано исключение. А еще они боятся исключений, поэтому стараются их все перехватывать. Например, вот так:
Процедура ОченьПолезныйИВажныйКод(СписокСсылокСправочника) НачатьТранзакцию(); Для Каждого Ссылка Из СписокСсылокСправочника Цикл ОбъектСправочника = Ссылка.ПолучитьОбъект(); ОбъектСправочника.КакоеТоПоле = "Я изменен из программного кода"; Попытка ОбъектСправочника.Записать(); Исключение Лог.Ошибка("Не удалось записать элемент %1", Ссылка); Продолжить; КонецПопытки; КонецЦикла; ЗафиксироватьТранзакцию(); КонецПроцедуры
Ну как, стало лучше, да? Ведь теперь, возможные ошибки записи обрабатываются и даже логируются. Исключения больше не возникнут при записи объекта. И в логе даже видно - на каком объекте, не поленился, вывел в сообщение ссылку вместо лаконичного "Ошибка записи справочника", как это часто любят писать вечно торопящиеся разработчики. Иными словами, налицо забота о пользователе и рост компетенций.
Однако, опытный 1С-ник здесь скажет, что нет, лучше не стало. По сути ничего не поменялось, а может даже стало и хуже. В методе "Записать()" платформа 1С сама начнет транзакцию записи, и эта транзакция будет уже вложенной по отношению к нашей. И если в момент работы с базой данных 1С свою транзакцию откатит (например, будет выдано исключение бизнес-логики), то наша транзакция верхнего уровня все равно будет помечена как "испорченная" и ее нельзя будет зафиксировать. В итоге этот код так и останется проблемным, и при попытке фиксации выдаст "уже происходили ошибки".
А теперь представьте, что речь идет не о маленьком методе, а о глубоком стеке вызовов, где в самом низу кто-то взял и "выпустил" начатую транзакцию из своего метода. Верхнеуровневые процедуры могут и понятия не иметь, что кто-то там внизу начинал транзакции. В итоге, весь код валится с невнятной ошибкой, которую расследовать невозможно в принципе.
Код, который начинает транзакцию, обязан завершить или откатить ее. Не взирая ни на какие исключения. Каждая ветка кода должна быть исследована на предмет выхода из метода без фиксации или отмены транзакции.
Методы работы с транзакциями в 1С
Не будет лишним напомнить, что вообще 1С предоставляет нам для работы с транзакциями. Это всем известные методы:
- НачатьТранзакцию()
- ЗафиксироватьТранзакцию()
- ОтменитьТранзакцию()
- ТранзакцияАктивна()
Первые 3 метода очевидны и делают то, что написано в их названии. Последний метод - возвращает Истину, если счетчик транзакций больше нуля.
И есть интересная особенность. Методы выхода из транзакции (Зафиксировать и Отменить) выбрасывают исключения, если счетчик транзакций равен нулю. То есть, если вызвать один из них вне транзакции, то возникнет ошибка.
Как правильно пользоваться этими методами? Очень просто: надо прочитать сформулированное выше правило:
Как же соблюсти это правило? Давайте попробуем:
Выше мы уже поняли, что метод ДелаемЧтоТо - потенциально опасен. Он может выдать какое-то исключение, и транзакция "вылезет" наружу из нашего метода. Окей, добавим обработчик возможного исключения:
НачатьТранзакцию(); Попытка ДелаемЧтоТо(); Исключение // а что же написать тут? КонецПопытки; ЗафиксироватьТранзакцию();
Отлично, мы поймали возникающую ошибку, но что с ней делать? Записать сообщение в лог? Ну, может быть, если код логирования ошибок должен быть именно на этом уровне и ошибку мы тут ждем. А если нет? Если мы не ожидали тут никаких ошибок? Тогда мы должны просто передать это исключение выше, пусть с ними разбирается другой слой архитектуры. Делается это оператором "ВызватьИсключение" без аргументов. В этих ваших джава-сиплюсплюсах это делается точно так же оператором throw.
НачатьТранзакцию(); Попытка ДелаемЧтоТо(); Исключение ВызватьИсключение; КонецПопытки; ЗафиксироватьТранзакцию();
Так, стоп… Если мы просто прокидываем исключение дальше, то зачем тут вообще нужна Попытка? А вот зачем: правило заставляет нас обеспечить завершение начатой нами транзакции.
НачатьТранзакцию(); Попытка ДелаемЧтоТо(); Исключение ОтменитьТранзакцию(); ВызватьИсключение; КонецПопытки; ЗафиксироватьТранзакцию();
Теперь, вроде бы, красиво. Однако, мы ведь помним, что не доверяем коду ДелаемЧтоТо(). Вдруг там внутри его автор не читал этой статьи, и не умеет работать с транзакциями? Вдруг он там взял, да и вызвал метод ОтменитьТранзакцию или наоборот, зафиксировал ее? Нам очень важно, чтобы обработчик исключения не породил нового исключения , иначе исходная ошибка будет потеряна и расследование проблем станет невозможным. А мы помним, что методы Зафиксировать и Отменить могут выдать исключение, если транзакция не существует. Здесь-то и пригождается метод ТранзакцияАктивна.
Финальный вариант
Наконец, мы можем написать правильный, "транзакционно-безопасный" вариант кода. Вот он:
НачатьТранзакцию(); Попытка ДелаемЧтоТо(); Исключение Если ТранзакцияАктивна() Тогда ОтменитьТранзакцию(); КонецЕсли; ВызватьИсключение; КонецПопытки; ЗафиксироватьТранзакцию();
Постойте, но ведь не только "ОтменитьТранзакцию" может выдавать ошибки. Почему же тогда "ЗафиксироватьТранзакцию" не обернут в такое же условие с "ТранзакцияАктивна"? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к "размазыванию" логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, "прячущего" старое .
Чек-лист рефакторинга
Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.
Паттерн:
НачатьТранзакцию(); ДелаемЧтоТо(); ЗафиксироватьТранзакцию();
Обернуть в "безопасную" конструкцию с Попыткой, Проверкой активности и пробросом исключения.
Паттерн:
Если Не ТранзакцияАктивна() Тогда НачатьТранзакцию() КонецЕсли
Анализ и Рефакторинг. Автор не понимал, что делает. Начинать вложенные транзакции можно безопасно. Не нужно проверять условие, нужно просто начать вложенную транзакцию. Ниже по модулю он наверняка еще там извращается с их фиксацией. Это гарантированный геморрой.
Примерно похожий вариант:
Если ТранзакцияАктивна() Тогда ЗафиксироватьТранзакцию() КонецЕсли
аналогично: фиксация транзакции по условию - это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.
Паттерн:
НачатьТранзакцию() Пока Выборка.Следующий() Цикл // чтение объекта по ссылке // запись объекта КонецЦикла; ЗафиксироватьТранзакцию();
- ввести управляемую блокировку во избежание deadlock
- ввести вызов метода Заблокировать
- обернуть в "попытку", как показано выше
Паттерн:
НачатьТранзакцию() Пока Выборка.Следующий() Цикл Попытка Объект.Записать(); Исключение Сообщить("Не получилось записать"); КонецПопытки; КонецЦикла; ЗафиксироватьТранзакцию();
Данная транзакция уже не завершится в случае исключения. Нет смысла продолжать цикл. Код требуется переписать, сверяясь с исходной задачей. Дополнительно обеспечить более информативное сообщение об ошибке.
В заключение
Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята - основная проблема 1С, как экосистемы - это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я "НачатьТранзакцию()"....
И знаете - самое главное, что это прекрасно. Простота разработки в 1С позволяет моментально реализовывать бизнес-идеи и встраивать их в процессы компании. Потом всегда можно отрефакторить, главное понимать как. И если вдруг вам нужна помощь в аудите вашей "медленной 1С" - обращайтесь к специалистам по оптимизации. Она совсем не медленная.
На протяжении ряда лет богатый папа уделял много времени тому, чтобы научить своего сына и меня работать и общаться с самыми разными людьми. Если вы читали книгу «Богатый ребенок, умный ребенок», то, возможно, помните, что богатый папа часто усаживал своего сына и меня рядом с собой, когда проводил деловые разговоры с людьми. Учиться тому, как нанимать и увольнять людей, оказалось очень интересным занятием, особенно когда люди, которых богатый папа нанимал и увольнял, были ровесниками моих мамы и папы. Для него научить нас общаться с самыми разными людьми было важнейшим начальным этапом в нашем образовании. Он постоянно говорил: «Если вы научитесь работать с разными людьми, то сможете стать такими богатыми, что вам и не снилось».
Те из вас, кто читал книгу «Квадрант денежного потока», наверное, помнят, насколько важна была для богатого папы следующая простая схема:
Богатый папа придумал эту схему, чтобы проиллюстрировать свою мысль о том, что мир бизнеса состоит из людей четырех типов. Квадрант «Р» обозначает работающих по найму, квадрант «С» - работающих на себя и владельцев малого бизнеса, квадрант «Б» - владельцев среднего и крупного бизнеса, а квадрант «И» - инвесторов.
Основная задача этой диаграммы - показать, что люди из разных квадрантов отличаются по самой своей сути. Богатый папа говорил: «Чтобы преуспеть в квадранте "Б", надо знать, как общаться и работать с людьми из всех четырех квадрантов. Это единственный квадрант, где такая способность абсолютно необходима». Другими словами, бизнес может потерпеть крах, если предприниматель окажется не способен работать и ладить с людьми разных типов.
В 1980-е годы я вернулся на Гавайи и богатый папа пригласил меня на совет директоров одной компании, находящейся в тяжелом положении. И богатый папа, который был одним из ее директоров, хотел, чтобы я поучился на этом малоприятном примере. Это была маленькая начинающая компания, занимавшаяся разведкой нефтяных месторождений в Канаде. Богатый папа не создавал эту компанию, но, когда возникли трудности, его пригласили войти в совет директоров, чтобы посмотреть, можно ли как-то ее спасти.
Из-за одного-единственного решения ее финансового директора компания глубоко погрязла в долгах и находилась на грани банкротства. Когда собрание началось, богатый папа спросил остальных членов совета:
Почему финансовому директору было позволено принимать такие важные решения без консультации с советом директоров?
Один из членов совета ответил:
Потому, что он был первым заместителем главы нефтяного гиганта «XYZ».
Ну и что? Ну и что, что он в свое время был первым заместителем директора большой нефтяной компании?
Мы думали, он знает намного больше всех нас. Поэтому позволили ему действовать по своему усмотрению, - сказал другой член совета.
Богатый папа молча сидел, постукивая пальцами по столу, а затем сказал: «Да, он был первым заместителем директора, но он был наемным служащим на протяжении 30 лет. Он был наемным работником в большой компании. У него нет ни малейшего понятия о том, как управлять маленьким начинающим бизнесом с весьма ограниченным бюджетом. Советую вам заменить его, предпочтительно на того, кто уже владел собственной компанией и нес полную финансовую ответственность, пусть даже это была не нефтяная компания. Существует огромная разница между наемным работником и предпринимателем, независимо от того, в какой отрасли они работали. Существует огромная разница между управлением маленькой компанией и управлением большой компанией. Для большой компании ошибка такого масштаба неощутима. Для маленькой компании такая ошибка гибельна.
В итоге компания обанкротилась. Через год я спросил богатого папу, почему она в конце концов потерпела крах. Он ответил: «Руководство компанией осуществлялось из рук вон плохо. И это при том, что были наняты великолепные люди и им платились большие деньги. Но эти люди так и не стали великолепной командой. Преуспевающие предприниматели создают великолепные команды. Именно так они составляют конкуренцию большим компаниям, у которых больше денег и больше служащих».
Разные навыки
В своей третьей книге, «Руководство богатого папы по инвестированию», я писал о треугольнике Б-И богатого папы, который изображен ниже.
Треугольник Б-И важен для любого, кто хочет начать бизнес в квадранте «Б» или уже имеет его. Он также важен для любого, у кого есть идея на миллион долларов и кто планирует превратить ее в бизнес. Другими словами, людям бывает трудно начать бизнес в квадранте «Б», потому что для настоящего бизнеса требуются более одного навыка и более одной специальности.
Наша образовательная система выпускает людей, обладающих такими специальными навыками. Но нужно быть истинным предпринимателем, чтобы собрать вместе людей, обладающих всеми этими навыками, заставить их работать как единая команда и таким образом создать мощную компанию.
Основная проблема
Основная проблема - это не только собрать в вашем бизнесе все четыре квадранта и иметь в наличии все технические навыки из треугольника Б-И. Проблема в том, чтобы найти лидера - предпринимателя, который сумеет заставить этих несхожих людей с разными навыками и разными базовыми системами ценностей работать вместе как одна команда. Вот почему богатый папа говорил: «Самое трудное в бизнесе - это работать с людьми. Заниматься бизнесом было бы просто, если бы не люди».
Другими словами, предприниматель должен прежде всего быть выдающимся лидером, и каждый из нас должен работать над развитием своих лидерских качеств.
Что такое предприниматель?
Богатый папа учил своего сына и меня быть предпринимателями. Когда я спросил его, что такое предприниматель, он сказал:
Предприниматель видит какую-нибудь благоприятную возможность, собирает команду и создает бизнес, который получает прибыль от этой благоприятной возможности.
Тогда я спросил его:
А что, если я увижу какую-нибудь благоприятную возможность, смогу я воспользоваться ею в одиночку?
Хороший вопрос, - заметил богатый папа. - Если ты видишь возможность и можешь воспользоваться ею в одиночку, значит, ты владелец малого бизнеса или человек, занимающийся индивидуальной трудовой деятельностью, - и богатый папа принялся объяснять разницу между человеком, занимающимся индивидуальной трудовой деятельностью, и предпринимателем: - Индивидуальный торговец или специалист - это человек, который может производить товар или оказывать услугу в основном своими силами. К примеру, художник может нарисовать картину самостоятельно, зубной врач может вылечить тебе зуб своими руками. Истинный же предприниматель не может сделать то, что он задумал, только своими собственными силами. Предприниматель должен уметь собрать вместе толковых людей самых разных специальностей, владеющих разными навыками, и сделать так, чтобы они работали вместе ради общей цели. Другими словами, предприниматель создает команды, производящие такие продукты, которые ни один человек не в состоянии произвести в одиночку. Причина, по которой большинство людей так и не выходят на более широкую арену, заключается в том, что они решают только те проблемы, которые в состоянии решить самостоятельно.
Так значит, предприниматель берется за задачи, требующие для своего решения целой команды? - сказал я. - Человек из квадранта «Б» не получит денег, пока его люди не сделают то, что они должны сделать как команда. Большинство наемных работников и людей, занимающихся индивидуальной трудовой деятельностью, получают деньги за то, что они делают самостоятельно. Предприниматель же не получит денег, пока его команда не добьется успеха.
Богатый папа утвердительно кивнул и продолжал объяснять:
Подобно тому как в строительстве подрядчик, чтобы построить дом, привлекает рабочих разных специальностей (сантехников, электриков, плотников) и профессионалов из разных областей (архитекторов, бухгалтеров), точно так же и предприниматель привлекает различных рабочих, техников и профессионалов, которые помогают ему создавать бизнес.
Вы хотите сказать, что предприниматель - это, по сути, лидер команды, хотя сам он физически может и не работать в ней? - спросил я.
Чем лучше ты умеешь организовать работу команды из умных и квалифицированных людей, сам при этом не работая в ее составе, тем более преуспевающим и более значительным предпринимателем сможешь стать, - пояснил богатый папа. - Я владею несколькими компаниями, но не выполняю никакой работы внутри их. Так я могу сделать больше денег и принести больше пользы, сам при этом не выполняя конкретной работы. Вот почему лидерство - это важнейший навык, необходимый для того, чтобы стать истинным предпринимателем.
А лидерским навыкам можно научиться? - поинтересовался я.
Да, - ответил богатый папа. - Л заметил, что в каждом человеке присутствуют качества лидера. Проблема большинства людей заключается в том, что они посвящают всю свою жизнь развитию своих профессиональных и карьерных навыков, почему, собственно, большинство людей и находятся в квадрантах «Р» и «С». Очень немногие люди посвящают свою жизнь тому, чтобы развивать в себе лидерские навыки, столь необходимые в квадранте «Б». Поэтому я говорю: «Да, можно научиться быть лидером».
А еще через много лет богатый папа сказал: «Лидеры принимают вызов жизни, в то время как остальные люди ищут гарантированные рабочие места».
