BDD asks questions about behavior of app before and during development to reduce miscommunication.
BDD concentrates on behavior of app vs. implementation of app.
Idea (BDD): user story can be formulated as acceptance test before code is written.
Test Driven Design or TDD tests implementation.

** выше — цитаты из курса SaaS на coursera.

— BDD:
Слово Driven в BDD означает, что behaviour (выраженные в виде user stories) ведут вашу разработку. И вы разрабатываете именно те фичи, которые нужны заказчику.
В итоге одной user story соответствует Acceptance test.
Т.е. сначала пишете список user stories, потом их реализуете, показываете заказчику, потом берете следующие user stories и их реализуете, показываете и т.д..
Это тесно связано с методологией Agile Development.

— TDD
Ключевое слово Driven в TDD означает, что сначала пишется тест (который задает, что должно быть и как должна работать система), а потом уже пишется код.
Т.е. TDD — это не набор определенных тестов, это — методология (стиль) процесса разработки.
Точно так же BDD — это не набор определенных тестов, это идея процесса разработки, часть которого — написание тестов.

Если вы вначале пишете весь код, а потом перед сдачей проекта пишет набор тестов (которые могут и не покрыть все 100% кода) — то это не TDD.

— Процесс разработки
Если вы узнали требования от заказчика или прочитав спецификацию, и начали создание системы с написания кода (классов, сервисов, структуры базы данных).
Потом вы пообщались с заказчиком, уточнили требования, или поменялась спецификация, и после этого вы поменяли свой код.
И тут пришло время сдавать проект и вы решили писать тесты...
То это не имеет никакого отношения к TDD и BDD.

1. согласен,
предъявлять претензии могут только компании, у которых есть представительство (или доверенное лицо) в Украине, т.е. тот, кто может подать иск или заявление.
Т.е. можно не беспокоиться, что у вас есть какой-то нелицензионный софт не очень известной компании (может даже Winrar не имеет представительства в Украине).
но как всегда есть нюансы. Есть лица, которые как-то официально оформлены как представители (того же Adobe и кучи других фирм) в Украине, и они приходят вместе с милицией (УБЭП).
До суда очень редко кто доводит претензии того же Microsoft — обычно это очень злостные. Обычно договариваются раньше. Ведь Microsoft заинтересован не штраф снять с вас (после которого у вас отпадет желание вообще пользоваться их продуктами и будет больше желания экономить), а продать вам лицензии и подсадить вас пользоваться продуктами дальше легально.

2. В большинстве случаев, проблема состоит не в том, что к вам предъявят претензии за лицензионное ПО и попросят взятку. Проблема таких проверок, что забирают все компьютеры. Чем обычно и пугают. Для многих компаний это парализует всю работу.
Поэтому важее уметь наладить работу офиса в ситуации, когда все все ваши компьютеры унесут в неизвестном направлении (на ответственное хранение). Считайте это как форс-мажор или наводнение или пожар, к которому нужно заранее готовиться.

чтобы не заниматься своей системой оплаты на сайте — посмотрите на regnow.com или share-it, esellerate (похоже это уже одна компания) — www.mycommerce.com/regnow.

после получения денег на счет Regnow вы можете их вывести разными способами — например, на свой банк. счет (можно попросить у них нужные документы для предоставления в банк).

На западе (USA) есть две распространненные платежные системы — paypal, authorize.net.
Прикрутить их легко, но снять с них деньги — нереально.

я бы добавил — нужно уметь понимать бизнес-процессы (для этого нужна элементарная логика) + использовать готовые фреймворки и модули.

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

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

каждый день все используют фреймворки и готовые модули, но 99% из этих «умников» никогда сами не напишут ни свою CMS (по причине большой сложности), ни даже один модуль для умножения двух матриц.
ага! если кто-то подумал, что он сможет за 15 мин написать алгоритм умножения матриц, то может выбросить его в мусорку, потому что им никто пользоваться не будет. Т.к. его нужно оптимизировать, чтобы он работал раз в 10-100 быстрее. 90% программистов даже не читали этих статей, где описываются алгоритмы по правильному обращению к памяти. А если читали, то мало что поняли..

По работе с базами данных — то же самое.
все знают про индексы, и просто ими пользуются.
А глубже — по быстрой работе с данными — никто не копает.
а там уже просто математика (даже 5 курсов мех-мата) не поможет — потому что это не учат.

ТС может посмотреть в сторону приложений по работе с базами данных. Все таки там больше фана (в смысле там чууть больше креатива), чем в администировании.
Лепить формы в десктоп или веб приложениях тоже нужно и полезно, если это решает (автоматизирует) задачи бизнеса.

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

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

В целом же, если люди хотят социальную защищенность, то за это кто-то должен кто-то заплатить, — а именно, за это платит средний класс.
Тогда можно избрать путь Канады, но ваша ЗП будет на 30-40% ниже.
Готов ли средний класс получать на 30-40% меньше, но быть более защищенным?

Либо путь США, где ЗП намного выше, но где даже нет закона, который гарантирует отпуск при рождении ребенка. Уже достаточно сильно в США слышится мнение, что средний класс в США исчез, что люди вкалывают всю жизнь, но когда они заболеют или уйдут на пенсию — это для них как конец света с их расходами на мед. обслуживание.

Насчет Украины, получать огромные (по меркам Украины) зарплаты программистов и платить только 5% в бюджет и требовать социальной защищенности — так не получится.

зачем вам нужно официальное трудоустройство?

— пенсионный фонд?
а что вам мешает получать бОльшую зарплату как СПД и с этой зарплаты самостоятельно платить в пенсионный фонд на столько больше, на сколько вы хотите, чтобы у вас потом была пенсия?
или «халява» приятнее ? чтобы за вас кто-то другой заплатил? в данном случае, компания.

например, средняя зарплата в Украине 3-4 тыс грн, т.е. вы перечислите примерно 1200 грн в мес в пенсионный фонд. В итоге у вас будет средняя пенсия.
так вот получайте в конторе доход на свой СПД $2000 = 16 тыс грн и платите в пенсионный фонд, скажем, 5 тыс грн и будет у вас пенсия в 4 раза больше, чем средняя по Украине.
в чем проблема?

— платить налоги?
5% с оборота на СПД — это немаленький процент. конечно, на Западе платят больше налог, но он платится с прибыли. Но т.к. у нас будут злоупотреблять и показывать минимальную прибыль при огромных оборотах, то пришли к консенсусу, чтобы платить простой минимальный 5% со всего дохода.

P.S. бросайте привычки перекладывать свои проблемы на чужие плечи.

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

— до этого постановления мы сами всю сумму продавали на межбанке и учитывали курс НБУ на момент прихода денег.
т.е. налоговую интересовал курс НБУ, а не коммерческий курс, который устанавливался рынком, и считала максимальную сумму, с которой нужно заплатить налог (даже если курс межбанка оказался ниже курса НБУ, все равно заплатишь бОльше).

— после этого постановления, из-за этой технической детали (что деньги идут мимо нашего валютного счета), 50% поступлений будет считаться в налогах по курсу межбанка, а не курсу НБУ.
как-то не верится, что налоговая так позволит занизить свои расходы.

я объясню ситуацию, почему это важно.
например, валюта CAD продается на межбанке по курсу ниже НБУ.
получается после этого постановления, можно будет платить меньше налогов, т.е. для 50% валюты не будет применяться курсовая разница (которая всегда считается в пользу налоговой).
с другой стороны, курс межбанка — это коммерческий курс, т.е. он может быть любым.
Я могу продать валюту по любому курсу, потому что там есть механизм спроса и предложений как на базаре. Т.е. я иду на межбанк, выставляю заявку о продаже своих долларов по курсу заметно ниже курса НБУ. Представьте, что я договорился со своим банком или с покупателем на межбанке, чтобы он купил у меня доллары по этой цене (это ведь рынок). Итог — я занижаю свои поступления в грн, с которых считаются налоги.

как правильно считать в таком случае — я не знаю. Выше я просто выразил свои сомнения, что налоговая позволит занижать свои поступления.

т.е. если повезет, просканируем небольшую кучу данных, а если совсем не повезет, то 100% отсканируем.
я думаю, что на практике просто поставить LIMIT недостаточно.
а в теории фулскан есть фулскан, т.е. если теоретически оценивать временную сложность данного решения, то сложность = фулскану. А то, что иногда может повезти и не придется просматривать все-все записи, то это опять же не меняет сути решения.

т.е. LIMIT не решает поставленной задачи, и нужно что-то другое придумать, чтобы этот запрос более-менее нормально работал.

на практике такие запросы редко возникают, т.е. для конечного юзера они не настолько критичны и обычно условие идет сложное, что позволяет отсеять количество просматриваемых записей на раннем этапе, типа такого:
select .. from ..
where field1 IN (v1,v2,v3) AND field2!=1000
ORDER .. LIMIT

— с другой стороны, если будет просто WHERE field!=1000, то тут есть два варианта.

когда field2 — хранит ограниченный набор, т.е. некие константы
тогда field!=1000 переписывается как field IN (ограниченный набор).

когда field2 может хранить любое число, т.е. мощность множества почти бесконечна.
Но такой запрос нужно просто избегать делать и переделать логику, чтобы такого не было.
Представить себе запрос, когда пользователю нужно выбрать field!=1000.
Например, если field — это цена, то искать товары, у которых цена != 1000 как-то странно.
Обычно ищут по диапазону, WHERE field BETWEEN 500 AND 1000.
Если же field = бренд или категория товара, то это вполне жизненный запрос, когда хотят найти все товары, кроме заданного бренда. Но в этом случае поиск будет по ограниченному набору значений. И в UI это будет выглядеть как набор отмеченных брендов, т.е. поиск с позитивным условием (field IN (..)).

Общий вывод — не пишите такие запросы.
Если они у вас возникли, сначала подумайте, может с логикой/требованиями к приложению, что-то не так и задачу можно решить по-другому.