Как читать чужой код? Часть 4. Программный интерфейс. Исправление чужих доработок
Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и, главное, как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
" Расчет ФОТ - это довольно сложная задача в ЗУП. Написать самому это не получится от слова НИКАК!"
Хорошо, что я в свое время об этом не знал. Взял и написал конфу для расчета ЗП. И не так чтобы сильно сложно было ...
Хорошо, что я в свое время об этом не знал. Взял и написал конфу для расчета ЗП. И не так чтобы сильно сложно было ...
(3) Ты такой не один. Многие на старте освоения программ 1С (особенно в 90-е и начале 2000-ных) прошли путь по написанию какой-либо нетленки. Но контекст данной статья предполагает собственный опыт автора, который по умолчанию категоричен и освещает его подход с попыткой поделиться с нами.
"5. Он же изменится... Зачем его использовать, если 1С перепишет его".. Вот тут не совсем согласен.
В итоге все сводится к тому что сам почти уже и не пишешь , а пытаешься понять логику того кто это написал, НУ а в ЗУП пытаться разобраться как как "оно устроено" и как написать так что бы при обновлении не было головняка - времени займет массу, т.е. зачастую больше если сам напишешь, при этом напряг временем - срочность "вчера".
Особенно доставляет когда БСП категорично написана так что или влезать "ломать код" - что скверно само по себе или придумывать как почесать ухо левой пяткой. Вот потребовалось как то сделать так что бы в Контактную информацию можно было добавить еще одно поле четко увязанное с видом адреса, для каждого вида свое. Та я вам скажу задача. БСП трогать нельзя.
Использование экспортных процедур и функций из общих модуле это прекрасно. Однако был опыт когда Бухам срочно нужно было обновится, иначе они отчетность не могли сдать, но после обновление все (!!!) самописные отчеты просто перестали работать из за любимого сюрприза 1с - кучу функций и процедуру или переименовали или изменили работу, в итоге все у бухов встало колом.
Так что хорошим тоном считается делать "самонесущие" сложные отчеты которые будут работать сами по себе . Кончено без фанатизма и в каждом случае нужно разбираться. Но сложные отчеты лучше делать без использования общих модулей (если они только не свои собственные) и без использования всяких сторонних библиотек. А то рискуешь нарваться на то что отчет не просто не работает, а работает с "плавающией" ошибкой, которая фиг его знает по какой причине появляется и не всегда А что там было 2-3 года назад уже и никто и не помнит.
В итоге все сводится к тому что сам почти уже и не пишешь , а пытаешься понять логику того кто это написал, НУ а в ЗУП пытаться разобраться как как "оно устроено" и как написать так что бы при обновлении не было головняка - времени займет массу, т.е. зачастую больше если сам напишешь, при этом напряг временем - срочность "вчера".
Особенно доставляет когда БСП категорично написана так что или влезать "ломать код" - что скверно само по себе или придумывать как почесать ухо левой пяткой. Вот потребовалось как то сделать так что бы в Контактную информацию можно было добавить еще одно поле четко увязанное с видом адреса, для каждого вида свое. Та я вам скажу задача. БСП трогать нельзя.
Использование экспортных процедур и функций из общих модуле это прекрасно. Однако был опыт когда Бухам срочно нужно было обновится, иначе они отчетность не могли сдать, но после обновление все (!!!) самописные отчеты просто перестали работать из за любимого сюрприза 1с - кучу функций и процедуру или переименовали или изменили работу, в итоге все у бухов встало колом.
Так что хорошим тоном считается делать "самонесущие" сложные отчеты которые будут работать сами по себе . Кончено без фанатизма и в каждом случае нужно разбираться. Но сложные отчеты лучше делать без использования общих модулей (если они только не свои собственные) и без использования всяких сторонних библиотек. А то рискуешь нарваться на то что отчет не просто не работает, а работает с "плавающией" ошибкой, которая фиг его знает по какой причине появляется и не всегда А что там было 2-3 года назад уже и никто и не помнит.
(8)
Мои статьи написаны ровно для того, чтоб несогласных становилось меньше, чтоб не было сложностей при обновлении (подходы описаны во второй статье). И вообще чтоб не было проблем с кодом.
Единственное, с чем согласен из Вашего поста - не стоит трогать БСП.
С остальными вопросами у меня не возникает сложностей. Мой профиль именно ЗУП! И всегда получается и разобраться и доработать и обновить потом.
Вот тут не совсем согласен.
Мои статьи написаны ровно для того, чтоб несогласных становилось меньше, чтоб не было сложностей при обновлении (подходы описаны во второй статье). И вообще чтоб не было проблем с кодом.
Единственное, с чем согласен из Вашего поста - не стоит трогать БСП.
С остальными вопросами у меня не возникает сложностей. Мой профиль именно ЗУП! И всегда получается и разобраться и доработать и обновить потом.