в жизненном цикле программы можно условно выделить два периода: разработки и развития. в период разработки, когда все требования и код запросто помещаются в голове, эффект от TDD на фоне других методик не очень заметен. просто держите себя в руках, следуя классическим методикам программирования — ООД, паттерны, и что там ещё проходили в школе — и вы обязательно достигнете желаемого результата. преимущества от TDD появляются на втором этапе, когда, условно говоря, часть предыдущих разработчиков уже уволилась, а у оставшихся нюансы требований стёрлись из памяти. в отличие от людей, тесты не бросают работу и ни чего не забывают.
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
Также то, что Unicode поддерживается только UTF-16, а не UTF-8, что было бы сильно логичнее.
ходят слухи, что ms office понимает csv в utf-8 когда в начале файла есть нужный BOM (так-ли это на самом деле не могу проверить за неимением сего чуда).
мм. интересно, это чудо как-то ограничивает количество пунктов в меню и количество символов в надписях? как реагирует если у уже открытого меню меняется описание javascript'ом (добавил 100 пунктов, через секунду убрал)? как решат проблему, что в меню можно добавить пункты с привычными пользователю названиями, но выполняющие совершенно иные действия?
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.
думаю, корпорации это бизнес, а бизнесу нужны гарантии. заказчик, заключая полугодовой контракт с разработчиком сайта, хочет быть уверен, что получит современный результат. разработчик, в свою очередь, хочет зафиксировать объем работ. как быть, если за это время появятся ещё две версии браузера, с неизвестными нюансами? по сути — лишние риски, которые ни заказчику, ни разработчику нафик не упёрлись.
Мажорные версии браузеров, для разработчиков сайтов, долгое время символизировали определённые стандарты и, соответственно, степень проработки вёрстки под них, то бишь объём работ в итоге, ТЗ, контракты… Куда понесло FireFox? 4 версии X 2,5 популярные платформы нехило прибавят работы верстакам и тестировщикам за этот год — такими темпами себестоимость веб-интерфейсов скоро станет слишком высокой. Зачем гонка версий нужна «корпорации добра», понятно — они строят собственную платформу. А вот на что рассчитывает Mozilla?
хотел сказать, что такой интерфейс для отправки POST запроса мне кажется бесчеловечным. в мире TDD есть лучшие примеры, реализующие ту же функциональность. прямо мм… как некоторые шоткаты на хабре)
видимо, так и появилась возможность пушить коммиты из prime в hub — вполне себе решение, если нет возможности содержать процесс с блэк^H^H^H^H стэйджингом и тестировщиками)
вы контролер из аэроэкспресса? (у меня уже несколько раз проверяли валидность билета методом такого вот гениального взгляда на распечатку с баркодом, без всякой аппаратуры :))
возможно я не правильно вас понял, в примере — синтаксически корректное выражение (равно как корректно предложение у Толстого с точки зрения правил русского языка), но вырванное из контекста, вызывает проблемы с интерпретацией.
интерпретация этого выражения спотыкается, в первую очередь, о неопределенность переменных «x» и «i». интерпретатор может поискать их в глобальном контексте, или определить их значения самостоятельно, используя какие-то собственные эвристики (как это делает, скажем, php — с той же степенью неожиданности).
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.
а если вместо отступов сделать скобочки, будет обратно похоже на Lisp :)
хотел сказать, что такой интерфейс для отправки POST запроса мне кажется бесчеловечным. в мире TDD есть лучшие примеры, реализующие ту же функциональность. прямо мм… как некоторые шоткаты на хабре)
интерпретация этого выражения спотыкается, в первую очередь, о неопределенность переменных «x» и «i». интерпретатор может поискать их в глобальном контексте, или определить их значения самостоятельно, используя какие-то собственные эвристики (как это делает, скажем, php — с той же степенью неожиданности).