Если коротко ищем тех, кто:
- любит (или готов полюбить) делать тиражируемые фреймворки
- хочет делать продукт, которым пользуются миллионы людей
Чтобы показать детальнее, каких разработчиков мы ищем и как, мы взяли короткие интервью у нанимающих менеджеров нашей компании. Вопросы в ходе интервью задавались такие:
- Какие вам нужны разработчики?
- Что спрашиваете на интервью?
- Какие вопросы предпочитаете на интервью – теоретические или практические?
- Должен ли программист писать тесты?
- Задаете ли вопросы не из профессиональной сферы деятельности?
- Задаете ли логические задачи на сообразительность, не связанные непосредственно с программированием? Типа задачи про шарик с гелием в машине:
В каких областях у нас могут работать программисты в разработке платформы? Ну например:
- IDE для разработки бизнес-приложений
- Компилятор встроенного языка
- Веб-фреймворк
- Балансировщик нагрузки
- и многое другое:
Группа интернет-разработки
Группа пишет онлайн-сервисы, которыми пользуются, наверное, миллионы конечных пользователей продуктов 1С. Сервисы, например, позволяют по ИНН получить информацию о контрагенте, проверить надежность контрагента, и т.д. Область деятельности очень ответственная, сервисы работают под большой нагрузкой, простои в работе сервисов крайне нежелательны, поэтому стараемся создавать максимально надежный продукт. А еще делаем продукт под названием Система Взаимодействия. Это механизм, передающий информацию между клиентскими приложениями и серверами 1С:Предприятия; с его помощью, в частности, реализован встроенный в приложения 1С мессенджер.
От разработчика хочется, чтобы он разрабатывал продукт в целом — анализировал потребности пользователей, продумывал архитектуру, писал код. Потому что часто приходят на интервью люди и говорят – мне неинтересно анализировать предметную область, я хочу, чтобы аналитик написал мне ТЗ, по которому я запрограммирую функциональность. То есть человеку интересны только технические моменты программирования. Мы таких людей стараемся не нанимать, т.к. команда у нас небольшая, заниматься приходится большим количеством смежных областей. Поэтому основные требования, не связанные с профессиональными навыками – это умение красиво и аккуратно оформить требования к продукту, продумать реализацию, разработать продукт и отвечать за конечный результат. Важна личная заинтересованность человека в качестве конечного продукта, чтобы человек делал продукт, которым сам хотел бы гордиться.
В книге Эрика Эванса «Предметно-ориентированное проектирование» одна из главных идей – то, что разработчик должен быть еще и аналитиком, хорошо понимать предметную область, которую он автоматизирует, понимать, что ценно для бизнеса, а если он этого не понимает, то не сможет разработать хорошую систему, которая удовлетворит всем требованиям пользователя. Если разработчик абстрагируется от предметной области, то ключевые решения по архитектуре продукта будет принимать не он, а реализовывать эти решения придется ему, и в этом случае есть риск некачественной реализации. Тот же Эванс рекомендует выделить в доменной области две части – часть, которая принципиально важна для бизнеса, та, что делает ваш продукт собственно вашим продуктом, и вторая часть, которая не очень важна, отвечающая за инфраструктурную обвязку. И самым лучшим разработчикам надо давать реализацию первой, важной части.
Как проходит собеседование? У нас есть анкета, около 10 вопросов, которые мы задаем соискателям. Вопросы в анкете не теоретические, а практические, например – код вызвал исключение с таким-то стек-трейсом, объясните, что вы будете делать. Или – у вас есть запрос в базу данных, который выполняется медленно (текст запроса дается), есть план запроса, оцените – что в плане запроса плохо, надо объяснить, как ускорить запрос. Нет смысла спрашивать человека, какие есть типы JOIN-ов — разумеется, он знает эти типы, если хоть немного готовился к собеседованию. Интересен практический опыт использования этих JOIN-ов. Если человек имеет опыт анализа планов запросов – для него не составит труда рассказать про пути решения проблемы, если нет такого опыта – книжка тут не поможет. Как раз тут проходит грань, отличающая разработчика, который просто читал про функциональность, от разработчика, который эту функциональность действительно использовал. Иметь дело со вторым типом разработчика нам более интересно, хочется, чтобы человек сразу «включился в игру».
Часть вопросов анкеты уже перестала работать, и мы эти вопросы заменили на новые. Например, некоторое время назад, на собеседованиях часто просили реализовать паттерн Singleton, а когда кандидат это делал, говорили – а теперь сделайте его lazy. С тех пор появилось несколько статей на Хабре, где подробно рассказывалось, как писать подобные вещи, люди просто выучили эту задачу наизусть, и она перестала быть тестом на профпригодность.
Еще мы хотим, чтобы разработчики грамотно писали тесты; например, чтобы в сигнатуре теста описывался контракт, которому должна удовлетворять система. Это можно делать, например, на Java в стиле, рекомендованном Роем Ошеров, когда название контракт-метода делится на три части – «дано», «что ожидаем», «какой результат». А можно делать на Groovy, используя Spock. Важно, понимает ли кандидат, что именно надо тестировать, надо ли тестировать граничные значения, знает ли он про пирамиду тестирования и т.п.
Еще спрашиваем о проектах, которыми человек занимался, особенно если в них использовались релевантные нам технологии. Например, мы используем Hazelcast, его пока мало кто использует в production (из недавних крупных внедрений – в Яндекс.Деньгах), и нам очень интересны люди с опытом использования Hazelcast. Более того, кандидат может раскрыть нам неожиданные и полезные стороны новой технологии, про которые мы пока не знаем.
Важная для нас тема – как писать код для работы в многопоточной среде. Например, есть несколько нодов приложения в высоконагруженной среде, и мы просим кандидата рассказать, как сделать систему работоспособной и надежной, при этом минимально ее блокируя.
Должен ли программист писать тесты? Должен, но не все. Юнит-тесты программист должен писать безусловно. Кстати, мы в команде не настаиваем на обязательном применении каких-либо методик, например, TDD; некоторые разработчики используют TDD по собственной инициативе, им так нравится. Также пишем интеграционные тесты. Разработчики делают также нагрузочное тестирование, пишут планы тестирования для JMeter.
Группа разработки веб-клиента
Хотя мы и разрабатываем веб-клиент на JavaScript, предпочитаем, чтобы у кандидата помимо опыта веб-разработки на JavaScript был опыт разработки на «классических» ООП языках – С++ или Java или C#. Это связано со спецификой проекта; веб-клиент 1С, написан на JavaScript, но больше по идеологии напоминает приложение, написанное на ООП языке. Код на JavaScript мы покрываем аннотациями JSDoc, благодаря этому при сборке происходит статическая проверка типов. Этот подход был выбран потому, что мы используем Google Closure Compiler, помогающий нам, в частности, увеличивать быстродействие нашего кода и снижать объем потребляемой им памяти. Таким образом, ООП-опыт будет большим подспорьем для кандидата.
На собеседовании спрашиваем, какие задачи приходилось решать кандидату и его команде на предыдущих местах работы, обсуждаем архитектуру решений, реализованных им. Задаем кандидату задачи, часть из них — на сообразительность и алгоритмическое мышление. Например, есть задачи, которые «в лоб» решаются довольно большим количеством кода, а если подумать – то в одну строку.
Есть пул задач на специфические знания по верстке, по JavaScript. Например, рисуем на листке бумаги структуру HTML страницы (структура может быть динамической, меняться во времени по определенному алгоритму) и просим написать код, который создаст такую структуру и реализует ее в динамике.
Стараемся также оценивать предрасположенность кандидата к аналитической деятельности; нам не хотелось бы иметь в команде «чистого» кодера, пусть даже пишущего качественный код, но работающего строго по фиксированному ТЗ. Хочется, чтобы разработчик был вовлечен в задачи, глубоко понимал, что и для чего делается в продукте, в идеале – был еще и драйвером новой функциональности.
Если кандидат – студент или вчерашний студент, можем задать чисто теоретические вопросы, например, спросить базовые принципы ООП или что-то еще. Если человек с опытом, подобные вопросы могут быть бессмысленны, наверняка кандидат знает эти принципы и использует их в своей работе, просьба сформулировать их может поставить его в тупик, потому, что он банально забыл формулировку из учебника.
Каждое собеседование получается уникальным. С одним человеком интересно поговорить на одни темы, с другим – на другие. В конце собеседования мы рассказываем про наш продукт, про масштабы его использования (а они внушительные – у нашей системы миллионы конечных пользователей), смотрим, насколько человек заинтересовался.
Группа повышения масштабируемости приложений
Кто мы
Наша команда – эксперты в области построения высоконагруженных систем на платформе 1С:Предприятие. Эти инженеры решают задачи обеспечения надежности и масштабируемости. Такие задачи часто находятся на стыке вопросов администрирования и разработки. Результатом решения таких задач является действительно классно работающая система. Примеры таких задач:
- развернуть отказоустойчивую инфраструктуру в двух ЦОД и провести моделирование отказов,
- обеспечить неухудшение производительности системы с увеличением числа пользователей в 10 раз, ускорить многочасовой расчет себестоимости в 3 раза,
- расследовать и устранить возникающие взаимоблокировки,
- обеспечить согласованное восстановление более десятка распределенных информационных баз на момент времени с учетом обменов между этими базами.
И это далеко не полный список задач. Особенно приятно, что многие из задач попадают к нам с формулировкой: «Это вообще возможно сделать?» Т.е. люди сначала не верят. Мы не спорим и всегда стараемся убедить попробовать проверить на практике, сделать. К этому нужно прибавить готовность подключиться посреди ночи к системе крупного клиента, потому что у местных инженеров что-то сломалось, и никто не знает что делать. Не один раз приходилось восстанавливать разрушенную базу при отсутствии бэкапов или выяснять, почему нагрузка на систему выросла на 5%. При желании можно даже почитать отзывы о нашей работе.
Кого мы ищем
Мы ищем инженеров, которые страстно хотят делать невозможное. Одно из самых важных требований к кандидату – горящие глаза, желание и умение быстро разбираться в том, с чем раньше не сталкивался, используя уже имеющиеся знания. Это инженеры по надежности и разработчики в одном лице. Представьте, что вам обращается клиент с несколькими тысячами пользователей и рассказывает, что пытается запустить в работу сложный механизм, который разрабатывали его инженеры в течение года. И кстати:
- ещё не успели закончить разработку в условиях постоянно изменяющихся требований от бизнеса клиента;
- пока разработка ключевых механизмов на внедрении в самом разгаре, инженеры ещё не добрались до тестирования механизма с тысячами пользователей;
- даже сейчас никто понятия не имеет, почему с увеличением числа пользователей на этом внедрении ровно в этом механизме резко падает производительность;
- разработку вели в Windows и с СУБД MS SQL Server, а на финальном этапе было принято политическое решение внедрять в CentOS и с СУБД PostgreSQL, чтобы оказаться в центре течения импортозамещения;
- а ещё вы случайно выясняете, что возникают таймауты при работе даже 10 пользователей;
- вам нужно посчитать оборудование для этого механизма, потому что клиенту его надо было закупить в прошлом месяце;
- вы понимаете, что вам нужно проработать параллельную реализацию алгоритмов в этом механизме, согласовать их с коллегами и вместе решить, как вы успеете в срок, не привнеся новых ошибок.
Да, и еще: не все готовы помогать выявлять ошибки и анти-паттерны в их решениях, поэтому нужно уметь очень дипломатично общаться с инженерами, работающими в непрерывном стрессе последние месяцы.
Как мы ищем
Собеседование может быть стрессом для кандидата. Но этот стресс может даже не сравниться со стрессом, который вы получите в реальной ситуации, если не будете думать и использовать весь свой имеющийся опыт.
Проблема многих кандидатов в том, что они не умеют применять имеющиеся у них знания и не могут объяснить их шестилетнему ребенку. Именно поэтому на собеседовании периодически просим научить нас чему-нибудь, в чем кандидат лучше всего разбирается. Естественно очень хочется набирать людей, у которых многому можно научиться. В таких обсуждениях очень важна глубина знаний и очень хорошее понимание. Был опыт, когда в 7 утра собеседовали кандидата, пришли к обсуждению компонентов управления памятью в MS SQL Server и в итоге остановились на понимании страниц и экстентов. Тут вмешался HR, мол: “Что мы его мучаем?! Кто это вообще знает!?“, и мы вышли из комнаты поговорить. По коридору случайно проходил сонный и зевающий коллега в направлении кофе. Коллеге были заданы те же самые вопросы, он ответил четко, правильно, по существу, не открывая один глаз и продолжая зевать.
Естественно, стараемся проверять знание математики, алгоритмов. Они скорее относятся к базовым знаниям. А вот знание распределенных алгоритмов и умение применить такой алгоритм в задаче будет уверенным плюсом для кандидата.
Ещё один способ – попросить кандидата представить себя на месте разработчика 1С и попросить его реализовать какую-то прикладную задачу. В условиях собеседования и стресса кандидата такая задача позволяет увидеть, как кандидат думает. Смотрим на решение кандидата, помогаем кандидату увидеть существенную технологическую проблему в его решении, затем смотрим, как кандидат изменит решение, не допустив ещё одной технологической проблемы. Иногда так делаем 6-7 итераций, ищем и оцениваем слабые стороны решения. При этом сразу появляется возможность не только обсудить и понять, что знает человек, например, о взаимоблокировках, но и понимает ли, как в своем коде свести вероятность их возникновения к нулю.
Знание конкретного языка программирования не является супер важным фактором. Важнее, когда человек думает в терминах программирования с использованием языка, а не ограничивается конструкциями языка.
Что используется в работе
Первый и самый часто используемый инструмент – технологическая платформа 1С:Предприятие. Знание платформы требуется на уровне администратора и разработчика. Т.е. нужно понимать, как реализовать конкретное решение и запустить его в системе на тысячи пользователей.
Очень часто требуется анализировать работу СУБД MS SQL Server и PostgreSQL, поэтому использование инструментов профилирования, динамических представлений, журналов входит в багаж активных навыков. И тут важно умение работать с большими объемами. Стандартный блокнот Windows не очень удобен при работе с 1 Тб текстовых журналов с машинно-генерируемыми запросами и их планами. Сразу возникает необходимость знания регулярных выражений, а также целого набора инструментов и языков, их поддерживающих. Для анализа планов запросов нужно понимать, что такое индексы, и чем merge join отличается от hash join.
Системы на корпоративном рынке часто работают в ОС Linux. Там на серверах нет никакой графической среды. Навыки работы в консоли оказываются достаточно важными.
Представьте, что нужно найти, почему нагрузка на CPU на серверах c PostgreSQL в CentOS процессами Postgre выросла на 5%. Попробуйте написать на бумажке алгоритм вашего расследования. И сразу возникает понимание, что нужно
- уметь применять не только uptime, vmstat, sar, atop, perf,
- знать, как воспользоваться pgbadger, psql и настроить сбор журналов в postgresql.conf,
- уметь найти один нужный запрос,
- воспользоваться analyze, проанализировать его план,
- переписать запрос и проверить, что нагрузка спала.
Что для нас важно
Очень важно, чтобы человек мыслил масштабно и старался всегда видеть картину в целом. Например, большинство кандидатов, решая задачу сортировки текстового файла, предлагают алгоритм, подходящий для сортировки файла в 10 Мб. Но как же существенно меняется их понимание и точка зрения, когда они сталкиваются с сортировкой файла в 10 Тб в условиях ограниченного объема памяти и места на диске. И ведь нужно помнить, что стоимость обращения к диску выше стоимости обращения к памяти. Очень хочется, чтобы кандидат мыслил «в масштабе» во всех задачах.
Группа разработки платформы 1С:Предприятие
Главное, что в нашей команде требуется от кандидатов – это умение аналитически мыслить, тщательно анализировать задачу и умение взвешивать способы решения. У платформы 1С:Предприятие довольно долгий цикл разработки (месяцы), поэтому нельзя, как в веб-разработке, реализовывать функциональность по частям, шаг за шагом. Это требует способности глубоко мыслить при продумывании деталей реализации, нужно стараться сделать «все и сразу». Т.е. не использовать для решения проблемы первый попавшийся способ, про который вчера прочел на Хабре, а тщательно взвесить все плюсы и минусы различных путей решения.
Понять на собеседовании, есть ли такие качества у кандидата, не так просто. Наиболее релевантный способ – беседа о предыдущем опыте кандидата. Когда человек рассказывает, какое клевое решение он придумал, спрашиваем – а какая задача, собственно, решалась? Почему было выбрано именно это решение, а не другое? А если бы условия задачи немного изменились, как изменилось бы решение? Задав несколько подобных вопросов, можно понять, насколько человек глубоко погружался в тему.
Есть и другой аспект, иллюстрируемый фразой: «Нанимаем тех, кто умеет работать, а потом почему-то хотим, чтобы они хотели работать». Поэтому на собеседовании хочется понять, чем для человека является работа. Если для него это приятное времяпрепровождение, которое позволяет зарабатывать деньги, то с высокой долей вероятности у нас с кандидатом ничего путного не выйдет. Для большинства профессиональных разработчиков их работа – это самое интересное, чем им когда-либо приходилось заниматься, исследовательская деятельность, желание и умение создавать что-то новое. Человек, приходя к нам, должен быть готов учиться, учиться и учиться. Нам не нужны просто исполнители, нам нужны люди, которым никогда не надоест учиться, на нашей работе учиться приходится очень много и постоянно.
Что еще хочется увидеть у кандидата – инженерные навыки, то есть, фигурально выражаясь, умение из кубиков собрать элегантное решение.
Требуемое знание языков программирования зависит от области разработки платформы, для которой ищется кандидат. Ядро платформы – С++ и Java, веб-клиент – JavaScript и желательно знать основы C++, для некоторых проектов нужно знание 1С, но при этом крайне желательно знание и других языков и технологий. Нам приходится создавать много нового для мира 1С, хочется, чтобы кругозор и эрудиция разработчиков позволяли им оперировать идеями и понятиями, придуманными в других языках и технологиях, и понимать, как их хорошо и правильно применить в нужных местах при разработке решений на 1С. Например, для разработки нашего облачного продукта 1cFresh мы пишем различные инструменты, в основном для администрирования, на 1С (на 1С их быстрее разрабатывать, чем на традиционных языках). Если разработчик понимает паттерны технологий и языков, используемых системными администраторами (bash, Python, Perl), это поможет ему создать удобный в использовании инструмент.
Если собеседуем студента – можем попросить посчитать его интеграл и объяснить, почему интеграл так считается. Средний студент старших курсов смысл интеграла помнит уже нетвердо, а добросовестный, увлеченный студент смысл помнит очень хорошо и может объяснить.
Если перед нами системный администратор – можем спросить, например, об особенностях манипуляций с оперативной памятью в Linux. Если человек работает с СУБД – спрашиваем, например, какие уровни изоляции транзакций бывают, каким кандидат предпочитает пользоваться и почему. Если, например, человек работал над синхронизацией нескольких баз данных – обсудим с ним, как быть, если одна из синхронизируемых баз внезапно была восстановлена из бэкапа. Типичная архитектурная проблема, которую можно решать разными способами.
Еще в кандидате хотелось бы видеть желание изменить мир к лучшему и здоровую долю перфекционизма. Без разумной доли перфекционизма трудно написать код, который будет работать годами на очень разных внедрениях.
Должен ли программист писать тесты? Программист должен выдавать продукт, который работает. Если это взрослый программист, никого не должно волновать, как он это делает. Если это начинающий программист – ему рекомендуется писать тесты. Серьезный разработчик со временем начинает понимать, какие тесты следует писать для создаваемого им кода, где находятся слабые участки кода, которые лучше покрыть тестами. Мы против бездумного глобального покрытия тестами. Программа работает корректно не потому, что ее стопроцентно покрыли тестами, а потому, что разработчик включил голову. Тесты – это вспомогательный инструмент для того, чтобы в наиболее сложных местах программы защититься от ошибок. И надо помнить, что тесты – это не панацея от архитектурных проблем. Самое главное – человек должен включать голову.
Из не-ИТшных вопросов иногда задаем вот такой вопрос – а кем человек себя видит через 3-5 лет? Считаем, что сработаемся с человеком, если его стремления по развитию совпадают с тем, как видит его развитие компания.
Критично важно оценить две вещи. Первая – где человек находится сейчас, какие у него сейчас опыт и знания, какого уровня задачи он может решать прямо сейчас. Вторая – кем человек в благоприятной обстановке готов стать через несколько лет. И чтобы, конечно, эти несколько лет он работал в нашей компании, решал задачи, рос профессионально. Нам даже больше интересно не то, что представляет собой человек сейчас, а то, кем он будет через год-два-три. Нам перспектива всегда важнее текущего положения вещей. Для нас более интересен многообещающий новичок, чем человек с большими достижениями, но погасшими глазами.
Разработка платформы 1С:Предприятие – еще один взгляд
Обычно начинаем интервью с вопросов – какой у вас был самый интересный проект, самый любимый проект? Очень хочется сразу понять, что человека заставляет зажечься на работе, и зажигается ли он на работе вообще.
Далее интересует, приходилось ли человеку оптимизировать производительность программ, как он это делал.
Спрашиваем, какие методики тестирования кандидат использовал на своих проектах, как он выстраивает стратегию тестирования проекта, можем спросить – у нас есть система с вот такой заявленной функциональностью, как будем ее тестировать?
Если интервью на разработчика на Java – спрашиваем про работу сборщика мусора; человек, разрабатывающий более-менее сложные программы, должен быть в курсе нюансов его работы, и как писать код, за которым сборщик мусора эффективно убирает мусор.
Из не-программерских тем интересно поспрашивать про бизнес – какую задачу с точки зрения бизнеса решал любимый проект кандидата, какую пользу приносил. Ви?дение общей картины – очень ценное свойство для разработчика. Однажды был кандидат, делавший блокчейн, его рассказ был очень познавательным.
Задаем задачи на проектирование, просим кандидата спроектировать несложную систему. Потом вместе смотрим на проект, ищем недостатки, обсуждаем, как их устранить. Очень важно, как кандидат реагирует на замечания.
Обязательно рассказываем про то, чем мы занимаемся, а именно – делаем платформу 1С:Предприятие. Рассказываем о том, что у нас можно работать над высокотехнологичными вещами, например, над кластером серверов или над мобильной платформой.
Код на бумаге писать кандидатов не заставляем. Но рисуем на бумаге в ходе собеседования много, рисуем архитектуру системы, схемы модулей, картину их взаимодействия.
Знание конкретных языков не является критичным. Бывает, человек приходит в компанию на позицию разработчика C++, будучи C# разработчиком, и учит C++ довольно быстро. И вокруг много примеров коллег, в ходе работы выучивших новые языки. Если есть желание и знание одного из языков, то выучить новый язык – не проблема.
Еще спрашиваем, что человек читает, только ли Хабр и stackoverflow, или еще и книжки по специальности, и какие именно. Иногда находим для себя таким образом полезные книги.
Группа разработки механизмов отчетности
Нам нужны хардкорные разработчики на C++. Наша команда занимается механизмами отчетности, а значит – наш код много работает с большими объемами данных, и нужно хорошее знание контейнеров и алгоритмов.
На собеседовании спрашиваем – какие библиотеки кандидат использовал в работе, какие алгоритмы. Мы много используем STL, поэтому активно спрашиваем про эту библиотеку, какие контейнеры из нее разработчик использовал, для каких задач. Например, просим написать код, помещающий определенный класс в map, и еще пару аналогичных задач. По таким задачам сразу видно, какого уровня программист перед нами.
Вопросы по теории программирования задаем редко. Считаем, что важнее практические знания. Если человек хорошо решает задачу, удачно применяет теорию на практике, уже не так важно, что он не помнит точную формулировку базовых принципов ООП.
Кстати, если на собеседование пришел студент, которому из-за отсутствия опыта пока трудно справляться с предлагаемыми задачами – делаем на это скидку. Тут уже имеет смысл погонять его по теории, поспрашивать про его профессиональные интересы. Если человек выглядит многообещающе как специалист, имеет смысл дать ему возможность развиться у нас в хорошего профессионала.
Довольно важный критерий для нас – готовность разбираться в чужом коде. Платформа 1С:Предприятие – большой продукт, более 10 миллионов строк кода, столкновение с этим кодом в повседневной работе неизбежно, как минимум на уровне встраивания в него своего собственного кода.
Спрашиваем, как кандидат предпочитает, чтобы ему ставили задачи – в виде детально расписанной спецификации, или достаточно постановки в виде «сделай такой-то механизм». Мы понимаем и принимаем оба подхода, не будем отказывать хорошему программисту только из-за того, что ему нужно разжевывать постановку задачи; нам просто важно сразу понять – как работать с человеком. Но хочется, чтобы в дальнейшем сотрудник развивался в сторону большей самостоятельности, смог взять на себя ответственность за отдельное направление. Как примеры направлений могу привести динамический список или диаграммы. И хочется, чтобы сотрудник развивал это направление – выяснял потребности пользователей этого механизма, общаясь с пользователями на форумах и конференциях, составлял списки новых фич, расставлял им приоритеты, понимал проблемы механизма, предлагал пути решения. Если человеку интересно, он может развиваться как тимлид, начав с курирования студентов-стажеров из нашего Центра Молодых Специалистов, а позже возглавив свою команду. Ну а если человек по натуре «чистый» разработчик, который предпочитает работу по ТЗ и ему не очень интересно разбираться в потребностях пользователей – что ж, и такие люди нам нужны.
Должен ли программист тестировать? Безусловно! Программист, не делающий тестов – как повар, не пробующий то, что приготовил. От программиста нельзя, конечно, требовать полных тестов на всех поддерживаемых средах (Windows, Linux, macOS, веб- и мобильном клиенте), но на текущей операционке проверить базовую функциональность он обязан. Ну а еще лучше, если напишет автоматический тест. Это будет уже готовый регрессионный тест, который ляжет в библиотеку тестов и будет регулярно прогоняться при изменении в соответствующей области кода.
Группа разработки 1C:Enterprise Development Tools
1C:Enterprise Development Tools написан на Java, и мы ищем разработчиков и тестировщиков со знанием Java. Мы ищем людей с горящими глазами, как уже состоявшихся профессионалов, так и новичков с потенциалом. Знание Java для нас обязательно, равно как и знание алгоритмов и структур данных, многопоточного программирования; в нашей команде мы, к сожалению, не можем позволить себе ждать, пока новый разработчик выучит эти вещи. А вот знание конкретных фреймворков, которые мы используем (EMF, Xtext, GEF, Lucene, Handly, …) — дело наживное. Если видно, что человек хорошо соображает и с ним комфортно общаться – значит, в команду он впишется и необходимые знания быстро получит.
Вообще вписываемость в команду – наверное, главный для нас критерий, наравне с профессионализмом. Наша команда – команда энтузиастов, не хочется разбавлять ее людьми другого склада характера. Да и человеку с другим характером в нашей команде, наверное, будет некомфортно работать. Однозначный красный флаг для нас – неуважительная манера общения. Человек может быть очень хорошим профессионалом, но если он не может уважительно общаться с коллегами, он нам не подойдет. У нас игра – сугубо командная.
Особенность институтского образования в том, что в институтах в массе не учат промышленному программированию. Учат синтаксису, конструкциям языка, алгоритмам. А вот умению писать документированный, сопровождаемый код, в который заложены возможности развития, расширяемости – учат очень мало где. Поэтому на собеседовании очень важный тип задач – задачи на проектирование. Например, спрашиваем – как кандидат стал бы писать тетрис, на какие компоненты поделил бы проект, какие интерфейсы бы спроектировал для взаимодействия компонентов между собой. Далее усложняем вводную – например, говорим, что тетрис будет трехмерный (или добавятся новые типы фигур, или фигуры станут падать с разных сторон) и смотрим, насколько хорошо подходит выбранный дизайн под изменившиеся условия. Вообще одна из главных задач собеседования – понять, насколько гибко и широко кандидат может мыслить. И конечно же, программист должен писать тесты, как минимум – юнит-тесты, а еще хорошо бы интеграционные. Стандартный вопрос к задаче по дизайну – а как вы будете тестировать спроектированную систему?
Ну а для тестировщика умение широко мыслить еще более ценно! Есть известная шутка, как тестировщик тестировал бар: заказал одну кружку пива, 2 кружки пива, 0 кружек пива, 999999999 кружек пива, –8 кружек пива, qwertyuip кружек пива, а после сдачи проекта в продакшн в бар зашел клиент и спросил – а где туалет? Главное умение тестера – придумать нестандартные (и в то же время реалистичные) сценарии; стандартные сценарии, как правило, разработчик и сам протестирует.
Заключение
Как не привести тут ссылку на открытые вакансии :)
А еще можно просто прислать резюме на job@1c.ru.
Комментарии (92)
AllexIn
11.12.2018 12:20У 1С ПО репутация популярного, но очень плохого продукта.
На фоне этого статья о том, как набирать специалистов вышлядит усмешкой. Видимо отсюда такая реакция по рейтингу статьи.
Почему бы не рассказать вместо этого о причинах по которым в 1С ПО применяются те или иные решения, которые ведут к созданию такой репутации? Это было бы интереснее и воспринималось бы лучше.
ИМХО.EvilBeaver
12.12.2018 09:43+1У 1С репутация хорошего продукта. Просто низкий порог вхождения порождает большое количество говнокода. Я на каждом собеседовании спрашиваю "что такое индекс в базе данных"? И я редко слышу даже попытку ответить. А вы говорите 1С… Не в ней дело.
PeterG Автор
12.12.2018 09:55Почему бы не рассказать вместо этого о причинах по которым в 1С ПО применяются те или иные решения
Есть пара статей на эту тему:
- Как мы в 1С: Предприятии работаем с моделями данных (или «Почему мы не работаем с таблицами?»)
- Как мы решаем «Что делать?»
Если интересует что-то конкретное — спрашивайте, постараемся ответить в комментариях или в новых статьях.
SkyerAL
11.12.2018 12:40все четко…
но где же прикладники???PeterG Автор
11.12.2018 12:40но где же прикладники???
Если вы про то, как набирают разработчиков прикладных решений — про это в одной из следующих статей.MrRoger
12.12.2018 10:51Тогда, пожелание к следующей статье, если можно, разъясните, пожалуйста подробнее, почему на собеседованиях разработчика прикладных решений, по направлениям, которые не сильно развиты, его проводит специалист HR, а не тех.специалист. К HR вопросов и претензий никаких, они не должны знать тонкостей кода и архитектуры, но если собеседуется разраб, то будьте добры либо прислать ответы с комментариями от тех.спеца, либо вырезать из теста вопросы касающиеся тех.части.
SkyerAL
12.12.2018 12:11есть несколько уровней собеседования. и тех специалисты опрашивают также.
MrRoger
12.12.2018 12:58Видимо, когда я разговаривал со специалистом HR, во всем офисе 1С не было ни одного квалифицированного технаря, способного провести собеседование, на которое пригласили разраба по направлению, которое, хотят сами развивать. Печально :(
EvilBeaver
12.12.2018 16:41Не знаю, я собеседовался технарем (А. Моничев же считается, да?) и потом сам собеседовал, как технарь… <troll-mode>Видимо, вас даже на уровне HR понятно было, куда заворачивать</troll-mode>
fenixnow
11.12.2018 12:40-2Я очень нервничал когда проходил собеседование… более 4 часов со мной общались, узнавали что и как, потом еще час трясло когда ехал домой :) в итоге получил отказ :(
EvilBeaver
12.12.2018 16:43Я б тоже отказал, если кандидат до тряски нервничает. Это ж сразу говорит о внутренней самооценке, как специалиста. Волноваться — нормально, а трястись — лучше уж сразу не ходить на собеседование.
vlad1c
11.12.2018 12:40Имейте уважение к кандидатам, указывай размер зарплаты.
PeterG Автор
11.12.2018 12:42Зарплата обсуждается с кандидатом индивидуально.
Это довольно распространенная практика.
Это не вопрос (не)уважения.
На hh.ru, например, много (на мой взгляд — большинство) интересных вакансий без указания зп.
И это, на мой взгляд, во многих случаях правильно и оправданно.kloppspb
11.12.2018 13:08Это не вопрос (не)уважения.
Это вопрос «пройдёт кандидат мимо вакансии или нет». Я, например, даже вчитываться не буду, если нет хотя бы вилки.red_perez
11.12.2018 13:47Я, например, даже вчитываться не буду, если нет хотя бы вилки.
Аналогично, если нет вилки то прохожу мимо — обычно это означает что работодатель стесняется открыто заявить что зарплата ниже рынка и пытается хитрить.rasswet
11.12.2018 14:14Если открыть hh и взять крупные компании, то яндекс, касперский, рамблер, озон, тинькофф, сбертех, мэилру, такском, ситибанк, мвидео, крок (привет 10 часовой раб день) вилку не ставят. Я не топлю за «лучше не ставить», просто справедливости ради, не одна фирма 1С не ставит вилку.
только дойче банк ставит свои 180.red_perez
11.12.2018 15:03+1Если открыть hh и взять крупные компании, то яндекс, касперский, рамблер, озон, тинькофф, сбертех, мэилру, такском, ситибанк, мвидео, крок (привет 10 часовой раб день) вилку не ставят.
Ну это не логично хотя бы с точки зрения поисковых алгоритмов. По интересующей меня тематике несколько тысяч вакансий, я не собираюсь штудировать их все. Отрезаю по зарплате вершину пирамиды пока не останется меньше сотни вакансий и работаю с ними. Зарплаты без вилки при таком поиске не отображаются.
Я понимаю что Яндекс не развалится без меня, но не мне кажется что не я один так вакансии ищу?
bromzh
11.12.2018 15:33Я вот тоже шлю нафиг, когда не могут сказать вилку. Ведь если вакансия известна, то понятно, какого специалиста надо, и должно быть чёткое понимание, сколько денег компания готова за это платить.
Обычно сумму ЗП не могут сказать, если это бодишоп, типа люксофта, и там куча вакансий с мутными расчётами итоговой зп. Либо когда компания жмотится и хочет уже после собеседования назначить как можно низкую ЗП.
OksikOneC
11.12.2018 21:11+1но не мне кажется что не я один так вакансии ищу?
Так ищут, скорее всего, большинство. Сами эйчары, в большинстве своем случае, фанатично убеждены, что вакансия без суммы, ищется, если кандидат задал интервал ;) Я вас поддерживаю и накидываю еще одну лепешку на вентилятор: я считаю, что не указывать конкретную цифру (или диапазон) в описании вакансии — это просто элементарное не уважение к будущему сотруднику, т.к. для того, чтобы это выяснить нужно:
1. откликнуться
2. возможно списаться/созвониться
3. возможно прийти даже на собеседование, а для этого нужно выделить время
и в результате всего вполне можно услышать предлагаемую сумму, от которой тебе «по-плохеет» в прямом смысле этого слова. Это в 1сниковской среде нормально (у прикладников). И поэтому, я таких скрытных товарищей, считаю людьми, наплевательски относящимися к чужому времени. Но среди этих скрытышей, которые не могут написать сумму или диапазон, есть те, кто находится на вершите креатива. Они в описании своей вакансии пишут так: «Просьба при отклике указывать желаемый уровень дохода.» Т.е. там реально какое-то поле чудес, сектор приз на барабане! и пошел уже торг в темную, мы тебе ничего не скажем — а ты нам давай говори прям сейчас!
Я думаю поэтому, в т.ч. и поэтому, появляются такие статьи ярко-хантинговой окраски. Т.е. вакухи тупо не ищутся по суммам, а «девочки из hr», очевидно перестали по какой-то причине гнать стада кандидатов, у которых горят глаза огнем.
P.s.:
крок (привет 10 часовой раб день)
Это вброс или правда?Neikist
11.12.2018 23:05+110? А не больше? Хотя если про факт говорить помню письма и за полночь от РП из крока приходили.
rasswet
12.12.2018 10:19рабочий день в кроке не имеет строгого времени начала, но за 10 часов ты должен каждый день в программе учета отчитаться. В неделю надо закрыть 50 часов.
можно приходить на 11 и уходить в +10 к этому часов.
мой бывший начальник приходил к 13 или 14ти. иногда мог прийти и в 16 часов. Потом письма писал в 3 ночи.
в каждой ресурсной группе строгость соблюдения может варьироваться но общее правило такое.
kloppspb
12.12.2018 01:58+1Т.е. там реально какое-то поле чудес, сектор приз на барабане! и пошел уже торг в темную, мы тебе ничего не скажем — а ты нам давай говори прям сейчас!
Как хорошо сказал :)
kloppspb
11.12.2018 16:02Возможно, это одна из причин того, что меня нет в этих компаниях :) У меня вообще нет цели «работать в Крупной Известной ИмяКомпании». Есть интересующие меня области, есть понимание сколько это стоит. И только при попадании в оба пункта буду изучать вакансию подробней. Нет ясности — ни секунды и ни калории не потрачу.
korobkov-k
12.12.2018 10:24+1Это значит вы пропускаете самые вкусные вакансии. Ни разу не видел, чтобы компании, которые платят действительно много писали вилки. Вот странно же — программисты с зп 300-400к в природе существуют (либо такие, которые машину покупают на премию), а вакансий на hh таких не бывает никогда.
Собственно в чем проблема при первом же общении с кадровиком обозначить стоимость своего труда? Вы когда приглашаете к себе условного сантехника — он вам говорит цену или вы ему?red_perez
12.12.2018 13:56Это значит вы пропускаете самые вкусные вакансии.
Скорее всего это значит что я пропущу «токсичного» работодателя который хочет скрыть факт что нанимает нового сотрудника на зарплату серьезно больше чем получают «старички». Я готов это пережить, я обычно рассчитываю на долгосрочное сотрудничество и меня не радует перспектива быть прокинутым с зарплатным ростом точно так же как прокинули тех кто пришел раньше меня.
SkyerAL
12.12.2018 12:12это привилегия крупных компаний.
red_perez
12.12.2018 14:09Соглашусь, да крупные не пишут обычно.
Наверное потому что у них есть достаточно стандартная тарифная сетка в зависимости от позиции и никакой интриги нет.
Во всяком случае я работал в 3х больших компаниях, там было так.
И это та самая причина по которой последние 10 лет я не работаю в больших компаниях, обычно они предлагают немного выше средней по рынку но ничего особенного.
Dementor
12.12.2018 18:10Это плохая практика. Некоторое время назад я искал работу. Как хороший специалист (вероятно у вас есть доступ к моему файлу и у вас как на ладони все мои десятки сертификатов и отчеты по внедрениям; но и без него можно посмотреть в мой профиль тостера), решил попробовать силы в разработке типовых конфигураций для Украины. Для вакансий в ABBYY (украинский локализатор 1С) не был указан оклад, но я посчитал, что поскольку это элита программистов 1С, то теоретически у них должна быть хорошая или как минимум рыночная зарплата. В моем резюме даже была указана вилка ожиданий. Я успешно прошел собеседование и только после этого мне на салфетке написали предлагаемый оклад — он оказался в 2 раза меньше от нижней границы ожидания. Меня просили публично не озвучивать цифры и потому прекращаю их позорить.
Но вернемся к вашей корпоративной практике сокрытия размера зарплаты — если бы я знал насколько у вас мизерные оклады, то не терял бы ни свое время, ни время HR и руководителя отдела разработки. Да и смысл скрывать? Сотрудники потом «в курилке» все равно меряются окладами, а искатели работы в фильтрах ставят нижнюю границу и просто не видят ваше предложение.
retran
11.12.2018 12:42… и ни слова про принятый в компании график работы и прочие особенности от которых может возникнуть некоторый культурный шок.
Несмотря на это, 1С для технаря — отличная место работы за счет действительно очень интересных и уникальных задач.PeterG Автор
11.12.2018 12:45принятый в компании график работы
9:15 — 18:00.Naglec
11.12.2018 12:47+1содомия
PAE
11.12.2018 14:11+1Интересно, за что минусуют комментарий Naglec, потому что для разработчика 9-18 — это уже чистой воды архаизм. Нет никаких практических причин фиксировать эти два числа из мантр тридцатилетней давности: часы создания кода не влияют на его качество, а «у нас всё сломалось! почини, тыжпогромист!» решается грамотным тестированием и адекватным процессом релиза/отката.
PeterG Автор
11.12.2018 14:45А, вот коллеги поправили — можно на час двигать, 8:00 — 17:00 или 10-19.
red_perez
11.12.2018 17:57Уже лет 10 как работаю по свободному графику, и с очень большим подозрением отношусь к тем организациям где без нужды требуют посещение строго по рассписанию. Я так понимаю удаленки при таком раскладе быть не может совсем?
Зачем без нужды закручивать гайки? Поверьте мне, это никак не способствует эффективности.
Самое большое раздолбайство всегда там где самые строгие порядки.VVizard
13.12.2018 13:07Вы по свободному графику сайты рисуете?
Или работаете над созданием системного ПО, промышленной системы, которая используется на более чем 1 500 000 рабочих мест и работает на всех платформах?
Просто это немного разная специфика и требует разного подхода к работе.
Возможно прикладные разработчики 1С и могли бы рассчитывать на удаленную работу т.к. все же прикладная разработка проще и масштабы / ответственность немного ниже (только в рамках прикладного решения (кроме БСП)).red_perez
13.12.2018 14:05Вы по свободному графику сайты рисуете?
Вы удивитесь, но нет, занимаюсь производственным софтом, то что крутится на производственном и тестовом оборудовании на заводах и в сборочных цехах. Ну не миллионы конечно рабочих мест, скорее десятки, максимум сотня, в 4х разных странах, а я сижу в другой стране. То есть изначально сама модель бизнеса заточена на удаленку и реально нет большой разницы ты сидишь в офисе или дома.
По поводу свободного графика мне одна аналогия на ум приходит, я когда жил в Германии весьма был удивлен что магазины там рано закрываются а по выходным дак и вовсе почти все закрыты. Привык что все открыто 24 часа в сутки. А потом понял — это помогает снижать издержки и соответственно покупателю будет обходиться дешевле. Все что нужно — это быть немного более самоорганизованым. Так и со свободным посещением, жесткое рассписание отсидки в офисе это непозволительнаая роскошь которая местами уже давно не нужна.
retran
13.12.2018 14:34Или работаете над созданием системного ПО, промышленной системы, которая используется на более чем 1 500 000 рабочих мест и работает на всех платформах?
Просто это немного разная специфика и требует разного подхода к работе.
Нет там никакой специальной специфики. И вопрос про график разработчиками внутри самой 1С поднимается регулярно, благо там уже есть люди работающие по индивидуальным графикам или вообще удаленно. Просто компания большая, консервативная и неповоротливая.
В общем-то, и ужасов, которые возникает в голове при упоминании «фиксированного графика» там нет, все вопросы легко решаются если предупредить за день, штрафов и санкций за опоздания нет.
EvilBeaver
12.12.2018 18:52Я уже от многих слышу, что «в 1С заставляют работать сутками». И всем приходится объяснять, что это не так. Все равно этот слух сидит в отрасли и уходить не собирается.
bonv
12.12.2018 19:12Не сутками конечно, но доля правды в этом есть.
Уйти ты можешь сильно после 18:00 (какой-то факап, срочное изменение законодательства и т.п.), но в 09:15 нужно строго быть на рабочем месте.EvilBeaver
12.12.2018 21:13Ну ежели факап, то ты и в любой другой конторе будешь сидеть ))
EvilBeaver
12.12.2018 21:16Не помню я, чтоб ты тщательно соблюдал приход в 9:15 :D
Но положение такое есть, да
werklop
11.12.2018 13:08-3Важная для нас тема – как писать код для работы в многопоточной среде. Например, есть несколько нодов приложения в высоконагруженной среде
это не про многопоточность, а про распределенность. Вам важно, чтобы человек писал у вас велосипеды или умел применять необходимые навыки?
а кем человек себя видит через 3-5 лет?
да уж… остались в совке и даже этого не понимают. Вы сами то хоть знаете, что с вами будет через те же самые 3-5 лет? Наивные, как дети, ей богу…DrunkBear
11.12.2018 16:44Про «что вы хотите через 5 лет» всегда отвечаю «А чем компания будет заниматься через 5 лет?»
5 лет назад Big Data лично для меня была бесполезной штукой, которая может пригодиться только телекому, а я переходил от MySQL и JS на C# и MSSQL, 10 лет назад я вообще не особо думал о продолжении карьеры в IT, зато всерьёз строил планы развития своей компании.
Сейчас я стал не хучшим специалистом в области Big Data и понятия не имею, чем стану заниматься к 2023.
mkshma
11.12.2018 17:41Читаешь такой, думаешь: «Серьезные, блин, ребята». А потом послушаешь знакомых из компаний-партнеров 1С и кроме смеха ничего и не остается. Багов больше, чем строк кода, в прод выпускаются абсолютно сырые продукты, не способные выполнять даже базовые свои функции, обновление конфигурации вообще штука настолько легендарная, что известна далеко за пределами 1С коммьюнити. В это контексте
Еще мы хотим, чтобы разработчики грамотно писали тесты
выглядит особенно смешно.VVizard
11.12.2018 18:16Замечу что обновление в 1С реализовано очень даже удобно, я немного окунулся в ад «миграций» с помощью скриптов SQL. Там даже свою систему, на 4-5 релизов в верх сложно поднять а если ее еще и допиливали то вообще только ручное обновление. А если откатиться нужно тоже не простая задача.
В этом плане платформа 1С очень удобна, если конфигурация на поддержке то обновление вообще проходит в автоматическом режиме.
Даже если на поддержке но изменений мало тоже все почти автоматом происходит.
А вот если взяли типовую УХ или ERP, основательно поменяли включая и БСП часть, потом 5-6 релизов пропустили потому что невозможно это обновлять, и потом вы пришли на этот проект, то тут да легенды можно сочинять.
Но давайте справедливо рассмотрим если бы в теории на современном стеке WEB (go + js) была коробка имеющая под миллион внедрений, причем каждый бы перепиливал и таблицы и код под себя. Описание процесса обновления были бы не менее легендарными на всех форумах страны.
Я не эксперт (может эксперты меня поправят) но если взять WordPress добавить в него десяток плагинов, потом основательно его допилить, поменяв и расширив объекты и таблицы, допилить так же плагины, и не просто CSS поменять а расширить функицонал.
Потом пропустить 3-4 релиза WP все это время частично дергая из них куски в своего франкенштейна.
А потом предать этот проект вам и попросить обновить на последнюю версию (WP и все плагины).
Я думаю история будет не менее легендарная.
Другое дело что современные подходы к разработке позволяют не менять в корне систему а добавлять новые плагины, наследоваться, тот же CSS позволяет в широких приделах настраивать внешний вид. И WP конечно более модульный, поэтому для его адаптации не обязательно переписывать ядро системы.
В последних релизах платформы добавили механизм расширений это что то типа наследования (в стиле 1С) и это на порядок упростило даже сложную доработку типовых решений.
По поводу багов в платформе.
Я не могу сказать что платформа забагована по 10 бальной шкале я бы оценил качество платформы на 8 балов. Да учитывая масштабы использования платформы я вообще могу сказать что качество реализации платформы идеальное.
Если же говорить о конфигурациях (которые и пишут на языке 1С) то (возвращаясь к языку 1С) очень сложно писать без ошибок, вся структура языка провоцирует ошибки которые не ловятся при синтаксис контроле.
Я сравнивая свою работу на RoR и на 1С могу сказать что у меня соотношение ошибок в продакшене 1:5. Т.е. в решениях на RoR у меня 1 ошибка на 5 ошибок в разработке на платформе 1С.
Потому что большую часть ошибок RoR не дает сделать.
Если в 1С есть процедура в которую передается как параметр структура я обязан проверить все места откуда вызывается эта процедура что бы понять что там вообще в этой структуре приходит.
И нет никаких гарантий что завтра туда не придет структура в которой не будет нужного мне поля. Да можно написать комментарий и описать в нем поля структуры, проверять наличие свойства перед обращением(и выкидывать исключение?), но в нормальных языках структура описывается не в комментарии а в самом языке, и это на порядок надежнее чем писать комментарии.
В том же RoR я могу сказать что процедура принимает на вход конкретный объект и описать структуру этого объекта в отдельном классе, при этом если кто-то в другом модуле передаст туда объект другого типа я получу предупреждение от компилятора, а в 1С я узнаю об этом по ошибке на тестировании или на продакшене.
EvilBeaver
12.12.2018 09:47+1Эти "партнеры" просто в глаз не видели, как обновляются базы в других языках. Если бы видели, то миграция в 1С казалась бы почти шедевром
1c80
11.12.2018 21:22Не знаю, по мне всё новые управляемые формы испортили, появились тормоза, усложнилась разработка, переусложнился код, как выше написано ну и соответственно увеличилась стоимость поддержки, а у клиентов и так бабла нету, пользы 0, только красивее стало, но кому оно надо такой ценой.
По остальному же, для бизнеса лучшей программы не найти, на данный момент аналогов и близко не видно, хоть готовое бери, хоть то что есть допиливай, да есть некоторые глюки и непредсказуемость, но если знаешь как что, то особых проблем нету.9thlevel
12.12.2018 05:02+1Управляемые формы — это вполне логичное развитие платформы. Обычный клиент устарел технически и морально. Перенос основной нагрузки на серверы — правильное решение. Не должен клиент выполнять сложные алгоритмы. Для этого существуют серверы приложений. Разработчику нужно только перестроить сознание, прочитать несколько статей и принять новую архитектуру. Поверьте, если есть опыт разработки управляемых приложений, стоимость поддержки не выше, чем у обычных приложений.
Но самый важный плюс — появление веб-клиента. Да, он еще сырой, иногда приходится костылить код конфигурации, чтобы обойти ошибки в веб-фреймворке клиента. Но больше нет головной боли с разворачиванием на машинах сотрудников свежих версий клиентских приложений при миграции сервера 1С на более свежую версию платформы. Человек просто открывает браузер и начинает работать.
Еще технология управляемых приложений позволяет быстро разрабатывать B2B-системы. Естественно, есть некоторые минусы. Лично для меня — бедный интерфейс, если сравнивать с веб-сайтами, и высокая стоимость лицензий при построении многопользовательских систем (от 500 пользователей).nki
12.12.2018 09:17+1Если был опыт разработки в web, то управляемые формы заходят на ура. Мне очень нравится, что 1С сделали шаг в сторону мобильной разработки.
EskakDolar
12.12.2018 11:59У кого был опыт разработки в web управляемые формы вызывают двоякое чувство. С одной стороны да — есть нечто знакомое и даже привычное, а с другой реализовать вэбинтерфейс на языке 1С это как сделать современный авианосец из дерева. Плавать он может и даже в чем то даже лучше чем из метала, но, блин, 21й век на дворе.
И еще. Я считаю сделать управляемые формы и не сделать штатный конвертер для неуправляемых форм это издевательство по отношению ко всему штату 1С программистов.bonv
13.12.2018 17:41И еще. Я считаю сделать управляемые формы и не сделать штатный конвертер для неуправляемых форм это издевательство по отношению ко всему штату 1С программистов.
Вот есть конвертер из 7.7 в 8, но что-то пользы от него 0. Хотя там гораздо проще, чем из обычных форм сделать управляемые.
Ta_Da
13.12.2018 22:52Я могу конечно ошибаться, но на других платформах и языках с конвертерами тоже как-то не очень. Потому что регулярно вижу как разработчики рассказывают о героических усилиях при переходе с одной версии библиотеки/языка на следующие или горький плач тех, кто вынужден работать на неактуальной версии языка, т.к. «кровавый интерпрайз» и «легаси».
Но если этого конвертера нет у 1С — это сразу издевательство? =)
o4karek
14.12.2018 09:49Самая очевидная причина — этот конвертер нормально сделать невозможно.
Т.е. форму можно попытаться перерисовать в управляемом режиме. А вот код — уже не получится. Смысла в таком конвертере не очень много.
jenki
12.12.2018 09:34+1Подскажите, в разработке какую систему контроля версий вы предпочитаете, какими системами автоматизации используете, какие методологии разработки вы используете? Есть ли такая вещь как bug trecker? И ещё крамольный вопрос — посматриваете ли в сторону контейнеризации?
PeterG Автор
12.12.2018 09:49в разработке какую систему контроля версий вы предпочитаете
svn, git
какими системами автоматизации используете
Jenkins например.
Вот тут и тут про это есть подробнее.
какие методологии разработки вы используете
Зависит от команды. Кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде.
Тут про это есть чуть подробнее, раздел «Люди и процессы».
Есть ли такая вещь как bug trecker?
Обязательно!
Используем собственную конфигурацию «База задач», написанную на 1С, на ней же отлаживаем самые новые версии платформы 1С. Тут есть подробнее, раздел «Eating your own dogfood / База задач».
Некоторые команды используют Jira и Bugzilla.
посматриваете ли в сторону контейнеризации?
Посматриваем. Более подробно, к сожалению, пока ответить не могу.jenki
13.12.2018 00:45svn, git
Почему тогда эти наработки не реализованы? Чтобы взять поставку или конфигурацию, надо заниматься извратом в виде подключения к хранилищу и последующей выгрузки (подключение не всегда происходит корректно, выгрузка происходит медленно и без нормальной индикации процесса).
Jenkins
Это объясняет ошибку, которую вываливает 1С при ошибке в параметрах подключения. Что-то про диск D и Jenkins.
Зависит от команды.
Это объясняет ту разножопицу, которая творится в ваших поделках. ЦКК нахерачили на один лад (жутчайший ответ Заббиксу от 1С), в менеджере сервиса по другому, шлюз кто-то на Яве решил вдруг написать. Куча громких заявлений и амбициозных замашек, ни одна из которых не доведена ни до ума, ни до логической завершённости. Не зря некоторые крупные торговые сети не пользуются последними версиями платформы, а ждут около года, пока более менее косяки не поправят. Правда это не сильно помогает.
Используем собственную конфигурацию «База задач», написанную на 1С, на ней же отлаживаем самые новые версии платформы 1С.
Имел в виду сервис, куда можно присылать ошибки с описанием, чтобы хоть как-то давать обратную связь. Например, как в некоторых операционных системах.
Посматриваем. Более подробно, к сожалению, пока ответить не могу.
Оставьте их в покое. Посмотрите лучше в сторону адекватного дизайна интерфейса и юзабилити. У вас вообще есть такие люди? Интересно, а временами очень, кто же так шедеврально лажает.
Наша мечта — делать лучший в мире инструментарий для разработки бизнес-приложений.
Чья конкретно это мечта? Почему о ней ни сном ни духом не знают разработчики?
У нас очень много отличных идей.
Так сделайте их нормальными, хоть какие-нибудь.
реализация которых позволяет нам эту мечту осуществлять, развивать наши инструменты, чтобы оставаться лучшими
Кто такое сказал? Статья заминусована, комментарии полны токсичности и отвращения к вашему продукту. О чём вы?PeterG Автор
13.12.2018 09:57svn, git
Почему тогда эти наработки не реализованы?
Я писал о том, чем пользуется команды разработки платформы.
А вопрос, как я сейчас понимаю, был про прикладные конфигурации.
Извините что не сразу понял суть вопроса.
EvilBeaver
12.12.2018 09:53Спасибо за статью. Удивлен отрицательному рейтингу.
В самом начале увидел отдельный пункт "разработка компилятора встроенного языка". Мне, как автору альтернативного компилятора 1С, интересно- что же за задачи будут поставлены сотруднику, который придет в эту группу разработки? Дело в том, что язык крайне консервативен и не развивается уже больше десятилетия. Возможно, внутри компилятора и есть оптимизации, но нам они не видны, снаружи разработка компилятора выглядит мертвой. Что такого будет разрабатывать новый сотрудник этой группы и вообще, есть ли планы по развитию языка? Выше в комментариях привели подробный разбор его проблем, и он далеко не полный. Спасибо за ответ.
Dementor
12.12.2018 18:1516 минусов — это не очень много.
Удивляет другое: почему не найдется 16 человек, которые их перекроют?
chelovekkakvse
13.12.2018 09:26Не оправдывая DSL, считаю, что основной проблемой платформы является ее монопольность. Если были бы другие интерпрайзные решения по бухгалтерии и складу, особенно опенсорс, то и 1С пришлось бы развиваться. А так… Зачем?
EskakDolar
Когда же вы наконец поймете — что бы достичь вашей мечты (если конечно не врете) вам нужно отказаться от корявого велосипеда под названием «язык 1С».
Neikist
Вот у меня ощущение что это как раз из чрезмерной увлеченности прикладной областью вместо технической, которую так расхваливают. И да. Я действительно считаю 1с отличным фреймворком для решения своих задач но с настолько ужасным языком, что меня это заставило спустя 4.5 года работы с нее уйти.
PeterG Автор
"отказаться от корявого велосипеда под названием «язык 1С»."
Пока не вижу причин отказываться от Domain-Specific Language — он позволяет решать задачи выбранного домена на порядки быстрее классических языков программирования.
В пользу чего предлагаете отказываться?
Что взамен?
EskakDolar
А я уверен что «Domain-Specific Language» сдерживает развитие 1С.
Вариантов много — Java, JavaScript, Kotlin. Можно предложить еще, но этих достаточно.
Главное отказаться от концепции «язык быстрого старта для бухгалтера».
Уже на 1С 7.7 было очевидно что она не работает. Профессионалу язык 1С плох недоразвитостью. Бухгалтеру он просто не нужен потому что он бухгалтер, а не программист. Я за всю жизнь знал только одного финансового директора который мог бы заняться программированием, но не делал этого потому что это ему незачем.
dskozin
JavaScript? Серьезно да? Забыли еще Go, Haskell и PERL в список добавить. А что? Взрослые языки.
Neikist
Ну не js а ts или лучше dart. Да хоть в свой язык бы добавили полноценное ООП, статическую типизацию, замыкания и прочие современные возможности повышающие надежность, ускоряющие разработку и уменьшающие количество кода.
EskakDolar
И все таки лучше именно JS. TS расширение JS и обратно совместим.
Внедрили бы в 1С JS и TS стал бы доступен сам по себе. И не только TS.
В результате 1С развивался бы по инерции вместе с развитием JS.
1С развивало бы сообщество программистов.
А что имеем теперь? Внедрили в 1С «очень много отличных идей» и на этом все встало. Весь мир ушел вперед, а в 1С язык по сути остался тем чем был 15 лет назад.
dskozin
Или CoffeeScript. Отлично уменьшает количество кода. Популярный…
dskozin
Если серьезно, то нужно просто понять, что язык вообще не определяет технологию. Вы мало знаете примеров плохого кода на JS или Java? Проблемы у 1С возникают в первую очередь из-за проблемных франчей, которые понанимают вчера родившихся «программистов», а потом люди очумевают от говногода. Почему много «новорожденных»? Две причины: массовость технологии и крайне низкий порог входа. Так что получается, что основная проблема 1С не в языке, а в его простоте и популярности. И не будет развиваться платформа, если сменить язык — она как была так и останется, только с другим языком. Только специалисты станут дороже.
Хотите сравнить язык платформы 1С с ABAP? Как раз языки одного класса.
Извините конечно, но если вы думаете что проблема в языке, то вы совсем не разбираетесь ни в платформе 1С, ни вообще видимо в разработке корпоративного ПО.
EskakDolar
1C ругают не за говнокод неофитов, а за искусственные ограничения.
Ведь были же в 1С 7.7 1с++, OpenConf и другие сторонние разработки. Отличные вещи, скажу я вам. Ведь была же в 1С 7.7 возможность реализовать их. И они делали 1С 7.7 живой средой которую можно совершенствовать и развивать. Так надо было продолжать этот путь.
1С 8 убил их на корню, а все из за нездорового стремления все контролировать.
VVizard
На мой взгляд(со стороны прикладного разработчика) основные проблемы в языке 1С:
Отсутствие типизации, крайне ограниченные возможности ООП.
В итоге нормальный статический анализ кода невозможен, IDE старается, но ее автодополнение практически бесполезно.
Любая более менее крупная конфигурация это 150-200 модулей типа:
Еще и при доработке приходится использовать префиксы модулей, в итоге имеем что-то вроде ДОУ_ОбщегоНазначения.
В RoR(Ruby on Rails) я могу написать UserFullName, "." получу в автодополнении: «titleize».
В 1С нужно вспомнить в каком из 180 модулей есть нужная функция, и затем написать:
«ОбщегоНазначения» (тут выскочит автодополнение в котором модули будут перечислены примерно так: «ОбщегоНазначенияКлиент...» (8 таких элементов, нужно угадать какой именно нужен, так как полностью название не отображается), затем "." затем я увижу подсказку IDE где будут абсолютно все экспортные методы которые есть в модуле, дальше я должен среди всего этого разнообразия найти нужный мне метод.
В итоге получим:
ПолноеФИО = ОбщегоНазначенияКлиентСерверПовтИсп.Титулизировать(ПолноеФИО);
Или например есть у меня 2 справочника: Пользователи, ВнешниеПользователи, и я хочу
написать функцию «ПроверитьЗаполнениеПаспортныхДанных()».
Я должен придумать в какой же модуль разместить эту функцию.
Отлично, у нас есть модуль: «Пользователи», точнее не так, у нас есть 11 модулей «Пользователь»:
Помогите разработчику 1С разместить функцию ПроверитьЗаполнениеПаспортныхДанных.
Вы наверно думаете что разместить нужно в «Пользователи»?
А вот и нет, Пользователи это модуль стандартной библиотеки (БСП) который на поддержке и дорабатывать изменять его нельзя (точнее можно но при обновлении на новую версию библиотеки нужно будет переносить эти изменения руками, поэтому нельзя).
Так что задача куда бы приткнуть эту функцию не такая уж и простая.
(многие даже не пытаются а создают модуль: Префикс_Пользователи и размещают туда, в итоге спустя год у нас уже не 11 модулей «Пользователь» а 22 модуля «Пользователи...» + «Префикс_Пользователи...»)
В том же Ruby я бы добавил метод в класс «Пользователи» и вызывал бы его так:
При этом язык и IDE абсолютно не развиваются.
Даже если перейти на Eclipse ситуацию со статическим анализом, автодополнением, организацией кода это никак не поправит.
Еще один интересный пример, если я добавляю реквизит на форму я указываю для него тип, и в IDE и в коде этот тип естественно учитывается и IDE понимает какой тип и показывает релевантную подсказку автодополнения (с учетом встроенных в платформу типов).
При этом в языке нет возможности просто объявить переменную с указанным типом или тип параметра процедуры/функции и тип возвращаемого значения.
В итоге так и живем, иногда IDE что то подсказывает иногда нет, все для разработчика.
Так же Платформа на первый взгляд мощный инструмент, масса возможностей, часть из них (СКД) вообще не имеет аналогов. Но стоит копнуть чуть глубже и выясняется что пользоваться этими возможностями нужно с оглядкой.
Из недавнего:
Нужно было интегрироваться с внешней системой через SOAP, казалось бы в платформе и XDTO есть и WS сервисы и ссылки, функционал достаточно мощный (хотя XDTO это отдельный разговор). Во время реализации выяснилось что платформа не поддерживает HEADER в SOAP запросах.
PeterG интересно как сами системные разработчики платформы относятся к языку?
Вы не пробовали внутри компании поручить вашим программистам реализовать более менее сложный функционал на языке 1С? Возможно тогда станет более понятно почему все программисты так «не любят 1С»?
Есть вероятность что переход с С++ на 1С будет не таким болезненным как с RoR тут мне сложно судить.
Да и вообще интересно есть ли хоть один человек который перешел в 1С из мира С++, С#, Ruby, Go без ломки сознания и негатива?
p.s. Может сложиться мнение что я сильно не люблю платформу, на самом деле это не так, платформа на мой взгляд уникальное решение которое реально позволяет упростить и ускорить разработку. При этом встроенная объектная модель (типы которые реализованы в платформе) продуманна хорошо и к ней у меня претензий нет. И развивается платформа очень активно, настолько что уже хочется притормозить.
Но язык, подходы к разработке, организация процесса, слишком примитивны. Особенно разница заметна если 2-3 месяца писать на Ruby (в RubyMine) а потом вернуться к конфигуратору 1С.
(использовать RoR приходится в основном потому что лицензионная политика 1С делает разработку различных «личных кабинетов» достаточно дорогостоящим занятием, и по соотношению качество/деньги выгоднее писать отдельные системы на том же RoR которые затем синхронизировать с основной ИБ на платформе 1С).
nki
Перешел в 1С из C#. Сознание не ломалось. Особого негатива нет. В целом я доволен.
MrRoger
По мне так, большинство аргументов притянуты за уши. Начиная от оратора выше про «какая клевая была 7.7 с openconf и 1cpp» и заканчивая вайном, про " 11 модулей Пользователи". Не стоит путать теплое с мягким, Вам понравилось, что 7.7 можно было дополнить openconf'ом? а чем? тем, что ограниченность 7.7 не позволяла использовать автоподстановку, а openconf вам это дал? Отлично, получите 8.х — все собрано в одном ядре. 11 модулей «пользователи», так спросите автора сего творения, на кой так проектировать. Не устраивает, никто не запрещает вам взвести флаг «глобальный» и уйдут проблемы с «наследованием» и «докомпляцией» модулей и не надо будет писать «ОбщийМодуль.» и т.п. А сделав его глобальным не стоит истерить о том, что софт медленно работает.
Что-то такой портянки «стонов» я не замечал, когда была статья об «обновлении VS от мелкософта». А если по сабжу — могу согласиться только с тем, что 7.7 была лучше в работе с внешними файлами. На ходу подцепить какую-то dbf'ку и не потерять в производительности — да, круто было. Только не стоит забывать о том, что это цена за защищенность данным в пределах БД и она у тебя не крашнется, только из-за того, что какой-то «мега-умный» одмэн решил почистить каталог в непонятными файлами и убил всю отчетность. А по функциональности меня 8.х более чем устраивает.
Neikist
Вот не знаю. Я с 1с 4 года с копейками, как то мне много по мелочам не нравилось, но в целом устраивало. Хотя дико раздражала перезаточенность коммьюнити вместо кода и технической части на учет и конкретные прикладные решения.
А потом распробовал статическую типизацию, удобные инструменты вроде идеи, возможность писать ПО общего назначения а не только учетное и не платить за лицензии, использовать удобные языковые конструкции вроде лямбд и реактивщины, да даже интерфейсов… После этого в 1с мне работать показалось болью и в итоге не смог заставить себя остаться.
EskakDolar
Именно по этому мне иногда кажется что разработчики 1С сборище программистов-садистов. Ведь саму они платформу пишут не в конфигураторе на 1С.
VVizard
Я в индустрию разработки на 1С пришел на 8.2.
Версию 7.7 видел только на картинках.
Что такое «7.7 с openconf и 1cpp» даже близко не знаю, посмотрел в гугле, какие то велосипеды начала 21 века.
Вы точно мне отвечаете?
Может ошиблись темой?
MrRoger
Я в целом. Если по частностям, то openconf — habr.com/company/1c/blog/432672/#comment_19483866
а про количество модулей — уж, прошу простить, то к Вам.
EskakDolar
Ваше счастье что вы не видели язык запросов в 1С 7.7.
Мне бы очень хотелось тому кто его создал посмотреть в глаза и спросить «ЗАЧЕМ ТЫ ЭТО СДЕЛАЛ!? Ты что никогда нормального языка SQL не видел !?»
Кстати, именно чтобы исправить это недоразумение и был создан 1с++, но к сожалению сторонними разработчиками. В головах у разрабов 1С, видимо, сидит какой то неискоренимый комплекс.
fishca
О! ДА! ДА! ДА!
EvilBeaver
А я кстати
знаюдогадываюсь зачем. Это должен был быть упрощенный SQL. Т.е. минимальный порог вхождения, описать результат получаемый из базы, но проще, чем на SQL. Потом, как обычно, вылезли нюансы и «простой» язык превратился в «особенный»…