Как читать чужой код 1с
Доброго времени суток! Вопрос по закрытию кода 1С, применяете ли и в каких случаях? Каков стандартный подход? Все что пишется под заказ клиенту закрывать нельзя? Можно закрывать только продаваемые серийно наработки? Или вопрос решается за счет цены? Закрытый код - цена дешевле, открытый - дороже? Есть ли правило, что по умолчанию, если не обговаривалось сторонами, код обязательно должен быть открыт? Или на усмотрение разработчика?
Зачем? Потом как дальше поддерживать?
Закрытый код видел только в особо крутых и известных тиражных решениях, и то чтобы защититься от пиратов, а не от кражи алгоритмов.
Платные обработки на Инфостарте обычно закрывают, вот там боятся копирования кода.
(9) + Обговариваю будет ли закрываться самим клиентом или нет,чтоб вопросы потом не задавал что я закрыл.
(10)а как это обходится в тиражных решениях? ведь тоже есть Покупатель программы, но код ему недоступен, или Покупатель<>Заказчик?
Книга учёта доходов и расходов и архив КУДиР для 1С 7.7 любой конфигурации для УСН ПСН ОСНО: закрытый код
(17)не смущает ситуация, что написал клиенту что-то, а он раздал это всем, или раз ему написали, то он может всем это продавать и раздавать?
(22)а как обходите претензии Покупателя, ведь он же заплатил деньги, значит это его, например в (10) написано, что "Код собственность заказчика."
это как автосигнализация с обработной связью
- вроде круто ,а толку мало (работаешь ты в офисе, приходит уведомление "машину угоняют" и . Легче стало ?
ситуации бывают разные , но всегда должна быть альтернатива.
Ну закрыл ты в конфигруции модуль документа. В чем проблема удалить его (документ) и написать свой код. в принципе так со всеми объектами. Внешние отчеты , обработки, печатные формы, модульность - закрывают все вопросы.
(22)например он захотел доработать закрытый код своими силами или силами других разработчиков, и не готов платить за доработку его Вами.
или все упирается в то, что несмотря на то, что он Покупатель, он не является Владельцем, а лишь Пользователем?
>а как обходите претензии Покупателя, ведь он же заплатил деньги, значит это его
с чего бы вдруг?
покупатель купил лицензию на право пользования. а не ПО и его разработчиков впридачу
и да. иногда "чужой" код читаешь - лучше бы он был закрытым или его вообще не было.
и "чужой" код еще уметь читать нужно иногда бывает легче и быстрее самому написать, чем "чужое" разгребать.
(24)"Ну закрыл ты в конфигруции модуль документа. В чем проблема удалить его (документ) и написать свой код. в принципе так со всеми объектами. "
кто же против, пусть сами напишут, если готовы. только это ресурсы, время, квалификация.
(0) и ты разделяй
- одно дело Заказчик к тебе обратился - написать для него конкретно (тогда все его и идеи и чертежи и код)
- другое дело ты создал и предлагаешь купить Заказчику (вот тут твои условия могут быть)
(34)а если что-то среднее? предложил написать для Заказчика, то есть предложил идею и реализовал ее. чем это отличается от продал Заказчику?
>- одно дело Заказчик к тебе обратился - написать для него конкретно (тогда все его и идеи и чертежи и код)
пока полной оплаты нет никто права заказчику не передаст
>предложил написать для Заказчика, то есть предложил идею и реализовал ее. чем это отличается от продал Заказчику?
читаем об лицензировании и авторском праве. меньше будет глупых вопросов
(0) т.е. тебе кто предложил что то написать
ты написал - думаешь , что вещь хорошая получилась
и теперь тебя жаба душит отдавать заказчику в чистом виде, так как сам хочешь еще навариться на этом - в этом суть темы ?
(41)заказчик склонен к нерегулярным беспорядочным контактам, если отдать ему, то вмиг по всем расползется, потому что он так часто меняет партнеров, что все его быстро становится общим
(48)у сотрудников "по умолчанию" такие жесткие ограничения, или-же только если в трудовом договоре и должностной инструкции они прописаны? то есть может ли работодатель "дать вольную" своим работникам через условия трудового договора? например, платит в месяц только МРОТ, но зато в Трудовом договоре дает вольную на авторские права своим сотрудникам?
А вот интересно. Есть же такие фирмы, сотрудники и руководители которых брезгливо так отзываются о защите кода (типа сначала дорастите, и вообще 1сники не любят делится и все на гитхаб) и одновременно распространяют свое обучающее видео с адской защитой от копирования? (:
не вижу в этом смысла.
Все эти закрывашки только усложняют жизнь клиенту, а от тех, кому реально надо, ни чего не защищают.
(56)по крайней мере появляется "порог входа", клиент будет вынужден продолжать работать с подрядчиками более-менее адекватного уровня, демпинговать студентами и тарелками супа будет сложнее.
(57) студенты с тарелками они хорошие, не гони на них, если тебя разменяли на студента значит не твой клиент, после студентов клиенты обычно сговорчивей становятся
Лет 15 назад создали тиражную конфигурацию на 7.7. Не защищали.
Конфигурация оказалась удачной, простой и универсальной. Ее стали копировать, пользоваться и продавать, все кому не лень, бухгалтера, сисадмины.
Бывали случаи. Обращается потенциальный клиет:
- У нас есть база 1С, честно спи. я. Работаем на ней давно. Но теперь законодательство изменилось. Нужны новые формы отчетов и пр.доработки.
Я спрашиваю:
- что за конфигурация, где брали?
Отвечает:
- Не знаю. Предыдущий бухгалтер принесла. Но тут при запуске базы в заставке написано "разработчик такой то"
Я:
- ну вот и познакомились, это я.
Потом нашли информацию про "КЗК" (Комплекс защиты конфигураций). Купили.
В глобальный модуль добавили простейшую проверку и закодировали все модули. Если клиенту потребовались доработки, в любой момент можно раскодировать.
И все, как отрезало. Больше ворованныхх копий не встречали.
(64) мне кажется те времена уже ушли, когда можно сделать простую рабочую конфу, а ля автомат калашникова
>у сотрудников "по умолчанию" такие жесткие ограничения, или-же только если в трудовом договоре и должностной инструкции они прописаны?
они прописаны в ГК как дефалтное значение. и конце там есть фраза "если в договоре не предусмотрено иное" - т.е. выверты в сторону должны фиксироваться и не противоречить действующему законодательству
Опять-же компиляция защищает от претензий в авторстве модификаций. Например сделал что-то клиенту, ушел, он через день звонит - то что ты наделал не работает, приходи срочно исправляй, ты виноват. приходишь, а там явно кто-то другой успел потрудиться, но клиент утверждает, что никто не прикасался и виноват именно ты.
(68)зачем платить разработчику, если все открыто и админ соседа Васи тебе итак за бутылку все откопипастит.
Закрываю код тиражных конфигураций. Если конфигурация подходит многим организациям, простая, если ее скопировать и можно спокойно пользоваться без помощи программера 1С - то кодирую.
Если конфигурация сложная, заточена под узкую специализацию, требует обучения пользователей, т.е. без полноценного внедрения не взлетит - то не закрываю, так как не имеет смысла.
(65) Ошибаешься. Продажи у нас увеличились :)
Но возможно это связано с тем, что 1С стало более широко распространяться, а конкурентов у нас на тот момент было немного. Спрос есть, а дешевых ворованных предложений нет. Вот и стали чаще обращаться к нам.
(66) Сейчас обращаются клиенты, которые бы хотели аналогичную конфигурацию на 8.3. Работаем над этим.
Планируем ее также защищать.
Подскажите аналог "КЗК" для 8.3?
Закрытые конфиги покупают только лохи, а лохов становится всё меньше. Да и любой одинесник может легко написать заново закрытую часть кода, чем я неоднократно занимался.
>Да и любой одинесник может легко написать заново закрытую часть кода, чем я неоднократно занимался.
очень гиморойно иногда. втыкают проверку через слово в коде
иногда очень хочется выдрать левые защиты просто чтобы официально купленный продукт мог адекватно работать
Добрый день! Хочу рассказать о способе, который позволит быстро разобраться в чужом коде. Я, конечно, думаю, что это жесткий баян, но не видел, чтобы кто-то пользовался этим способом. По крайней мере, новичкам точно будет интересно.
Данный метод будет очень полезен в типовых конфигурациях, так как там может быть очень глубокий стек вызовов процедур, в котором новичку разобраться достаточно сложно.
Предположим, нужно разобраться, как устроен механизм печати БП 3.0.
Идем в конфигуратор, запускаем режим отладки. Кстати, некоторые процессы, например, формирование отчетов могут выполняться фоново, и для их отладки требуется настроить автоматическое подключение.
Также в типовых конфигурациях есть дополнительный параметр запуска «/РежимОтладки», который так же отключает фоновое выполнение.
После запуска режима отладки заходим в документ для формования печатной формы, но перед выполнением печати запустим механизм замера производительности.
Данный механизм позволит увидеть список выполненного кода за период работы механизма.
Далее выполняем печать и отключаем замер производительности.
Теперь нужно решить: какой ключевой оператор поможет найти требуемую процедуру, в которой формируется печатная форма. Для формирования печатной формы требуется в любом случае создать объект Табличный документ, таким образом ключевой оператор будет «Новый ТабличныйДокумент» или просто «ТабличныйДокумент». Находим нужную строку, используя ключевой оператор, устанавливаем точку останова и запускаем формирование отчета.
После остановки отладки на требуемой строке кода запускаем стек вызовов.
Выходит окно со списком вызванных процедур, по которым можно выполнять переход для изучения механизма печати.
Специальные предложения
Уважаемый, если бы Вы НА САМОМ ДЕЛЕ открыли способ , как разбираться в чужом коде, Вам бы памятник при жизни поставили. А это - боян для новичков.
Вчера только сделал короткую заметку, что можно применять поиск в окне замера производительности
p.s. Пользуясь случаем, поздравляю всех с Новым Годом !
за 10 лет ни разу "именно так" не изучал чужой код - просто шел по отладке "следующий шаг" - еще "следующий шаг".
а вообще представленный метод полезный
П.С. баян - не баян. мне не интересно, как это назовут.
поток инфы настолько огромен, что часть инфы проходит мимо.
для меня инфа полезна, хоть я не новичок в плане копаться в чужом коде.
(11) кстати, в стеке вызовов доступны все переменные всех функций стека. Т.е. проваливаешься на уровень Х и можешь посмотреть любую переменную.
(9) Десять лет назад я тоже начинал "расследование" от кнопочки "Сформировать". Но пару лет назад мне попалась УНФ, а там на банальную печать документа жесткая мешанина из процедур модуля менеджера этого документа, специальной печатающей именно этот документ обработки и кучи вызовов из общих модулей, часть из которых спрятана в БСПшных кишках, и часть из которых вызывается вообще в фоне. Почухал репу и на меня снизошло озарение про "Замер производительности", благодаря которому очень быстро все вызовы проанализировал.
Теперь у меня две стратегии разбора чужого кода. При анализе "классических" конфигураций - просто движение по F12 или пошаговая отладка. А для конфигураций на основе БСП - по "замеру производительности".
(12) все куда проще. Есть модуль менеджера печати, общая форма печатного документа и экспортные методы менеджера объектов, из которых вызывается печать. Есть функции бинда кнопок в интерфейс, которые вызывают уже общую форму, которая создает объект с макетами и дергает функции менеджера объекта, формирующие макет, прибинденые к кнопке.
(13) я всегда за примеры. Если код пишет сотня человек с высокой текучкой кадров, то подобный стек вызовов вполне оправдан, ибо повышает уровень абстракции, чем, в пределе понимания, весьма существенно упрощает код.
можно по проще и на понятном языке выражаться? 1С позиционирует себя на рынке, как легко модифицируемые продукты на коленке любым средним специалистом, для малого и среднего бизнеса. А тут надо быть экспертом по типовым КФГ. Наши клиенты (малый бизнес) не готовы оплачивать работу эксперта, когда надо НАПРИМЕР: вывести/убрать пару доп. колонок или подписей на печ. форму. Анализируя код типовых, мы уже давно пришли к выводу, проще (дешевле для клиента) написать свое с нуля, простое и надежное как АК - 47 и его модернизировать, чем искать точку минимального воздействия в каше из типовых модулей, которые еще и переписываются от релиза к релизу.
П.С. А самое дешевое (цена/качество) сидеть на УТ 10.3, и заточить ее под свои бизнес процессы, за несколько десятков часов. Наполнить готовыми доп. подсистемами с инфостарта. Окупаемость ROI, такого проекта для малого бизнеса, несколько месяцев.
(18) уровень абстракции - это весьма простой термин. Любая область воспринимается легче, если говорить о ней в общих чертах, т.е. не погружаясь в детали. Вот, например, об организме - мозг управляет мышцами, которые крепятся к скелету. Для питания мышц есть кровеносная система и сердце, которое приводит ее в движение. Легкие снабжают кислородом, кишечник - питательными веществами, которые попадают в него изо рта через пищевод и желудок. Почки и печень очищают кровь и снабжают ферментами с помощью желез. Ну и т.д.
Это уровень абстракции, приближенно описывающий работу организма. То же самое можно сказать и о программировании. В ООП обычно есть некий глобальный объект - синглтон, к которому вяжется вся логика верхнего уровня, которая состоит из конструктора начального состояния, механ змов, осуществляющих его изменение. Дальше к интерфейсным объектам цепляются обработчики событий.
В итоге чем выше уровень абстракции, тем легче воспринимать программу, как систему взаимодействующих сущностей. А дальше кже детали реализации конкретного объекта, которые и составляют основную сложность в программировании.
Правильный метод. Сто лет его юзаю (еще с паскалей, но том это иначе называлось - профилирование, но я юзал турбо-дебагер). На курсах подготовки экспертов данный метод рекомендуют (настоятельно) для поиска узких мест перед тем как лезть в профайлер скула и техжурнал.
С одной стороны, сложность типового кода повышает общую капитализацию сегмента отрасли и уменьшает общее количество некачественного исходного кода, с другой стороны она же снижает производительность и повышает требования к аппаратному обеспечению. Уже сейчас минимальная конфигурация компьютера для комфортной работы в типовых конфигурациях приближается к игровым системам начального уровня.
Если тенденция не изменится, то предположу появление и рост объемов методических пособий по технике убеждения клиентов и работе с возражениями, тематических семинаров, пропагандистских материалов, литературы класса "как преодолеть себя и достичь успеха с 1С", детских лагерей и кружков изучения гимна 1С. Или я увлёкся? )
(21) все правильно. Инфраструктура франчайзи нужна, но программисты в них уже не требуются, разве что в очень крупные и значительно меньше, чем сейчас.
Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и, главное, как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.
Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Итак, прежде чем читать чужой код, необходимо понять, зачем мы это делаем, какой результат хотим получить в итоге. Чтение кода - это задача, причём довольно сложная! И без понимания того, какой результат мы хотим видеть, - никак не обойтись.
В моей практике чужой код необходимо читать в следующих ситуациях:
1. Необходимо выполнить небольшую или, наоборот, большую доработку в уже существующем (не типовом) объекте метаданных или во внешней обработке/отчете.
2. Выполняем код ревью. Актуально для опытных специалистов, которым поручают контроль джуниоров. Иногда перекрестный код ревью, чтоб глаз не замыливался.
3. Отдельно выделю доработку типовой конфигурации. Её код усложнён из-за необходимости учитывать большое количество сценариев и стандартов разработки. Универсальный код всегда сложнее анализировать.
4. Вам необходимо провести обновление доработанной кем-то или Вами конфигурации. Зачастую необходимо обновить вообще незнакомую конфигурацию, возможно, Вы с ней не сталкиваетесь по работе. Например, моя конфигурация ЗУП, но мне приходилось обновлять 5 примерно похожих между собой конфигураций УПП 1.3.
5. Отдельно выделю разбор и изменение запросов.
6. Как разобраться в работе программного интерфейса. Как его использовать в своей доработке.
7. Отдельно выделю необходимость помочь коллеге, или необходимость за кого-то переделать работу в невероятно короткие сроки. Не все разработчики могут выполнить поставленную им задачу, и приходится за кем-то переделывать.
Теперь определимся с ожидаемым результатом от наших действий:
1. Доработка выполнена таким образом, чтоб не сломать уже существующие сценарии. Доработка соответствует общепринятым стандартам разработки. Если дорабатывается тиражное решение - стилистика кода соответствует общепринятой.
2. Проверили работу коллег, указали им на явные и не очень ошибки, рассказали, какой код можно оптимизировать либо заменить на программный интерфейс. Проверили синтаксис написанного кода, указали на опечатки и лишние сокращения.
3. Разобрались, как работает типовой код. Определили объекты метаданных, из которых вызывается. Определили сценарии работы кода. Выполнили свои доработки, не нарушив логической целостности кода.
4. Обновили доработанную конфигурацию, перенесли весь дописанный код. Где-то код заменили на типовой. Где-то пришлось заново доработать.
5. Разобрались с запросом. Внесли в него свои доработки. По возможности оптимизировали запрос.
6. Разобрались с программным интерфейсом, включили его в свою доработку.
7. Помогли коллеге, ответили на вопросы, проверили его способ реализации, подсказали правильный путь. Либо всё это сделали без использования коллеги. Исправили все ошибки, либо с нуля выполнили доработку.
Вводная информация, применимая ко всем кейсам:
1. Конечно же, будут попадаться незнакомые процедуры или функции встроенного языка. Их изучают в 2 простых шага:
-- Синтакс помощник расскажет Вам о её предназначении.
-- Поиск по всем текстам в любой типовой конфигурации покажет Вам множество примеров по использованию. Часто эти примеры можно прямо копировать в свой код, когда будете вести разработку.
2. В целом программирование в 1С построено на том, что любая переменная или реквизит имеет определённый тип значения. Набор свойств и методов, доступных для переменной/реквизита, можно найти в синтакс помощнике в разделе, где описан конкретный тип значения. Тип значения конкретной переменной в коде можно посмотреть отладчиком. Узнав тип значения какой-то переменной, Вам может стать понятней код, который написан применительно к переменной.
3. Не нужно никогда изучать код путём прохождения ВСЕГО кода через отладчик. Поверьте, Вы сойдёте с ума и ничего не поймёте! На выходе будет каша в голове. Пользуйтесь поиском по всем текстам, чтоб найти нужное для разбора и отладки место.
4. Возможно, Вам требуется разобраться с каким-то объектом метаданных, с которым Вы никогда не сталкивались. Тут описанные выше методы не подойдут. Вам необходимо поискать статьи, которые описывают теорию об этом объекте и практическое применение объекта. Например, Вы не знаете, как работают Web-сервисы. Найдите статью об этом, скорей всего, статья даже окажется на Инфостарте. Часто авторы статей совмещают теорию с практикой и показывают примеры кода, как это использовать. Если пример можно скачать за 1$m, не жалейте этих денег. Самостоятельно дольше будете писать! И нет, это не скрытая реклама данного ресурса. Это мой опыт, который позволил со многими трудными механизмами разобраться.
5. Не стесняйтесь непонятные вопросы задавать на форумах. Даже если Вас обольют 10 человек грязью, всегда найдётся один, который поможет!
6. Любая конфигурация/обработка/отчет/объект метаданных - это набор сценариев, который заложил в неё разработчик. Прежде, чем пытаться доработать тот или иной кусок кода, необходимо выявить те сценарии, которые уже заложены. Способы выявления сценариев будут раскрыты ниже для каждого кейса.
7. Приучите себя к правилу: Нельзя начинать разработку, пока Вы четко не знаете существующие сценарии и как должен выглядеть сценарий после Ваших изменений. Сценарий - это основа для любой разработки. Писать его нужно ДО кодирования, а не после!
8. Не рекомендую никому вести разработку на "тестовых примерах". Тестовые данные никогда не показывают полную картину. Максимум тестовый пример охватывает 20-30% сценариев, которые необходимо учесть. Задайте себе вопрос: "Кто будет дорабатывать/тестировать остальные 70-80% сценариев"?
Кейс 1. Доработка кем-то придуманного кода. Условимся, что это не код типовой конфигурации.
В данном случае рассмотрим самую страшную ситуацию, когда доработать нужно либо написанное с нуля решение/обработку/отчет, либо так называемые партнёрские решения.
1. Первое, что Вы должны понять, есть ли описание этого решения, либо человек, который может рассказать, как оно работает. Конечно, Вам не требуется знать всю архитектуру, но Вам обязательно нужно понять, как работает кусок, который требуется доработать.
2. Если так случилось, что нет ни описания, ни носителя знаний - надо запускать в пользовательском режиме и пробовать использовать доработку.
а. С отчетом всё просто - попробовать разные настройки, посмотреть, какие данные выводит, разные варианты отчета посмотреть.
б. С обработкой сложней:
-- Первое, что надо посмотреть в коде - какие объекты модифицирует обработка. Делаем просто поиск процедуры Записать(). Всё станет очевидно.
-- Далее надо ответить на вопрос: откуда берется список объектов, который меняется. Скорей всего есть запрос.
-- Грамотные разработчики для многоразовых обработок создают промежуточную табличную часть, в которую помещают список изменяемых объектов. Попробуйте определить, что это за список на данном этапе.
-- Если обработку писал не очень грамотный или ему она показалась одноразовой. Список изменяемых объектов нужно посмотреть в коде отладчиком. Обязательно нужно изучить массив обрабатываемых данных!
ВАЖНО: Прежде чем отладчиком смотреть такие обработки, необходимо закомментировать все Записать(), найденные на первом шаге. Это убережет Ваши данные от ненужных изменений.
-- Нужно разобраться с заполнением тех параметров, которые выведены на форме. Для этого смотрим, где в запросах они используются? Некоторые параметры могут быть не используемыми! Это нужно определить на данном этапе и убрать сразу их с формы обработки!
-- Когда уже понятно, откуда взялись данные, какие данные будут модифицироваться. Вам нужно пройти отладчиком несколько циклов по обработке данных. Так Вам совсем понятно станет, что происходит.
в. С чужими доработками, особенно когда нет описания, самый сложный случай. Рассмотрим именно его. Финальная цель - также разобраться со сценариями работы и потом их модифицировать. Вот что для этого необходимо сделать:
-- Весь код можно разделить на 2 части: интерфейсный код (управление элементами формы) и объектный код (обработка заполнения, проверки, записи объекта, формирования движений документов, печать). Поэтому первое, что надо сделать - определиться, что Вы планируете доработать - интерфейс или объект.
-- С интерфейсным кодом обычно в самописных решениях никто особо не заморачивается. Поэтому найти, где прячется тот или иной реквизит, несложно. Но здесь стоит напомнить, что прятать реквизиты можно благодаря ещё 2-м механизмам: функциональные опции и права пользователя (для управляемых форм).
-- С объектным кодом чуть сложней. Надо определиться, какую часть кода Вы хотите изменить (обработка заполнения, проверки, записи объекта, формирования движений документов, печать).
-- Далее Вам необходимо посмотреть на уже заполненные данные. Неважно, какой это объект метаданных, можно вывести запросом все или часть данных с отбором по периоду или какому-то полю (чтоб не повесить сервер). Изучите, какими значениями заполнены реквизиты, особенно, если их тип - Перечисление. Стоит помнить, что перечисления созданы для описания сценариев. Можно по коду посмотреть, прописаны какие-то сценарии по значениям перечислений или это просто настройка, которую в отчете используют.
-- Чтобы разобраться с заполнением, необходимо изучить, куда потом заполненные данные идут? Если это документ, то изучаем движения. Если это регистр сведений - изучаем, где он используется. Так можно выяснить часть сценариев работы.
-- Необходимо понимать, где какой код искать. Печать, заполнение - модуль менеджера. Часть процедур могут быть вынесены в общие модули. Проверка заполнения, запись, проведение - модуль объекта. У регистров вместо модуля объекта используется модуль набора записей. Обычно в модуле набора записей расположен код формирования записей вспомогательных регистров сведений. Не стоит искать код заполнения объекта в форме объекта, хотя иногда и такое ещё встречаю.
-- Конечно, потребуется в пользовательском режиме ввести какие-то данные, чтоб увидеть, как работают найденные на предыдущих шагах сценарии работы. Как и в остальных случаях, непонятные куски кода можно посмотреть в отладчике.
После того, как мы выяснили сценарии работы, изучили массив данных, протестировали в пользовательском режиме и посмотрели в отладчике. Можно приступать к доработке такого кода.
ВАЖНО: В остальных кейсах необходимо пройти те же самые шаги. Поэтому по остальным кейсам буду описывать только отличия от первого.
Кейс 2. Выполняем code review.
Почему кейс 2 идёт после доработки нетиповых решений? Всё потому, что проверяем-то мы не типовую конфигурацию от 1С. А проверяем мы то, что написали наши коллеги. Иногда приходится проверять то, что написали уволенные коллеги или уволенная вся команда))) Т.е. никто не знает, как оно работает, и нигде не описано.
НО! Цель код ревью - проверка соблюдения стандартов разработки 1С. На эту тему написано очень много статей, поэтому подробностей здесь не будет. Коротко опишу, что проверяю сам:
1. Есть в стандартах раздел "Соглашения при написании кода". Этот раздел по сути показывает, грамотный человек писал код или нет. Многие любят излишние сокращения, не любят писать с заглавной буквы, делать пустые строки между блоками и т.д. Выполнение разработчиком этой группы стандартов так же важно, как и грамотная устная и письменная речь. Несоблюдение этих стандартов затрудняет чтение и понимание кода! Да и просто это неуважение к остальным коллегам! Ну и собственно длительно с таким кодером я работать не стану. Пару раз предупреждаю о соблюдении этой группы стандартов, не понял - на выход!
2. Если в рамках задачи создаются новые объекты метаданных - проверяю группу стандартов "Создание и изменение объектов метаданных". Цели данной проверки те же. Обеспечение единого подхода при создании объектов метаданных. Иногда встречаю реквизиты вместо Сотрудник, Подразделение - Сотр, Подр. Встречалось, что Сотрудник был с типом "Строка", а не справочник. И это была не механическая ошибка. В самописной базе не было такого справочника! Необходимо создавать объекты метаданных по описанным в стандартах принципам. В обработчике ПередЗаписью встречал проверку заполнения реквизитов и т.д.
3. Далее проверяю вопросы клиент-серверного взаимодействия. Собственно в этой группе стандартов перечислены необходимые проверки. Очень много кода пишут на клиенте, много лишних серверных вызовов, не используется серверный вызов без контекста.
4. Следующее проблемное место в коде - обработка данных (запросы, выборки, транзакции, блокировки).
-- По запросам наиболее часто встречается неверное использование индексов, либо вообще не думают об этом. Данная ошибка тормозит работу не только одного клиентского сеанса, но и сервера в целом! Не используются виртуальные таблицы с параметрами, запросы делают к физическим таблицам. До сих пор встречаю вложенные запросы к довольно большим таблицам.
-- При выборке данных часто встречается Запрос.Выполнить().Выгрузить() и дальше обрабатывается таблица. Зачем? Необходимо использовать выборку из результата запроса.
-- Часто встречаются запросы в циклах. Особенно часто они неявные, возникают при вызове программного интерфейса типовых конфигураций в цикле. Иногда пишут свою процедуру/функцию с запросом и используют её потом в цикле. Цикличное обращение к базе данных в несколько раз замедляет работу кода. При количестве итераций более 1000 замедление будет очень заметным!
-- Избыточное использование транзакций (при редактировании формы, к примеру)
-- Неоправданное использование блокировок при выполнении запросов к регистрам накопления. Ведь блокировка нужна только при ОДНОВРЕМЕННОМ обращении нескольких пользователей К ОДНИМ И ТЕМ ЖЕ ДАННЫМ! Но её используют и там, где пользователи жестко разграничены через РЛС. Необходимо на этапе разработки понимать, как будут работать пользователи. Можно по этому вопросу проконсультироваться с архитектором проекта. На всякий случай использовать блокировки НЕЛЬЗЯ!
-- Из неописанного в стандартах разработки. С удивлением для себя обнаружил, что использование следующего кода сильно тормозит работу. В выборке 6000 записей, в таблице, которую обрабатываем 100 000 (сто тысяч). В итоге этот код выполнялся 40 минут!
После того, как данный код был переписан на запрос, заполнение ссылок занимает секунды.
5. В последнюю очередь проверяется группа стандартов "Разработка пользовательских интерфейсов" и "Проектирование интерфейсов 8.3". Список проверок описан в стандартах. Нет цели его здесь повторить. Самое главное это удобное расположение элементов формы, таблиц, команд, итогов. Необходимо располагать самые важные элементы так, чтоб они заполнялись первыми. В табличных частях фиксировать левые колонки, если без прокрутки невозможно просмотреть всю табличную часть. Интерфейс должен быть понятен пользователю и не содержать лишних элементов, которые в текущем сценарии не используются.
6. Без привязки к стандартам проверяю выбранный способ решения задачи. Многие коллеги настолько боятся менять типовые объекты, что копируют их целиком и меняют скопированный объект! В этот момент коллеги забывают, что скопированный объект работает на программном интерфейсе конфигурации, в которой он создан. Если через сколько-то релизов сильно изменят программный интерфейс, то скопированный объект перестанет работать и его придётся обновлять! Так почему не доработать сразу типовой объект?!
Аналогично поступают с некоторыми процедурами общих модулей. Создают новый общий модуль, в него копируют процедуры и функции, которые планируют поменять и там меняют. Ошибочно это по той же причине: как только изменят используемые процедуры и функции в типовой конфигурации, Ваша доработка перестанет работать!
7. Также по коду часто видно, отработаны все сценарии? или разработчик схалтурил и сделал лишь часть работы. Понять это можно, анализируя условия, которые есть в доработанных процедурах и функциях. Часто встречаю, что из нескольких веток условия доработка есть только в одной ветке. А кто остальные будет делать?
8. Очень рекомендую проводить дополнительный (промежуточный) этап проверки Desing review. Этот этап проводится когда разработчик выполнил примерно треть своей работы. Он уже разобрался в коде, который ему требуется менять, уже знает, какие запросы и как будет менять, "накидал", как будет выглядеть интерфейс. Цель этого этапа на старте разработки понять, что разработчик выбрал правильный путь решения с одной стороны, архитектор/аналитик верно поставил задачу с другой стороны.
Главная причина срыва сроков в разработке - не все сценарии учтены. Так это или нет позволяет понять промежуточная проверка. Если мы находим новые сценарии или видим, что текущие описаны неверно, можем сразу об этом сообщить руководству/заказчику, согласовать новые сроки и учесть бОльшее количество сценариев при разработке.
Пройдя все описанные этапы код ревью, пишем кучу замечаний разработчику и заставляем его исправлять свой код, даже если ему кажется, что "оно же работает!".
Остальные части доступны по ссылкам:
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и, главное, как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.
Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Кейс 6. Как разобратьcя и использовать программный интерфейс.
Наверняка часто встречаются разработчики, которые считают, что написать самому запрос к какому-то регистру гораздо проще, чем разбираться в существующих модулях типовых конфигураций. На первый взгляд - ДА! НО! Любой программный интерфейс генерирует с десяток, а иногда и больше временных таблиц. Часто оказывается, что данные одной из временных таблиц ну просто специально для меня написали, чётко под мою задачу! Конечно, не все это знают, не все знают, что вообще есть какой-то программный интерфейс, как его искать и т.д. Вот и разберёмся со следующими вопросами:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
2. Что такое БСП (кратко)?
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
5. Он же изменится. Зачем его использовать, если 1С перепишет его?
Раскроем каждый пункт подробно:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
На самом деле элементарно! Давайте рассмотрим на примере ЗУПа. В ЗУП есть часто используемые разделы:
-- Учет страховых взносов
Остановимся на таком списке. Конечно, разделов гораздо больше. На что надо обратить внимание: На то, что каждый раздел имеет свои Общие модули, и они называются так же, как и раздел учета. Т.е. в любой конфигурации названия общих модулей сделаны очень понятными и соответствуют разделам учета/решаемым задачам.
Здесь необходимо напомнить о стандартах разработки! Согласно стандартов по оформлению общих модулей, секция "Программный интерфейс" должна всегда располагаться вверху общего модуля. Далее следует секция "Служебный программный интерфейс".
Берем штатное расписание. Заходим в основной серверный модуль "УправлениеШтатнымРасписанием". Видим процедуры:
если посмотреть в служебный программный интерфейс, можем найти там довольно полезную функцию:
полезные процедуры можно найти даже в секции "Служебные процедуры и функции". Например, в этом модуле много функций, для построения запросов по штатному расписанию:
или процедуры, которые позволяют получать какие-то данные по позициям штатного расписания:
Если таким образом проанализировать каждый раздел учета, можно обнаружить невероятное количество полезных процедур и функций. Расчет ФОТ - это довольно сложная задача в ЗУП. Написать самому это не получится от слова НИКАК! Она даже запускает "страшный и ужасный" менеджер расчета зарплаты. А здесь всего лишь надо на вход дать правильные данные и система рассчитает ФОТ позиций штатного расписания сама!
Окунувшись в стандарты разработки чуть глубже, станет понятно, что программный интерфейс есть не только в общих модулях. Эта область в коде может присутствовать в модуле менеджера или модуле объекта абсолютно любого объекта метаданных.
Опять же на примере ЗУП обратимся к модулю объекта обработки "Менеджер данных учета времени сотрудников". Здесь есть вот такие полезные процедуры:
Если посмотреть модуль менеджера документа "Больничный лист", можно найти функцию:
На этом перестану переписывать названия процедур и функций в текст статьи. Главное понять принцип, что общие модули, модули объекта и менеджера могут содержать программный интерфейс, который Вам требуется.
Настоятельно рекомендую изучать программный интерфейс того раздела учета, в котором Вам предстоит вести разработку по Вашей задаче. Наверняка много полезного найдёте для себя.
БСП - Библиотека стандартных подсистем. Описывать её функционал, конечно, не стану. Функционал в каком-то виде описан и на сайте ИТС, и на данном ресурсе.
Что важно отметить в этом пункте: Если Вам нужно что-то сделать с таблицей, массивом, файлом, хранилищем значений или ещё с каким-то универсальным механизмом, которым "оборудованы" все конфигурации. ОБЯЗАТЕЛЬНО смотрите в описание БСП. Наверняка Ваша задача уже решена. Осталось с ней разобраться ниже описанными способами, и использовать программный интерфейс в своём коде.
С точки зрения качества кода при использовании как программного интерфейса как типового (имею в виду учетные задачи), так и БСП, Вы шагнёте на новую высоту (это больше, чем на ступень вверх!). На собеседованиях Вам наверняка зададут вопрос о том, знаете ли Вы, что такое БСП, используете программный интерфейс в своём коде или нет?
По себе могу сказать, что половину своих задач решаю именно с помощью программного интерфейса! Лучше я потрачу время на изучение этой темы, чем буду писать никому ненужный код с так себе качеством.
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
Опишу способы которыми пользуюсь сам:
-- Первое, что я делаю - читаю описание процедуры/функции, которое, согласно стандартам разработки, является обязательным для экспортных процедур/функций программного интерфейса модулей. Обычно в нём сухо, коротко описано назначение и тип значения/назначение входящих параметров. Часто уже это описание на 30% даёт понимание, как использовать этот программный интерфейс.
-- Программный интерфейс БСП описан на сайте ИТС и в большом количестве статей. Нужно не полениться воспользоваться поиском и почитать статьи.
-- Следующий шаг - посмотреть, как вызывается программный интерфейс в типовой конфигурации. Бывало, сталкивался с неиспользуемым программным интерфейсом. Таким пользоваться сразу не рекомендую, т.к. наверняка его забыли стереть и скоро это обязательно сделают. На этапе анализа примеров вызова программного интерфейса необходимо обратить внимание на заполнение параметров программного интерфейса.
-- Главное, что помогает мне и обязательно поможет Вам, - отладчик! Найдя место вызова нужного Вам программного интерфейса, нужно изучить, что у него на входе и на выходе. Для этого необходимо:
а. Поставить точку останова в месте вызова программного интерфейса в типовом коде. Конечно, необходимо найти хотя бы одно место, откуда он вызывается. Т.е. какое пользовательское действие приводит к запуску программного интерфейса. Зачастую таких мест много и найти их нетрудно, часто даже можно догадаться.
б. Скопировать весь текст вызова программного интерфейса в свой код, и постепенно адаптировать свой код под параметры интерфейса, чтобы он сработал без ошибок. Данный путь, во-первых, сложней, во-вторых, Вам его всё равно придётся пройти, т.к. адаптация своего кода под программный интерфейс неизбежна, если Вы его хотите использовать. Поэтому обязательно идём по этому пути.
-- В отладчике Вам необходимо посмотреть параметры на вход, тип значения, чем заполнены. Часто необходимо, чтобы в Менеджере временных таблиц уже была временная таблица с определёнными колонками, которая станет "фильтром" для получаемых данных. Отладчик позволяет увидеть, какие данные в этой временной таблице.
ВАЖНО: Опять же напишу - не пытайтесь фантазировать, как выглядит заполненная таблица. Надо найти такой вызов программного интерфейса, чтоб в нём было как можно больше данных и на входе, и на выходе. Иногда полезно несколько мест посмотреть отладчиком.
-- Последним действием необходимо изучить все временные таблицы, которые создал программный интерфейс, и посмотреть на результат его работы. В моей практике нередко бывает, что использую не результирующую таблицу, а несколько промежуточных! Поэтому и надо посмотреть их все. Вдруг наилучшим образом под Вашу задачу подойдёт промежуточная таблица!?
-- После того, как программный интерфейс сработал, не забывайте удалять из менеджера временных таблиц ненужные данные. Особенно если какие-то временные таблицы огромных размеров, т.е. >= 100 тыс. записей.
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
Для ответа на этот вопрос нужно обратиться к стандарту разработки под названием "Структура модуля". В нём указано вот какое описание:
а. Раздел "Программный интерфейс" содержит экспортные процедуры/функции, которые можно вызывать из любых объектов метаданных, в т.ч. через внешнее соединение. Т.е. не важно какую задачу решаете, если есть потребность в использовании процедур/функций этого раздела смело пользуйтесь!
б. Раздел "Служебный программный интерфейс" содержит экспортные процедуры/функции, которые являются частью какой-то подсистемы. Их использование, согласно стандарту, допускается только внутри подсистемы, в которую входит общий модуль или объект конфигурации. Т.е. если мы смотрим служебный программный интерфейс штатного расписания, то эти процедуры не следует использовать в расчете налогов или зарплаты) Да и вряд ли они туда подойдут!
в. Раздел "Служебные процедуры и функции" содержит процедуры/функции, которые используются для реализации программного интерфейса (в т.ч. служебного) данного модуля. Не рекомендуется их использование за рамками модуля, а тем более за рамками подсистемы. Но "не рекомендуется" не означает, что в модуле не могут быть экспортные процедуры/функции. Их необходимо также использовать в рамках подсистемы, в которую входит общий модуль.
Как видно, знание стандартов разработки помогает лучше понимать подходы и принципы, которыми руководствуются разработчики типовых конфигураций и тиражных решений.
5. Он же изменится. Зачем его использовать, если 1С перепишет его?
Помните, мы раньше ТиС 7.7 дорабатывали? А как ЗУП 2.5 или УПП 1.3 в хлам переписывали? Никто ведь не думал в тот момент, что 1С придумает УТ11, ЗУП3, ЕРП2? Всё меняется со временем, поэтому не стоит рассчитывать, что программный интерфейс 1С никогда не поменяет! Но вопрос тут, конечно, не в психологии, а в том, что делать, если программный интерфейс перестал работать!?
Необходимо попробовать следующие действия:
-- Чаще всего меняется состав, назначение или тип значения у переменных, передаваемых в программный интерфейс. Как это понять? Найти место, где этот программный интерфейс используется в типовой конфигурации, и изучить обновлённый состав параметров.
-- Необходимо зайти в модуль, в котором располагается программный интерфейс, и изучить описание самого интерфейса и параметров. Также рекомендую остановиться в общем модуле отладчиком и посмотреть, как теперь он работает, какие данные в нём.
-- Иногда меняются временные таблицы, которые создает программный интерфейс, или убираются/добавляются колонки в основной таблице. Опять же увидеть можно все эти изменения в отладчике. По сути надо повторить путь разбора программного интерфейса, описанный выше.
-- Бывает, что процедура/функция переносится в другой общий модуль. Здесь поможет поиск по всем текстам той, которая перестала работать. Меняем название модуля - опять всё работает.
Делаем вывод: Волка бояться - в лес не ходить! Каждая проблема имеет своё решение. Главное не паниковать, а подумать над этим решением. Варианты постарался описать.
Наверняка многие сталкивались с ситуацией, когда есть сложная задача, её поручили кому-то. А он взял и не справился! И самое приятное в этом - поиск нового исполнителя, того кто справится.
Так вот, если Вы тот самый бедолага, кому прилетела такая задача - этот кейс для Вас!
Сразу напишу, что самое главное, что Вы должны выяснить, - сценарии работы по прилетевшей Вам задаче. Т.е. Вам необходимо найти хотя бы один из источников информации:
1. Техническое задание
2. Список сценариев работы. В грамотных командах этот список составляется ДО начала разработки. Сценарий работы пользователя - это основа для проектирования любого процесса.
3. Консультанта, который выяснял детали и писал какую-то документацию по этой доработке.
4. Можно дать задание консультанту набить тестовых примеров в базу, где Вы планируете вести доработку. По себе знаю, что для программиста вводить тестовые примеры - каторга! Для консультанта - ничего необычного, это его работа. Поэтому для ускорения процесса нужно получить тестовые примеры.
5. Пообщаться с архитектором (если такая опция есть в проекте). Необходимо выяснить максимум того, что не так в выполненной кем-то работе и каковы ожидания.
6. Всё, что удалось выяснить, необходимо ОБЯЗАТЕЛЬНО ЗАПИСАТЬ! Не надо надеяться на свою память. Она Вас точно подведёт!
Как только выяснили постановку, сценарии, ошибки и как должно быть. Срочно начинаем доработку. Какие действия Вам помогут ускориться:
1. Попробуйте выяснить у архитектора правильный путь решения задачи. Как бы он сам делал? Может, даже подскажут, в какие модули надо залезть, и пояснят подход к решению задачи.
3. Если в процессе кодирования столкнулись с непониманием кода. Уже в этой статье много способов в нём разобраться описано. Не стесняйтесь просить более опытных коллег пояснить кусок кода, который непонятен. Не нужно полдня тратить на разбор 10 строк кода.
Итак, коллеги, те, кто дочитал до этого места, начав с первой части, Вы, как и я, проделали огромную работу. Да, это всё теория. Практика всегда менее радужная и занимает время. Прочитав мою статью, Вы не сможете за 5 минут прочесть чужой код. НО! Уверен, мои подходы позволят Вам сократить время на изучение чужого кода. Если кто-то вдруг не обладает такой компетенцией, то статья - хороший старт. Надеюсь, что даже профи с многолетним опытом работы найдут в этой статье для себя что-то новое.
Остальные части доступны по ссылкам:
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
Работаем с коллегой в отделе занимающимся 1с.Оба пишем код, я хорошо понимаю администрирование 1с, а колгега хорошо понимает алгоритмы и пишет качественный код. С недавнего времени стал прикалывать что я пишу быдло код =(. Конечно когда нужно сделать еще вчера то нет времени писать качественно, делаешь просто что бы работало. Но сама мысль не дает теперь покая, как улучшить качество кода ? И есть оправдание быдло коду ?
Хороший код - это когда через пару лет ты читаешь свой код и полностью понимаешь его логику. Плохой код - это когда проще написать заново, чем понять. Хороший код может быть менее эффективным в плане быстродействия и памяти, чем плохой.
(0) это как подтирать попу в туалете, смывать за собой и мыть руки после.
если этого не делаешь, то и код красивый никогда не напишешь.
ИМХО в вашем случае. Есть коллега, который по вашему признанию больший программист, чем вы. И это удача для вас.
В таком случае попросите его выработать (и зафиксировать письменно) критерии хорошего кода для вашей компании (стандарт оформления кода).
И вот теперь ваша главная (на данном этапе обучения) задача - чётко следовать этим договорённостям, регулярно получая обратную связь от коллеги.
Уже на следующем этапе (когда научитесь следовать критерию оформления кода коллег) можно читать умные книги, чтобы выработать свой стиль и возможно привнести его на текущем или следующих местах работы.
(0) шли такого коллегу нах, я бы так и сделал. есть хороший совет таким знатокам - "критикуешь - предлагай, предлагаешь - делай", так вот попроси его написать лучше. а то балаболов много, а кто действительно может нормальный код писать, мало.
(9) настолько оптимальный, насколько это позволяет поставленная задача / возможности встроенного языка?
(0) У меня препод был, преподавал Pascal,
и вот однажды приходим на пару, а он всему взводу одну и туже контрольную дает ВСЕМ! я ему говорю:
-А вы не боитесь что тут по кругу все друг у друга спишут?
на что я получаю ответ:
-Списывайте, НО только я знаю кто и как пишет, и у кого вы спишите тот получи зачет остальные .
и запомни: Сколько хозяек, столько и борщей!
+11 От себя дабавлю, красивого кода НЕТ в природе, так же как нет и совершенства, это понятие субъективное.
Например квадрат Малевича, многие от него тащутся, а лично для меня полное г--о, что там такого выдающегося я не понимаю.
+15 или если нет доступа поиск по ключевым словам :
"система стандартов и методик разработки конфигураций для платформы 1с"
(16) В самом квадрате ничего, а вот то, что художник так хорошо закрасил вызывает восхищение у фантазеров.
(0) Просто читать чужой код - это не панацея. Чужой код тоже может быть быдлокодом. Нужно стремиться писать ХОРОШИЙ код и читать чужой ХОРОШИЙ код.
Вот ещё неплохая книга:
(0) лично вот ты или твой напарник что вкладываете в само понятие: ХОРОШИЙ КОД.
Для кого он хороший? Почему он хороший?
Я думаю, надо разделить понятие хорошего кода на "красивый по оформлению" и "хороший в плане оптимальности". Ибо может быть код оптимальный, написан по всем рекомендациям 1С и гуру, но без абзацев, без пробелов, без форматирования.
А ещё скажу для кого-то крамольную мысль, нужно хорошо понимать идеологию ООП. Когда за любой функцией стоит хотя-бы абстрактный её исполнитель, даже не ООП-код приобретает больше порядка.
А лучше, конечно, умные книжки прочитать. Там уже собрана вся нужная информация. А то пока эти мысли, как жемчужины, соберешь из моря г-овно-кода - глаза задергаются.
блин вот сижу, читаю и прикалываюсь )) как будто тут все прям такой идеальный код пишут, все супер пупер
я иногда свой код читать без успокоительного лекарства не могу ))
БСП сама по себе го-вно-код. Наглядный пример того, как не нужно разрабатывать проекты с большим объемом кода.
(24) до того как вместе стали работать, работали в разных филиалах. И как то пришлось паралельно делать одно и тоже задание, конечный результат которого заполненый ексель файл. Я дописывал за главным программистом код. Он для реализации скопировал типовой документ и сделал в нем, я его дописал. В итоге получили печатную форму, которую копи пастом копировали в ексель. А коллега это сделал обработкой в которой был 1 запрос и все это сразу выгружалось в ексель.
(34) Лена, я тебя просил пожарить яйца, ты их пожарила не разбивая - Антон, формулируй свои желания правильно! (с)
(38) из этой же серии:
Программист не явился на работу. В конторе переполошились, решили его
проведать. Звонили в дверь, звонили - никто не открывает. Из-за двери
только плеск воды слышен. Решили взломать дверь. Заходят и наблюдают
такую картину: сидит программист в ванне, волос на голове почти не
осталось, но он судорожно намыливает голову шампунем. Читают инструкцию
к шампуню:
1 выдавить небольшое количество шампуня на руку.
2 намыливать 2-5 минуты.
3 смыть водой.
3 повторить.
ратую за оптимизацию.
все в угоду экономии и быстродействия. не впитывая чужую мудрость и без собственных экспериментов это невозможно.
поэтому голос раз.
(48) я про тему, опрос похож на вопрос "Как лучше обучить нейронную сеть" ведь ясно что только одним действом дело не выйдет
качественный код существует только на момент написания его разработчиком и со временем, этот код становится все хуже и хуже, который в итоге превращается в г-код.
каждый разработчик проходит эти стадии. можешь почитать что-нибудь, чтобы проскочить на этом пути несколько шагов
(56) мне - нормально, недавно полез исправлять свою поделку на дельфях десятилетней давности, мне все понятно было.
кстати, да
найди и попроси коллег твоего тру-кодера выслать его код, который он на старте писал.
поржёте вместе
(57) Ну дело тут не в понятности. Просто студенческие поделки кишмя кишат велосипедами, проистекающими из незнания темы. После того, как становишься в теме, свои старые проекты прямо руки чешутся переписать правильно. Только лень мешает.
(3) Можно пользоваться деревенским уличным туалетом, биде и делать всё в резиновых одноразовых перчатках. И при этом писать красивый код.
Красивый код - это не только читаемый, но и эффективный.
А еще он должен выполнять свою функцию, а не гонять данные ради красоты.
И еще считаю важным делать проверки на заполненность, на возможность деления на 0, ограничивать ошибки пользователя. В общем, продумывать в алгоритмах наперед что в них может пойти не так.
Плюс красиво работу кода подавать, рисовать интерфейс, строки состояния, вопросы при нажатии на кнопки.
и прочие запросы в циклах.
(63) ссать на пол и при этом писать красивый код - это оксюморон. разруха в голове не бывает частичной.
(0) Код не бывает красивый или некрасивый. С объективной точки зрения, всякий код - убожество (субъективно - код может казаться красивым его автору). Код бывает работающим и не работающим.
(67) есть (два стула, на одном . ) два куска кода.
делают одно и то же, делают это успешно.
первый написан одной процедурой в 1000 строк без комментариев с цикличными неявными чтениями бд по десятку раз за круг, другой оформлен модулем с несколькими точками входа в экспортных процедурах, параметризуются по потребности, повторяемые части кода вынесены в функции, сперва происходит сбор всех необходимых данных, отдельно цикличная математика и блоки условий, постобработка.
какой сам напишешь, какой у коллеги прочитаешь?
Нет единого рецепта.
Меня, например дико раздражают чьи-то переменные названные примерно так :
Параметр
Параметр
Параметр
Видимо, на сях сидел человек когда-то.
ну как так можно вообще..
упс..
форматировался текст в (71)
Имелось в виду параметр, начинающийся с одного, двух , трех или более символов нижнего подчеркивания.
(0) "Как писать качественный код?" - Качественный код писать очень просто: надо писать его качественно! :)
Читайте также: