Комментарии 13
Вот я смотрю на вашу статью, и понимаю почему вы проект завалили. Много, долго, умно,сложно объясняете, слишком увлекаетесь усложнением на пустом месте.
Вы идеальный исполнитель, но над вами должен стоять человек, который вам запрещает делать сложные умные штуки, которые вы умеете и любите делать. А должен следить, чтоб вы делали всё просто и примитивно. Но вы ведь так не умеете?)
Такие как вы, почему то не владеют примитивной логикой: если проект загнулся от чрезмерной сложности - надо его упростить. Вместо этого вы его усложняете внедрением TDD.
TDD - это всё та же груда строчек кода, которые абсолютно так же ломаются, и усложняют проект.
Я много думал, почему так. Я думаю такие как вы, большой объем оперативы в мозгу, это ваша сильная чёрта и вы её грузите по полной созданием сверхсложных систем и хранением её в своей оперативной памяти.
А у людей, которых оператива маленькая, но мощный проц, поэтому они сверх логично всё систематизируют, делают всё простым , логичным и эффективным.
И для успеха проекта нужно оба типа людей)
Большое спасибо за отзыв! Очень интересная точка зрения.
Нам всегда нужны люди с мощным процессором - приходите на открытые вакансии ;-) https://www.linkedin.com/jobs/view/3948294658/
Зачем? На собесе вы меня спросите: как вы относитесь к TDD, а я вам честно отвечу: что это прикольный способ полностью остановить разработку и заморозить проект.
Что когда в процессе разработки внезапно начинают уделять повышенное внимание тестам - это первый признак того, что проект пошёл ко дну.
Ещё раз ваше проблема не в том, что у вас кто-то на с плохо пишет. У вас проблема, что чтобы сделать тележку на колёсиках, вам требуется чувак с гиганстким списком требований. А не расбери и с.
Забавно, что вы это не способны понять) Потому что у вас одна из аксиом в жизни, чем сложнее -тем лучше)
Я не соглашусь с тем что TDD - это способ полной заморозки проекта. Мы никогда не жили по полному TDD - но когда в разработку бралась фича, всегда задавался вопрос: как ЭТО тестировать. Ну потому что хорошо, когда штука имеет дисплей и клавиатуру - можно скзать что мы потыкаем, и затестим. Хуже - если штука показывает только цифры, и клавиатура только цифровая.. Совсем плохо - если это какой-то алгоритм внутри МК который срабатывает по определенному сочетанию внешних (и внутренних) факторов. Это очуметь можно такое тестировать "в натуре".
В итоге, нам удалось добиться архитектуры, которая изолировала аппаратную часть от сложной логики, и можно было комфортно отлаживать приложение собрав его под обычный linux x86, и юнит-тестами контролировать как масштаб времени (вплоть до полной его остановки), так и входные данные которые якобы приходят в этот момент времени от аппаратуры. И чему тут ломаться ? Если бизнес-требования изменяются, то да - тесты ломаются. Но согласитесь, еще страшнее когда бизнес-логика в приложении поменялась, а тесты - зеленые. Это означает что можно как хочешь портить код и его контракты, а выяснится это только на финальной сборке с железом... Опасненько...
В целом - нормальный проект (а особенно - эмбеддед, где нельзя вот просто так залезть отладчиком и посмотреть, ибо как в квантовой механике - измерение меняет состояние объекта! :-) ) - тесты должны быть. Если добавление тестов ухудшает положение разработчиков - значит что-то сильно не так с архитектурой...
Тут я с вами соглашусь. С одной стороны у меня нет опыта по проганью таких вещей и если использование дешевего труда тестировщиков невозможно и затруднено, то конечно надо обходиться без них.
С другой стороны, я специально дописал о "внезапном внимании": если с самого начала программист пишет TDD, то я бурно завидую его аккуратности и трудолюбию. С другой стороны, когда проект вплотную у релиза, а тут начали внезапно кричать о необходимости его затестировать по самое не могу, то явно всё начало бурно ломаться, когда фикс одной баги вызывает две других.
Это да. Нельзя долго и упорно писать код - а потом вдруг решить обмазать его тестами. Тестирование должно начинаться ДО того как первая строчка кода написана - тогда глядишь и польза от него в проекте будет...
Эээ... Я сказал, что я завидую их трудолюбию и аккуратности, но не сказал, что это эффективно)))
Тесты надо писать на методы которые часто ломаются, сложны к пониманию или критичны для системы. Тупо покрывать всё тестами - это крайне трудоёмко и очень неэффективно.
И уже после того, как из пару раз сломали)
Ну а на что именно писать тесты - это есть целая теория тестирования. Пусть специально обученные люди думают. В общем, я так чувствую что мы сошлись на том что TDD как методология имеет право на жизнь при условии что:
Планирование тестирования начинается до-, или одновременно с написанием кода
Testability понимается как одно из важных нефункциональных требований к системе и закладывается в архитектуру
Тесты пишутся не от желания левой пятки, а на основе согласованной методологии (управление рисками или управление сложностью, или что-либо еще применимое в конкретном случае).
В общем, все как всегда - любой инструмент требуется применять с умом, от молотка и до микроскопа...
Я никогда не видет tdd вживую. И не знаю лично человека, который бы видел.
Я однажды присутствовал при попытке внедрения TDD , я налил себе с утра кофе, и сказал себе велкам ту новая жизнь.
TDD - это как ездить на велосипеде задом наперёд. Больно, неудобно и очень медленно. Я ни смог физически написать ни одного теста, вперёд метода. К концу недели из 70 человек в департаменте на TDD остался один. Он продержался три недели и то он писал тесты после кода, просто очень много этих тестов было.
Да, я верю, ято можно научиться ездить на ведоспиде в свиче, но рассказывать мне что этот надёжнее и удобней не надо. Да багов на 60%меньше, потому что в тот момент когда ты начинаешь требоватт TDD 90% программистов увольняются.
Что по мне это невозможно.
Я тоже не видел чистого TDD "в дикой природе". Однако, у нас прижилось нечто довольно близкое к этому: пишем кусок нетривиального (или хотя бы потенциально переиспользуемого) кода - приколачиваем его контракт к столу тестом (-ами). Пишем следующий кусок кода, опирающийся на закрепленное поведение - прибиваем его к столу гвоздями (тестами). В результате, получается программная конструкция, которая нигде не хлябает, не болтается, не провисает. Иногда даже потом работает с первого раза. :-)
Можно спорить, test-ли это driven development в каноническом смысле - но поскольку на наши архитектурные (и технические) решения влияет наша стратегия написания тестов (то есть мы изначально знаем что будем так тестировать - и система обязана позволять такую стратегию тестирования) - то я считаю что оно втч test-driven (хотя, конечно, драйверов у разработки не один и это не только тестирование).
Заголовок "TDD в Embedded". А по факту, очередная апологетика TDD, а про встроенные системы почти ничего. Интересно, как у вас 100500 тестов на ферму деплоятся и как они каждую ночь на реальных стендах работают, а не картинка про TDD.
В защиту автора статьи скажу что TDD (и вообще автоматическое тестирование) в embedded (и при разработке на промышленных контроллерах) - известно очень плохо, поэтому любые упоминания скорее помогают прогрессу. То, что для нормального энтерпрайз перекладывателя джейсонов является альфой и омегой (тесты, метрики качества, CI/CD пайплайны с запуском батареи тестов вне зависимости от желания автора MR) - для эмбеддед и индастриал - откровения (если не ересь!). Я лично видел как на заводе приехавший из Мск инженер комментировал блоки защиты в прошивке, и забивал значения датчиков константами чтобы затестить обновления на производственной линии. В других местах уже только за мысли об этом - могут и по рукам дать... Но это ж эмбеддед - им еще и не то можно, отчаянно смелые же люди... :-)
Отличная статья. TDD отличная штука. Удачи вам.
Test Driven Development в Embedded, или Как увеличить производительность команды на 37%