1
Вы пишете код для человека, не для программы или компьютера. Делайте код понятным, чтобы человек, который будет разбираться в нём через полгода или год или два, мог легко это сделать. Возможно, этим человеком будете Вы, только через год Вы уже не вспомните, что там где подразумевалось "по умолчанию"
2
Помните, что телепатов нет. Ещё раз. Телепатов нет. Код, а равно и интерфейс пользователя, должны быть понятными и не должны содержать умолчаний, понятных только Вам.
3
Названия переменных "Пер1", "А", "Сп" допустимы только в студенческих работах, отладочных обработках или крайне простых процедурах, но не в промышленных решениях. Название переменной должно отражать её содержимое, в крайнем случае нужно оставлять комментарий при её инициализации.
4
Процедуры и функции должны быть как пуля — небольшими и быстропонимаемыми. Вернее, процедуры и функции могут быть большими, а иногда и очень большими, но только в том случае, если они остаются безопасными (пункт 5), то есть название процедуры отражает суть её действия, не больше и не меньше.
// добавление подписантов в файл PDF (последней страницей) из таблицы подписантов в 1С,
// а также добавление нумерации страниц
Процедура ПолучитьФайлСНумерациейИПодписями(НакопленныеДанные)
ОпределитьВозможностьСклейкиСПодписями(НакопленныеДанные);
Если НакопленныеДанные.МожноСклеить = Истина Тогда
ПолучитьИзначальныйФайл(НакопленныеДанные);
ПодготовитьСредствоРаботыСPDF(НакопленныеДанные);
СгенерироватьФайлСлужебнойИнформации(НакопленныеДанные);
ПолучитьИнтересующиеДанныеИзФайлаСлужебнойИнформации(НакопленныеДанные);
СоздатьPDFСНумерацией(НакопленныеДанные);
СоздатьPDFСПодписями(НакопленныеДанные);
СклеитьФайлы(НакопленныеДанные);
УдалитьВременныеФайлы(НакопленныеДанные);
КонецЕсли;
КонецПроцедуры
5
Процедуры и функции должны быть безопасными, то есть — а) их название должно отражать суть б) они не должны делать то, что от них не ожидается исходя из названия
6
Если Вы не можете описать простыми словами, как работает Ваш алгоритм, значит, Вы неправильно выполнили задачу, или недостаточно хорошо умеете повышать уровни абстракции.
6А
Если Ваше решение сложное и запутанное, значит, количество уровней абстракции, которое Вы использовали, является недостаточным.
6Б
Хорошее сложное решение отличается от плохого сложного решения количеством уровней абстракции.
6В
Единственный способ создать что-то сложное хорошо — увеличивать уровни абстракции. Когда Вы смотрите на руку — Вы думаете о руке, а не о миллиардах клеток, из которых она состоит. Когда Вы смотрите на вену на руке — Вы думаете о вене, а не о лимфоцитах.
7
Реализация очень сильно зависит от постановки задачи.
Можно поставить задачу "отправлять бухгалтеру на почту уведомления о поступлении РКО с видом Подотчёт", а можно поставить задачу "Реализовать универсальный механиз рассылки уведомлений по триггерам". А ещё можно поставить задачу "Найти на Инфостарте универсальный механиз рассылки уведомлений по триггерам".
8
Информация не должна дублироваться. Информация не должна дублироваться. Информация не должна дублироваться. Если Вам нужен какой-то необычный срез данных, лучше использовать временные таблицы или сложные запросы, чем дублировать информацию в новый регистр или справочник.
9
Если схожая задача возникает 3 раза, значит, она возникнет ещё 300 раз, и пора подумать о создании универсального механизма
10
Пользовательский интерфейс должен быть максимально лёгкий. Запрещается перегрузка интерфейса лишними элементами. Любые возможности нужно систематизировать — объединять в группы, выносить на отдельные вкладки и так далее. Если пользовательский интерфейс перегружен реквизитами и полями, назначение которых понятно только избранным или требует отдельной инструкции, значит, интерфейс очень плохой.
11
При разработке пользовательского интерфейса не надо мельчить. Вам доступны полные страницы! Если одновременно показываемых пользователю элементов слишком много, значит, разработка идёт неправильно.
12
Автоматизация повышает эффективность учёта, но при одном условии, которое очень важно выполнять — при условии правильности вводимых данных. Например, если Вы неправильно заполните информацию о номенклатуре, любые автоматизированные обработки номенклатуры станут бесполезны.
12А
Хорошая автоматизированная система — это очень жёсткая диктатура. Эта диктатура может быть просвещённой, и её правила могут быть очень гибкими, но они должны быть абсолютно обязательными к исполнению, если мы конечно хотим получить от АС ту пользу масштабируемости, ради которой всё и затевается. Наказания за нарушения правил диктатуры ведения данных в АС должны быть суровы, иначе человеческий фактор дискредитирует все благие намерения.
12Б
Любой неправильный ввод документа или справочника с откладыванием данных "в мозгу" (типа "потом поправлю") недопустим. Лучше вообще не ввести документ, даже если это приходная накладная на миллион долларов, чем ввести его неправильно. Любой неправильный ввод данных в систему повышает её энтропию и уменьшает доверие к системе, лишая верхних уровней возможностей, для которых АС и предназначена.
13
При проектировании следует чётко и ясно определять уровни взаимосвязи объектов — один к одному, один ко многим, много к одному, много ко многим, и исходя из этого сразу планировать правильную логику. Например, если в чеке для видов оплат сразу спроектировать таблицу "оплаты", всё становится на свои места. Можно платить частично наличными, частично картами, частично яндекс.деньгами. Или наоборот — заранее заложить при проектировании, что вид оплаты должен быть один и только один, а если видов оплаты несколько — оформлять несколько чеков. Оба подхода имеют право на жизнь и свои плюсы и минусы.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
14 Не усложнять. Чем проще алгоритм и структура метаданных, тем проще его поддерживать, дорабатывать + как правило производительность выше.
Статья хорошая. Но об этом всем я узнал еще на 1 курсе своего профильного обучения. От себя добавлю, что хорошие комментарии и пояснения в коде облегчат вам или приемнику жизнь в разы.
Насчёт 12Б. С точки зрения программиста я полностью согласен с данным тезисом. Однако не думаю, что с таким положением дел согласятся собственники предприятий. Для них ведь на первом месте получение прибыли. И именно для этого им нужна автоматизация. Для сокращения издержек, прозрачного учёта и тд. Но если ради автоматизации придётся откладывать условные накладные на миллионы долларов, то какой им толк от неё? Да, в базе всё будет красиво, правильно, чётко и ясно. Но ведь на первом месте для них прибыль, а не отлаженный механизм учёта. И когда условный программист говорит условному владельцу бизнеса «Сейчас мы не можем обработать этот выгодный заказ от клиента, т.к. мы потом не сможем автоматически обработать эту номенклатуру», то вряд ли он встретит одобрение со стороны собственника.
Вот если бы 1С придерживался этих правил. 🙂
Не соглашусь. Денормализация БД иногда единственный выход чтобы заметно ускорить работу на огромных базах.
(6) Ну тогда это не дублирование, а денормализация)
(6) Да. Ничто не догма. Иногда приходится идти на чудовищные с точки зрения теории и «хорошего тона» решения. Они уродливы, ненормализованны, задублированны, как угодно ещё страховидны. Но эти решения дают отличную производительность. Помните, вы не эстетствуете и не пытаетесь «1С-Совместимо» получить (что вообще анекдот, учитывая, как они сами свои стандарты не соблюдают), вы делаете решение. Решение проблемы. И если временные таблицы сжирают оперативку сервера, а наплодить регистров — это выход, то почему бы нет?
(2) Хороший код не нуждается в комментариях)
(5) Пора статью писать, «Мой путь в 1С»
Все конечно здорово. Но(теперь моя очередь быть кэпом) прошу добавить самое главное — делайте бэкапы. Вернее не так, правильно — делайте и проверяйте бэкапы. Иначе рискуете остаться пандой=)))
(6) я бы этот совет вообще перевернул с точностью до наоборот:
«Если вам нужен какой-то необычный срез данных, лучше использовать новый регистр или справочник, чем сложные запросы или алгоритмы получения данных»
практически всегда под сложный отчёт / механизм лучше предусмотреть отдельные регистры, чем городить сложные, непонятные и медленные запросы и алгоритмы
в подавляющем числе случаев (если требуемый срез данных действительно сложный, а не простое соединение нескольких регистров) поддержка синхронизации дублирующихся данных обходится намного дешевле, чем поддержка сложных алгоритмов получения этих данных.
Ещё из спорного:
«7. Реализация очень сильно зависит от постановки задачи» -> «Эффективность реализации очень сильно зависит от того насколько одинаково понимают задачу (её прикладной смысл и область применения) «постановщик задачи» и «исполнитель задачи (программист)»
«12Б Лучше вообще не ввести документ, даже если это приходная накладная на миллион долларов, чем ввести его неправильно» -> «лучше закрыть часть проблемы оперативно, чем ждать когда появится возможность закрыть всю проблему сразу»
Уровень абстрактности статьи крайне высок, те кто уж прошел такой же путь как автор — поймут, остальные могут и не принять.
«Код программы должен быть простым» я думаю слово понятным подходит больше. Мысль то правильная и хорошая, можно еще добавить, то что понятно здесь и сейчас, в другое время может стать абсолютно непонятным.
Также программа должна быть без ошибок, а еще должна быть оптимальна с точки зрения производительности и масштабируемости.
(11)Если установлен Microsoft SQL Server то проще через агент регламентное задание настроить, на бэкап и разворачивание бэкапа на тестовую базу. Заодно и тестовая база со свежими данными будет под рукой.
(12) +++
95%
населения — идиотыразработчиков не имеют ни представления о механизмах работы СУБД, ни прогноза на объемы обрабатываемой информации. Т.е. не могут сказать, как будет работать тот ли иной запрос на продуктивной базе.Жалко,что разработчики типовых конфигураций далеко не всегда следуют этим правилам)))
(16)
Так устроился бы в 1С и научил бы их там всех программировать. За одно и качество тиражных решений поднял.
Правила 12 это не про программирование.
Правило 0. Программист не должен подменять собой генерального директора.
Хочется поспорить с п. 8 — «Информация не должна дублироваться». Иногда для повышения быстродействия алгоритма приходится хранить информацию с избытком. Например, для формирования какой-то сложной отчётности необходимо заранее готовить данные и хранить их отдельно от исходных данных, чтобы потом быстро собрать в отчёт. Таким образом, мы храним информацию избыточно, но повышаем скорость формирования отчёта.
А вот дублирования программного когда следует, конечно, избегать.
Пункт 0
Стив Макконнелл
Пусть меня закидают камнями, но я скажу. Основная проблема в том что «программист 1С» собственно программистом не является. Все эти прописные истины, которые привел автор статьи преподаются или еще в школе или на первом курсе института. Изложены в книгах (пример выше приводил — «Совершенный код. Стив Макконнелл»), но увы 1С-ники с этим не знакомы. Начинают не с азов программирования, а сразу с кода. Отсюда и имеем пресловутые «запросы в цикле». Порог вхождения очень низок и это сыграло злую шутку.
(21) Вы правы, мистер д’Артаньян
(16) в основных типовых решениях — следуют в полной мере.
Толсто
(20) правда непонятно как быть если ты сам склонный к насилию психопат…
(5)Все круто, я думаю у многих по-разному сложилось в жизни только вот к чему эта исповедь?
(4)а в чем 1С не придерживается этих правил?
К примеру у автора процедура так себе. Нет входного описания параметра, а по стандарту он должен быть описан иначе не понятно, что это?Структура, таблица значений, строка дерева значений Ит.д.
(20)»Совершенный код»
(27)Относится к Макконнеллу в таком тоне может только бездарность которая ленится даже синтаксис читать.
(27) принцип «keep it simple, stupid» работает, но до определённого предела
(30) бгг… Взрослый вроде дядя, а такой наивный…
» Если пользовательский интерфейс перегружен реквизитами и полями, назначение которых понятно только избранным или требует отдельной инструкции, значит, интерфейс очень плохой. »
Это аксиома. Следствие : все типовые конфигурации очень плохие 🙂
Может быть стоит начать с изучения документа «Система стандартов и методик разработки конфигураций для платформы 1С»? У меня нет подписки на ИТС, но получить его не составило большого труда.
(4)
(21) Да, я только через несколько лет работы узнала, что запрос в цикле — это не хорошо. Но самое ужасное — когда такое пишут программисты с 15-летним стажем и при этом ругают платформу 1с…
Тут все это прекрасно описано.
(31) и какой же там предел?
С прописными истинами есть одна смешная проблема.
Либо ты уже их выстрадал сам и для тебя это банальности, не стоящие упоминания в приличном обществе, либо ты еще в начале пути и для тебя они — брюзжание пердунов, неправильно расставляющих приоритеты и талдычащих одну и ту же неважную фигню (тут хоть как-то работающий код написать бы).
(39) есть еще один момент — когда ты их применяешь на практике и вдруг выясняешь что стало еще хуже.
(23)О да,особенно в ДО,прям ягодка.Печатные команды добавлены кнопками на форме!!!!
И куча избыточных процедур где сверху в комментариях чётко написано,что нам пока это менять лень,в будущих релизах уберём.
(26) в соответствии с темой обсуждаемой статьи я написал о том что оказалось мне полезным для развития как 1Снику. И дополнительно захотелось привести ссылку на бесплатные по общим вопросам разработки, в том числе на 1С.
Блин ну зачем всякую ерундистику писать? Есть давно разработанная система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8. Ссылка дана была выше
(28) Не усложнять. Чем проще алгоритм и структура метаданных
1С любит налепить регистров в огромных количествах!
Например, раньше в зарплате обходились одним регистром, а сейчас
под сотню скоро будет! Тоже и в Бухгалтерии
(44) 1С как раз не усложняет. Не забывайте, что типовые конфигурации 1С являются универсальными.
(45) А раньше не было все универсальным? И хватало одного регистра. А сейчас,
особенно с ЗУПе их столько… Информация по сути дублируется, возможны рассогласования и т.п.
А вот эти ребята автоматизировали проверки по стандартам
Код и решения получаются более качественными.
(17) Как то писал разработчикам расширения что они рожают очередного монстра. Тем более у меня был опыт сопровождения системы IBSO (Новосибирск) с подобным ПРОСТЫМ механизмом. Кто там будет слушать то? Практически всегда ответ что «САМ ДУРАК и не понимаешь всей тонкости реализации». В системе IBSO в модулях расширениях(хуках) лежали только те модули, в которых меняется код, а не всё подряд(формы, реквизиты, доп. объекты метаданных). Помнится делал одно простое расширение, так у меня в это расширение 10% всей конфигурации перенеслось. «Круть»… Хотя есть и плюсы, более просто сделать изменить форму, не сталкивался правда с тем, что обновление конфигурации потребует обновить форму пока, скоро наверно уже начнётся.
(47) Вы сами проверяли? 🙂
это частный случай, в общем виде это так:
Если вы не можете объяснить что-то на пальцах добросовестному дураку, вы сами не понимаете этого.
(41) В WMS тоже «интересный подход» — строки табличной части документа — это отдельные документы. Проводки делают не сами документы, а спец. документы им подчиненные. Изменение статусов документов регламентными заданиями, провел кладовщик и ждет когда статус документа поменяется. Я понимаю, что это такое архитектурное решение, но нельзя же так.
В ДО точно такая же ситуация — задумка хорошая, реализация мрачная. Система прав вообще жесть.
(49) угу. Пётр один из наших клиентов (надеюсь, что благодарных)
(8)
О чём конкретно речь? Приведи примеры, пожалуйста.
(52) когда не делал code review 2 месяца под ряд и решил посмотреть на качество, очень приятно удивился, что программисты хорошо так выросли.
(49) Вот открытый мой проект крутится
(55) Вы проводите непрерывный анализ и измерение качества задачи размером 8 тысяч строк кода. Я создавая и поддерживая на едине с пользователями программы большего размера (к примеру розничный автозаказ товаров) не вижу смысла использования системы непрерывного анализа и измерения качества. В попыхах несколько раз делались и всплывали очень досадные ошибки (при желании по быстрому реализовать новую частную функцию и связанные с не предупреждением отказов отдельных компонентов системы). К примеру в резутьтате «блокировки» не записан и не проведен документ из цепочки автоматически выполняемых действий или не изменено значение константы. Данные узкие места, и например то, что один из регистров сведений тяжелый для чтения/записи, по опыту знаю только я, кто кроме меня может это обнаружить? Эффективно ли привлекать особых специалистов проверять не большую программу? Не возрастут ли затраты собственных программистов на мониторинг качества кода в ущерб функциональности? Как в Вашей системе непрерывного анализа и измерения качества реализована проверка конечного результата работы задачи при каждом варианте настройки тестируемой системы и проверка на отказоустойчивость?
(58) Прикольно кстати. Бухгалтерия сложна, главное понять принцип двойной записи.
(18) +Программист может подменять любого работника на время его отпуска или на время поиска/обучения нового работника.
Если программист может подменять ТОЛЬКО генерального директора — это не программист.
(50) класс.. умный в любом случае разберется, даже если вы сами этого не понимаете.
(58) Игорь, речь не о сложности интерфейса, а о перегрузке количества регистров. Вы же прекрасно знаете, что творилось и продолжает твориться с НДФЛ с декабря в 3.1.4 и далее…
(59) Бухгалтерия сложна в части налогового учета (где и как правильно учесть затраты по большей части), а принцип двойной записи вообще элементарщина, из одной копилки вынь, в другую положи, в одном месте убыло, в другом прибыло, тут главное запомнить номера копилок и их смысл (Консультант+ в помощь). Ровно такие же проблемы у людей с пониманием копирования файлов на диске и самое сложное с вырезанием в одном месте и вставкой в другом. Меня порой веселит, как в крупных конторах, в бухии сидят отдельные бушки под отдельный вид учета, ну допустим только занимается учетом ОС и НМА, а другая списанием в производство, третья на приходных накладных, четвертая на продажах… и блин вроде бушки и должны шарить во всем дебете с кредетом, а не взаимозаменяемые…
Программист не сможет заменить прям любого работника, я хоть к примеру и прошареный в бух. учете, кадровом учете, расчете ЗП, но плеваться буду, если меня заставят сдавать регламентированные отчеты, — это адище и адище это оплачивается людям с соответствующей профессией, а программисты как бы все же призваны заниматься другим делом, автоматизация там, оптимизация, внедрение и другие красивые словечки. Ну сделаю я отчет в спешке, а дальше что? А если есть проблемы, нужно позвонить подружке в ФСС или ПФР, а у меня та её там нет, у бушек как правило уже свой круг знакомых у которых они могут узнать контакты и прочее, а я буду как дурак среди прогеров 1С искать контакты))
Генерала прогер тоже не заменит, так как найдутся люди по рангу выше его, но ниже генерала.
Все должны заниматься своим делом, однако на долю прогеров 1С свалилась такая ноша, что приходится шарить в своем деле и предметных областях с ним связанных, и случается так, что шаришь лучше юзеров работающих в системе. А, ну и раз ТЫЖ ПРОГРАММИСТ, ты должен шарить во всей админской/сервисной тематике и как два пальца об асфальт заправить любой картрижд, усилить громкость звука в скайпе…
Вы пишете код для человека, не для программы или компьютера. Делайте код понятным, чтобы человек, который будет разбираться в нём через полгода или год или два, мог легко это сделать
В целом с утверждением согласен. Программы для программистов? За 10ть лет следовало бы понять, что программы — для пользователей.
Информация не должна дублироваться. Информация не должна дублироваться. Информация не должна дублироваться. Если Вам нужен какой-то необычный срез данных, лучше использовать временные таблицы или сложные запросы, чем дублировать информацию в новый регистр или справочник.
Не могу согласиться с утверждением. Возможно, это справедливо в системах на 10 пользователей, но в высоконагруженных системах дублирование ради повышения скорости выборки данных за счет упрощения запросов — дает ощутимые результаты. То, что поддерживать этого монстра и обеспечивать целостность данных — дело не легкое, можно не писать. В контексте моего сообщения, пишу о оптимизации работы, а не разработке или поддержке. Система же пишется для пользователя.
Если схожая задача возникает 3 раза, значит, она возникнет ещё 300 раз, и пора подумать о создании универсального механизма
Код необходимо сразу писать с расчетом на многократное использование.
(61) Проблема не столько в типовых конфигурациях 1С, сколько в даунизме наших законотворцев… то ли еще будет…
(1) вот этим грешат многие начинающие программисты. Я для себя сделал вывод: хорошее решение — простое решение. Лучше 7 раз подумать и написать небольшой правильный код, чем начать писать, а потом уйти в неведомые дебри, которые уже не решают задачу. Точка отсчета очень важна
(51)Почему так сделано в WMS, и что этот подход дает — вы просто не поняли. Про ДО согласен на 100%.
(62)
Канэчна найдется! Свято место пусто не бывает.
Но ПРОГРАММИСТ стоит ДЕШЕВЛЕ.
В лучшем случае через какое то время фикси деградирует до банального гастарбайтера — штрейхбрекера.
Посему пользы от своевременной перемены мест работы гораздо больше чем неудобства от ошибок в коде, доставшихся от коллег или коллегам по цеху.
(66) WMS очень удобен, особенно удобны рабочие места. Кладовщиков от увольнения спасло повышение зарплаты :). Франчайзинг отчитался о еще одном «успешном» внедрении 1С. К отваливаниям ТСД уже привыкли, очищать регистр «Текущее действие пользователя ТСД» кладовщики обучены. В общем «Всё хорошо прекрасная маркиза, всё хорошо, всё хорошо».
Какая система у вас? По описанию вроде не акселот, или всеже?
Вай-вай…
(70) Смущает явное сравнение? Явные сравнения легче читаются. В типовых конфигурациях они сейчас используются намного чаще, чем раньше.
(71)
Истина в том, что склеить накопленные данные нельзя. Даже если они читаются.
(73)
это ключ структуры
(71)
Например в Рознице 1000+ раз встречается явное сравнение в условии.
И есть ещё функции платформы у которых возвращаемый результат может быть как булево, так и ссылочное значение.
(71)(75) Фигня какая-то. Если название переменной/свойства уже соответствует булеву, то явное сравнение с литералом только затрудняет чтение.
Вот сравните два предложения, только читайте не как код (а то я смотрю, у вас уже глаз замылился), а как произведение:
«если можно склеить тогда»
«если можно склеить равно истина тогда»
(76)Я никому вроде не советую писать явное сравнение и сам его не пишу. Я только написал что в типовых это встречается и часто.
Явное сравнение может быть тогда когда не известно возвращает функция результат в виде булево или она может возвращать что то отличное от булево.
Например функция «БезопасныйРежим()» и тд.
Вы слишком буквально понимаете правила.
(77)
Так тогда и вариантов других нет 🙂 Но в этом случае и давать переменной/свойству название, однозначно подразумевающее булево — в корне неверно.
То есть назвать функцию ЭтоБезопасныйРежим() и позволять ей возвращать что-то отличное от булево — грубая стилистическая ошибка.
А если функция ЭтоБезопасныйРежим() будет возвращать, как ей и положено, только булево, то стилистической ошибкой будет уже использовать ее явное сравнение с литералом.
Это мои личные правила, которые я понимаю да — буквально 🙂
(80)
Однако с этими ошибками приходится работать.
Например функция платформы «БезопасныйРежим()»
(82) Я не зря привел в пример название «ЭтоБезопасныйРежим» — это название не оставляет неоднозначности в части возвращаемого значения. Ответом может быть только да или нет. «БезопасныйРежим» такой однозначности не дает.
Но я соглашусь, что функция БезопасныйРежим() — пример плохого дизайна. Зачем ориентироваться на плохие примеры? 🙂
Ежу понятно, что если какая-то функция может возвращать не только булево, то остается либо явное сравнение, либо предварительная проверка типа.
(90)
Так я на них не ориентируюсь. Но с этим приходится работать.
Так об этом и речь. Проблема то в том что приходится работать с чужим кодом. И не всегда кто то другой взял и сделал правильно.
Я просто уже несколько раз так попадал.
(92)
Я просто уже несколько раз так попадал.
Очевидно, я просто неправильно понял ваш изначальный комментарий. Что вы мол, поддерживаете, а не возражаете. Перечитал и понял, что ошибся.
(1) Точно: Keep It Simple Stupid — KISS принцип в программировании — хорошая вещь!
В 80-х годах, уже прошлого столетия, мне как-то в руки попал документ (оригинал еще на магнитной ленте, от фирмы Motorola но могу и ошибиться) где были сформулированы правила оптимизации систем под общим заголовком Keep It Simple, Stupid! :
1. It’s easier to get a working system efficient then it is to get an efficient system working. (Легче сделать рабочую систему эффективной, чем эффективную систему рабочей.)
2. Optimaze a system only if it fails a performance test. It is futile to optimaze a system just for the fun of it, if that optimization brings no practical benefit. (Оптимизируйте систему, только если она не проходит теста производительности. Бесполезно оптимизировать системы только для удовольствия, если оптимизация не приносит никакой практической пользы.)
3. Simplicity is a virtue that bears its own rewards. (Простота это качество, имеющее собственную ценность.)
4. Optimize only the parts of the system worth optimizing. (Оптимизируйте только те части системы, которые действительно требуют оптимизации.)
(29)
К этой книге надо добавить постфикс for dummies
(41) ДО и ЗУП 3 — два достойных образчика соблюдения стандартов, ага. Больше всего, конечно, раздражает основной код на формах. В ДО, например, весь движок исполнения задач сдублирован — для интерактивного исполнения — всё на формах, для фонового-по почте — правильно, вроде, сделано, в модулях и объектах, но тока с ошибками и функционал не полный. В ЗУПе же, например, весь расчет отпусков на — форме…
(6) Просто человек ни когда не смотрел движение по регистрам в ERP. Там дублирование это основа основ, и что-то мне подсказывает это не с проста.
(46)По крайней мере, информацию из них получать стало гораздо проще. Интереса ради, попробуйте посчитать среднюю ЗП в ЗиУП 2.5 или загляните в процедуру автозаполнения Отражения зарплаты в бух. учете, после этого ЗиУП 3 со своими регистрами просто праздник…
(15) Иногда об этом (объемы обрабатываемой информации) не знают даже конечные пользователи. Жизнь очень переменчива — оптимизация это не «что-то что сделал раз и потом все время хорошо работает». Оптимизация — это постоянный процесс, причем иногда оптимизация заранее даже вредна (об этом писал еще Кнут)
(21) Порог вхождения низок теперь везде, не только в 1С, но и во всяких frontend / backend системах веб
(9) Гусару триппер не помеха?
(101)
не путайте дублирование с учётом
(104)
низок, высок — это всё оценочные характеристики. Хорошие специалисты всегда будут цениться, вне зависимости от наших представлений о пороге.
(9)Полностью согласен. У докладчика нет информации по комментариям. Он пишет о чистом коде, но не упомянул о комментариях совсем. Чистый и понятный код не нуждается в комментариях. Один из программистов, которого встречал буквально год назад, чтобы не забыть, писал комментарии в начале модуля, в начале процедур/функций, в конце модуля (о добавленных/измененных реквизитах на форме). Это тоже одна из болезней начинающих программистов. Названия функций должны быть простыми и не требовать комментариев. Но это не значит что их совсем не должно быть.
(102) Особенный «праздник» начинается с разборками 6-НДФЛ. 🙂
(58)Вы, когда подобные комментарии пишете, пишите от своего имени. В нашей фирме еще ни один юзер не дал положительного отзыва об интерфейсе «Такси». У меня вот тоже в голове не укладывается: как такая фундаментальная опция «Изменить вариант отчета» могла угодить в меню «Прочее». Или, например, как среднестатистическому пользователю объяснить, что две кнопки «еще» на форме документа относятся к разным объектам формы? Я даже после года работы их путаю.
(115) Интерфейс «Такси» — самый лучший интерфейс из всех возможных. А придираться по мелочи можно к чему угодно.
(116)А я не придираюсь. Но законы человеческого восприятия еще никто не отменял. После дня работы с этим «такси» в глазах строчки прыгают и руки трясутся. Потому что на экране все прыгает. Приходится зрение напрягать и руки, чтоб попасть точно в цель. Ну я лично эту тему закрываю. Какой смысл спорить с теми, кто нам работу дает? Бесполезно это.
(96)
Глаза режет. ((
(121) Как ни странно, есть и такой термин — синоним…
(124)
Действительно, странно. ))