дисклеймер |
|---|
| Все описанное в статье является субъективным мнением автора, и оно может не совпадать с вашим.
Так же все выводы основаны из-за того, что автор не постиг всего дзена 1с |
Всем привет.
Расскажу чуть-чуть о своем пути как я сначала стал 1сником.
Работая в тех поддержке, начал учить 1с, сдал спеца и пошел покорять просторы 1с.
Почему то была твердая уверенность, что я как "сертифицированный специалист" легко найду работу (как же я ошибался...)
После долгих поисков попал в Первый Бит, мне очень повезло, отдел был неимоверно крутым (даже спустя 5 лет мы все общаемся до сих пор) реализовывал международный налоговый учет, отдел распался и потом ушел в детский парк, там то и начал учить java более основательно, т.к. первое знакомство с java было еще во времена когда учил 1с.
Начал с gb (сразу скажу что это полный отстой как конторы целиком, есть здравые и хорошие преподы, но в своем большинстве все хотят срубить бабло а не научить чему то) записался на мобильную разработку.
Тогда еще не знал что мне интересно, просто хотел пощупать что это и с чем это едят и цели уйти из 1с не было, хотелось просто расширить кругозор.
Прошел весь курс по java и первую часть по Android и ушел оттуда, потому что как сказал выше, это фигня.
Но появилось непреодолимое желание начать вникать в android разработку и пробовать уходить от 1с в сторону мобильных приложений. Следующим шагом, пошел учиться в otus и параллельно вливаться в "android тусовку".
По началу было очень классно и нравилось, но потом сменился преподаватель и otus так же скатился в моих глазах.
p.s. сейчас если бы я захотел выучить что то новое, то больше не ввязывался бы в онлайн обучения (в интернете полно материала, который бесплатный и подан лучше чем на курсах)
Во время учебы посещал Android academy в мск, за что им большое спасибо, помогли структурировать некоторые моменты.
После прохождения учебы, смог запилить свой первый проект, который опубликовал в маркете. (p.s. бэк написан на 1с, куда же без него). Предвкушая что это мне даст сильный толчок в поиске работы начал понемногу откликаться на вакансии и думал что найду работу быстрее чем я искал в свое время по 1с (как же я ошибался... (2))
В проекте использовался на мой взгляд "базовый набор" программиста(retrofit, rx, recycler ну и т.д.)
А вот потом пошло долгое затишье почти на год, полтора, доделывал какие то фичи в приложении плюс грянул ковид.
Но в прошлом году решил, что если не сменю деятельность, то наверное не буду дальше пытаться.
Итого на момент начала основательного поиска работы у меня было:
рабочий проект в плей маркете, базовые знания (rx, retrofit, realm, mvvm ну и по ui части всякие recyclerview, constraint)
Поиск начался как то странно, с поступления в tinkof fintech и там я впервые познакомился с kotlin. Для меня было тяжело в нем разобраться с точки зрения чтения кода, но это дело привычки.
Во время обучения в тинькоф, спамил на все вакансии android на hh, но везде как ни странно были отказы, даже на собеседования не приглашали.
Тинькоф уже отпадал как первое место работы, т.к. не успевал сделать проект, который мы делали на занятиях.
И вот после долгих поисков, под конец учебы в тинькоф, меня позвали на мое первое собеседование на позицию android. Т.к. опыта собеседований у меня не было, то после прохождения собеседования сложилось впечатление, что я его завалил (из того что помню спрашивали про rx, dager, mvvm, было еще что то, но не помню)
Спустя 3 дня мне позвонили и сказали, что готовы меня взять...
Сколько же было радости... Отказался от двух интересных предложений с довольно высокой зп, но там пришлось бы заниматься 1с, чего мне уже не хотелось и я, решив что это мой шанс, который упускать нельзя, пошел на свою первую работу в качестве android разработчика.
Я очень давно не ходил на работу, на которую действительно хочешь идти а не потому что надо. Каждый день ждешь с нетерпением, чтобы погрузиться во что то новое.
По зарплате: она упала на треть что для меня очень критично, но всякие шабашки по 1с помогали мне оставаться на плаву.
Отработал полгода за это время структурировал свои знания, начал погружаться в kmm (мультиплатформа) познакомился с чистой архитектурой (какая же это классная вещь...), dagger и hilt, стал писать на kotlin и вот яндекс проводит конкурс... Как итог, лето начинается с работы в яндекс
А вот причины по которым решил уйти из 1с...
Мне всегда нравилось писать код, но 1с тебя ограничивает в плане задумок, это на мой взгляд и плюс и минус, тебе на надо заморачиваться над описанием классов, у тебя все есть: справочники, документы, перечисления ну и т.д., но в то же время ты не можешь создать свой класс. Так же работая программистом 1с, ты будешь выступать в роли консультанта или тех поддержки, а хочется просто писать код и со временем уже ничего не хотелось учить, что связано с 1с.
Итог
Не бойтесь идти к своей цели и занимайтесь тем чем нравится.
Всем добра...
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4)
По-сути, в 1С это все есть - модуль объекта и локальные и экспортные переменные, процедуры и функции реализуют инкапсуляцию, при том полиморфизм этих методов реализован "искаропки", а вот наследования нет - это может усложнить реализацию похожих объектов. При том множественное наследование могло бы помочь с реализацией и в 1С. Допустим, у нас есть движения по взаиморасчетам, остаткам на складе, париям, себестоимости, заказам/резервам и т.д. Если бы у нас были базовые объекты, двигающие остатки, то все документы, которые бы двигали остатки, могли бы иметь унаследованную от них логику движений остатков. И если бы к остаткам нам нужно было бы прикрутить еще один разрез, то нам не нужно было бы переписывать все эти документы - достаточно было бы подменить базовый класс. И это как раз пытаются сделать в типовых огородами, преодолевая ограничения отсутствия базовых механизмов наследования, в итоге код типовых становится очень сложно поддерживаем.
Зачем?
Класс - штука удобная, но чтобы это понять, нужно понять, что такое полиморфизм. 1С тут проста и примитивна - есть массив объектов, тебе не нужно думать, что это за объекты, при том ты можешь вызвать метод для любого объекта, если он у него есть ("Записать()", например). В ООП ты это реализуешь через наследование базового класса, переопределяя виртуальные методы.
По-сути, в 1С это все есть - модуль объекта и локальные и экспортные переменные, процедуры и функции реализуют инкапсуляцию, при том полиморфизм этих методов реализован "искаропки", а вот наследования нет - это может усложнить реализацию похожих объектов. При том множественное наследование могло бы помочь с реализацией и в 1С. Допустим, у нас есть движения по взаиморасчетам, остаткам на складе, париям, себестоимости, заказам/резервам и т.д. Если бы у нас были базовые объекты, двигающие остатки, то все документы, которые бы двигали остатки, могли бы иметь унаследованную от них логику движений остатков. И если бы к остаткам нам нужно было бы прикрутить еще один разрез, то нам не нужно было бы переписывать все эти документы - достаточно было бы подменить базовый класс. И это как раз пытаются сделать в типовых огородами, преодолевая ограничения отсутствия базовых механизмов наследования, в итоге код типовых становится очень сложно поддерживаем.
(9)Это все замечательно конечно, но остатки имеют как правило разное количество разрезов и разные типы разрезов.
Я как-то мало себе представляю ситуацию, в которой пришлось бы двигать несколько разных остаточных регистров по одной "структуре" остатков.
Далеко ходить не будем, возьмем ПартииТоваров, ТоварыНаСкладах, ОстаткиТоваров, СвободныеОстатки.
Зачем еще в каком-то регистре хранить остатки в тех же разрезах, что и в ОстаткиТоваров, например, мне не очень понятно.
А делать возможность программисту 1С создавать условный класс "ОстаткиТоварыНаСкладах" для использования его при работе с по-сути одним остаточным регистром "ТоварыНаСкладах" - такое себе.
Либо я не правильно понял вашу мысль.
Я как-то мало себе представляю ситуацию, в которой пришлось бы двигать несколько разных остаточных регистров по одной "структуре" остатков.
Далеко ходить не будем, возьмем ПартииТоваров, ТоварыНаСкладах, ОстаткиТоваров, СвободныеОстатки.
Зачем еще в каком-то регистре хранить остатки в тех же разрезах, что и в ОстаткиТоваров, например, мне не очень понятно.
А делать возможность программисту 1С создавать условный класс "ОстаткиТоварыНаСкладах" для использования его при работе с по-сути одним остаточным регистром "ТоварыНаСкладах" - такое себе.
Либо я не правильно понял вашу мысль.
(11)
Таким образом у нас могло бы быть энцать базовых классов, реализующих эти движения, а логика документа могла бы просто наследовать все эти классы, что сильно упростило бы повторное использования кода, для которого и придумано ООП. Если бы поменялась структура глобально - захотели бы мы, например, к остаткам добавить серию или характеристику, то мы бы просто поменяли базовый класс, а документы бы унаследовали от базового класса все изменения автоматически.
Далеко ходить не будем: возьмем ПартииТоваров, ТоварыНаСкладах, ОстаткиТоваров, СвободныеОстатки.
Зачем еще в каком-то регистре хранить остатки в тех же разрезах, что и в ОстаткиТоваров, например.
Ну вот Вы же сами понимаете, что документ не ограничивается только движением остатков (та же ЕРП с ее движениями при подборе и размещении в складских ячейках).
Зачем еще в каком-то регистре хранить остатки в тех же разрезах, что и в ОстаткиТоваров, например.
Таким образом у нас могло бы быть энцать базовых классов, реализующих эти движения, а логика документа могла бы просто наследовать все эти классы, что сильно упростило бы повторное использования кода, для которого и придумано ООП. Если бы поменялась структура глобально - захотели бы мы, например, к остаткам добавить серию или характеристику, то мы бы просто поменяли базовый класс, а документы бы унаследовали от базового класса все изменения автоматически.
(12)Так это было бы количество этих классов по количеству регистров, оно и в текущей версии реализуемо, пусть и огородами, как вы говорите.
Мне еще не понятно следующее: вот допустим, дали возможность делать классы, какими бы методами обладал при этом базовый класс у того же регистра накопления: ДобавитьРасход()/ДобавитьПриход()?
Из-за этого весь сыр-бор?
Мне еще не понятно следующее: вот допустим, дали возможность делать классы, какими бы методами обладал при этом базовый класс у того же регистра накопления: ДобавитьРасход()/ДобавитьПриход()?
Из-за этого весь сыр-бор?
(16)
Так вот с точки зрения SOLID - концепции разработки в ООП-парадигме - есть базовый класс, меняя который программа должна продолжать работать так, как будто изменений и не было.
Так вот если, допустим, в 1С был бы класс для работы с остатками, то интерфейс к нему в общем-то и не нужен был бы - документ был бы поставщиком данных, а при проведении базовый класс сам бы производил нужные движения по регистру остатков. Класс можно было бы расширить сериями - добавить к нему еще один механизм движений - по сериям. Потом по характеристикам, если бы нам понадобились характеристики. Ну и т.д. Второй класс, от которого наследовалась бы логика движений, может отвечать за взаиморасчеты, третий - за партии, четвертый за что-то еще (тот же РАУЗ). На выходе собранный объект.
Да, сейчас фактически обработка проведения так и собирается - тащатся запросы из подсистем оперативного или бухгалтерского учета, собирается итоговая таблица движений по всем используемым регистрам, потом результаты запросов накатываются на регистры. Но, честно, на сколько просто будет добавить разрез какой-то ко всем документам при таком подходе? Нужно будет или найти этот запрос и добавить в него разрез, найти все запросы с этим регистром, переписать гору кода, потом огрести проблемы с обновлением, т.к. придется всю эту гору измененного кода поддерживать. А если бы изменения касались только базового класса, то проблем бы вообще не было ни с расширением, ни с поддержкой обновлений.
В общем, у ООП есть свои плюсы, которые кажутся неочевидными с первого взгляда, но они действительно есть. И всегда можно написать программу без ООП. Но, повторюсь, суть ООП в том, чтобы код мог быть переиспользован максимальное количество раз, и при этом стабильность системы не была бы нарушена.
вот допустим, дали возможность делать классы, какими бы методами обладал при этом базовый класс у того же регистра накопления: ДобавитьРасход()/ДобавитьПриход()?
Из-за этого весь сыр-бор?
Все более масштабно, чем Вы думаете. Фактически, объект - это экземпляр класса. В 1С есть множество объектов, при том стандартные объекты типа документов, справочников, регистров и т.д. расширяемы. Но в 1С расширяемые объекты привязаны к ORM - реляционной модели, при этом механизм взаимодействия с СУБД жестко заложен в их внутренности, поэтому для программиста невидим (можно, конечно, заменить словом "прозрачен", но это не в полной мере отражает суть проблематики).
Из-за этого весь сыр-бор?
Так вот с точки зрения SOLID - концепции разработки в ООП-парадигме - есть базовый класс, меняя который программа должна продолжать работать так, как будто изменений и не было.
Так вот если, допустим, в 1С был бы класс для работы с остатками, то интерфейс к нему в общем-то и не нужен был бы - документ был бы поставщиком данных, а при проведении базовый класс сам бы производил нужные движения по регистру остатков. Класс можно было бы расширить сериями - добавить к нему еще один механизм движений - по сериям. Потом по характеристикам, если бы нам понадобились характеристики. Ну и т.д. Второй класс, от которого наследовалась бы логика движений, может отвечать за взаиморасчеты, третий - за партии, четвертый за что-то еще (тот же РАУЗ). На выходе собранный объект.
Да, сейчас фактически обработка проведения так и собирается - тащатся запросы из подсистем оперативного или бухгалтерского учета, собирается итоговая таблица движений по всем используемым регистрам, потом результаты запросов накатываются на регистры. Но, честно, на сколько просто будет добавить разрез какой-то ко всем документам при таком подходе? Нужно будет или найти этот запрос и добавить в него разрез, найти все запросы с этим регистром, переписать гору кода, потом огрести проблемы с обновлением, т.к. придется всю эту гору измененного кода поддерживать. А если бы изменения касались только базового класса, то проблем бы вообще не было ни с расширением, ни с поддержкой обновлений.
В общем, у ООП есть свои плюсы, которые кажутся неочевидными с первого взгляда, но они действительно есть. И всегда можно написать программу без ООП. Но, повторюсь, суть ООП в том, чтобы код мог быть переиспользован максимальное количество раз, и при этом стабильность системы не была бы нарушена.
(9) мне кажется за деревьями потеряли лес. Что мешает на 1с сделать ЕРП менее монолитной? Т.е. создавать классы - это не цель сама по себе. Возможность писать короче, лаконичнее и только то, что нужно. А не то чтобы в пустой базе иметь сразу набор классов для всех типов регистров. Может мне половина и не нужна, но они есть. И чем больше система, тем больше этого мусора приходится тащить. Плюс возможности оптимизации архитектуры также упираются в невозможность управлять классами полноценно.
(15)
это отлично, по мне до поры до времени тоже было комфортно, но потом наступил такой момент что хочется чего то большего, интересного. из последних работ что делал, это были различные интеграции, потому что там есть некая свобода, не знаю как описать, в общем не хотелось уже создавать очередной справочник, форму к нему и т.д. ушел в интеграции и там мне было более менее нормально, но на одних интеграциях далеко не уйдешь и 1с уже мои аппетиты не вывозила. Каждому свое. Если ты занят любимым делом, то какая разница на чем пишешь, 1с, java,kotlin, python, C.
это отлично, по мне до поры до времени тоже было комфортно, но потом наступил такой момент что хочется чего то большего, интересного. из последних работ что делал, это были различные интеграции, потому что там есть некая свобода, не знаю как описать, в общем не хотелось уже создавать очередной справочник, форму к нему и т.д. ушел в интеграции и там мне было более менее нормально, но на одних интеграциях далеко не уйдешь и 1с уже мои аппетиты не вывозила. Каждому свое. Если ты занят любимым делом, то какая разница на чем пишешь, 1с, java,kotlin, python, C.
(1)
В остальном полностью поддерживаю. Всем говорю, что если в 1С у тебя порог 150к, например, то в в Java, андройде, обджектив си, питоне и т.д. у тебя потолок куда выше - раза в два примерно.
Ну и вообще разработка на языке с декораторами, замыканиями, объектами-классами и т.д. - это куда интереснее, чем пытаться сломать систему на 1С (хотя, если честно, некое подобие всех этих структур на 1С тоже делается, но очень непростыми методами).
По зарплате: она упала на треть что для меня очень критично, но всякие шабашки по 1с помогали мне оставаться на плаву.
Очень фигово, что при падении ЗП на треть это становится критичным.
В остальном полностью поддерживаю. Всем говорю, что если в 1С у тебя порог 150к, например, то в в Java, андройде, обджектив си, питоне и т.д. у тебя потолок куда выше - раза в два примерно.
Ну и вообще разработка на языке с декораторами, замыканиями, объектами-классами и т.д. - это куда интереснее, чем пытаться сломать систему на 1С (хотя, если честно, некое подобие всех этих структур на 1С тоже делается, но очень непростыми методами).
(1)
Спасибо)), сам такой же только выбрал iOS, в этом месяце покинул 1с, хоть за плечами 9 лет опыта там.
Пофиг на потерю денег, лишь бы ходить на работу которая тебе по душе)
Но сейчас так счастлив что сделал это как и ты, давно такого не было)
Я очень давно не ходил на работу, на которую действительно хочешь идти а не потому что надо. Каждый день ждешь с нетерпением, чтобы погрузиться во что то новое.
Спасибо)), сам такой же только выбрал iOS, в этом месяце покинул 1с, хоть за плечами 9 лет опыта там.
Пофиг на потерю денег, лишь бы ходить на работу которая тебе по душе)
Но сейчас так счастлив что сделал это как и ты, давно такого не было)
(21)
но встречал не слишком грамотных программистов с сертификатом спеца
Да вот я вообще слишком грамотных специалистов пару раз только встречал. От сертификата это, конечно, зависит в самую последнюю очередь, но чтобы сдать на спеца, как говорят многие, хоть что-то знать надо в мире 1С )))
я не пророк , но предполагаю, что через икс лет ,
да и сейчас
будут востребованы специалисты
по безопасности и защите от взлома и киберг-атак
потому-что за рулем компьютера всегда будет тело мужского или женского пола
которому нужно ограничить как минимум права в системе и объяснить,
что флешку нужно безопасно извлекать
а лучше - не приносить на работу.
да и сейчас
будут востребованы специалисты
по безопасности и защите от взлома и киберг-атак
потому-что за рулем компьютера всегда будет тело мужского или женского пола
которому нужно ограничить как минимум права в системе и объяснить,
что флешку нужно безопасно извлекать
а лучше - не приносить на работу.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот