🎓 Ценность для бизнеса vs. Хороший код

ЦенностьДляБизнеса + ПлохойКод = ОтличныйПродуктСегодня

ЦенностьДляБизнеса + ХорошийКод = ОтличныйПродуктЗавтра

ОтсутствиеЦенности + КодЛюбогоКачества = ВсегдаПлохойПродукт

(c) Константин Кудряшов aka everzet (автор Behat), из презентации Moving Avay From Legacy Code with BDD

#BDD #Тестирование

🛩 Скрамгайд от Сибирикса

Красиво сверстаное пособие по терминологии Скрама. Инфографика прикольная.

https://blog.sibirix.ru/2018/10/31/scrumguide-all/

#говнокод #codesmells

💩 Полуночная неожиданость

Традиционно перед выходными собрался посвятить часик-два кодотерапии и, предвкушая удовольствие от процесса написания чего-то интересного для души, заварил кофе. А пока заваривается, решил бегло посмотреть, что там сегодня сдал разработчик.

И вот уже кофе остыл, а я сижу и пытаюсь сформулировать замечание так, чтобы
а) разработчик понял и признал, что это проблема и больше такого не повторял ("Ну работает же и сдано в срок.")
б) не воспринял замечание на личный счет и не обидился ("Не первый год программированием деньги зашибаю, а ты тут мне умничаешь.");

И в такие минуты понимаешь, что гораздо лучше, когда такие "детские" ошибки отлавливает бездушный линтер/статический анализатор: и тебе не нужно перелопачивать эти какашки, и разработчику не на кого будет обижаться.

Это, конечно, сложнее учесть в составе ROI от использования инструмента, но интуиция мне подсказывает, что в масштабах большой компании здоровье коллектива и отдельных ведущих специалистов тоже неплохо может окупить 780К, а то и больше за инструмент.

#говнокод #codesmells

😜 1C:EDT vs VSC vs Конфигуратор vs ST3

Disclaimer. Это провокация :)

Несмотря на то, что везде открыты одни и те же исходники (УНФ), сравнение безусловно не честное: нельзя сравнивать текстовые редакторы практически без обвеса и IDE, в которой выполняется проверка конфигурации и куча всего.

К вопросу потребления оперативы редакторами с учетом "обвеса": в ST3 установлены плагины Package Control и BSL, в VSC аналогичный плагин BSL + плагин для подсветки фиче-файлов на Gherkin'е. VSC, кстати, еще и несколько процессов запускает (такая вот архитектурная особенность).

В ST3 я один раз запускал глобальный поиск по файлам. В VSC просто открыл один модуль. В EDT был сделан импорт конфигурации из репозитория и сделан один коммит.

#EDT

#анонс #инфостарт

Хотел рассказать про то, как можно быстро решить проблему неработоспособного SOAP в 1С с помощью промежуточного сервиса. Писал пост, вылилось в статью :)

Прошу читать и может быть даже лайкать.
https://infostart.ru/public/965259/

P.S. Если у кого будут вопросы по поводу TypeScript - ловите меня в чатиках, обсудим сложности реализации и поноем вместе, что соап в 1с - не торт.

Знатный наброс!

📺 Борис Нуралиев: Как автоматизировать бизнес @ AmoConf

https://youtu.be/4FT8Rn9YrkQ (via @v8std)

Ничего нового для тех, кто варится в экосистеме 1С, но интересно с точки зрения понимания, как сейчас позиционирует себя фирма 1С. Ну и неплохой пример, как рассказывать о возможностях 1С на сквозном примере (сейлзам на заметку). Конечно, все слишком идеально и просто, но как высокоуровневый позитивный сценарий - ОК.

Большое отступление. Часто слышна критика в адрес БГ и докладчиков из компании 1С в целом насчет того, что на слайдах "многобукв". А с другой стороны недавно активно в FB и в одном канале про ИТ-конференции обсуждалось, что публиковать презентации после конференции — моветон, ведь в них только красивые слайды, и в отрыве от того, что говорит докладчик, все равно ничего не понятно.

Но у 1С как раз презентации — самодостаточный материал, из которого без докладчика можно прочитать тезисы и полезные данные и в целом она дает понимание, о чем была речь и куда смотреть дальше по теме.

И да, наверное, если объединить две мысли в одну, то получится, что в идеале:
— для выступления на сцене нужна версия презентации, где много красивых картинок-якорей и мало текста;
— для выкладывания в качестве доп. материала нужна "скучная" версия презентации, как у БГ, где много букв по делу.

🍕 #ZeroBugPolicy в ДоДо Пицца

Саму пиццерию не люблю по личным мотивам, но отдел ИТ у них крутой (ну и Овчинников молодец).

Баг, который не чинится и не напоминает о себе месяцами действительно не имеет смысла исправлять, это вроде как на уровне здравого смысла. А вот табличка приоритезации в статье отличная.

https://facebook.com/notes/dodo-pizza-engineering/zerobugpolicy-или-как-мы-баги-чиним/1446732912129727/

Что думаете о таком прогнозе?

Кстати. Абсолютно незамеченной прошла новость о том, что ВТБ Капитал сместил с поста гендиректора компании Техносерв её основателя и совладельца, одного из бартьев Ананьевых. А Техносерв на минуточку, это крупнейший в России и частный системный интегратор. О как.

Техносерв кончено же не Магнит - на сервисные ИТ-компании по большому счету всем наплевать (пока все работает), поэтому новость заметили только те, кто разивается на этом рынке ИТ-услуг. Да и то не все.

О чем эта новость? Да все о том же… о тихой наионализации крупного бизнеса в стране. Первая ласточка национализации прилетела и в ИТ. сейчас на Техносерве откатают процессы. И… кто будет следующим? ))

Вангую желтую компанию ))

🔥 GitRules — мерж правил обмена КД2 без боли

На прошлой неделе в чатике @ssl1c был бурный спор КД3 vs КД2 и среди прочих аргументов против Конвертации данных 2 была также названа сложность коллективной разработки. Да, когда-то это действительно было проблемой прежде всего из-за того, что XML-файлы сложно мержить инструментами для мержа исходного кода.

Так вот, на самом деле проблема относительно давно решена, но многие об этом еще не знают. Рассказываю.

Есть крутой инструмент — GitRules (ссылка ниже), написанный конечно же на OScript и который разбирает xml-дерево правил обмена на атомарные составляющие и сохраняет их в виде иерархии каталогов и файлов. Естественно, умеет и обратно собирать разобранные в структуру файловой системы правила. Благорадя этому разные версии можно легко сравнивать/объединять без боли универсальными инструментами типа kdiff3, WinMerge, Meld и т.п. и в строенный в git алгоритм мержа отлично будет работать.

Не используете Git и не знаете, нужен ли GitRules вам? Меня он очень сильно выручал не раз в ситуациях, когда нам заказчик возвращал правила "вот мы тут кое-что сами запилили, но не смогли полностью, пожалуйста, помогите доделать". Сравнение/объединение правил встроенными средствами Конвертации данных 2.0 не удобно, не все изменения видит, да еще и не умеет объединять исходный код скриптов, а с GitRules + любой из перечисленных выше инструментов для мержа это вообще не проблема.

Очень рекомендую, а авторам и контрибуторам GitRules и ExchangeRules1C (см. ниже *), огромное спасибо и большущий респект!

Ссылка на инструмент: https://github.com/otymko/gitrules

В readme репозитория исчерпывающая инструкция, но к этому есть еще и статьи про организацию процесса разработки и версионирование правил обмена:

— Версионирование правил обмена в Git — статья на ИС от автора ExchangeRules1C (Никита Коротаев aka bf0rce)
— Повышаем эффективность разработки правил обмена — статья от разработчика GitRules, Олега Тымко (aka @otymko)

* https://github.com/bf0rce/ExchangeRules1C — я точно не знаю, но, вероятно, это прародитель GitRules. Пытаясь решить проблему объединения правил первый раз я нашел и использовал сначала именно его. GitRules, судя по дате публикации, появился позже, но рекомендую к использованию именно GitRules в виду того, что это - полноценный инструмент командной строки, в то время как ExchangeRules1C это не один скрипт, а набор скриптов, без командного интерфейса (нужно файл правил размещать в исполняемой директории скрипта) и работает только под Windows (использует Microsoft XML Parser).

#Инструменты

🤓 Дублирование кода vs dependency hell

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

Особенно, когда мы создаем огромную сложность, абстрагируя код, который просто похож на другой.
— Sam Ferree

Зачастили последнее время подобные высказывания разработчиков в соцсетях.

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

Сегодня это часто приводит к dependency hell, что является другой крайностью. Правда, конечно же, посередине, а рулит к ней, как всегда, здравый смысл, но есть ли он у юных падаванов?

Let's the holywar begin! 😈

Давайте попробуем еще раз прогуляться по истории
FuncTest 7.7 - 2003+ год
FuncTest 8 - 2006+ год
xUnitFor1C 3-тья редакция - 2010+
xUnitFor1C 4-тая редакция 2012+
cuke4onec - vanessa-behavior - 2012+
vanessa-automation-driven-development (ADD) - 2016+

Поэтому Vanessa Automantion Driven Development имеет 5-тую редакцию - это прямая отсылка к исходным продуктам.

Вопрос - когда появились дымовые тесты ? Ответ: На мой взгляд в 2003 году, потому как я первый раз их увидел еще в проекте FuncTest 7.7
Другой вопрос - текущая реализация - кто её автор ? Во первых - дымовых тестов существует 2 реализации: в TDD и BDD стиле - кто их автор. Точно кто-то из контрибьюторов

Однажды я уже писал это в статье на Хабре.

Просьба всем кто не в курсе - на досуге изучить историю развития. Тогда не будет непонимания.

Статья на Хабре - вот эта https://habr.com/post/252473/

Скриншот оттуда

Хз, кому это надо, но для потомков немного уточню, а тут чат протестирование, так что в тему :-), тем более 1СUnit/xUnitFor1C — первый популярный репозиторий на 1С на github'е.

В интервале с 2010-2011 был SnowTest Федора Езеева, написанный во времена его работы в Яндексе.

В начале 2012 года я взял из него модуль утверждений и с нуля написал TestRunner для ОФ, так им и пользовался на двух проектах, функционально было это минимальное MVP. Потом в развитии инструмента была пауза до первого лампового Инфостарт Эвента, где я обмолвился в личной беседе о сделанном Артуру. Меньше чем через месяц ровно в ДР Артура я написал ему, и у нас завязался разговор, в результате которого я выложил на github первую публичную версию, которую назвал 1CUnit, потихоньку начали пилить вместе ОФ, а в декабре того же года присоединился Григорий Пташко и прикрутил первую версию поддержки УФ.

В 2013 фирма 1С официально всех предупредила, что 1С в названии можно использовать только если ты партнер и только специальным образом, и Андрей Аристархов, если не ошибаюсь, на ИЭ 2013 в мае (а может и раньше в Г+), намекнул нам, что надо бы переименоваться и этот вопрос начали кулуарно обсуждать. Алексей общался с Андреем лично, он посоветовал использовать суффикс "For1C" + была переписка в G+, в итоге два основных варианта было - xUnitFor1C и OpenUnitFor1C. В результате победил xUnitFor1C. Тогда же я передал репозиторий вновьсозданной организации на github с названием xddDrivenDevelopment (вместо буквы x в начале могла быть буква y, привет Жене Сосне 😊). Приблизительно тогда же, кажется, Женя Сосна прикрутил в проект precommit1C и разрабатывать стали в исходниках.

В 2015 г (я точной даты тут уже не знаю, т.к. я уже активного участия на тот момент не принимал) Женя Павлюк переписал полностью ядро xUnitFor1C в тот вид, какой мы его знаем сейчас, с поддержкой плагинов и т.п. Об этом была отличная статья на хабре https://habr.com/post/270061/

Ну и дальше уже все так, как написал Алексей.

Формально в проекте поучаствовало 31 разработчик: https://github.com/xDrivenDevelopment/xUnitFor1C/graphs/contributors

Все что вы хотели знать о технологии блокчейн в 1С (это реально из прода 🤪).

#codesmells 💩 #говнокод

Сегодня просто цитата из рабочей переписки:

«Я год работал над собой, прежде чем смог сменить чувство, что я подвёл чьи-то ожидания, не сделав задачу в срок, на чувство "какой дебил написал здесь "два часа".»

🥳 Вредные советы по юнит-тестированию

На хабре отличная саркастическая статья-исследование юнит-тестов в открытых проектах на java с кучей примеров со ссылками на реальные репы на github'е. Цитата для привлечения внимания:

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

Комментарии к статье тоже отличные и практически полезные.

Ссылка: https://habr.com/post/434972/

Потрясающая вводная статья по сценарному тестированию/bdd и применению инструментов от Владимира Литвиненко https://infostart.ru/public/969637/

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

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

С нетерпением жду продолжения цикла статей.