0. Alligator84 50 08.10.18 15:10 Сейчас в теме

Новичок в TDD

Краткие итоги первых шагов при разработке в 1С через TDD.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. Сурикат 181 08.10.18 15:41 Сейчас в теме
Поспорю с тезисом:
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.

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

А так спасибо за труд =)

+ втянутся в тестирование неочень легко, надо хотя бы пару книжек прочитать и научиться писать тестируемый код. А самому это довольно-таки тяжело.
JohnyDeath; Alligator84; +2 Ответить
2. Alligator84 50 08.10.18 15:44 Сейчас в теме
Абсолютно согласен только тогда, когда твой руководитель замыкает весь цикл разработки, а когда руководитель разработки ПО стремится быстрее отдать в отдел тестирования, то тут его мало интересует качество кода до того момента, пока ему в KPI не поставят показатель количества возвратов на доработку!
3. artbear 1084 08.10.18 16:16 Сейчас в теме
Олег, интересная статья.

Только названия инструмента-наследника от VB и xUnitFor1C я так и не увидел :)
Alligator84; +1 Ответить
6. Alligator84 50 08.10.18 16:30 Сейчас в теме
(3) А вот и уважаемый мною, artbear!

Проект объединен в единый общий репозиторий ADD

ADD - объединенный проект содержит в себе

BDD - bddRunner
TDD - tddRunner
единые расширения для тестирования


(4)
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.

Да уж, хоть как то сделать легче пользователям - это научиться правильному подходу самому!
4. artbear 1084 08.10.18 16:22 Сейчас в теме
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.
ЧерныйКот; DenisCh; Alligator84; +3 Ответить
8. Alligator84 50 08.10.18 16:59 Сейчас в теме
(4)
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.


Новый холивар: TDD vs DUS

TDD - test driven development
DUS - development through user suffering
42. VladimirL 795 09.10.18 18:15 Сейчас в теме
5. ivanov660 884 08.10.18 16:26 Сейчас в теме
Проблема в головах трудно решаемая задача, но решаемая)
Также, на мой взгляд, существенные трудности вносит некоторая не совместимость подхода TDD с 1С, его можно относительно эффективно использовать при части решаемых задач.
Alligator84; +1 Ответить
7. Alligator84 50 08.10.18 16:31 Сейчас в теме
(5) Не соглашусь в данный момент, на текущий момент не встречал таких задач, если приведете пример, будет круто!
13. ivanov660 884 08.10.18 17:21 Сейчас в теме
(7)Во-первых, если внимательно читали, то я утверждаю, что его эффективно использовать при части решаемых задач. Это значит, что деньги/время/эффективность при некоторых условиях перевешивают весы в другую сторону.
Во-вторых, расскажите мне как вы обходите отсутствие возможность создать mock объекты в 1С.
Alligator84; +1 Ответить
14. Alligator84 50 08.10.18 17:32 Сейчас в теме
(13)
mock объекты в 1С

А пока никак на данной ветке своей эволюции в разработке через TDD.
Я прочитал Вашу статью и нашел много полезностей, которые еще предстоит осознать и пощупать на практике.
Но при всем при этом, тому функционалу, который мне приходилось обвязать тестами, не требовались ни подставные объекты, ни заглушки.
Я даже не представляю пока как их применить в тестировании в 1С.
Есть статьи на эту тему или достойная книга на Ваш взгляд?
20. ivanov660 884 08.10.18 21:16 Сейчас в теме
(14)
1. В некотором приближении макет можно назвать мок объектом.
2. В рамках TDD и 1С я видел только статьи от Артура Аюханова и Ко.
3. По-моему опыту, эффективно обвязывать тестом блоки функций (относительно большой кусок). Обвязывать маленькую функцию слишком времязатратно и не эффективно (время/деньги/качество/люди).
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
5. У нас в компании, я в ближайшее время планирую провести вебинар посвященный тестированию юнит и TDD, думаю, я выложу на youtube канале некоторую интерпретацию некоторое время после.
Alligator84; +1 Ответить
25. Сурикат 181 08.10.18 22:07 Сейчас в теме
(20)
А по-моему наоборот. Легко получается писать unit-тесты, если функция маленькая и имеет мало зависимостей. Например, очень просто написать тест на функцию, чьими параметрами будет выступать пара документов и элементов справочников. Тогда и макеты не нужны. Можно создать пару элементов справочника только с нужными зависимостями.

К примеру, документ реализация, 2 номенклатуры и один склад. И мы уже можем протестировать движения документа по складскому контуру.

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

Если писать unit-тесты сразу, то получается не так трудозатратно и выигрыш больше. Но большинство существующего кода 1с тестируется плохо, с вами согласен. Зависимость от БД слишком велика.
43. ImHunter 21 09.10.18 19:29 Сейчас в теме
(20)
Насчет моков. У нас тоже достаточно большое поле возможностей и фантазии.
1. Тесты, обычно, обрамляются началом/откатом транзакции. Можно создать свой тестовый документ/справочник, записать и использовать его ссылку. При откате транзакции - будто ничего и не было.
2. Примерно тоже, что и п.1, только объект можно заполнить какими-то предварительно сериализованными данными.
3. Как иногда в типовых, подменять Структурой.
44. ImHunter 21 09.10.18 19:34 Сейчас в теме
(20) Насчет
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).

Ну не знаю... Как по мне, эта книжка достаточно правильно заряжает. И главное, вдалбливает режим "красный-зеленый-рефакторинг". Даже если этого не соблюдаешь, то как-то всегда помнится об этом.
9. JohnyDeath 291 08.10.18 17:06 Сейчас в теме
Хорошая статья. Знакомо до боли.
Но я так и не понял, чем всё закончилось? Автор, где сейчас работаешь? Всё также подпольно пишешь и запускаешь тесты? Или уже заразил всю команду зелеными кружочками?
Alligator84; +1 Ответить
10. Alligator84 50 08.10.18 17:08 Сейчас в теме
(9)
Но я так и не понял, чем всё закончилось?

Надеюсь не закончится еще очень долго!

(9)
Всё также подпольно пишешь и запускаешь тесты?

Так точно.

(9)
Или уже заразил всю команду зелеными кружочками?

К сожалению, нет...никому кодить в два раза больше строк кода не хочется.
JohnyDeath; +1 Ответить
11. JohnyDeath 291 08.10.18 17:14 Сейчас в теме
(10) Дымовые тесты же всем показывал?
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.
UniversaLL; Alligator84; +2 Ответить
12. Alligator84 50 08.10.18 17:19 Сейчас в теме
Да меня после зеленых кружочков никто не понял, почему сроки по новой подсистеме неоправданно высокие!

А если бы про "дымовые" заикнулся - все бы расценили как попытку поджёга офиса;-)

(11)
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.

Так и есть, заниматься можно постоянно повышая свой профессиональный уровень.

(11)
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.

Причины, на мой взгляд, очевидны, я их описал в публикации и изменить парадигму в коллективе сможет только тот, кто будет заточен на качество с большой буквы К.
23. TODD22 17 08.10.18 21:29 Сейчас в теме
(11)
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.

Или забросят, если никому не интересно, то продолжать не будут. Пробовал внедрять "промышленные подходы" после аналогичного курса. Всё из под палки, потом и самому всё это надоело.
21. ivanov660 884 08.10.18 21:24 Сейчас в теме
(10)
К сожалению, нет...никому кодить в два раза больше строк кода не хочется.

Я разработчика спрашиваю: "как ты докажешь, что твое решение правильное/работоспособное?" Хороший ответ, у меня есть тест)
UniversaLL; Alligator84; +2 Ответить
15. grumagargler 443 08.10.18 18:33 Сейчас в теме
Если будет больше статей практического характера, то и не будет, постоянного, простите, нытья, о том, что тестирование - круто, но большинство настолько слабы душой, что не тянут. Нет, ну серьёзно, если есть желание двигать тему - нужны тематические материалы, а не рассказы: "никто не использует тестирование, а ведь это так круто, ведь я попробовал и у же получается".
VladimirL; tsukanov; zqzq; CyberCerber; kuntashov; Adam12345678; JohnyDeath; Alligator84; +8 Ответить
16. Alligator84 50 08.10.18 18:38 Сейчас в теме
(15) Абсолютно верно, только учить нужно тем, кто в этом гуру, а тем кто начинает путь, если есть желание, рассказывать каков он, этот путь.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
17. grumagargler 443 08.10.18 18:45 Сейчас в теме
(16) Ждем следующей статьи, не нужно обучающей, просто поделитесь практическим примером наработок, к чему пришли, какие сложности и т.д. с точностью до строки кода. Понимаете, тема тестирования уже сильно взбудоражена и до нас вами, и не очень большое количество статей, где об этом рассказывается на практических примерах, начинает раздражать большую гвардию программистов, которые пытаются и не получается (не у всех хватает выдержки, но и ведь она не обязательно должна у них быть!)
so-quest; kuntashov; Adam12345678; Alligator84; +4 Ответить
46. VladimirL 795 09.10.18 22:06 Сейчас в теме
(16)
учить нужно тем, кто в этом гуру
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания

Учить и делиться практическим опытом - разные вещи. Ждать гуру для этого не стоит, можно не дождаться )) "Нет взрослых, кроме нас самих". Что мы публикуем и чем делимся друг с другом, то и становится фундаментом для нашего развития. Все использованные Вами инструменты относятся к миру Freeware и Open Source. А в нём всё именно так и работает.


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


Не хватает практических примеров? Да, есть такое. Многие публикации действительно пишутся на недосягаемом уровне абстракции и не содержит последовательности шагов от начала до конца для достижения цели. Так значит ниша ещё пуста! Заполняйте её.


Это позволило бы добиться сразу нескольких целей:

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

2) Дать понять другим авторам, куда лучше копать, когда они будут делать публикации на эту тему. Может быть это поможет контрибьюторам проекта улучшить справку по инструментам. Между прочим в обработке bddRunner сейчас есть довольно хорошая встроенная справка.

3) Сами же лучше систематизируете и структурируете для себя информацию. Под чем-то подведете черту. Где-то увидите новые пути для самого себя.



Вообще, если в публикации правильно употребляются понятия TDD/BDD и не путаются с "покрытием тестами", то попытка сходу начать применять TDD/BDD кажется рискованной. Может быть лучше сначала начать с покрытия тестами?

Это не обязательно должен быть тот функционал, который от Вас требуют прямо сегодня-завтра. Покрывать тестами можно уже реализованный и отлаженный функционал, который по разумным соображениям кажется наиболее критичным для работы системы. Или тот функционал, который по статистике чаще всего выходит из строя в результате изменения системы. Затем можно перейти к подходу "нашел баг -> исправил -> покрыл тестом". Покрытие тестом можно сделать прямо по сценарию воспроизведения бага.

Может быть стоит оставить экстремальный подход работы через TDD/BDD на время, когда Вы сами сможете определять подходы к разработке? Если начать с постепенного покрытия тестами, то Вы и свои технические навыки применения инструментов повысите и система станет стабильнее. Реализацию же новых задач пока оставить как есть, покрывая их тестами, когда появится такая возможность.

BDD - это же вообще об общении постановщика задач (заказчика) с разработчиком. Покрытие тестами и сценарное тестирование - чуть другое : https://www.youtube.com/watch?v=JnoZbbYZeeI
CSiER; zqzq; Alligator84; grumagargler; +4 Ответить
48. Alligator84 50 10.10.18 08:07 Сейчас в теме
(46) очень круто всё разложили:
- конечно, покрывать тестами существующий функционал - это против философии сначала тест потом код, но абсолютно согласен, что на этом можно неплохо набить руку. Сам грешу этим.

За конструктив огромная благодарность Вам!
VladimirL; +1 Ответить
18. artbear 1084 08.10.18 18:59 Сейчас в теме
Да, более практической части, конечно, не хватает.

Практики и технических деталей нужно больше, конечно.
Adam12345678; +1 Ответить
19. Alligator84 50 08.10.18 19:08 Сейчас в теме
Статья не предполагала тематику вида: азы входа в TDD. Скорее показать реалии TDD при входе, в том числе, подготовить программистов к тому, что их старания, возможно, и это печально, не будут оценены положительно - это Ваша инициатива сделать Мир разработки 1С лучше. К этому нужно быть готовым и большой успех, если Ваша команда пропагандирует это.

Но над конструктивными замечаниями подумаю на будущее - как это грамотно оформить в виде статьи. Благодарю за конструктив!
22. DrZombi 08.10.18 21:26 Сейчас в теме
ТДД Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторин

...
технология аникейщиков :)
24. CheBurator 3564 08.10.18 22:04 Сейчас в теме
"много букв" - это предупреждение для молодежи, читающей только твиттер? ;-0
26. CheBurator 3564 08.10.18 22:18 Сейчас в теме
Следует ли материал трактовать так, что ТДД неприменимо в маленьких (насколько каких?) компаниях, обслуживаемых 1-2 1Сниками, которые не занимаются промышленной разработкой на продажу..?
27. Alligator84 50 08.10.18 22:22 Сейчас в теме
Конечно же нет, и один разработчик может покрыть тестами свою конфу и спать спокойно!
Когда все фичи покрыты тестами, то и вносить изменения в разы проще, не боясь выпускать релиз в production!
28. CheBurator 3564 08.10.18 22:23 Сейчас в теме
Мне не нравится как я пишу, и качество разработок моих (но я и видал код таких хомячков - что мои каракули = верх совершенства). Я пробовал и регулярно (но нечасто), пытаюсь мелкие задачи через "тдд" писать (по сермяжному, по доморощенному, но хоть как-то улучшить качество разработки). Но все упирается как раз в это "нужно вчера". Задачи для бизнеса (не в ИТ-компании!) возникают по инициативе бизнеса. А (небольшой) бизнес принципально не способен планировать разработку инструментария для решения его задач. Почти всегда это надо сейчас и вчера. И что делать? Конечно, понятно, что - плюем на все "тдд" и срочно пилим "как есть". Замкнутый круг.
fancy; kote; +2 Ответить
29. Арчибальд 2705 08.10.18 23:36 Сейчас в теме
(28) Когда пишешь под "сейчас и вчера", тогда и происходит реальное тестирование. Собственно, откуда ТДД произошло? Еще Дейкстра показал, что протестировать программу невозможно (начиная с некоторого объема). А тестировать надо. Значит, надо создать надежный остов (как - это другой вопрос) и помаленьку наращивать на него оттестированные кусочки мяса. В ИТ-компании это реальная проблема (релизы, версии, преемственность, сопровождаемость и т.п.). А в бизнесе появилась задача - делаем (пишем) канву. Даже распечаткой результатов не заморачиваемся. И юзерам в зубы. Через пару не дней, часов косяки налицо. Далее постепенно растим функционал. Так что никакого замкнутого круга.
30. CheBurator 3564 09.10.18 04:01 Сейчас в теме
(29) ээээ! это не катит когда цена ошибки велика. В работу надо отдавать "правильный" вариант. а ошибки иногда бывают ну не очень явные... и времени на тщательное программирование - нет совсем.. вот и костылишь - основное пишешь тщательно по возможности, а оно хреняк и сработало "неосновное" - а там конь не валялся, в целом-то вроде и правильно, но не очень...
31. CheBurator 3564 09.10.18 04:02 Сейчас в теме
(30) Понятно, что от этого, по видимому, никуда не дется. Это - ПЛАТА за бизнесовское "надо вчера"...
32. Alligator84 50 09.10.18 07:34 Сейчас в теме
(29)
И юзерам в зубы. Через пару не дней, часов косяки налицо.


Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
Конечно же, это не норма такой разбор полетов - но повышать качество выпускаемых фич однозначно надо, моё ИМХО.
ivanov660; +1 Ответить
39. Арчибальд 2705 09.10.18 17:00 Сейчас в теме
(32)
руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату
Я про ИТ-фирмы не говорю. Три руководителя = перебор для любой другой фирмы.
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Такое может быть только у менеджера. Руководители знают Козьму Пруткова: и при железных дорогах сохраняй двуколку. Внедрение новой фичи не может сопровождаться разрушением старых механизмов - ну, при нормальном руководстве, конечно.
41. Alligator84 50 09.10.18 17:32 Сейчас в теме
(39) Как раз таки, это не была ИТ организация. Было создано ИТ подразделение со своими руководителями по направлениям.
55. Арчибальд 2705 10.10.18 10:56 Сейчас в теме
(41)
Было создано ИТ подразделение со своими руководителями по направлениям.

Ужас какой. И сколько времени прошло от создания подразделения до обнаружения его неэффективности?
56. Alligator84 50 10.10.18 11:02 Сейчас в теме
(55) К сожалению или к счастью, я не участвовал в этом процессе, да и про эффективность никто выводы при мне не делал.
Уверен, что эффективности можно достичь в любой структуре, вопрос полномочий и знаний того, кто управлять будет.
59. Арчибальд 2705 10.10.18 22:26 Сейчас в теме
(56)Ну, как же?
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
61. Alligator84 50 11.10.18 08:17 Сейчас в теме
(59) Не участвовал в создании и не фиксировал его НЕ эффективность. По сути, это структура очень хорошо показывала количество возвратов на доработку, при этом не нервируя пользователя на продуктиве.
62. Арчибальд 2705 11.10.18 19:56 Сейчас в теме
(61) Понял. Структура показывает, не нервирует.... все по феншую. Кстати, китайцы, когда все по правилам, а толку нет, херят правила. Поэтому у них 7% роста ВВП, а у нас 0.
33. zqzq 17 09.10.18 14:15 Сейчас в теме
Тестирование, всё же, не единственный вариант повышения качества разработки. Есть и другие, более независимые от команды и др. внешних факторов и не влияющие на скорость разработки в худшую сторону.

Есть, например, внутренняя автоматизация. У нас работает база-центр обменов и обработка обновления рабочей базы нединамически одной кнопкой (инструменты моего изготовления с учетом специфики).

Также есть повышения качества самого кода. Я не про унылые стандарты с ИТС (но и не против них). Отличная книга "Совершенный код" Макконела. Или написание запросов (почти) без конструктора (консоль запросов Инструментов Разработчика помогает автодополнением текста). Или освоение СКД в конце-концов (меньше кода -- лучше его качество).

Как-то экспериментировал с TDD, но моё впечатление, что более высокоуровневые приемочные тесты типа BDD это проще и более "по-1Сному", чем на каждую тривиальную функцию лепить тест по канонам классического TDD. (Но в те времена 1С-BDD было неразвито и как-то забросил тему.)
34. Alligator84 50 09.10.18 14:20 Сейчас в теме
(33) как всё то, о чем Вы написали поможет проверить 159 фич, которые могут быть "затронуты" новым релизом и гарантировать работающий функционал утром при ночном обновлении продуктива?
35. zqzq 17 09.10.18 14:27 Сейчас в теме
(34) Очевидно, никак ;) Но это поможет создавать меньше косяков изначально...
36. Alligator84 50 09.10.18 14:35 Сейчас в теме
(35) Вы пишете об инструментах создания/генерации кода, но не о механизмах проверки методов/фич - согласитесь, разный контекст.
37. artbear 1084 09.10.18 15:35 Сейчас в теме
(33) Согласен с тем, что есть и другие способы повышения качества.

Лучше применять все варианты, причем системно, а не эпизодически.

Статический анализ кода, полная расширенная проверка, прогон через SonarBSL, дымовые тесты разных видов, продвинутые инструменты, отладка запросов, авторазвертывание, сервер непрерывной интеграции, сервер развертывания и т.п. и т.д.
38. Alligator84 50 09.10.18 15:46 Сейчас в теме
Ух куда нас занесло) следующая статья про новичка в DevOps...
40. herfis 261 09.10.18 17:00 Сейчас в теме
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)
К сожалению, в большинстве случаев ситуация именно такая.
Серьезные подходы получается внедрять и они окупают себя только в серьезных продуктовых командах, которые востребованы в ограниченном количестве.
Где большие сложные продукты с большим количеством пользователей, поставленный цикл разработки и т.п. и т.д.
А не когда разработка идет в полтора лица, а цикл разработки разбит на случайные итерации от одного подзатыльника до другого с требованиями "на вчера".
ЧерныйКот; +1 1 Ответить
45. ImHunter 21 09.10.18 20:17 Сейчас в теме
(40) Есть такая ситуевина.
Тут нужно автоматизироваться. Это почти без вариантов.
Т.е., нужно иметь возможность - куда-то выкладывать тесты. На сетевой ресурс, на интранет-гит, на внешний гитлаб, еще куда-то.
И нужны постоянные автоматические прогоны выложенных тестов на тестовом контуре. Результаты - должны публиковаться где-то. И/или пусть приходят по эл.почте.
Тогда это будет хорошим стимулом писать тестируемый код и сами тесты.
Это я себя так подбадриваю;)
Нужно уже собраться и написать какую-то такую сборочно-тестовую линию.
Я, в свое время, пошел по альтернативной ветке - не по учениям Серебряной пули. Написал и почти не развиваю обертку Ванесса-Раннер/Деплойка для Jenkins для автоматизации развертывания.
Хех, нужно уже написать линию тестирования.
47. Alligator84 50 10.10.18 08:02 Сейчас в теме
(40)
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)

Корень проблемы в том, что повышать свой профессиональный уровень хотят единицы, все остальные из "под палки".
Я приведу пример из своего управленческого опыта:
- объявил всем сотрудникам о том, что бюджет на обучение не ограничен (за это, конечно, особая благодарность моему руководителю, который "услашал" меня), выбирайте любые курсы - учитесь, в том числе с выездом в мск.
- только один сотрудник из 40 прошел обучение и сдал на спеца с первого разва в УЦ №1 за два года.
Вот так то!
49. sam441 10.10.18 10:02 Сейчас в теме
(47)
только один сотрудник

я знаю этого сотрудника)) респект за статью
Alligator84; +1 Ответить
51. genayo 10.10.18 10:17 Сейчас в теме
(47) Или у вас очень странные сотрудники, или вы что-то не договариваете по условиям обучения.
52. Alligator84 50 10.10.18 10:20 Сейчас в теме
(51)
Или у вас очень странные сотрудники

Сотрудники были одни из лучших)
(51)
или вы что-то не договариваете по условиям обучения

Никаких обременяющих условий быть не могло, в принципе, компания могла себе это позволить.
В долгую перспективу выигрывали все.
53. genayo 10.10.18 10:46 Сейчас в теме
(52) Тогда согласен, что 1С-ники в большинстве своём ленивые :))
54. Alligator84 50 10.10.18 10:48 Сейчас в теме
(53) Лень - это не всегда плохо, лень + задача в срок с заданным качеством = эффективность!
57. genayo 10.10.18 11:50 Сейчас в теме
(54) Тогда сотрудники правы, получается. Им не нужны были курсы, чтобы быть эффективными, только и всего.
58. Alligator84 50 10.10.18 11:52 Сейчас в теме
(57) в их матрице мышления - да!
50. Alligator84 50 10.10.18 10:15 Сейчас в теме
60. Fox-trot 89 10.10.18 22:58 Сейчас в теме
гиты, шмиты....
как-то договорился с коллегой, что будем родное хранилище использовать. ну хотя бы так
ок, говорит, погнали...
гнали мы не долго, до возвращения начальника из отпуска
такие дела
63. herfis 261 12.10.18 15:40 Сейчас в теме
Если на то пошло, то TDD своей основной и самой вкусной частью - про юнит-тестирование. А в 1С с юнитами несколько особая ситуация.
Половина настолько простые, что овчинка выделки не стоит, а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет).
Функциональные и интеграционные автоматические тесты - это да. Это реально полезно. Только классическое TDD не про них.
64. Alligator84 50 12.10.18 15:55 Сейчас в теме
(63)
а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет)

Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.
Когда Вы изначально пишите тест, а после сам код, то это правило соблюдается как нельзя лучше.
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
65. herfis 261 12.10.18 17:17 Сейчас в теме
(64) Удачи. Хотите попробовать фигней пострадать - ваше право.
А лично я бы сосредоточился не на эфемерном TDD в 1С, а хотя бы на простейших функциональных и интеграционных тестах.
Чтобы получать ответ на самые насущные вопросы:
- не сломался ли запуск 1С
- не сломалась ли работа форм
- не сломалась ли работа документов на тестовых наборах данных
Так даже до этого руки не доходят.
66. Alligator84 50 12.10.18 17:19 Сейчас в теме
(65) И Вам удачи, у каждого свой путь!
Ну и ждем от Вас статьи на описанные Вами темы.
67. herfis 261 12.10.18 17:31 Сейчас в теме
(66)
Ну и ждем от Вас статьи на описанные Вами темы.

Жаль вас разочаровывать, но вроде бы я не давал повода для такого рода чаяний.
68. spacecraft 12.10.18 17:58 Сейчас в теме
(64)
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.

Я бы акцент сделал на "ограничением применимости технологии именно в 1С".
ТДД был придуман на ООП. Именно там это работает так, как нужно.
Даже Серебряная Пуля пришла к тому, что чисто модульные тесты в 1С не панацея. И сместили разработку несколько в другое русло.
69. spacecraft 12.10.18 18:09 Сейчас в теме
(64)
Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.

Вот когда в 1С будет возможно использование SOLID, DI, IOC без костылей, тогда и можно говорить о TDD.
Сам использовал TDD на ОПП. Реально стоящая вещь. Обеими руками за эту технологию. Но в реалиях 1С об этом можно только мечтать.
70. acsent 1077 15.10.18 17:05 Сейчас в теме
Сама методология ТДД - сначала тест, потом код не совсем подходит когда пишешь с 0.те "творишь".
Вот для исправления ошибок - вполне можно
71. spacecraft 15.10.18 17:20 Сейчас в теме
(70)
Сама методология ТДД - сначала тест, потом код не совсем подходит когда пишешь с 0.те "творишь".

Как раз наоборот. Именно когда с нуля. В любом случае, сразу с нуля писать код без предварительного обдумывания структуры и чернового плана, мягко говоря "код в никуда".
Именно TDD помогает сразу писать структурированный и покрытый тестами код. По другому просто сложно. И главное: код получается малосвязанный. TDD прямо навязывает использовать "включение" зависимостей.

Вот для исправления ошибок - вполне можно

Вот для исправления ошибок, это уже не TDD. И не каждый код можно "покрыть" модульными тестами. Да же не беру код завязанные на внешние факторы. Просто после "творишь" на это спагетти не всегда можно написать тест.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Нижний Новгород
зарплата от 120 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

Программист 1С
Новосибирск
зарплата от 80 000 руб. до 100 000 руб.
Полный день

Системный аналитик
Новосибирск
зарплата от 80 000 руб. до 100 000 руб.
Полный день

Программист 1С
Салехард
зарплата от 80 000 руб. до 200 000 руб.
Полный день