Не спеша, эффективно и правильно – путь разработки. Часть 2. Теория

0. 447 22.06.20 12:50 Сейчас в теме
Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. maxdmt 27 22.06.20 18:04 Сейчас в теме
Как-то тревожно. Еще один 1с интелиженс нарисовался? :(
надеюсь будет по теме
2. CheBurator 3456 22.06.20 23:37 Сейчас в теме
Все хорошо. Все правильно.
Кроме одного.
Рассматривается сферический разработчик. в каком-то коммунистическом обществе...
luckma; unknown181538; +2 Ответить
3. a_a_burlakov 23.06.20 07:11 Сейчас в теме
А поясните, пожалуйста, что есть такое "// tasks by workers, round Robin".
8. WildHare 447 23.06.20 13:31 Сейчас в теме
(3) Все просто. Есть массив заданий, допустим, на обработку данных (tasks). Есть массив исполняемых потоков обработки (workers). И есть простейший алгоритм распределения задач между исполнителями, «round Robin».

Его можно представить следующим образом. Управляющий процесс сидит с большим котелком каши, а исполнители сидят вокруг него с мисками, каждому по очереди наливают кашу из половника, и так по кругу, пока каша не закончится. Несложность при этом не оценивается, не учитывается. Ни сложность и трудоемкость обработки конкретной порции данных, ни конкурентность, ни загруженность сервера, на котором живет конкретный исполнитель, ну и так далее. Алгоритм из серии «Еловая табуретка».

Название алгоритма, если не ошибаюсь, произошло от французского делопроизводства, что-то связанное с коллективными исками или письмами.
a_a_burlakov; +1 Ответить
4. muskul 23.06.20 08:35 Сейчас в теме
Интересно, почему разработчиков тиражных продуктов не посылают на стажировку в поля? Два-три месяца сервисным инженером, мальчиком на все руки, на обновлениях и мелких доработках — вернется другим человеком. Level-up на десять уровней с гарантией.

А действительно почему?
5. smit1c 106 23.06.20 09:51 Сейчас в теме
(4) Потому что разработчик не пойдёт работать на ЗП сервисного инженера ))
6. muskul 23.06.20 10:18 Сейчас в теме
(5)Я не про это. а про то что наваял систему заказов в УТ иди теперь набей 1000 строчный документ. с несколькими складами или что то подобное.
9. WildHare 447 23.06.20 13:36 Сейчас в теме
(5) Дело не в зарплате, зарплата остается прежней, высокой. Дело в получении реальной полевой практики и реальной возможности побывать в шкуре пользователя. Раньше для будущих инженеров это называлось «производственная практика», сейчас-то от нее ничего не осталось. Если взять самый простой пример – это как разработчику различных бюрократических бумажных форм посидеть недельку другую третью над их ручным заполнением. Заменяет примерно годичный курс дисциплины «эргономика».
Drivingblind; JohnyDeath; mvxyz; maxx; CheBurator; +5 Ответить
12. smit1c 106 23.06.20 16:13 Сейчас в теме
7. MikhailDr 23.06.20 13:10 Сейчас в теме
В чем же причина такого подхода к разработке со стороны многих и многих, казалось бы, квалифицированных (сертификаты на стене точно есть) разработчиков? Причины обычно самые банальные. У кого-то сложности с абстрактным мышлением, способностью проектировать сложные сущности и особенно их взаимодействие. Кому-то просто лень. А кто-то просто не знает, что можно разрабатывать программный код как-то по-другому.


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

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

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

В челом интересное чтиво. Спасибо за материал.
CheBurator; WildHare; +2 Ответить
10. yarsort 133 23.06.20 15:06 Сейчас в теме
Никогда не понимал таких полотен статейных... И даже не читаю. Мозг можно поламать.
13. leemuar 23.06.20 19:38 Сейчас в теме
(10) спасибо за классику! "Не читал, не осилил, но осуждаю!". Повеселили
Relfirby; botokash; Kolobash95; +3 Ответить
11. pm74 196 23.06.20 15:31 Сейчас в теме
(0) спасибо за материал , читается легко
bulpi; EVKash; WildHare; +3 Ответить
14. mikukrnet 177 23.06.20 23:26 Сейчас в теме
Все искал в тексте (и не нашел) мой любимый антипаттерн - захерачить запрос в цикле без отбора по виртуальным и временным таблицам... Индийский код - безобидная фигня по сравнению с такими трактористами
15. Vortigaunt 84 23.06.20 23:55 Сейчас в теме
Спасибо. Очень занимательно.
А как называется антипаттерн, когда пишут вот такое?
Если Строка(ВидДвижения) = "Приход" Тогда

Очень весело было отлавливать ошибки, возникшие на ровном месте, когда никто ничего не трогал и код не изменял. А всего-лишь обновили платформу, и при установке подтянулись украинские региональные настройки.
bulpi; Kolobash95; mikukrnet; +3 Ответить
16. leemuar 24.06.20 08:25 Сейчас в теме
(15) сравнение со строковым представлением объекта похоже на индусский код. Последний славится такими перлами:

ПеременнаяБулево = ...;
Если СтрДлина(Строка(ПеременнаяБулево)) = 6 Тогда
// ...
17. mylogin2 24.06.20 09:00 Сейчас в теме
Можно поправить "ФлагУпр = Дожь" — видимо "ФлагУпр = Ложь"?
Хотя, с "Дожь" тоже интересно
18. orefkov 2101 25.06.20 18:59 Сейчас в теме
Имхо, используемое в примере "ЗаполнитьЗначенияСвойств" без указания списка свойств - тоже та еще бомба, подложенная под дальнейшее сопровождение, сродни тем, что перечислялись в первой части. Кто-то где-то что-то переименовал - алгоритм будет выполнятся не правильно, но никаких ошибок не возникнет, и неизвестно, сколько времени пройдёт, пока это выяснится.
karpik666; Denis S; +2 Ответить
19. user926954 26.06.20 04:49 Сейчас в теме
Паттерны, антипаттерны ....Забавно, современно, но, ....бесполезно.
Две статьи сводятся к двум словам - "здравый смысл". И что же это?, проповедь к неблагодарной пастве или глас вопиющего в пустыне?
Думающим людям это не интересно, они давно изучили тему на уровень глубже. Не включающим мозги на постоянный режим работы, эссе этого типа не помогут, как мертвому припарки.
Гораздо интереснее тема как подбирать, сортировать, отсеивать разработчиков (переучивать бесполезно), как организовывать и направлять команду, приемы работы с заказчиками, как быстро выстроить партнерские отношения ними. Интересны тенденции развития 1С-экосистемы, схемы аутсорсинга и т.д. То, до чего думающий разработчик дойдет и сам, но затратив время и набив шишек. Сократите нам время, благодаря своему опыту, снизьте наши издержки, и мы будем "очень признательными благодарными читателями" и поставим вашу книжку на вторую полку на видное место.
20. WildHare 447 26.06.20 10:26 Сейчас в теме
(19) Во-первых, категорически не соглашусь с тем, что «переучивать бесполезно», моя практика показывает обратное. Ну и во-вторых – не все сразу, даже небольшая книжка требует времени. Особенно когда речь идет не о разработке, а об управлении разработкой. В планах это есть, но по срокам сказать не готов.
21. bulpi 184 01.07.20 18:26 Сейчас в теме
Отличная статья. Прочитал, не отрываясь.
Есть маленькое замечание.
"Обращение к реквизитам объекта ссылочного типа «через точку». Грубейшее нарушение стандартов разработки."
В своих конфигурациях я постоянно такое делаю. При этом я знаю, почему это плохо. Но ведь код становится проще в несколько раз. А выполняется на 1 миллисекунду дольше (возможно, не обязательно). Так что it depends.
22. WildHare 447 02.07.20 12:14 Сейчас в теме
(21) Тут все дело в паттерне эксплуатации. Для настольной системы или системы с пятью пользователями – действительно не важно. А теперь представим, что обращение через точку выполняется к элементу справочника Товары, у которого есть реквизит типа ХранилищеЗначения (архив с фотографиями), обращение выполняется в одном из наиболее частотных сценариев работы пользователей, конфигурация развернута в режиме сервиса («Облачная» база), и в каждой ноде сервиса обычной рабочей нагрузкой является ~750 конкурентных сеансов. Посчитаем, сколько избыточного тепла в окружающую среду будет выделять одна единственная строчка нашего кода.
Стандарт потому и стандарт, что в нем пытаются учесть не только благоприятные, но и неблагоприятные ситуации. Например, переход проезжей части белой питерской ночью в ясную погоду при полной тишине на красный сигнал светофора является абсолютно безопасным, но не очень понятно, как это записать в ПДД.
forseil; Drivingblind; Zerga; bulpi; +4 Ответить
23. serge_focus 4 13.07.20 21:50 Сейчас в теме
(22) [IS-QUOTE]Например, переход проезжей части белой питерской ночью в ясную погоду при полной тишине на красный сигнал светофора является абсолютно безопасным, но не очень понятно, как это записать в ПДД.[/QВ\

Включить мигающий желтый, отмониторив трафик и погоду.

А стандарт - на то и есть стандарт, чтобы действовать строго.
А в неопределенных ситуациях лучше сразу зафиксировать ограничения к требованиям. Пусть даже на уровне внутренних документов, которые и станут расширением стандарта, позволяющими переводить светофор в состояние мигающего желтым.
WildHare; +1 Ответить
Оставьте свое сообщение
Вопросы с вознаграждением
Вакансии
Программист 1С
Екатеринбург
зарплата до 130 000 руб.
Полный день

Программист 1С
Новосибирск
зарплата от 150 000 руб.
Полный день

Программист 1С
Казань
зарплата от 100 000 руб.
Полный день

Архитектор 1С
Пермь
зарплата до 200 000 руб.
Полный день

Бизнес-аналитик 1С
Санкт-Петербург
зарплата от 120 000 руб. до 150 000 руб.
Полный день