Принципы разработки

Публикация № 1205430

Методология - Рефакторинг и качество кода

принципы разработка KISS YAGNI DRY Boy-Scout-Rule

Доброго дня и хорошего кода, коллега.

Следование этим принципам позволяет писать код, который мы все так любим:

- он легко читается

- он хорошо дорабатывается

- он минимально и в нужных местах документирован

- он отказоустойчивый

- он работает, и (возможно) работает быстро

 

Code For The Maintainer

Это основное правило и лейтмотив данной статьи: пиши код для того, кто будет его поддерживать.

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

Сюда же можно отнести принципы "Don’t make me think" (если код требует слишком много осмысливания от не-автора, то возможно он нуждается в упрощении) и "Principle of least astonishment" (код должен удивлять его пользователя наименьшим из возможных образом: соответствовать комментариям и названиям методов\полей, и эффект удивления от использования кода внешним пользователем должен быть сведен до возможного минимума)

KISS = "Keep It Simple Stupid"

Решать проблему самым простым путем. 

Идеал достигается не тогда, когда нечего добавить, а когда нечего убрать.

YAGNI = "You Aren't Gonna Need It"

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

DRY = "Don't Repeat Yourself"

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

Avoid Premature Optimization

Сложно определить заранее место образования узких мест, поэтому следует избегать преждевременной оптимизации

Следуй правилу "Make It Work Make It Right Make It Fast": иди от рабочего кода к правильному рабочему коду и, если это действительно требуется, к быстрому правильному рабочему коду.

Robustness Principle

Мягкий снаружи, твердый внутри.

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

Boy-Scout Rule

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

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

 

На основе статьи "The Principles of Good Programming" by Christopher Diggins

Конструктивные замечания и комментарии всегда приветствуются.

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. l_men 14 04.03.20 08:26 Сейчас в теме
Побаяню: "Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте" © C. McConnell
Terve!R; wolfsoft; Batman; DoctorRoza; Seaflame; Interrupted; AlexK_2012; vv2; wowik; +9 Ответить
3. artms 205 04.03.20 09:24 Сейчас в теме
(1) Хороший код писать важно и нужно, но не нужно это превращать религию (или самоцель), с библией "Совершенный код", потому что 90% проектов маленькие проекты где принцип Фэйл Фаст Фэйл Чип, что важнее этой религии.

(Из 90% проектов, выгорает только каждый 10 и в них уже в результате роста требуется командная разработка согласно правилам. И не нужно добавлять на каждое "Если" "Иначе" потому что этого просит McConnell)
4. l_men 14 04.03.20 09:38 Сейчас в теме
(3) Я думаю тут надо относиться как к пиратскому кодексу - это всего лишь свод указаний как писать качественный, легко читаемый и в дальнейшем поддерживаемый код. Честно признаюсь - сам иногда грешу написанием "костылей"))
wolfsoft; +1 Ответить
6. herfis 346 04.03.20 12:03 Сейчас в теме
(3) Стратегия
Фэйл Фаст Фэйл Чип
не имеет никакого отношения к качеству кода. Это просто стратегия обработки ошибок.
8. artms 205 04.03.20 13:14 Сейчас в теме
(6) Прямое отношение, поскольку, в жертву скорости реализации продукта, отлаживается все вопросы на потом, включая приведение в порядок кода. Основная задача стратегии "Фэйл Фаст Фэйл Чип" его работоспособность, все равно код скорей всего заменят, если продукт заработает, а нужно проверить работоспособность продукта, который скорей всего и не запустят вообще.
В итоге в такой программе идет частое дублирование кусков, закомментированный код, волшебные числа и т.д. Эти ошибки явно не соответствую никаким стандартам разработки и являются не качественным кодом, являющийся последствием этой стратегии.
11. herfis 346 04.03.20 13:47 Сейчас в теме
(8) И где же мне прочитать про то, что
частое дублирование кусков, закомментированный код, волшебные числа и т.д.

являются частью концепции fast fail?
Пока что мне это видится вашей вольной экстраполяцией.
13. artms 205 04.03.20 15:48 Сейчас в теме
(11) В прямую не описано в стратегии, но это прямое следствие, где в приоритете скорость над качеством https://habr.com/ru/company/funcorp/blog/455938/.

На начальных стадиях разработки игнорирование качества кода оказывается более эффективно, чем следование высоким стандартам.
14. herfis 346 04.03.20 16:23 Сейчас в теме
(13) Не увидел по приведенной ссылке ничего про fail-fast.
Вот про fail-fast: https://en.wikipedia.org/wiki/Fail-fast
И я не вижу там ничего про "тяп-ляп".
Вот статья "по мотивам" на хабре: https://habr.com/ru/post/218325/
И я опять не вижу там ничего про "тяп-ляп".
15. artms 205 04.03.20 16:33 Сейчас в теме
(14) А где Фэйл Чип?
Где стоимость https://habr.com/ru/post/218325/ в этой статье? (автор просто выбрал заставку покрасивее, но не слова о дешевизне)

Удивительно как мало источников по данной теме:
https://www.dp.ru/a/2017/01/17/Ne_sdavajsja_no_menjaj_nap
(описание принципа из источника не достойного доверия)
24. AlexO 128 07.03.20 11:22 Сейчас в теме
(15)вы ему про обработку ошибок и её первоочередную значимость (сразу после грамотного анализа и проектирования структуры), а он вам - "не, не увидел такого", "не, нет такого", "не, не похоже", "не, тут перевод другой".
23. AlexO 128 07.03.20 11:20 Сейчас в теме
(6)
не имеет никакого отношения к качеству кода. Это просто стратегия обработки ошибок.
Имеет прямое - к "наполнению" кода, отсюда и к его "качеству".
И именно с обработкой ошибок - у 1С (и, как следствие, одноэсников) - очень и очень большие проблемы.
Вот и для вас это вообще не вопрос - никакого отношения не имеет, и точка.
2. wowik 737 04.03.20 09:22 Сейчас в теме
"Написанию кода, который дешево поддерживать, нужно учиться" - золотые слова! напомнило) - https://infostart.ru/public/1195044/
5. PLAstic 247 04.03.20 12:00 Сейчас в теме
Статей на эту тему много на ИСе. Не могу выделить для себя каких-то новых моментов. Даже считаю странным призыв "писать проще" и удобнее для поддержки/модификации.
Недавно рефакторил код коллеги. Он запросом получал то, что мог, а потом в цикле ещё тремя запросами получал то, что не смог в основном. Запросами(!) в цикле, Карл! Ну, соединил я всё это хозяйство в один запрос, ну, получил результат, который просто залить в нужную ТЧ и всё. Что я слышу от коллеги? "Ну я специально разделил всё на части, чтобы было проще и легче вносить изменения". Мне-то самому не сложно поддерживать и далее получившийся запрос, моих мозгов на это хватает. А за других не скажу. Вдруг им сложно? И что, тогда мне оставлять три запроса в цикле? Ведь так проще по словам коллеги.
Всё относительно и описывается этот процесс намного более сложно и объёмно, чем тезисы из оригинальной статьи.

Я для себя лет 15 назад сформулировал принцип, что писать надо так, чтобы тебе было не стыдно потом объяснять эксперту, которого пригласил заказчик, почему ты сделал так или иначе. Этого принципа в тексте статьи не нашёл.
20. FreeArcher 91 05.03.20 05:57 Сейчас в теме
(5) Это принцип - моя хата с краю.
Все ведь зависит от ситуации, и то, что запрос в цикле это зло нам привили экзамены на спеца. Цикл может быть очень короткий, и запрос в цикле может очень сильно разгрузить логику запроса.

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

Если абстрагироваться от ситуации: есть программисты, которые любят писать сложно, выставляют на показ свои знания, объясняют все требования производительности. Но потом разбираться в их коде очень сложно. Т.е. сначала они тратят в 2 раза больше времени на код, а затем тот, кто будет вносить изменения потратит больше времени. Т.е. один и тот же результат будет стоить дороже. А это никому не нужно.

Собственно принципы в статье и пытаются донести такую мысль.

Я вот тоже проходил этап, когда мне хотелось писать круто и сложно. Но потом сам однажды попал в ситуации, когда очень долго разбирался со своим же запросом. С тех пор я перестал переусложнять код. Сложные расчеты стал предпочитать выносить из запроса, запрос только для получения данные и не более.
Terve!R; AlexO; +2 Ответить
21. PLAstic 247 05.03.20 09:01 Сейчас в теме
(20) Т.е. даже не зная текста запроса вы занимаете позицию, что он сложный, и предлагаете тупеть до какого-то среднего уровня по рынку? Когда запрос начинает быть сложным? Я написал его примерно за полчаса погружения в подсистему, которую разрабатывал мой коллега. Представим уровень мой и коллеги от 1 до 5, как в школе. Итак, разные кейсы:
1) у нас 5 и 2 соответственно;
2) у нас 2 и 1;
3) 3 и 5 (именно так).
Подозреваю, описанный вами кейс выше - это п.3. Но что делать в других случаях, когда коллега, например, просто недалёкий? Похоже, в вашем ответе возникает куча "если".
25. AlexO 128 07.03.20 11:31 Сейчас в теме
(5)
Запросами(!) в цикле, Карл!
Потому что 1С принуждает к этому, не давая более свободных инструментов в синтаксисе. Да, это нехорошо, но тут больше вопрос к вендору - "а зачем вынуждаешь?"
(5)
"Ну я специально разделил всё на части, чтобы было проще и легче вносить изменения".
Вынесите формирование текста в три разные функции. И будете и одним запросом, и в трех разных частях.
Вот уж проблему нашли - правильно код разместить.
(5)
Я для себя лет 15 назад сформулировал принцип, что писать надо так, чтобы тебе было не стыдно потом объяснять эксперту, которого пригласил заказчик, почему ты сделал так или иначе.
Ну и кто объяснять будет эксперту? Вы - по всем конфигурациям и по всему написанному коду?
Суть не "кто объяснять будет", и что "мне не стыдно объяснить", а суть - чтобы через 15 лет поняли, чего вы тут понаписали, и зачем.
Так что навряд ли вы через 15 лет будете свой код объяснять.
7. herfis 346 04.03.20 12:07 Сейчас в теме
Причем даже если считать, что говнокод будет автоматически обеспечивать "фэйл фаст" (что вовсе не факт, учитывая говнокодские попытки/исключения и отсутствие стратегии как таковой), то уж с "фэйл чип" говнокод не дружит изначально.
Грамотное использование этой стратегии (как и любой другой) плохо сочетается с некачественным кодом.
Vladimir Litvinenko; +1 Ответить
9. ImHunter 174 04.03.20 13:25 Сейчас в теме
Ну все, щас все прочитают волшебные слова KISS YAGNI DRY Boy-Scout-Rule - и количество говнокода резко уменьшится. Ура, товарищи!
10. ImHunter 174 04.03.20 13:44 Сейчас в теме
Меня жутко раздражают подобные статьи на пол-страницы.
Все эти принципы сами по себе замечательны. Но работают только в двух случаях.
1. Когда разработчик сам хочет развиваться. Для этого он много читает, думает и кодит. И тут рекламные статьи - не помощник.
2. Когда есть тот, кто говнокодеру систематически мозги вправляет. А тут говнокодеру не до рекламных статей.
PLAstic; herfis; +2 Ответить
12. herfis 346 04.03.20 13:49 Сейчас в теме
(10) Полностью согласен. Сам раньше выступал с подобной критикой. Все, кто до этого уже сам дорос - важно кивают и хвалят. А у остальных пока другие проблемы. Чтобы код в принципе как-то заработал :)
18. Правдин 37 04.03.20 17:59 Сейчас в теме
(10) А где Вы увидели рекламу?
16. herfis 346 04.03.20 16:47 Сейчас в теме
Именно в такой комбинации (c fail cheap) обычно упоминают этот принцип в бизнес-кругах, а не в программировании, где он имеет несколько другой смысл.
Но в программирования fail cheap может автоматически вытекать из fail-fast. Из известной зависимости между стадией обнаружения ошибки и стоимостью ее исправления. Это раз. Во вторых, разработка грамотных fail-tolerance систем сложнее и должна быть оправдана.

Так-то я не возражаю против принципа, когда на скорую руку клепается прототип без соблюдения канонов качества. В некоторых случаях этот подход эффективен для бизнеса. Но не надо устраивать "бородино" и валить все в одну кучу. fail-fast - не про это.
Только вот в 1С "безудержное прототипирование" применять противопоказано. Потому что хрен кто даст время и средства на выбрасывание рабочего прототипа и полное его переписывание. А это автоматически означает, что "выстреливший" прототип очень быстро превратится в неподдерживаемого монстра, переписывать который встанет очень дорого. Потому что основная сфера применения 1С - это "кровавый энтерпрайз" в его наихудшей ипостаси, а вовсе не модные микросервисы или аккуратный FDD. Вот и считай - дешевле в итоге получится бизнесу или дороже.
Vladimir Litvinenko; +1 Ответить
17. aha_ 04.03.20 17:54 Сейчас в теме
(16) Абсолютно согласен с автором. Более того, складывается ощущение, что прототипирование уже применяется в том числе и при разработке ряда типовых решений, знакомство с которыми порой навевает ощущение, что лидерами развития стало "поколение ЕГЭ", иногда находящееся в стороне от фундаментальных знаний и стремящееся вновь изобрести паровоз.
19. Vladimir Litvinenko 2227 04.03.20 19:29 Сейчас в теме
(16)
в 1С "безудержное прототипирование" применять противопоказано. Потому что хрен кто даст время и средства на выбрасывание рабочего прототипа и полное его переписывание.

В других языках программирования аналогично. Поэтому в западном корпоративном сегменте, медицине, автомобилестроении так и не прижились языки для RAD разработки (не среды, а именно языки), предполагающие путь "сначала написать MVP" а затем переделать под надёжную систему. Никто не даёт выбрасывать MVP, а требует развивать. Но это по факту оказывается невозможно и проект тупо закрывают, если нет вагона денег от других направлений бизнеса на постоянный фикс багов.

В последние пять лет много пишут про активный отказ от языков без строгой типизации в областях, где раньше им пророчили быстрый захват рынка и "быстрое решение бизнес-задач", так как программисту не нужно думать над "лишним" и поэтому он конечно думает о бизнесе ;)

Самое неприятное - попасть на проект, который писался как MVP а теперь надо запустить на полную катушку. Сказать "надо всё переписать" - сочтут за безумного Д`Артаньяна в белом пальто. Не сказать что "надо всё переписать" - значит гарантировано похоронить систему. А если согласятся переписать, то шанс похоронить всё равно очень велик, да ещё и пальцем покажут, как на того кто всё же решил переписывать ))

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

Про языки программирования и про "быструю" разработку корпоративных решений кстати интересные видео есть:
https://www.youtube.com/watch?v=Z-4MlKDxpwM
https://www.youtube.com/watch?v=1bhvP1CZI5A
Terve!R; acanta; +2 Ответить
22. capitan 1500 05.03.20 20:29 Сейчас в теме
Чужой код
Меня недавно спросили, почему программисты ненавидят работать с чужим кодом. Долго думал, как донести до обычного пользователя всю суть pdtpца.
Решил привести небольшую аналогию:

Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
— Как так–то, ,kzbь! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что–то в проекте менял?

— Немного, швабры вынес...
— Швабры потолок держали!
— Что??? Что, kzbь, извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.

— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его, kzbь, демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик kzbьдских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.

— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и kzbьайте!
© https://it.d3.ru/chuzhoi-kod-1555085

Есть стиль написания кода, его нужно и можно совершенствовать, а есть логика разработки, она иногда вообще от программиста не зависит.
AlanisV; Fominro; +2 Ответить
26. VKuser296681124 07.03.20 19:28 Сейчас в теме
27. sulfur17 35 09.03.20 20:35 Сейчас в теме
Вместо строки может прийти число, а в массиве не окажется значений, и код обязан отработать это без падений.

А как он может отработать без падений?
Это в любом случае непредусмотренная ситуация, вот и пусть код выбросит исключение.
Мы этим и пользователю сообщим об ошибке, и выполнение прервем, и в ЖР и технологический журнал запишем много диагностической информации.
Даже в ИТС есть рекомендация не стесняться выбрасывать исключение в таких случаях.
Оставьте свое сообщение

См. также

Рефакторинг в редакторе модулей

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Рефакторинг и качество кода

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье не рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    2327    pparshin    2       

Готовые переносы данных из различных конфигураций 1C Промо

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

Качество кода: Поведенческие паттерны проектирования

Статья Программист Нет файла v8 Бесплатно (free) Рефакторинг и качество кода

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    4380    ivanov660    0       

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Статья Программист Стажер Нет файла v8::Запросы 1cv8.cf Бесплатно (free) Рефакторинг и качество кода

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

02.03.2020    3785    aximo    35       

Онлайн-курс «Автоматизация процессов управления МТО: методика сбора и формализации требований» с 1 апреля по 13 мая 2020 года. Промо

Цель курса - повысить полноту и качество сбора и формализации требований к автоматизации процессов управления материально-техническим обеспечением. Курс основан на процессном подходе, позволяет в полном объеме выявить и учесть все факторы, влияющие на специфику процессов управления МТО. Участники курса получают теоретические знания в области организации процессов управления МТО и готовый инструментарий для сбора и формализации требований по автоматизации этих процессов (шаблоны, опросники, модели).

40000 рублей

Качество кода: слабое связывание и высокая сопряженность (Low coupling and High Cohesion)

Статья Программист Нет файла Бесплатно (free) Рефакторинг и качество кода

Поговорим о некоторых общепринятых подходах и принципах разработки кода.

10.02.2020    5526    ivanov660    90       

Как управлять качеством кода 1С, используя платформу SonarQube

Статья Программист Нет файла Бесплатно (free) Рефакторинг и качество кода Инструментарий разработчика

При быстром росте функциональности проводить визуальный Code-Review для обнаружения некачественного кода проблематично. О том, как автоматизировать проверку качества кода 1С с помощью платформы SonarQube на конференции Infostart Event 2019 Inception рассказал ведущий разработчик компании «Командор» Олег Тымко.

30.12.2019    5420    olegtymko    9       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Стабильность превыше всего

Статья Программист Нет файла v8 Бесплатно (free) Рефакторинг и качество кода

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    7355    YPermitin    40       

Оценка скорости кода. Сложность алгоритма

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Практика программирования Рефакторинг и качество кода

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    3504    m-rv    10       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Управление качеством кода

Статья Программист Руководитель проекта Нет файла v8 Бесплатно (free) Математика и алгоритмы Рефакторинг и качество кода

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    12730    Stepa86    33       

Как завести у себя в команде код-ревью. Отвечаем на вопросы

Статья Программист Нет файла Бесплатно (free) Рефакторинг и качество кода

Дадим советы как начать использовать у себя в команде код-ревью (code-review), а также ответим на вопросы читателей.

17.07.2019    7023    ivanov660    29       

1C:Предприятие для программистов: Расчетные задачи (зарплата). Онлайн-интенсив с 01 по 17 июня 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для автоматизации периодических расчетов, а именно - для расчета зарплаты. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Зарплата и управление персоналом” и прочих прикладных решений, в которых реализован функционал расчета зарплаты.

4900 рублей

По следам код-ревью

Статья Программист Стажер Нет файла v8 Бесплатно (free) Рефакторинг и качество кода

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

09.07.2019    10020    ivanov660    110       

Что такое рефакторинг и в чем его цели

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Рефакторинг и качество кода

Что такое рефакторинг, и в каких случаях им стоит заниматься? Евгений Шумилов дает ответы на эти вопросы, а также рассказывает о признаках хорошего и плохого кода. Кроме того, в статье приведены основные проблемы рефакторинга и способы их решения.

30.10.2018    8020    eu_genij    34       

Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо

На курсе вы получите практические навыки решения задач производительности 1С, в том числе характерных для высоконагруженных информационных систем (более 1000 пользователей). Подготовка к экзамену – только одна из составляющих курса. 70% слушателей приходят за знаниями, которые позволят расти и зарабатывать, делать сложные задачи на крупных проектах.

16450 рублей

Учебный курс. Повышение качества разработки. Ошибки программы

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы Рефакторинг и качество кода

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекции № 3,4,5. Эти лекции посвящены ошибкам программ, их классификации и способам исправления

10.07.2018    17770    Артано    92       

Как писать неподдерживаемый код

Статья Программист Нет файла Бесплатно (free) Практика программирования Рефакторинг и качество кода

Вы хотите чтобы Вы были самым ценным сотрудником компании? Чтобы Вас носили на руках? Тогда эта статья для Вас. Эти знания передаются из поколения в поколение и представляют особую ценность в умелых руках.

25.08.2015    21851    vandalsvq    61       

Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 20 апреля по 15 мая 2020 года. Промо

Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом

9000 рублей

Типичные ошибки, некоторые вопросы качества и эффективности работы при разработке в 1С

Статья Программист Нет файла Windows Бесплатно (free) Практика программирования Рефакторинг и качество кода

В этой статье мы приведем набор типичных и часто встречающихся ошибок при разработке в 1С (скорее всего особенно актуально для начинающих программистов). Предложим набор советов и рекомендаций по улучшению качества кода и работы при использовании типового инструментария. Это первая часть из 24 пунктов. Бонусом к каждому пункту мы привели разъяснения и комментарии.

15.02.2015    22264    ivanov660    40       

Как повысить качество разработки своих проектов под 1С?

Статья Программист Нет файла Бесплатно (free) Управление проектом Рефакторинг и качество кода

Здравствуйте уважаемые коллеги. Мы – небольшое франчайзи (4 человека), которое занимается разработкой под 1С вот уже более 2х лет. После первого года работы возникли некоторые проблемы с качеством кода, поскольку начался стремительный рост сложности проектов и, соответственно, начало появляться большое количество неприятных ошибок. В статье я постараюсь рассказать о тех мерах, которые мы приняли для повышения производительности труда программиста и качества написанного им кода. Кому интересно прошу под кат.

11.03.2013    24534    akomar    80       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Мастер-класс от Poppy (практикум по рефакторингу)

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Практика программирования Рефакторинг и качество кода

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

04.11.2008    17458    poppy    32       

Основы менеджмента кода в 1С

Статья Программист Нет файла Россия Бесплатно (free) Математика и алгоритмы Практика программирования Рефакторинг и качество кода

Продолжаем тему рефакторинга, начатую на примере "Глокой Куздры" Итак, каковы основные принципы поддержания кода в рабочем состоянии?

17.10.2008    30780    keleg    194