А вот и зря вы так говорите. Ибо хешмапа в java, например, вопреки интуитивному представлению, что поиск в ней должен осуществляться за константное время, производит поиск отнюдь не за константное время. Корень из n, хотя такое о большое, нигде не описано.
Универсальный класс Dictionary<TKey,TValue> обеспечивает сопоставление набора ключей с набором значений. Каждое дополнение к словарю состоит из значения и связанного с ним ключа. Получение значения с помощью его ключа происходит очень быстро, близко к O(1), поскольку класс Dictionary<TKey,TValue> реализован в виде хэш-таблицы.
Как реально в коде реализовано, я не знаю.
Поэтому, если вы на собесе по java скажете, что поиск в hashMap осуществляется за O(1), вы его провалите.
Ох, школота... при расчете о большое, выполняются правила:
константные слагаемые выбрасываются, n+1 => n
умножение на константу выбрасываются n*1/2 => n
члены с меньшей степенью выбрасываются, n3+n2+n => n3.
О большое не говорит, сколько будет выполняться итераций, оно говорит, во сколько раз увеличится количество итераций при увеличении исходных данных в два раза. В данном случае, при увеличении размера массива в два раза количество итераций увеличится в четыре раза.
Справедливости ради, при прослушивании курсов по java почти все преподаватели, описывая алгоритмы и контейнеры, "описывали" сложность (сложно это называть это О большое) как "при поиске элемента в хешмапе, содержащей 10000 элементов, будет производится проход по ста элементам массива и еще по ста элементам массива". Вот какая это сложность? Насколько увеличится количество итерации при увеличении исходных данных в десять раз?
Сигнал wow, имхо, похож на выстрел боевого лазера. Где-то в галактике идет война, противники излучают по кораблям врага лазерными лучами, и совершенно случайным образом луч полетел в сторону земли и был принят обсерваторией. Отсюда понятно, почему нет модуляции - никто не будет закладывать в луч боевого лазера какую-то информацию. Понятно, почему сигнал короткий - один короткий выстрел. И учитывая, что пальба в космосе, вообще говоря, приводит к тому, что стреляют в совершенно случайные по итогу направления, то поймать второй раз сигнал - совершенно невероятно.
Попытки сделать ИС без аналитиков и проектов - это как попытки сделать танк без конструкторов и чертежей. Можно, конечно, наварить листов на трактор...
тестирование, контроль. Должный проект, тщательный контроль. Не проходит код контроль тестера - зарплату девелопер не должен получать, независимо от того, сам он накропал или робот за него написал.
закрепление класса и модуля за ответственным. Кто написал, тот и должен его поддерживать. И ошибки, которые бот ему накидал в код и которые только через два месяца вскрылись - должен фиксить тот, кто сдал в продакшн этот код, тот, кто ответственный за него. Как в машиностроении - у каждого чертежа и сборки есть свой конструктор, ответственный за него. А не как в ИТ, когда один лепит, другие фиксят.
T-shape специалист - это оксюморон и ахинея. По-сути, как правильно сказал stackjava, это стремление владельца бизнеса навесить на специалиста еще парочку обязанностей.
По-факту - вредительство. Спец либо развивается в одном направлении, либо развивается во множестве. Человек ограничен в способностях. При этом он в основной специальности не будет развиваться, а в смежных специальностях он все-равно не разовьется до уровня, приносящего пользу делу и прибыль владельцу. Но, поскольку жадный буржуй навесит на него еще пару обязанностей, специалист гарантированно завалит задачи, сорвет сроки, подведет команду, принесет убытки компании и навредит своей карьере.
Правильное поведение, к примеру java-разработчику на попытку навесить на него devops - "Я не знаю девопс (и знать не хочу), и не смогу гарантировать выполнение задач. Ищите девопсину.".
Зачем вы это делаете? У нас что, все воры, жулики и казнокрады посажены? Сравнили Россию с Кореей... Этой чепухой вы отвлекаете ресурсы общества от реальных преступлений на ахинею. Понятно, что "бешеный принтер" с энтузиазмом займется этим, дурное дело нехитрое. Как и борьба с порнографией и с тренерами, сидящими на диванчиках рядом с девочками. Роскомнадзору, опять-же, можно дополнительно выбивать себе фонды. Следаками и прокурорам интереснее сажать школьников, а не бандитов.
Пока командой руководят менеджеры, а не специалисты - бардак так и будет продолжаться. Это раз.
Тысяча дураков никогда не придумают решение проблемы лучше, чем один умный и грамотный человек. Это два.
"Системы настолько сложные" - не смешите. Сложные системы - это ракеты и космические аппараты. И там такой херни, как в ИТ, скрумы и ретро - даже в страшном сне не приснятся. А в ИТ элементарные приложения на десять формочек растягиваются на год.
И даже если сложные системы - их можно и нужно дробить (все инструменты и возможности что языков, что технологий, хотя бы микросервисов) на простые части. Ровно также, как и делается в машиностроении и космонавтике. Простые детали и узлы давать инженерам послабее. Для решения сложных проблем и узлов надо искать и обучать сильных инженеров, а не собирать в одной комнате десять безграмотных людей, не имеющих даже инженерного образования.
Нет, уважаемый. За работу подразделения ответственность несет руководитель (ну, в нормальных успешных коллективах). Не манагер, а руководитель отдела. Он несет ответственность за сроки и качество. Руководитель выбирает инструменты, стандарты и подходы работы, стиль и качество кода (если это не стандартизована на уровне предприятия).
Я потому и говорю, что ИТ на уровне допромышленного производства - на уровне мастеров, которые "дело тонкое и творческое". Как у них душа захотела, так они и делают. Страдивари, блджад.
В промышленности же дело уже другое. Руководитель отдела у конструкторов - это самый лучший спец. Такой херни, что "у манагера профильных знаний нет" - там такого в страшном сне не может быть. Королев был суперспециалитом по ракетам. Глушко был суперспециалистом по двигателям. И так далее. И поэтому запускали ракеты.
А когда в ИТ руководят "манагеры" - это, извините, п...ц. Поэтому в ИТ провалы за провалами, просеры сроков за просерами. Обычное дело.
И только в Сбербанке, судя по постам "испуганных программистов", сбежавших оттуда, дела начинает двигаться к нормальному промышленному производству. Результаты, кстати, налицо.
Эх, сколько чепухи понаписано насчёт проблемы, которая в машиностроении, например, не имеет места быть.
В машиностроении любой узел, любой агрегат имеет своё кб, отдел и бюро, которое его ведёт, поддерживает и развивает. В любом техбюро отделе каждый конструктор и технолог ответственен за свой набор деталей и узлов. Когда возникает вопрос по детали или техпроцессу, всегда известно, кто ответственнен за данную деталь.
Другие просто не имеют права ничего менять в чужой документации.
В ит почему-то полный бардак. Огромная статья посвящена проблеме, которая в принципе решается элементарно - закрепление каждого класса за определённым разработчиком.
Боже мой! Дожили! Неужели же ИТ движется в правильную сторону?!!
Ладно, спокойно. Я когда-то уже комментил, и готов посторить сейчас: ИТ (по крайней мере до этого момента) находится в состоянии допромышленного производства. Грубо говоря, средневековье с мастерами и цехами. В то время, как производство материальных ценностей уже начиная с петровских времен находится в состоянии нормального промышленного производства.
Уже начиная с Петра 1, производство ружей делалось в такой вот "микросервисной" манере - каждый мастер точил только одну определенную деталь. По чертежу, строго по размерам. Можно было разобрать десять ружей, перемешать детали и собрать снова десять ружей, и они будут нормально функционировать и стрелять. Если мастер по замкам уволится, он не сможет сделать ружье самостоятельно. Драма это? Трагедия? Нынешние рабочие точат на определенных станках определенные детали и даже подумать не могут, что могут выточить трактор целиком, если уволятся. Драма это для них? Трагедия?
Почему же для айтишника это трагедия?
Все проблемы ИТ - это средневековая отсталось организации производства, я гарантирую вам это. В программировании нет разделения труда, бекэнед/фронтенд - это вообще не разделение. В программировании нет тотального контроля результатов труда. ТДД - это полная ахинея, я уже писал. ТДД сравнивает результат труда программиста не с чертежом, а с тестом. Не может исполнитель проконтролировать свой продукт. Контроль должен осуществляться ВСЕГДА сторонним человеком, причем это должен делать не разработчик проекта, а специально обученный контролер - тестировщик. В программировании царит тотальная самодеятельность. Понятия проектов (чертежей) в подавляющем числе контор не существует, либо они крайне размыто составляются и программисты крайне вольно раеализуют свои поделки, зачастую очень отдаленно реализующие проект. Да еще и продвигается мысль, что проекты - зло.
То, от чего так бомбит автор - отчуждение результатов труда от исполнителя - это нормальный процесс развития производства. В машиностроении это было реализовано триста лет назад (Маркс только описал). Рабочие на заводе ходят на работу не для того, чтобы самовыражаться. Они делают работу, точат детали (строго по чертежу) и получают за это зарплату. В ИТ почему-то творится дичь. Приходит программист и предлагает прикрутить к огромной системе какую-то фиговину сбоку, в пятьдесят строк кода, ага. Которая решит все проблемы.
Его правильно обломали. Есть чертеж изделия (к примеру ракета или ускоритель). По нему исполнитель должен в точности выточить все детали (классы). Детали тщательно проконтролируют и соберут из них узлы (микросервис). Узлы(Микросервисы) соберут в единую систему, которую можно будет запускать в космос (в продакшн). И тут приходит дядя Вася (талантище!) который предлагает "Давайте тут приварим фигнюшку! Ракета баще полетит!". Какие слова прозвучат при этом предложении?
Простите, но у вас, в корне неверная система оценки полезности тестов (да и вообще любой технологии).
Полезность любой практики для проекта должна оцениваться следующим образом.
Насколько практика или технология увеличивает прибыль клиента приложения? Клиент будет больше получать прибыли от приложения после внедрения tdd? Нет. С чего бы?
То, что вам, как исполнителю, будет удобно и приятнее работать, не имеет значения. Проект не для вашего удовольствия оплачивается.
Код будет качественнее? Нет. Это враньё. Tdd не приводит к увеличению качества работы. Качество кода - это соответствие работы приложения требованиям заказчика. Точное соответствие функционала кода прописанным в проекте алгоритмам. Tdd обеспечивает точное соответствие функционала приложения прописанным в проекте алгоритмам? Нет. Для многих откровением будет, что юнит тесты обеспечивают соответствие функционала только самим юнит-тестам. Сами юнит-тесты могут не соответствовать проекту. Кто будет тестировать юнит-тесты? Чтобы функционал соответствовал требованиям заказчика, нужно следующее: проект, отдел тестирования, отдельный от разрабов и аналитиков (у корейцев тестирование проводит вообще сторонняя контора, слышал). И самое главное - репрессивная система, способная карать исполнителей за несоответствие функционала проекту.
Про деда совершенно верно. Сеть подумала, что спрашивали не "что это за дед такой? ", а КТО его раздевает и слезы проливает. Рассуждение вполне логичное, такого рассуждения нет в корпусе текстов. Налицо понимание исходных данных, дед одетый в сто шуб. Понимание следующей из этой посылки наличие холода, смысловой цепочки шубы-холод-снег. Попытка из этих данных сгенерировать новую информацию. Кто его может раздевать и при этом течь водой? Ну, из того, что было в исходных данных - снег. Причем тут лук? Как лук может раздевать деда и при этом плакать? Вы упоролись? Мне кажется, что после того, как вы сказали, что это лук, машина просто начала язвить и тонко издеваться над вами, как над кретином. Всё очень логично, хотя логика чисто машинная. Честно говоря, мне становится страшновато, после рассуждений на эту тему. Это реально интеллект, а не бредогенератор на базе огромного корпуса текстов.
Для проверки надо изменить текст загадки, чтобы избежать разночтений.
Сидит "дед", во сто шуб одет. Если человек начинает его раздевать, то этот человек начинает плакать. Что это за дед?
Вам не кажется, что жпт просто издевается над вами? Слишком похоже, что у сети не только разум появляется, но и очень своеобразный юмор. Пост ирония или как она там...
А вот и зря вы так говорите. Ибо хешмапа в java, например, вопреки интуитивному представлению, что поиск в ней должен осуществляться за константное время, производит поиск отнюдь не за константное время. Корень из n, хотя такое о большое, нигде не описано.
При этом в C# Dictionnary, цитирую
https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2?redirectedfrom=MSDN&view=net-7.0
Универсальный класс Dictionary<TKey,TValue> обеспечивает сопоставление набора ключей с набором значений. Каждое дополнение к словарю состоит из значения и связанного с ним ключа. Получение значения с помощью его ключа происходит очень быстро, близко к O(1), поскольку класс Dictionary<TKey,TValue> реализован в виде хэш-таблицы.
Как реально в коде реализовано, я не знаю.
Поэтому, если вы на собесе по java скажете, что поиск в hashMap осуществляется за O(1), вы его провалите.
Ох, школота... при расчете о большое, выполняются правила:
константные слагаемые выбрасываются, n+1 => n
умножение на константу выбрасываются n*1/2 => n
члены с меньшей степенью выбрасываются, n3+n2+n => n3.
О большое не говорит, сколько будет выполняться итераций, оно говорит, во сколько раз увеличится количество итераций при увеличении исходных данных в два раза. В данном случае, при увеличении размера массива в два раза количество итераций увеличится в четыре раза.
Справедливости ради, при прослушивании курсов по java почти все преподаватели, описывая алгоритмы и контейнеры, "описывали" сложность (сложно это называть это О большое) как "при поиске элемента в хешмапе, содержащей 10000 элементов, будет производится проход по ста элементам массива и еще по ста элементам массива". Вот какая это сложность? Насколько увеличится количество итерации при увеличении исходных данных в десять раз?
Сигнал wow, имхо, похож на выстрел боевого лазера. Где-то в галактике идет война, противники излучают по кораблям врага лазерными лучами, и совершенно случайным образом луч полетел в сторону земли и был принят обсерваторией. Отсюда понятно, почему нет модуляции - никто не будет закладывать в луч боевого лазера какую-то информацию. Понятно, почему сигнал короткий - один короткий выстрел. И учитывая, что пальба в космосе, вообще говоря, приводит к тому, что стреляют в совершенно случайные по итогу направления, то поймать второй раз сигнал - совершенно невероятно.
Как интересно все это читать после прочтения статьи, которая в ленте тремя постами раньше:
https://habr.com/ru/company/first/blog/720058/
"Огромный рынок"! Петабайты данных...
Попытки сделать ИС без аналитиков и проектов - это как попытки сделать танк без конструкторов и чертежей. Можно, конечно, наварить листов на трактор...
Кто-нибудь может мне объяснить, как осуществлялось в этом стальном гробу мытье, переодевание и отправление естественных надобностей?
Это какой-то юмор?
В чем выражается ответственность у топ-менеджера? Во времена Сталина все понятно, а сейчас как?
Это решается не ревью, а:
тестирование, контроль. Должный проект, тщательный контроль. Не проходит код контроль тестера - зарплату девелопер не должен получать, независимо от того, сам он накропал или робот за него написал.
закрепление класса и модуля за ответственным. Кто написал, тот и должен его поддерживать. И ошибки, которые бот ему накидал в код и которые только через два месяца вскрылись - должен фиксить тот, кто сдал в продакшн этот код, тот, кто ответственный за него. Как в машиностроении - у каждого чертежа и сборки есть свой конструктор, ответственный за него. А не как в ИТ, когда один лепит, другие фиксят.
T-shape специалист - это оксюморон и ахинея. По-сути, как правильно сказал stackjava, это стремление владельца бизнеса навесить на специалиста еще парочку обязанностей.
По-факту - вредительство. Спец либо развивается в одном направлении, либо развивается во множестве. Человек ограничен в способностях. При этом он в основной специальности не будет развиваться, а в смежных специальностях он все-равно не разовьется до уровня, приносящего пользу делу и прибыль владельцу. Но, поскольку жадный буржуй навесит на него еще пару обязанностей, специалист гарантированно завалит задачи, сорвет сроки, подведет команду, принесет убытки компании и навредит своей карьере.
Правильное поведение, к примеру java-разработчику на попытку навесить на него devops - "Я не знаю девопс (и знать не хочу), и не смогу гарантировать выполнение задач. Ищите девопсину.".
Зачем вы это делаете? У нас что, все воры, жулики и казнокрады посажены? Сравнили Россию с Кореей... Этой чепухой вы отвлекаете ресурсы общества от реальных преступлений на ахинею. Понятно, что "бешеный принтер" с энтузиазмом займется этим, дурное дело нехитрое. Как и борьба с порнографией и с тренерами, сидящими на диванчиках рядом с девочками. Роскомнадзору, опять-же, можно дополнительно выбивать себе фонды. Следаками и прокурорам интереснее сажать школьников, а не бандитов.
Я вообще очень сомневаюсь, что ретро даст хоть какое-то вменяемое решение хоть какой-то мало-мальски сложной проблемы.
Пока командой руководят менеджеры, а не специалисты - бардак так и будет продолжаться. Это раз.
Тысяча дураков никогда не придумают решение проблемы лучше, чем один умный и грамотный человек. Это два.
"Системы настолько сложные" - не смешите. Сложные системы - это ракеты и космические аппараты. И там такой херни, как в ИТ, скрумы и ретро - даже в страшном сне не приснятся. А в ИТ элементарные приложения на десять формочек растягиваются на год.
И даже если сложные системы - их можно и нужно дробить (все инструменты и возможности что языков, что технологий, хотя бы микросервисов) на простые части. Ровно также, как и делается в машиностроении и космонавтике. Простые детали и узлы давать инженерам послабее. Для решения сложных проблем и узлов надо искать и обучать сильных инженеров, а не собирать в одной комнате десять безграмотных людей, не имеющих даже инженерного образования.
Нет, уважаемый. За работу подразделения ответственность несет руководитель (ну, в нормальных успешных коллективах). Не манагер, а руководитель отдела. Он несет ответственность за сроки и качество. Руководитель выбирает инструменты, стандарты и подходы работы, стиль и качество кода (если это не стандартизована на уровне предприятия).
Я потому и говорю, что ИТ на уровне допромышленного производства - на уровне мастеров, которые "дело тонкое и творческое". Как у них душа захотела, так они и делают. Страдивари, блджад.
В промышленности же дело уже другое. Руководитель отдела у конструкторов - это самый лучший спец. Такой херни, что "у манагера профильных знаний нет" - там такого в страшном сне не может быть. Королев был суперспециалитом по ракетам. Глушко был суперспециалистом по двигателям. И так далее. И поэтому запускали ракеты.
А когда в ИТ руководят "манагеры" - это, извините, п...ц. Поэтому в ИТ провалы за провалами, просеры сроков за просерами. Обычное дело.
И только в Сбербанке, судя по постам "испуганных программистов", сбежавших оттуда, дела начинает двигаться к нормальному промышленному производству. Результаты, кстати, налицо.
Эх, сколько чепухи понаписано насчёт проблемы, которая в машиностроении, например, не имеет места быть.
В машиностроении любой узел, любой агрегат имеет своё кб, отдел и бюро, которое его ведёт, поддерживает и развивает. В любом техбюро отделе каждый конструктор и технолог ответственен за свой набор деталей и узлов. Когда возникает вопрос по детали или техпроцессу, всегда известно, кто ответственнен за данную деталь.
Другие просто не имеют права ничего менять в чужой документации.
В ит почему-то полный бардак. Огромная статья посвящена проблеме, которая в принципе решается элементарно - закрепление каждого класса за определённым разработчиком.
Боже мой! Дожили! Неужели же ИТ движется в правильную сторону?!!
Ладно, спокойно. Я когда-то уже комментил, и готов посторить сейчас: ИТ (по крайней мере до этого момента) находится в состоянии допромышленного производства. Грубо говоря, средневековье с мастерами и цехами. В то время, как производство материальных ценностей уже начиная с петровских времен находится в состоянии нормального промышленного производства.
Уже начиная с Петра 1, производство ружей делалось в такой вот "микросервисной" манере - каждый мастер точил только одну определенную деталь. По чертежу, строго по размерам. Можно было разобрать десять ружей, перемешать детали и собрать снова десять ружей, и они будут нормально функционировать и стрелять. Если мастер по замкам уволится, он не сможет сделать ружье самостоятельно. Драма это? Трагедия? Нынешние рабочие точат на определенных станках определенные детали и даже подумать не могут, что могут выточить трактор целиком, если уволятся. Драма это для них? Трагедия?
Почему же для айтишника это трагедия?
Все проблемы ИТ - это средневековая отсталось организации производства, я гарантирую вам это. В программировании нет разделения труда, бекэнед/фронтенд - это вообще не разделение. В программировании нет тотального контроля результатов труда. ТДД - это полная ахинея, я уже писал. ТДД сравнивает результат труда программиста не с чертежом, а с тестом. Не может исполнитель проконтролировать свой продукт. Контроль должен осуществляться ВСЕГДА сторонним человеком, причем это должен делать не разработчик проекта, а специально обученный контролер - тестировщик. В программировании царит тотальная самодеятельность. Понятия проектов (чертежей) в подавляющем числе контор не существует, либо они крайне размыто составляются и программисты крайне вольно раеализуют свои поделки, зачастую очень отдаленно реализующие проект. Да еще и продвигается мысль, что проекты - зло.
То, от чего так бомбит автор - отчуждение результатов труда от исполнителя - это нормальный процесс развития производства. В машиностроении это было реализовано триста лет назад (Маркс только описал). Рабочие на заводе ходят на работу не для того, чтобы самовыражаться. Они делают работу, точат детали (строго по чертежу) и получают за это зарплату. В ИТ почему-то творится дичь. Приходит программист и предлагает прикрутить к огромной системе какую-то фиговину сбоку, в пятьдесят строк кода, ага. Которая решит все проблемы.
Его правильно обломали. Есть чертеж изделия (к примеру ракета или ускоритель). По нему исполнитель должен в точности выточить все детали (классы). Детали тщательно проконтролируют и соберут из них узлы (микросервис). Узлы(Микросервисы) соберут в единую систему, которую можно будет запускать в космос (в продакшн). И тут приходит дядя Вася (талантище!) который предлагает "Давайте тут приварим фигнюшку! Ракета баще полетит!". Какие слова прозвучат при этом предложении?
Простите, но у вас, в корне неверная система оценки полезности тестов (да и вообще любой технологии).
Полезность любой практики для проекта должна оцениваться следующим образом.
Насколько практика или технология увеличивает прибыль клиента приложения? Клиент будет больше получать прибыли от приложения после внедрения tdd? Нет. С чего бы?
То, что вам, как исполнителю, будет удобно и приятнее работать, не имеет значения. Проект не для вашего удовольствия оплачивается.
Код будет качественнее? Нет. Это враньё. Tdd не приводит к увеличению качества работы. Качество кода - это соответствие работы приложения требованиям заказчика. Точное соответствие функционала кода прописанным в проекте алгоритмам. Tdd обеспечивает точное соответствие функционала приложения прописанным в проекте алгоритмам? Нет. Для многих откровением будет, что юнит тесты обеспечивают соответствие функционала только самим юнит-тестам. Сами юнит-тесты могут не соответствовать проекту. Кто будет тестировать юнит-тесты? Чтобы функционал соответствовал требованиям заказчика, нужно следующее: проект, отдел тестирования, отдельный от разрабов и аналитиков (у корейцев тестирование проводит вообще сторонняя контора, слышал). И самое главное - репрессивная система, способная карать исполнителей за несоответствие функционала проекту.
Про деда совершенно верно. Сеть подумала, что спрашивали не "что это за дед такой? ", а КТО его раздевает и слезы проливает. Рассуждение вполне логичное, такого рассуждения нет в корпусе текстов. Налицо понимание исходных данных, дед одетый в сто шуб. Понимание следующей из этой посылки наличие холода, смысловой цепочки шубы-холод-снег. Попытка из этих данных сгенерировать новую информацию. Кто его может раздевать и при этом течь водой? Ну, из того, что было в исходных данных - снег. Причем тут лук? Как лук может раздевать деда и при этом плакать? Вы упоролись? Мне кажется, что после того, как вы сказали, что это лук, машина просто начала язвить и тонко издеваться над вами, как над кретином. Всё очень логично, хотя логика чисто машинная. Честно говоря, мне становится страшновато, после рассуждений на эту тему. Это реально интеллект, а не бредогенератор на базе огромного корпуса текстов.
Для проверки надо изменить текст загадки, чтобы избежать разночтений.
Сидит "дед", во сто шуб одет. Если человек начинает его раздевать, то этот человек начинает плакать. Что это за дед?
Вам не кажется, что жпт просто издевается над вами? Слишком похоже, что у сети не только разум появляется, но и очень своеобразный юмор. Пост ирония или как она там...
Прадеды так не писали, мне кажется. Тотальное закрытие полей и гетеросеттеризация - относительно новый тренд.