Развитие 1С программиста

10.12.19

Саморазвитие

Делюсь своим опытом и видением развития 1С программиста.

Поработав как 1С программист лет 10 и имея опыт работы с другими языками (oracle в штате 1.5 года, C# любительски 2 года) заметил, что есть намного больше в мире программирования, что ранее не замечал. В других языках используются понятия «паттерн», «подход ООП», «классы», «наследование» и пр. Для 1С все это неприменимо, но некоторые подходы могут повысить качество разработки и повысить ценность специалиста. Рассмотрим, как устроена градация программистов и зачем она нужна.

 

Для начала попробуем разобраться зачем нужна градация специалистов.

Кажется, без градации жить хорошо, но присмотритесь к развитию бизнеса.

У мелкого бизнеса мало работы, средний и крупный бизнес уже сильно перерабатывает типовые и нанимает в штат программиста 
для дальнейшего развития и поддержки программы. Со временем поддержка их программы требует все большего количества программистов
при этом сохраняя тепы доработок и развития. И принимая нового программиста им нужно понимать чего от него ожидать.
Тут возникает следующий вопрос.

Для выполнения работы нужны специалисты, но как понять сможет ли сотрудник выполнить работу?

Какое качество от него стоит ожидать?

Вот тут и появляется классификация, чтобы понимать, какого спектра задачи может решить разработчик и какой результат работы ожидать.

К примеру, начинающий разработчик, мало знающий систему, не сможет быстро спроектировать и внедрить небольшую систему.

Опытный разработчик, может не внедрить систему, натыкаясь на проблемы со скоростью работы или непониманием конечного результата.

 

Начинающий программист

Как сделать?

Обладает первоначальной технической базой. 

Первое время программист погружается в техническую часть и изучает платформу, ее возможности. 

Выполняет задачи по доработке без анализа последствий в бизнес области.

Компетенции: выполнение технических задач под присмотром более опытных разработчиков.

 

Продвинутый программист

Сейчас сделаем!

Получив уверенные знания позволяющие решать большинство задач, программист начинает осваивать бизнес процессы и типовые конфигурации. 

Выполняет задачи по проектированию бизнес процессов, понимая их связь и последствия для бизнеса.

Компетенции: самостоятельное решение технических задач.

Проблема при решении: последующая доработка выполненных решений, проблемы при масштабировании, техническое решение прийдется переделывать под "пропущенные" пожелания бизнеса.

 

Старший программист

Зачем это нужно? Как это повлияет на другие системы и процессы? Будут ли проблемы у предприятия после разработки?

Научившись писать код и поняв бизнес процессы, наступает время оптимизации кода и программного решения. 

Выполняются задачи прикладного характера с чистым и понятным кодом. 

Появляются свои стандарты написания кода.

Разработчик решает не только технические задачи, но и понимает, как это отразится на бизнесе.

Компетенции: самостоятельное решение бизнес задач (части бизнес процесса) с возможностью последующих доработок.

 

Ведущий программист

Понимаю возможности программы и знаю процессы организации. Могу спланировать функционал который не надо будет переделывать и не поломает работу бизнес процессов.

Как правило, к этому времени работа становится рутинной и ищется что-то новое. 

Разработка новых решений или подсистем с учетом долголетней перспективы развития. 

Приходит понимание необходимости мониторинга системы, тестирования (для уменьшения ошибок при доработках), поиска существующих стандартов разработки.

Происходит поиск возможности улучшения системы - работа с неопределенностью но определенным результатом.

Уже решаются не прикладные задачи, а происходит проектирование работы в системе для решения бизнес задач.

Компетенции: самостоятельное проектирование бизнес процессов и разработка бизнес функционала.

 

Архитектор

Обладает компетенциями по построению систем.

Учитывает различные взаимосвязи между системами повышая отказоустойчивость, скорость взаимодействия между ними.

Занимается развитием архитектуры, шины данных ( например ESB).

 

Руководитель проекта.

Отвечает за реализацию проекта, рассчитывает риски по проекту.

Умеет находить общий язык с заказчиком и программистом.

Описывает требования заказчика в бизнес процессах и передает на работу разработчикам.

Решает конфликтные ситуации в случае их появления. К примеру не соответствие разработанного функционала ожиданиям заказчика.

 

Руководитель отдела

Выстраивает процесс работы отдела повышая эффективность работы.

Отвечает за всех сотрудников отдела и их качество работы.

 

 

Для вертикального роста необходимо не только развивать технические навыки, но так же и ряд других: эмпатию, коммуникабельность, мышление.

Часть этих навыков хорошо описана в статье "Нетехнические навыки для разработчиков. Зачем они нужны? Как развивать?".

 

При развитии в сторону старшего или ведущего программиста необходимо заниматься качеством кода, 

поэтому хочется выделить два фактора, которые пока опускает сообщество 1С: это качество кода и тестирование написанного кода (бизнес процесса).

Плохой код - тяжелее поддержка - со временем переписывание когда достанет (если помножить на все задачи то переписывание всей конфы или подсистемы) - появление новых багов при добавлении нового функционала.

Отсутствие тестов - быстрое обновление - возможные ошибки в других местах кода - потеря выручки при плохом варианте (потеря времени при хорошем) и возможный второй виток.

Зачем хороший код при разработке конфигураций:

- легче читать и понимать (на разбор кода уходит значительно меньше времени, значит его больше остается для выполнения задачи)

- при доработке кода не приходится его переписывать (при плохом коде бывает копирование механизмов и исправление в одной копии необходимо делать во всех остальных)

- количество ошибок при доработке уменьшается (к примеру не использование повторного кода)

- Фирма 1С разработала стандарты позволяющие им разрабатывать и поддерживать их конфигурации (https://its.1c.ru/db/v8std)

 

Поскольку объем материала большой, по росту от начинающего до ведущего, сделан отдельный онлайн курс.
 

 

Приведу пару примеров:

При падении в случае обработки XDTO пакета мы получим запись в ЖР "В этой транзакции уже происходили ошибки"

Процедура РегламентнаяОбработка() Экспорт
	
	....
	
	Попытка
		Док.Провести();
		ОбработатьXDTOПакет(Пакет);
	Исключение
		ЗаписьЖурналаРегистрации("РегламентнаяОбработка", УровеньЖурналаРегистрации.Ошибка,,, КраткоеПредставлениеОшибки());
	КонецПопытки;
	
КонецПроцедуры


Процедура ОбработатьXDTOПакет(Пакет)
	
	Попытка
		Пакет.Значени = "Тест";
	Исключение
		ВызватьИсключение КраткоеПредставлениеОшибки();
	КонецПопытки;
	
КонецПроцедуры

В этом случае при падении будет описана сама ошибка.

Процедура РегламентнаяОбработка() Экспорт
	
	....
	
	Попытка
		Док.Провести();
		ОбработатьXDTOПакет(Пакет);
	Исключение
		ТекстОшибки = КраткоеПредставлениеОшибки();
		ЗаписьЖурналаРегистрации("РегламентнаяОбработка", УровеньЖурналаРегистрации.Ошибка,,, ТекстОшибки);
	КонецПопытки;
	
КонецПроцедуры


Процедура ОбработатьXDTOПакет(Пакет)
	
	Пакет.Значение = "Тест";
	
КонецПроцедуры

Много параметров, которые легко перепутать при вызове

Процедура РасчетЛиквидностиТовара(Товар, Склад, Организация, ХарактиристикаТовара, ВесРасчета, АналитикаДляРасчета) Экспорт
	
	....
	
КонецПроцедуры

При передаче структурой передать неверный параметр тяжелее

Процедура РасчетЛиквидностиТовара(ПараметрыСтруктурой) Экспорт
	
	Товар 		= ПараметрыСтруктурой.Товар;
	Склад 		= ПараметрыСтруктурой.Склад;
	Организация = ПараметрыСтруктурой.Организация;
	ВесРасчета  = ПараметрыСтруктурой.ВесРасчета;
	ХарактиристикаТовара = ПараметрыСтруктурой.ХарактиристикаТовара;
    АналитикаДляРасчета  = ПараметрыСтруктурой.АналитикаДляРасчета;
	
КонецПроцедуры

 

Надеюсь, эта публикация поможет понять что нужно для развития и достижения больших успехов.

 

А Вы задумываетесь о горизонтальном росте?

Работаете над ним?

Интересно ли более детальное описание знаний и навыков необходимых для роста программисту?

 

 

См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

вчера в 09:10    163    0    Radio_Analyst    0    

3

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    325    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    334    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    475    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

Никакой продажник не продаст ВАШ продукт лучше ВАС. Но презентация продукта – это не только наука, но и искусство. О том, как сделать выступление запоминающимся, насколько важны базовые ораторские навыки, сторителлинг и инструментарий для наглядного погружения в детали, расскажем в статье.

12.02.2024    913    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

Персональный личный бренд повышает вашу стоимость на рынке труда – чем больше потенциальные работодатели знают о ваших достижениях, тем больше они готовы вам платить. Но что делать на старте, когда вы решили прокачать своё имя в отрасли? Какие инструменты и подходы для этого необходимо использовать? О том, как прокачать свой бренд, принося пользу компании, пойдет речь в статье.

01.02.2024    827    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2772    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1648    0    KChebykina    0    

31
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mrm1212 34 17.10.18 10:18 Сейчас в теме
Статья хорошая, призывает разработчиков к оптимизации и качеству разработки, но видео зря обрезали.....на самом интересном месте! =)
2. Art1387 4 17.10.18 10:20 Сейчас в теме
Иногда приходится выбирать скорость или качество. Когда в отделе кроме тебя два "быдлокодера", которым важна только скорость и быстрей отчитаться о сделанной задаче, качество будет расценено как "нежелание работать". поэтому получается сделать быстро и качественно - делаем, если нет - "быдлокодим".
cosmo2004; smit1c; RomanKod; Kinestetik; Albert_2008; Aggressorak; LisaAVR; SagittariusA; Waanneek; Larkan; serega22; +11 1 Ответить
7. dsdred 3225 17.10.18 12:37 Сейчас в теме
(2)А зачем работать в такой конторе? Сейчас на рынке дефицит 1с-ников, ищите то что по душе.
cloudspb; Kinestetik; Gang031; int18h; +4 Ответить
8. Art1387 4 17.10.18 14:03 Сейчас в теме
(7)Возьму ипотеку - поищу работу. З/п вроде в Уфе поднялись выше получаемой сейчас.
9. dsdred 3225 17.10.18 14:08 Сейчас в теме
(8)Не только в Уфе. В том году то, что считалось средней ЗП, сейчас минималка...
15. MegasXXX 2 18.10.18 12:04 Сейчас в теме
(2)
От системы зависит, если система более менее нагруженная то быдло код очень быстро вылазит наружу.
У вас же есть руководство? Если руководство устраивает былокод, то нафиг такое руководство?
3. CSiER 35 17.10.18 10:23 Сейчас в теме
А Вы задумываетесь о качестве кода? Стараетесь его повышать?
-
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте
(источник)
Приведённый источник - классика данного вопроса - помогает смотреть на код "под правильным углом", рекомендую.
4. awk 741 17.10.18 10:26 Сейчас в теме
1. Не ТЖ, а ЖР.
2. Во втором примере желательно функцию получающую параметры, что бы опечаток не делать: "ВесРаАсчета " - я вряд ли правильно напишу.
3.
опыт работы с другими языками (oracle в штате 1.5 года
??? :)
5. a_a_burlakov 284 17.10.18 10:49 Сейчас в теме
Тема хорошая, а статья нечитаемая. Логика дёрганая, заголовки подчиненные и главные выглядят одинаково, на знания препинания - вообще пофиг. Даже в коде опечатки/описки/пофигизм.

Видел комментарии под статьями из 2000-2010, которые темы свои раскрывали шире, грамотнее и красивее. А тут статья. Не круто как-то.
smit1c; kuzyara; CSiER; int18h; CyberCerber; dsdred; zeegin; acanta; +8 Ответить
12. pashamak 265 17.10.18 16:30 Сейчас в теме
(5)Часть замечаний исправил, по остальным напишите в личку подробнее. Возможно это поможет более понятные статьи писать.
dvsidelnikov; +1 Ответить
6. dsdred 3225 17.10.18 12:35 Сейчас в теме
По заголовку статьи ждал чего то большего...

Такое ощущение, что это черновик, причем еще только начало черновой работы...
Cерый; A_Max; SagittariusA; for-elenak; Yakud3a; awk; Jeka44; CyberCerber; +8 Ответить
10. starik-2005 3031 17.10.18 14:34 Сейчас в теме
Статья больше похожа на рекламу полной версии ролика (предположу, он может быть где-то доступен не бесплатно).

Рацио в статье есть: качество кода, тесты, движение вперед и вверх. Правда тема при этом не раскрыта совершенно.

Вот что такое "качество кода"? Если Макконнелла читать, то качественный код - это такой, который и использует оптимизации, и структурирован хорошо, и ревью по которому удобно производить, и, понятное дело, откомментирован прилично, отформатирован хорошо, переменные лишние не использует и структуры данных в тему. И если ведущий разработчик пишет код сложного механизма, то не каждый юный падаван (и не юный, кстати) сможет этот код поддерживать, если требования к функциональности, реализующиеся высоким уровнем абстракции и сложными оптимизационными алгоритмами, соблюдены. В итоге код удовлетворяет критериям производительности и использования памяти, а понятен сотне человек в мире, как операторная алгебра.
Kinestetik; Aggressorak; LisaAVR; SirAlexIT; nbeliaev; Yakud3a; FreeArcher; _LkMaksimka_; +8 Ответить
11. pashamak 265 17.10.18 16:26 Сейчас в теме
(10)Эта статья призвана обратить внимание на качество кода. Вижу что интерес к этой теме есть. Вероятно расширю статью или более подробную новую сделаю как будет время. По поводу рекламы это заблуждение. Увидел ролик помогающий донести мою мысль и воспользовался им.
_LkMaksimka_; +1 Ответить
13. Automatik 913 18.10.18 06:56 Сейчас в теме
Про развитие где? Как развиваться? Куда? Что для этого делать? Сколько времени выделить в день?
14. Vovan1975 13 18.10.18 11:43 Сейчас в теме
автор страдает детскими болезнями "оопие головного мозга" и "паттерние головного мозга"
16. kuzyara 1896 18.10.18 13:07 Сейчас в теме
Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.

Когда быть хорошим плохо (с) habr
1Sacha; st4rk; Kinestetik; birkoff; aparinp; SirAlexIT; CSiER; starik-2005; acanta; +9 1 Ответить
17. Synoecium 777 19.10.18 07:09 Сейчас в теме
(16) слишком примитивная точка зрения, программирование всё же сильно отличается от создания горшков из глины. Вообще это давнишний спор, является ли программирование ремеслом или искусством. На мой взгляд программирование, ремесло и искусство это 3 разные вещи, и некоторая схожесть одного с другим не превращает это одно в другое.
19. starik-2005 3031 19.10.18 10:18 Сейчас в теме
(17) любая деятельность может стать искусством, если делать это с душей. Можно в макдачнице с душей делать гамбургеры - и это будет искусством, а можно кодить без души - и это будет халтурой.
san4o; user1486915; Jestery; Aggressorak; SirAlexIT; 3762515; kuzyara; +7 Ответить
24. gaglo 24.10.18 10:23 Сейчас в теме
(17) Ну не смог удержаться. Заказываю "такую же" статью на тему "Чем же программирование отличается от создания горшков из глины"! И чтоб так же обоснованно был изложен предмет!
Если серьезно, то применение аналогий к предмету спора не может / не должно быть объявлено проявлением примитивной точки зрения. Оно должно помочь в осмыслении аргументов и достижении истины или правды. И не более. А если
программирование, ремесло и искусство это 3 разные вещи

так можно подискутировать и о том, что программирование - это (не) практическая религиозная деятельность, в рамках культа, скажем 1С, или С++, или С#, или общего культа ООП, который подразделился на разные секты; тут уже говорилось о болезни "ООПие", а можно вместо этого обсудить культ ООПизма и т.д.
18. azhilichev 213 19.10.18 07:31 Сейчас в теме
(16) К сожалению, есть еще третья группа. Она просто херачит код и ничему не учится.
42. AlexO 135 19.05.19 17:00 Сейчас в теме
(16) это где так можно - написать 100 раз одно и то же в коде, и в результате получить лучший код, чем тот, который предварительно продуман?
Вы и автор статьи рассуждаете весьма поверхностно, и 10 лет программирования в 1С - ничему не научили. И для 1С это не удивительно.
46. pashamak 265 20.05.19 04:13 Сейчас в теме
(42) Т.е. копирование кода (в том числе с небольшими доработками) это для вас норма? Подскажите, на каком языке работаете и какой у вас стаж?
47. acanta 20.05.19 05:16 Сейчас в теме
(46) в 1с предприятии в списке документов или справочников есть возможность копирования. Даже если программист сделает запоминание последнего состояния объекта и заполнение всех реквизитов в новом объекте из сохранённых, пользователь всегда предпочитают найти какой-то похожий или просто как нибудь заполненный чем угодно, скопировать его и изменить на то что требуется.
Копировать можно абсолютно любой код, вообще никак не связанный.
20. vasvl123 118 19.10.18 10:58 Сейчас в теме
Развитие идет пока учишь новый язык. А дальше - совершенствование.
21. pashamak 265 22.10.18 03:27 Сейчас в теме
(20) Помимо изучения языка есть смежные области помогающие эффективнее работать. Если заказчик хочет функционал но ты понимаешь что он не решит его проблему надо это ему объяснить. Для этого нужно уметь доносить мысль, вести переговоры. При решении задач оптимизации приходит понимание как можно быстрее и лучше писать код. Все это на мой взгляд развитие.
22. vasvl123 118 22.10.18 08:17 Сейчас в теме
(21) Да, ограниченное определенными рамками
23. mkalimulin 1135 22.10.18 09:16 Сейчас в теме
Повышайте качество кода и станете ИТ-директором.
talych; acanta; +2 Ответить
25. Господин ПЖ 24.10.18 10:36 Сейчас в теме
Статья "ниочем". Компетенции IT-директора с 1С-ником не пересекаются практически. Тем более если в организации 1С не является "светом в окошке" и есть отдельные службы системного администрирования, саппорт и разработка ПО внутреннего использования ведется не только на 1С - сайты, личные кабинеты, системы учета online с большим количеством транзакций. 1С-ник как правило слабо понимает структуру IT-среды компании за рамками своих задач и серверов приложений, далек от задач подразделений с которыми не работает непосредственно
user1395339; +1 Ответить
27. pashamak 265 25.10.18 05:36 Сейчас в теме
(25) Верно, но речь шла о горизонтальном росте. Поднимаясь выше меняешь мышление. На уровне ИТ директора уже мыслишь процессами и выстраиваешь схему работу.
29. Господин ПЖ 25.10.18 10:05 Сейчас в теме
(27)
Поднимаясь выше меняешь мышление.


Насколько мне понятна психология бизнеса - они предпочитают черпать управленцев из админов или саппорта.

(27)
На уровне ИТ директора


как вы туда попадете? места уже заняты как правила. в случае "я устал я ухожу" текущего директора и "больше никого вокруг"? в крупных конторах такого не бывает. есть замы. и они как правило не 1с-ники
26. 3762515 24.10.18 15:53 Сейчас в теме
Очень слабенькая и весьма спорная статья. Очень большой акцент делается на некий "качественный код", но кому он нужен то? В текущей парадигме оплаты труда программиста 1С, быдлокодить гораздо эффективней - больше денег/иных плюшек. С почасовой оплатой, думаю и так понятно - чем больше овна намесишь - тем больше заработаешь. На фикси чуть иначе - чем больше задач и проектов выполнишь - тем больший респект и уважуха от руководства. Ни там, ни там качество кода в оценку труда не ставят.
veiuper; pm74; +2 1 Ответить
28. pashamak 265 25.10.18 05:41 Сейчас в теме
(26) При большом продукте и плохом коде его невозможно становится поддерживать. Реализация нового функционала приводит к появлению новых ошибок и отказе в работе части текущего функционала. Возникают простои во время которых организация теряет деньги. Для решения этой проблемы и появилось качество кода. Статью планирую дорабатывать освещая больше спорных и непонятных моментов.
30. Господин ПЖ 25.10.18 10:07 Сейчас в теме
(28)
При большом продукте и плохом коде его невозможно становится поддерживать. Реализация нового функционала приводит к появлению новых ошибок и отказе в работе части текущего функционала. Возникают простои во время которых организация теряет деньги.


неизбежное состояние любой крупной конфигурации 1с.
31. Господин ПЖ 25.10.18 10:19 Сейчас в теме
(28)
Для решения этой проблемы и появилось качество кода.


качество кода за пределами отдела никого как таковое не интересует. да и в отделе это как один из "маркеров" для оценки, не более того

но опять же - если для качество кода надо удлинить время разработки в разы, обвешаться разным инструментарием - причем "не типичным" для среды + сама среда устарела и крайне лояльна к ошибкам (львиная доля их вообще проявляется только в реал-тайме) - погоня за качеством = катание камня в гору
34. pashamak 265 26.10.18 06:17 Сейчас в теме
(31)
За пределами отдела интересует качество программы и стабильность работы. А это зависит от качества кода. Качество кода определяет его поддержку, возможность доработки с наименьшим количество ошибок.

Инструментом для поиска и выявления ошибок является тестирование.

По поводу "львиная доля их вообще проявляется только в реал-тайме" - без качественных тестов так и происходит. При разработке через тестирование львиная доля ошибок выявляется во время тестирования после окончания разработки. Это затратно, поэтому используется не везде, а там, где риски простоя стоят значительно дороже работы разработчика.
43. AlexO 135 19.05.19 17:04 Сейчас в теме
(34)
По поводу "львиная доля их вообще проявляется только в реал-тайме" - без качественных тестов так и происходит.
так вы всю работу сделаете за каждого буха, причем - именно имитируя его голову и руки? Ну тогда понятно, что мифическое "качество кода" в 1С - для Вас реальное понятие.
33. 3762515 25.10.18 11:37 Сейчас в теме
(28) Так опять же у кого эти проблемы для решения которых нужен "качественный код"? У тех кто работает в самой 1С и клепает типовые и разработчиков продуктов "1С Совместимо" и то не всем. Таких 1Сников крайнее меньшинство. В основном все программисты 1С во франчах внедряют типовые и быдлокодят дабы часов по больше "продать". И фикси - работают на окладе, где работодатель требует "СделатьФсёЕщёВчера".
Называть статью "Развитие 1С программиста" и опираться в ней на проблемы крайне узкого сегмента как то странно.
35. pashamak 265 26.10.18 06:20 Сейчас в теме
(33) Согласен, статью следует еще доработать, но этапы развития есть и кратко описаны. Проблемы, на которые обращаю внимание в конце статьи - лишь детализация небольшой части развития.
32. acanta 25.10.18 10:25 Сейчас в теме
Качество кода - это отношения между сотрудниками внутри отдела, их взаимозаменяемость и возможность подключения сторонних разработчиков.
Daynestro07; pashamak; +2 Ответить
44. AlexO 135 19.05.19 17:07 Сейчас в теме
(32) тогда в этом критерии - качество кода современных типовых УФ = 0.
Ну ладно, 0,001. Тут и взаимозаменяемость, и подключение "к доработке", и сопровождение кода, да и просто - разобраться в логике работы.
45. acanta 19.05.19 17:59 Сейчас в теме
(44) Имхо, об УФ изначально обсуждалось как терминальный режим (rdp, Citrix).Во всяком случае если Генри Форд утверждал, что от него клиенты ожидали более быстрых лошадей, то от 1с ожидали изображения серверного экрана, транслируемого платформой на клиента средствами тонкого клиента 1с.
То, что управляемые формы упростили разработку форм и их связи с правами и функциональными опциями это несомненно большой шаг вперёд.
Вообще ожидания редко совпадают с реальностью, как и желания с возможностями. Но это же бизнес, а не бракоразводный процесс..
36. JohnGalt 57 26.10.18 17:08 Сейчас в теме
Даже не говоря про более тесную связь 1с с другими программами/продуктами/решениями и более глубокое знание какой либо области/отрасли, для 1с программиста очень много направлений, куда можно развиваться. Например:

1. Создание, наполнение, настройка форм/макетов
2. Формирование бизнес-процессов, задач.
3. Отчеты: написание запросов, оформление вывода данных, СКД
4. Права, доступ, роли и ограничения.
5. Обмены: работа с внешними источниками данных (таблицы, базы данных, web SOAP, REST HTTP-методы, обмен данными в форматах XML и json), настройка правил конвертации, автообмен, сложные структуры обмена
6. НСИ: разработка механизмов и интерфейсов работы.
7. ЭДО: обмен заказами, платежками, расходными и налоговыми с разными системами
8. Администрирование: регламентные операции (резервирование, очистка и оптимизация БД, оптимизация работы пользователей)
9. Бух. учет: план счетов, проводки, регламентированная отчетность, ОС, НМА, производство, налоги
10. Упр. учет и международная отчетность: P&L, Cashflow, EBIT, IFRS, GAAP, трансляция и трансформация проводок, расчет себестоимости продукции.
11. Торговля: работа с торговым оборудованием (фискальные регистраторы, принтеры чеков, сканеры штрихкодов, ТСД, весы, платежные терминалы), программа лояльности (акции, бонусы, скидки, анкеты, сегменты покупателей), ценообразование, печать чеков.
12. Кадровый учет: начисление зп, отпусков, больничных, графики работы, увольнения.
13. Склад: адресное хранение, маркировка, штрихкоды, остатки, запасы, планирование.
14. Производство: планирование, бюджетирование, заказы на производство, затраты на производство (материалы, услуги), выпуск продукции (отчеты производства за смену), расчет себестоимости, полуфабрикаты, встречный выпуск, учет брака, давальческая схема производства, амортизация ОС.
37. acanta 26.10.18 17:19 Сейчас в теме
(36) это в порядке приоритета? По встречаемости и востребованности задач, или по уровню потенциальных зарплат?
38. JohnGalt 57 26.10.18 17:32 Сейчас в теме
(37) Это список направлений. Все важны. Некоторые важнее из-за сложности, некоторые важнее из-за потребности. Некоторые просто нужные на протяжении большого периода времени, некоторые будут нужнее в будущем и т.д
39. acanta 26.10.18 17:38 Сейчас в теме
Дорог нет, есть направления.
40. acanta 26.10.18 19:29 Сейчас в теме
Это хороший вариант для собеседования, своего рода анкета работодателя. Соискатель на должность программиста 1с должен интересоваться не количеством рабочих мест, баз и конфигураций, а какие из этих направлений актуальны для работодателя.
41. riposte 382 13.05.19 02:11 Сейчас в теме
Зачем хороший код при разработке конфигураций:

- легче читать и понимать

Старайтесь жить по заветам:
- Хороший код пишется один раз, а читается много раз.
- Мы рады, что у тебя динамическая типизация. Но не поленись или обозвать свою переменную так, чтобы было ясно, какой в ней тип, или хотя бы функцию ее инициализации очевидной сделай.
Не
Перем1 = ПолучитьПерем1(Выборка);

А хотя бы
Перем1 = ПолучитьСтруктуруПоДаннымВыборки(Выборка);

А еще лучше
СтруктураВыборки = ПолучитьСтруктуруПоДаннымВыборки(Выборка);

- Придерживайся своей логики. Если ты решил однажды, что все хуки формы ты будешь обрамлять в контейнер #Область События_формы - не соскакивай с этого. Ты не поверишь, насколько проще кому-то будет перемещаться по твоему коду, когда этот кто-то увидит, что у тебя есть свой паттерн.
- Это делают многие, но все же: сделал заплатку - обозначь ее
// +++Вася 13.05.2019
// Нашли косяк [Описание косяка]. Исправление.
// [Закоментированный старый кусок кода]
Новый код;
// ---Вася


А Вы задумываетесь о горизонтальном росте?

Я задумываюсь о сортах CI/CD в связке 1С и внешних систем.
Функционал платформы уже вышел далеко за "база для учета кисточек".
48. acanta 20.05.19 06:14 Сейчас в теме
У программистов обычная практика похожа, найти чужой код, обосновать почему он не подходит, стереть значительную часть и дополнить своим. Разница только в объеме чужого кода, необходимого для начала работы и объеме уничтожаемого или комментируемого кода прежде чем программист включит мозги и начнет что то делать сам.
С опытом программист больше использует старые собственные наработки для старта, это что то связанное с чувством защищённости. В коде сначала нужно освоиться, найти себя, свой путь.
49. pashamak 265 20.05.19 08:55 Сейчас в теме
(48) При таком подходе весь типовой механизм переписывает каждый разработчик. Но есть разработчики разбирающиеся как работает код, и вместо создания своего велосипеда дорабатывают существующий типовой код. С опытом этот процесс происходит быстрее и легче.
50. kalashae 27.05.19 08:21 Сейчас в теме
Для начинающих программистов есть очень хорошая книга по качеству кода. Выше её упоминали, но мимоходом. Дам полноценную ссылку:

https://www.chitai-gorod.ru/catalog/book/275242/

После прочтения начинаешь другими глазами смотреть на то, как ты сам раньше работал, и на работу твоих коллег. Книга очень хорошая.

51. Tavalik 3347 05.07.19 09:42 Сейчас в теме
Как то у вас все профессии в одну слились, и все в качестве ступеней роста разработчика 1С.

Мой опыт говорит мне, что Разработчик 1С, Аналитик 1С (Консультант) и Руководитель проекта - это абсолютно разные профессии. И внутри каждой из них есть точно также стадии развития и направления роста.

Да, в некоторых случаях возможны перемещения между этими видами деятельности, но мешать все в одном я бы не стал.
52. starik-2005 3031 05.07.19 14:14 Сейчас в теме
(51) я вот думаю, что профессия - это так. наносное. Важно именно развитие личности, а не профессиональных качеств. И уже от нее - личности - должна как-то профессиональная деятельность зависеть, а не наоборот. Т.е. сначала я, а уже потом клиенты, продукты, ...
56. pashamak 265 23.07.19 08:54 Сейчас в теме
(52) Хорошее мнение. Для работы личность не менее важна, но после выбора профессии без развитых профессиональных качеств мало чего получится.
58. starik-2005 3031 23.07.19 13:35 Сейчас в теме
(56) более того, т.к. производительность труда помимо квалификации зависит от процессов и мотивации, всегда найдутся две организации, в одной из которых прокачанные профессионалы в хаосе будут творить менее эффективно, чем студенты в четком процессе второй.

Вот личность - это то, что может организовать процесс, и вот тогда уже стоит поработать и над квалификацией. А если нет личностных качеств, но есть профессиональные, то такого аутиста можно легко воткнуть в процесс где-нить в SAP'е, но никак не в желтых франчах...
59. pashamak 265 23.07.19 19:12 Сейчас в теме
(58) Согласен, разные организации работают по разному. Но студент во франче при плохом качестве работы не будет востребован равно как и в других местах.
60. starik-2005 3031 24.07.19 10:04 Сейчас в теме
(59) все зависит от работы. Студент вряд ли осилит целиком комплекс мер по реализации валютного учета, например, но если разбить на подзадачи типа создать справочник валют, добавить реквизит в документы, сделать функцию пересчета и т.д., то тут и студент справится.
61. pashamak 265 24.07.19 15:31 Сейчас в теме
(60) Опускаете качество технического решения. Код он тоже будет писать. За студентом потом прийдется переделывать чтобы была возможность дальнейшей поддержки. Разбивать задачу на множество мелких простых, это если есть отдельно в штате аналитик, но он редко где встречается. Зачастую его работу выполняет сам разработчик.
62. starik-2005 3031 24.07.19 17:16 Сейчас в теме
(61) с учетом того, что аналитик стоит обычно дешевле разработчика, а разработчик делает работу аналитика, то отсутствие аналитика = увеличение затрат. Странно, что далеко не все это понимают.

Фактически аналитик сам по себе делает работу по анализу за меньшие деньги, чем программист, так он еще и снижает требования к программисту - бьет ему комплексные задачи на элементарные. Сплошная выгода.
55. pashamak 265 23.07.19 08:52 Сейчас в теме
(51) Виталий, у Вас замечательная компания. В ней несколько иная от других иерархия, но подобное разделение мне встречалось редко. В основном роль аналитика берет на себя разработчик. Руководитель проекта тоже не всегда есть. А если есть то он проводит выявление потребностей, ставит задачу. Он предполагает что решение этой задачи не сломает другой функционал (а для этого надо знать процессы порою).
Скажите, при постановке задачи кто отвечает за нештатное поведение взаимосвязанного функционала?
При постановке задачи всегда понятна взаимосвязь с другими процессами?
Например выполняется доработка по отправке почты. Доработка выполнена и решает поставленную задачу. Но, после ее выполнения часть писем перестает отправляться, связано это с дополнительным регламентным заданием специфика которого не была учтена? Эту проблему должен был увидеть разработчик или руководитель проекта?
53. nytlenc 23.07.19 04:34 Сейчас в теме
Всю эту большую статью в которой налито столько воды можно было заменить всего одной простой ссылкой
https://its.1c.ru/db/v8std
54. pashamak 265 23.07.19 08:39 Сейчас в теме
(53) Качество кода важно, но одного этого недостаточно.
Разработчик умеющий качественно писать код и не думающий о том как этот код будет работать будет малоэффективен и дальше мелких доработок не уйдет.
57. nytlenc 23.07.19 09:49 Сейчас в теме
(54) вы меня наверное не правильно поняли, вы в статье рассказываете про то как растет программист и т.д. А в конце резко приводите какие-то не совсем готовые и не совсем подходящие для завершения статьи примеры кода, которые по своей сути намного более глубоко и более грамотно описаны в стандартах и методиках разработки 1С. Мне кажется вместо кода стоит порекомендовать прочесть каждому программисту (от начинающего до архитектора) непосредственно сами стандарты https://its.1c.ru/db/v8std
И там в стандартах сказано не только про качество кода, а также и про то, что нужно думать как этот код будет работать и будет ли он эффективен, затрагивают тонкости оптимизации и удобства оформления, а также многие и многие полезные вещи.
63. biimmap 1793 14.11.20 11:43 Сейчас в теме
Статья правильная! В ней затронута проблема большинства проектов - быдлокодеры.
Чем меньше таковых будет на проектах, тем проще будет работать архитекторам, Ведущим программистам.

Единственное с чем я не согласен. так это с тем, что оптимальный код возникает только на уровне Старшего программиста. Грамотный код должен возникать сразу! Разница между начинающим и ведущим программистом должна быть в скорости работы. Но никак не в качестве!

Поэтому изучение стандартов разработки - это то с чего необходимо начинать самообразование. Как писать оптимальный код - это также надо изучать сразу.

Для тех, кто вечно сомневается, зачем писать грамотный код - у Вас надеюсь не возникает вопросов зачем писать письма без орфографических ошибок? Есть понимание зачем писать оловянный, стеклянный, деревянный с 2-мя буквами Н? потому что это ПРАВИЛА!

Язык программирования 1С тоже имеет правила. Так почему грамотная речь, грамотная переписка - это важно, а грамотный код - нет?

Может Вы не тем занимаетесь? Смените поле деятельности. По своему опыту могу сказать, что уже задолбался за быдлокодерами всё переделывать. Если человек не способен писать грамотный код, значит он не способен качественно решать задачи. Такой человек обычно упускает до 60% сценариев. Это из 10 летнего опыта работы архитектором.

Поэтому в статью предлагаю добавить изучение стандартов на самый начальный уровень... А статья очень правильная!
64. stavrpl 04.02.21 15:36 Сейчас в теме
статья действительно годная, тему стоит продолжить. Данные проблемы особенно хорошо осознаются теми, кто работает в узкопрофильных коллективах разработчиков над крупными проектами, где кроме разработки по ТЗ у тебя нет задач в принципе. Там сразу понятно, для чего нужен аудит кода, стандарты и т.п.

Если работаешь "волшебником по 1С" у дилера региона по торговле чем-нибудь - разумеется это все не нужно, скорость решения задач на первом месте. Но нет и профессионального роста, людям проще сменить работу, когда система начнет падать от нагрузки. И тогда ищут кого-то из вышеописанных, но часто уже поздно.

Довольно точно описан момент, когда теряешь интерес к собственно процессу разработки в конфигураторе. И прекрасно, это знак, что ты из него вырос и пора идти дальше, в архитекторы или еще куда-то.
Оставьте свое сообщение