Bash.org.ru IT Happens Истории ## 12001 – 12100

Вот восстановление системы. В Windows XP оно работало из рук вон плохо: как результат — потерянные библиотеки и огрызки приложений. Но чаще можно было увидеть сообщение: «Не удалось вернуть предыдущее состояние Windows».

XP начинает заметно подтормаживать уже через год с момента установки, а «семёрка» шустро работает в течение двух лет.

По большинству тестов Windows XP работает заметно медленнее.

Также стоит отметить, что за последние три поколения системные требования ОС заметно снизились, поскольку Windows 7 без тормозов запускается там же, где Windows Vista, а Windows 8 — там же, где и Windows 7.

Может, хватит заниматься некрофилией?

Время идёт. Windows XP прожила длинную жизнь. Но пришла пора нового железа и новых систем. Так пусть же Windows XP продолжает жить только на старых компьютерах. А на новые машины — новые системы!

Rest in peace, sweet Windows XP! Мы тебя никогда не забудем.

#12086: Как за неделю написать трёхмесячный проект

12:12 09.04.2014, IT happens

Процесс разработки программного обеспечения делится на четыре главных стадии: планирование продукта, разработка, тестирование, внедрение (то есть распространение, продажа, снятие сливок) — то, ради чего вся бодяга и затевалась. Если пропустить хоть одну стадию, продукт до конечного потребителя не дойдёт. Важное уточнение: момент перехода от одной стадии к другой необратим. Нельзя во время разработки менять планы этой же версии. Нельзя во время тестирования заниматься разработкой. Это краеугольный камень всей науки о создании программ.

А теперь — собственно, рецепт.

--------------------------------------------------------------------------------

Стадия планирования. Планировщики строят какие-то планы. Менеджмент эти планы утверждает, планы передаются отделу разработки.

Стадия разработки. Все работают согласно приготовленным планам.

Стадия тестирования и стабилизации. QA проверяют функциональность, согласно утверждённым планам, находят какие-то баги, разработчики их чинят.

Две недели до выхода Release Candidate. Приходит крутой спец из отдела продаж и говорит: «А я тут был на презентации конкурента, у них такая классная фича есть! Давайте, чтобы быть конкурентоспособными, мы забацаем вот эдакую фичу? Продаваться наш продукт будет в …дцать раз лучше! А без неё этот наш продукт вообще никто не купит».

«У-у-у… Без продаж нам будет туго. А давайте!» — соглашается менеджмент.

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

QA, скрупулёзно следуя планам, добираются до только что вписанного куска. Описанная в нём функциональность, естественно, не работает, потому что её никто не писал. Открывается баг на тему «Мегаважная фича не работает!!111»; ему присваивается экстравысшая категория важности.

Только тут разработчики офигевают от бага, смотрят в планы (которые не должны были меняться ни при каких условиях), офигевают ещё раз и интересуются: «Это ваще что было?! А нас кто-нибудь спрашивал?»

Всё это сопровождается беготнёй, мейлами через три континента, криками, воплями и инфарктами. Менеджмент убеждает разработчиков поднапрячься. Кого-нибудь делают крайним и спихивают весь проект на этого бедолагу. Он выполняет задачу, держась исключительно на кофе и на мотивирующих пинках начальства. Ну, как «выполняет»… За неделю трёхмесячный проект не написать. Поэтому пишется только good path, и новая фича будет работать, если пользователь ни в коем случае не попытается отойти от описанной в документах процедуры. Всё остальное (а 80% работы обычно занимает обработка граничных и нестандартных значений) закрывается заглушками — иногда прочными, иногда не очень. Поведение программы в том случае, если пользователь всё-таки отошёл от good path, вообще никем не гарантируется. Если повезёт, заглушка сработает, и пользователь ничего не заметит. Если не повезёт… Значит, не повезет. Программист сдаёт проект, получает премию и уходит спать.

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

Менеджмент радостно объявляет о включении новой функциональности в продукт. Продавцы готовят новые буклеты. Все счастливы.