А я вот не понимаю как вы можете делать такие заявления. Но это не мешает вам их делать.
Я могу что-то заявлять или нет — и вы вполне можете это не понимать, НО(!!!) мои заявления — не являются уголовными преступлениями.
А вот поведение Вайнштейна — именно уголовное преступление. И многочисленные актрисульки, готовые залезть в Голливуд через известное место — своим молчанием покрывали уголовное преступление. Многократное. И это нормально — относиться к этому с недоумением в стране, где, как нам утверждают, превалирует торжество закона.
Ведь США любят выпячивать свою сверхзаконность и сверхподсудность во всех сферах, а тут у нас оказывается, что у них тоже "законы не всегда работают"? Что есть такое понятие как "определённые обстоятельства".
бояться открыто говорить о совершённом на тобой преступлении «более недостойным» чем само преступление
Своим молчанием они негласно — покрывали дальнейшие "преступления" Вайнштейна. Преступления в "кавычках", потому что странно говорить о преступлениях, если — нет заявления и пострадавших. А их не было.
Образно говоря — через Вайнштейна прошли десятки актрис. Но всё могло закончиться на первом-втором случае… И подобный конвейер бы кончился. Мы ведь говорим о США — где главенствует закон. Якобы.
Т.е. те первые Н, который "стыдливо молчали", продолжая "завоёвывать Голливуд" — довели до последующих десятков, которые раскрыли варежку тогда, когда уже и на них смотрят с недоумением — "чё вы тогда молчали и поощряли это, а открылись только сейчас? Десятки психологических травм из за вас, а вы теперь в героинь играете?"
Какая критическая масса нужна вам чтобы сохранить собственное самоуважение? Чтобы не сопротивляться насильнику? Чтобы спокойно взирать на начальство, которое кроет тебя матом тебе же в лицо? И не послать его в ответ.
Тем более сейчас — в век социальных сетей, когда новости о сложностях на трудоустройстве разлетаются мгновенно? Когда можно приложить фото долбодятла с комментарием — этот "супергерой" называется человек-говно. С человеком-говном у тебя не будет ни нормальной работы ни карьеры.
Как можно продолжать работать с человеком, который смешал тебя с говном и продолжает это делать? Как можно продолжать работать с человеком — который тебя изнасиловал? А некоторых и не единожды? Я не понимаю этого.
А почему только госорганизаций? А как же множество коммерческих продуктов разработанных в стиле: ПМ приходит и просит "Добавить вот сюда кнопочку", а потом радостно рапортует "фича имплементирована", хотя никакая кнопочка там нафиг никому не нужна.
Если честно эта статья мне напомнила популярный ныне хайп с продюсером Вайнштейном и #MeToo. Но, увы, в отличие от большинства людей я имею альтернативное мнение на эту проблему обвинения спустя годы…
Я не понимаю логику людей, которые продолжают сами унижать себя и собственное достоинство в процессе работы на кого-то в погоне за выгодой, а спустя Н прошедших месяцев или лет вопить: "ай-ай-ай, они — негодяи!" Если ты понял, что это "негодяи" сейчас — то надо уходить и кричать об этом сразу, а не спустя нанадцать лет.
Этим — ты не даёшь "негодяям" — пользоваться не только собой, но и другими людьми.
Это одинаково истинно как и для работников, которые договаривались и шли работать именно за 12 долларов в час и теперь плачут, что их не взяли в штат, хотя критерии взятия в штат были размыты изначально, и мирились из за этого с унижением и прессингом начальства, так же как и для неизвестных актрисулек, которые были готовы на всё в любых позах, а теперь, получив заветные роли и известность — вопят что "их изнасиловали". Неправда! Я видел в сети много фотографий с Ванштейном, окружённым улыбающимим актрисами (в том числе и теми, кто его сейчас обвиняет) и моё устоявшееся мнение — вы были если не за, то уж совершенно не против. И если, как вы утверждаете, это продолжалось годами — то именно вы, ранее безызвестные актрисульки, виноваты в том, что Вайнштейн регулярно вас имел. Т.е. вас надо судить вместе с ним.
P.S. Я считаю недостойным поведение Вайнштейна, но ещё более недостойным я считаю поведение актрис, которые молчали годами и этим — ему способствовали. И вылезли со своими обвинениями только сейчас — где вы были раньше?
Я сижу в опенспейсе, который был сдан в эксплуатацию в феврале (это о новизне). В 3 метрах от двери… И каждый день через эту дверь проходят десятки людей. Каждый день я слышу десятки раз эти клац-клац-клац автоматического запирания. Раз за разом, каждый день. Это — ;"(;№)(;№;)
Так что не надо мне врать про "современные материалы" и "хитроумную конфигурацию" — уж на чём на чём, а на этом НИКТО из застройщиков НЕ запаривается. Опенспейс — это НИ В КОЕМ СЛУЧАЕ НЕ "реально удобная для работы среда".
Если вам удобно сидеть, когда регулярное клацанье отвлекает вас от работы — вам повезло. Мне — увы, но нет.
Очевидно, по собственному желанию.
1) Не у каждого хватит нервов писать заявления в прокуратуру.
2) После написания заявления в прокуратуру интенсивность гнобления усилится.
Ээээ, а как задействуются нервы в написании заявления? Есть пример — пишешь по примеру. Бумага всё стерпит.
Усиливается давление — тогда заявления не просто демонстрируются, а ещё и реально идут в прокуратуру… А по каждому заявлению — прокуратура, насколько мне известно, ОБЯЗАНА проводить как минимум проверку.
В свою очередь проверки прокуратуры — это намного большие нервы для тех, кого проверяют.
Проверка раз, проверка два… в конце концов до самого тупого начальника дойдёт, что не надо гнобить людей.
Не увидел одну очень важную ошибку, которая звучит как "не оставление места для перевода". Суть в том, что переводимый на другой язык текст может иметь совсем другой размер — количество символов, пробелов, дополнительные знаки препинания, всевозможные крышечки, точки над буквами и умлауты и т.д.
И если изначальный текст может спокойно входить в определённое для него место, то локализованный, скажем, на тот же немецкий (когда в одно слово упихивается десять) — необходимо закладывать минимум процентов 30 места плюсом к длине самого текста и нельзя городить строки "одна сразу под другой".
Это часть процесса разработки, а не что-то, что нужно постоянно согласовать в с бизнесом.
С точки зрения пока ещё большинства людей из бизнеса всё, что не относится к внедрению новой функциональности или изменению старой для следования новым тендециям бизнеса или починки багов. Увы.
И казалось бы — да какое им дело до внутренностей проекта, если это им не видно — взял да поменял тихонечко. Да, это работает, но проблема возникает если требуемые изменения слишком глобальны, чтобы это можно было починить парой фиксов за один спринт. Приходится выбивать время из бизнеса.
Взять средний Enterprise продукт — куча кода с техническим долгом, legacy и сотнями и тысячами todo:"надо отрефакторить впоследствии" и todo:"вставил дамми-функцию — надо переписать". Порой (особенно если ПО писать начинали ещё в 90-тых) — сильно связанные. Любой decoupling — затрагивает сотни файлов, а те в свою очередь — другие сотни файлов. А значит — компиляция не проканает пока ты все концы не "подвяжешь" хотя бы на дамми функции. И в подобном продукте — TDD мог бы помочь… Если бы он был! Но писать его с нуля обходится в статье и кроме того означает не писать полезные для бизнеса функции какое-то время. То бишь вообще.
Добавим сюда — усилия QA, которые вы обязаны предупредить и которые должны порой вручную перетестировать дофига функциональности…
Вообщем почувствуйте на своём горле массаж руками уже двух подразделений (Бизнес и QA) и поймите, что разработчики "не любят" TDD по весьма очевидным и уважительным причинам.
Эффективнее — в сравнении с чем? На элементарном примере представленным автором — я никакого повышения эффективности не заметил. Мало того — не видно существенного улучшения ни одного из вышеперечисленных пунктов. Как распланировалась будущая архитектура приложения применительно к примеру?
Формально, для адекватного сравнения нужно взять сработавшуюся команду, разбить случайным образом на две и предложить сделать 10-ток проектов регулярно меняясь: сначала команда 1 делает с TDD, а команда 2 без, а потом меняться. И замерять эффективность и время. Только тогда можно будет говорить о корректном сравнении и повышении эффективности. А в том случае как вы это предлагаете — это эмоции и демагогия. Вам помогло — вы молодцы. Но есть команды, которые справляются без TDD — и у них тоже всё хорошо.
Это хорошо, если TDD вводится с самого начала проекта, а если нет? Если есть проект и хочется перевести его на TDD разработку?
Но даже в классической схеме — когда начинаем TDD тоже есть большой такой косяк о который бьются.
Вот есть приличных видов фича. Вы её получаете и садитесь писать для неё тесты. Для одной функции, второй… двадцатой.
Проходит неделя. Вторая. Спринт заканчивается, а конечного функционала — нету. То бишь — есть набор разрозненных функций, которые работают и условно оттестированы вашими же искусственными тестами. Но всё в одно работающее решение — не собрано (напомню, что фича большая). Кроме того в процессе собирания — есть шанс, что прийдётся часть функционала менять (кто не ошибается? Допустил неточность в проектировании и вуаля — изменения), а в процессе этого изменения — уже надо менять тестовые функции постфактум. Причём — каскадно. Одно меняет другое (с тестовыми функциями), захватывает третье (с ними же родимыми)… И понеслось. Добавление одного параметра — заставляет менять 5 функций. Немного, а если параметров 5? А если меняется интерфейс? В целом — работа ведётся, но функционала готового нет. Бизнес на написанные строчки кода — глазами лупает, истерит на тему "всех уволю!" и требуя "чтобы работало". Ведь с точки зрения бизнеса — продавать можно работающий функционал, необходимый потребителю, а не сопутствующую ему внутреннюю инфраструктуру, которая необходима только вам, чтобы удостоверять, что код "условно работает".
Апологеты TDD — подобные случаи сложного проектов обычно не рассматривают. Им ведь надо — кратенько показать, чтобы все вдохновились и ломанулись использовать и настанет дзен. Да и читать слишком большие портянки текста — мало кто будет.
Поэтому и "не любят" разрабы TDD — из-за банальной рутины, которая увеличивается каскадно. Любая смена интерфейса — ведёт переписку не пары-тройки, а минимум десятка функций (в том числе и тестовых).
Ну так компания на то и компания — что команды разные со многими людьми и разными приоритетами и задачами.
А если ещё — руководить взяли "пришлого", который пришёл вчера, а сегодня уже выдвигает стратегические решения — это вообще амбец. Но ведь боссам свою голову не вставишь. Они почему-то думают, что это работает.
Я потому и писал — надо растить своих специалистов. Дорого вначале и есть риски потерять, но зато — твой. Так не хотят.
У меня лет 10-12 назад была ситуация с международной компанией (казалось бы — педантичные и пунктуальные немцы), которая "продала красивую обёртку" — т.е. набор фич, которые были в принципе ещё не реализованы.
Сноска
Был продукт, который завоевал свой место на рынке и готовил силы на следующее завоевание. Предыдущее — позволило нанять топ-менеджмент со страшными зарплатами в год, которую я, боюсь, не заработаю за всю жизнь (ну да я пессимист). ХЗ зачем боссам компании понадобилось это, но… увы произошло.
В свою очередь нанятые топ-менеджмент — нананимал "себе помощников", что тоже прошло без внутреннего сопротивления боссов компании. И они начали продавать. Что делали, кстати, профессионально — ибо продали то, чего не существовало, что вполне логично, ибо продавали Программный Продукт.
Когда стало ясно, что "это они поторопились", бизнесу были озвучены риски и был задан вопрос — что важнее "поставить вовремя" или "поставить качественный продукт"? Бизнес ответил "поставить вовремя"!
"ОК" — сказали программисты и реализовали вовремя.
Знаете что потом случилось?
На версию с набором проданных фич — спустя три месяца пришлось выпускать патч, после чего, спустя полгода, ещё один, но страшно было не это. Страшно то, что с трудом заработанное доверие потребителей — было подорвано. Было даже несколько отказов, а продукт своё место на рынке подрастерял настолько, что пришлось ему закрыть как минимум наше подразделение, чтобы сохранить своё (немецкое) без разгона. Англичан, кстати — тоже разогнали.
Самое смешное, что нанятое бизнес подразделение — не разогнали. Оно постепенно разошлось само спустя пару-тройку лет. Самая главная нанятая тётка — ушла в другую компанию "продвигать новые горизонты".
Ну и выводы:
Фразой "озвучить риски бизнесу" — нельзя обольщаться. Потому что у бизнеса какое-то "своё мышление" и интерпретация ответов IT-команд. Вплоть до того, что твоя фраза "мы только на ресёрч потратим две недели" может быть истолкована как "через две недели — будет готов прототип". Сегодняшнее "впарить" — для них может быть важнее "репутационных потерь" потом. Они могут думать что-то типа "ай, выпустим дополнительный фик или патч" или "ай, подсадим клиента на сервис поддержки и будем потом регулярно доить" — не суть. Важно то, что они не программисты, не IT-шники. Разгребать за ними — будут совсем другие люди. Исполнители головой и руками того, что они всего лишь пообещали языком.
Нанятый бизнес (даже те, которые ранее работали в крутых компанях), которые "ищут новые челленджи" и приходят, чтобы "сделать хорошо" или "сделать ещё лучше" — увы ЗЛО. Да, список компаний, где они "раздвигали горизонты" может выглядить очень солидно и красиво, но важнее то, что случалось в этих компаниях во время и после того, как они оттуда ушли. Да, ты мог/ла порешать одну проблему/"раздвинуть горизонт", но этим — породить ещё десять. Но ты про них даже не узнал/а, потому что сделал/ла и ушёл/ла, а все остальные остались разгребать то, во что ты даже не вник/ла. Поэтому — свои кадры лучше всего готовить самому. Да это дорого, но зато специалист будет "в теме" и бесценен (в позитивном смысле).
Ну и то, что это был очень ценный опыт на самом деле. Опыт разработки в стрессовой ситуации, опыт увольнения после того, как тебе вещали "компания это семья" (бесценно!!! Рекомендую каждому! Потому что это меняет мировоззрение кардинально), опыт взаимодействия с бизнесом (ты сказал "а", за тебя додумали — весь остальной алфавит, а потом вменили тебе это в вину), ликвидация иллюзий, срыв шаблонов и куча ещё всего разного.
Так у бухгалтерии все сроки расписаны и процессы налажены уже десятилетиями: сдача квартального отчёта, годового, выплаты зарплат и т.д. Ситуации дополнения задач в этот пул имеются, но в целом — все критические дедлайны устоявшиеся.
Сравним это со взаимоотношения бизнеса и IT (т.е. уже ситуация, что кто-то от кого-то требует сроки), а именно ситуацию, когда бизнес уже "что-то кому-то продал" и сидят довольные, празднуя с шампанским удачную сделку, но вот теперь IT должен сделать из говна конфетку ровно к сроку Х (который определили даже не проконсультировавшись с IT) или внедрить новую фичу опять же к сроку Х, которую уже продали, чтобы бизнес не выглядели жуликами. И при этом надеяться, что внедряемая фича не рухнет хотя бы на презентации.
аргумент про ВЧЕРА работает только для маленьких проектов либо для проектов на начальном этапе
Нифига подобного. Аргумент "ВЧЕРА" работает со всеми видами проектов при низкой культуре знания бизнеса о процессах IT.
это ВСЕГДА рефакторинг и ВСЕГДА
Если имеется в виду постройки ПО по процессу "ВЧЕРА" — имеет место громадный технический долг и отсутствие выделения времени хотя бы на какой-то ГРАМОТНЫЙ рефакторинг в принципе, поэтому рефекторинг рефакторингом, но убирание старого костыля и вставка нового — рефакторингом считаться не может.
Мне вот что интересно — почему в подобных случаях "доказательств" в качестве примера обычно берут какю-то фигню в постановке задачи, которая пишется на 5-10 строк и на этом примере показывают "как всё клёво". И, типа, доказано! Вот вам и тесты и код и рефакторинг. Красота! Кушайте! Ну почему вы не кушаете?
Тогда как в реальном проекте бизнес зачастую требует фичу "чтобы это и это и ещё вот это было" и когда начинаешь писать эти 5-10-20 функций, а потом думать, что на эти 5-10-20 функций надо написать ещё 10-20-50 для тестирования — то TDD уже становится не столь привлекательным. Потому что бизнес требует ВЧЕРА, а на аргументы "тестирование", "чистый код", "рефакторинг" — смотрит на тебя как на идиота, которому нужны шашечки, а не ехать. Как будто ты фигнёй занимаешься для своего удовольствия, а единственные кто работает — это они. И они очень занятые, а у тебя так дохрена времеи, что ты в бирюльки играешь тут.
Хорошо если начальник/тим лидер — адекватный и сможет им доказать, что "это нужно", а если нет? (и один хрен — они будут на эти аргументы смотреть скептически, так что работает только начальниковское — мы будем делать так или идите в задницу и нанимайте других ПОГРОМистов).
Да я то как раз воспринимаю это естественным и считаю, что если кому-то что-то не нравится — достаточно лишь дать честно понять оппоненту, что его потуги не к месту. Но вот некоторые дамы с определённым интеллектуальным складом ума принимают это слишком близко к своей неокрепшей психике — отчего могут случаться конфликты в том числе и судебные.
А некоторые — пользуются этим, что с одной стороны запутывает ещё больше, а с другой подливает батхёрта другим.
Я могу что-то заявлять или нет — и вы вполне можете это не понимать, НО(!!!) мои заявления — не являются уголовными преступлениями.
А вот поведение Вайнштейна — именно уголовное преступление. И многочисленные актрисульки, готовые залезть в Голливуд через известное место — своим молчанием покрывали уголовное преступление. Многократное. И это нормально — относиться к этому с недоумением в стране, где, как нам утверждают, превалирует торжество закона.
Ведь США любят выпячивать свою сверхзаконность и сверхподсудность во всех сферах, а тут у нас оказывается, что у них тоже "законы не всегда работают"? Что есть такое понятие как "определённые обстоятельства".
Своим молчанием они негласно — покрывали дальнейшие "преступления" Вайнштейна. Преступления в "кавычках", потому что странно говорить о преступлениях, если — нет заявления и пострадавших. А их не было.
Образно говоря — через Вайнштейна прошли десятки актрис. Но всё могло закончиться на первом-втором случае… И подобный конвейер бы кончился. Мы ведь говорим о США — где главенствует закон. Якобы.
Т.е. те первые Н, который "стыдливо молчали", продолжая "завоёвывать Голливуд" — довели до последующих десятков, которые раскрыли варежку тогда, когда уже и на них смотрят с недоумением — "чё вы тогда молчали и поощряли это, а открылись только сейчас? Десятки психологических травм из за вас, а вы теперь в героинь играете?"
Какая критическая масса нужна вам чтобы сохранить собственное самоуважение? Чтобы не сопротивляться насильнику? Чтобы спокойно взирать на начальство, которое кроет тебя матом тебе же в лицо? И не послать его в ответ.
Тем более сейчас — в век социальных сетей, когда новости о сложностях на трудоустройстве разлетаются мгновенно? Когда можно приложить фото долбодятла с комментарием — этот "супергерой" называется человек-говно. С человеком-говном у тебя не будет ни нормальной работы ни карьеры.
Как можно продолжать работать с человеком, который смешал тебя с говном и продолжает это делать? Как можно продолжать работать с человеком — который тебя изнасиловал? А некоторых и не единожды? Я не понимаю этого.
А почему только госорганизаций? А как же множество коммерческих продуктов разработанных в стиле: ПМ приходит и просит "Добавить вот сюда кнопочку", а потом радостно рапортует "фича имплементирована", хотя никакая кнопочка там нафиг никому не нужна.
Если честно эта статья мне напомнила популярный ныне хайп с продюсером Вайнштейном и #MeToo. Но, увы, в отличие от большинства людей я имею альтернативное мнение на эту проблему обвинения спустя годы…
Я не понимаю логику людей, которые продолжают сами унижать себя и собственное достоинство в процессе работы на кого-то в погоне за выгодой, а спустя Н прошедших месяцев или лет вопить: "ай-ай-ай, они — негодяи!" Если ты понял, что это "негодяи" сейчас — то надо уходить и кричать об этом сразу, а не спустя нанадцать лет.
Этим — ты не даёшь "негодяям" — пользоваться не только собой, но и другими людьми.
Это одинаково истинно как и для работников, которые договаривались и шли работать именно за 12 долларов в час и теперь плачут, что их не взяли в штат, хотя критерии взятия в штат были размыты изначально, и мирились из за этого с унижением и прессингом начальства, так же как и для неизвестных актрисулек, которые были готовы на всё в любых позах, а теперь, получив заветные роли и известность — вопят что "их изнасиловали". Неправда! Я видел в сети много фотографий с Ванштейном, окружённым улыбающимим актрисами (в том числе и теми, кто его сейчас обвиняет) и моё устоявшееся мнение — вы были если не за, то уж совершенно не против. И если, как вы утверждаете, это продолжалось годами — то именно вы, ранее безызвестные актрисульки, виноваты в том, что Вайнштейн регулярно вас имел. Т.е. вас надо судить вместе с ним.
P.S. Я считаю недостойным поведение Вайнштейна, но ещё более недостойным я считаю поведение актрис, которые молчали годами и этим — ему способствовали. И вылезли со своими обвинениями только сейчас — где вы были раньше?
Пиликает, но лишь в половине случаев: только если проходить в помещение, если выходить — обычный клац.
Отвечу тут же и DMGarikk — вентиляции слава богам не слышно.
Я сижу в опенспейсе, который был сдан в эксплуатацию в феврале (это о новизне). В 3 метрах от двери… И каждый день через эту дверь проходят десятки людей. Каждый день я слышу десятки раз эти клац-клац-клац автоматического запирания. Раз за разом, каждый день. Это — ;"(;№)(;№;)
Так что не надо мне врать про "современные материалы" и "хитроумную конфигурацию" — уж на чём на чём, а на этом НИКТО из застройщиков НЕ запаривается. Опенспейс — это НИ В КОЕМ СЛУЧАЕ НЕ "реально удобная для работы среда".
Если вам удобно сидеть, когда регулярное клацанье отвлекает вас от работы — вам повезло. Мне — увы, но нет.
ИМХО, сыгранная команда, решившая много проблем — сама по себе достаточно ценна. Даже без самой главной "звезды".
Особенно если есть старые клиенты.
P.S. Очередной раз убеждаюсь, что если кадры не ковать — в конце концов фигня происходит.
Ээээ, а как задействуются нервы в написании заявления? Есть пример — пишешь по примеру. Бумага всё стерпит.
Усиливается давление — тогда заявления не просто демонстрируются, а ещё и реально идут в прокуратуру… А по каждому заявлению — прокуратура, насколько мне известно, ОБЯЗАНА проводить как минимум проверку.
В свою очередь проверки прокуратуры — это намного большие нервы для тех, кого проверяют.
Проверка раз, проверка два… в конце концов до самого тупого начальника дойдёт, что не надо гнобить людей.
Блин, жаль…
Но я потому и написал, что сходил бы из любопытства
С другой стороны — можно тянуть: Дддааааа… Неееееет… Демонстрируя неуверенность.
Я б сходил из чистого любопытства. К тому же на всякий вопрос можно ответить так, что не ответить :)
Не увидел одну очень важную ошибку, которая звучит как "не оставление места для перевода". Суть в том, что переводимый на другой язык текст может иметь совсем другой размер — количество символов, пробелов, дополнительные знаки препинания, всевозможные крышечки, точки над буквами и умлауты и т.д.
И если изначальный текст может спокойно входить в определённое для него место, то локализованный, скажем, на тот же немецкий (когда в одно слово упихивается десять) — необходимо закладывать минимум процентов 30 места плюсом к длине самого текста и нельзя городить строки "одна сразу под другой".
С точки зрения пока ещё большинства людей из бизнеса всё, что не относится к внедрению новой функциональности или изменению старой для следования новым тендециям бизнеса или починки багов. Увы.
И казалось бы — да какое им дело до внутренностей проекта, если это им не видно — взял да поменял тихонечко. Да, это работает, но проблема возникает если требуемые изменения слишком глобальны, чтобы это можно было починить парой фиксов за один спринт. Приходится выбивать время из бизнеса.
Взять средний Enterprise продукт — куча кода с техническим долгом, legacy и сотнями и тысячами todo:"надо отрефакторить впоследствии" и todo:"вставил дамми-функцию — надо переписать". Порой (особенно если ПО писать начинали ещё в 90-тых) — сильно связанные. Любой decoupling — затрагивает сотни файлов, а те в свою очередь — другие сотни файлов. А значит — компиляция не проканает пока ты все концы не "подвяжешь" хотя бы на дамми функции.
И в подобном продукте — TDD мог бы помочь… Если бы он был! Но писать его с нуля обходится в статье и кроме того означает не писать полезные для бизнеса функции какое-то время. То бишь вообще.
Добавим сюда — усилия QA, которые вы обязаны предупредить и которые должны порой вручную перетестировать дофига функциональности…
Вообщем почувствуйте на своём горле массаж руками уже двух подразделений (Бизнес и QA) и поймите, что разработчики "не любят" TDD по весьма очевидным и уважительным причинам.
Эффективнее — в сравнении с чем? На элементарном примере представленным автором — я никакого повышения эффективности не заметил. Мало того — не видно существенного улучшения ни одного из вышеперечисленных пунктов. Как распланировалась будущая архитектура приложения применительно к примеру?
Формально, для адекватного сравнения нужно взять сработавшуюся команду, разбить случайным образом на две и предложить сделать 10-ток проектов регулярно меняясь: сначала команда 1 делает с TDD, а команда 2 без, а потом меняться. И замерять эффективность и время. Только тогда можно будет говорить о корректном сравнении и повышении эффективности. А в том случае как вы это предлагаете — это эмоции и демагогия. Вам помогло — вы молодцы. Но есть команды, которые справляются без TDD — и у них тоже всё хорошо.
Это хорошо, если TDD вводится с самого начала проекта, а если нет? Если есть проект и хочется перевести его на TDD разработку?
Но даже в классической схеме — когда начинаем TDD тоже есть большой такой косяк о который бьются.
Вот есть приличных видов фича. Вы её получаете и садитесь писать для неё тесты. Для одной функции, второй… двадцатой.
Проходит неделя. Вторая. Спринт заканчивается, а конечного функционала — нету. То бишь — есть набор разрозненных функций, которые работают и условно оттестированы вашими же искусственными тестами. Но всё в одно работающее решение — не собрано (напомню, что фича большая). Кроме того в процессе собирания — есть шанс, что прийдётся часть функционала менять (кто не ошибается? Допустил неточность в проектировании и вуаля — изменения), а в процессе этого изменения — уже надо менять тестовые функции постфактум. Причём — каскадно. Одно меняет другое (с тестовыми функциями), захватывает третье (с ними же родимыми)… И понеслось. Добавление одного параметра — заставляет менять 5 функций. Немного, а если параметров 5? А если меняется интерфейс? В целом — работа ведётся, но функционала готового нет. Бизнес на написанные строчки кода — глазами лупает, истерит на тему "всех уволю!" и требуя "чтобы работало". Ведь с точки зрения бизнеса — продавать можно работающий функционал, необходимый потребителю, а не сопутствующую ему внутреннюю инфраструктуру, которая необходима только вам, чтобы удостоверять, что код "условно работает".
Апологеты TDD — подобные случаи сложного проектов обычно не рассматривают. Им ведь надо — кратенько показать, чтобы все вдохновились и ломанулись использовать и настанет дзен. Да и читать слишком большие портянки текста — мало кто будет.
Поэтому и "не любят" разрабы TDD — из-за банальной рутины, которая увеличивается каскадно. Любая смена интерфейса — ведёт переписку не пары-тройки, а минимум десятка функций (в том числе и тестовых).
Ну так компания на то и компания — что команды разные со многими людьми и разными приоритетами и задачами.
А если ещё — руководить взяли "пришлого", который пришёл вчера, а сегодня уже выдвигает стратегические решения — это вообще амбец. Но ведь боссам свою голову не вставишь. Они почему-то думают, что это работает.
Я потому и писал — надо растить своих специалистов. Дорого вначале и есть риски потерять, но зато — твой. Так не хотят.
У меня лет 10-12 назад была ситуация с международной компанией (казалось бы — педантичные и пунктуальные немцы), которая "продала красивую обёртку" — т.е. набор фич, которые были в принципе ещё не реализованы.
Был продукт, который завоевал свой место на рынке и готовил силы на следующее завоевание. Предыдущее — позволило нанять топ-менеджмент со страшными зарплатами в год, которую я, боюсь, не заработаю за всю жизнь (ну да я пессимист). ХЗ зачем боссам компании понадобилось это, но… увы произошло.
В свою очередь нанятые топ-менеджмент — нананимал "себе помощников", что тоже прошло без внутреннего сопротивления боссов компании. И они начали продавать. Что делали, кстати, профессионально — ибо продали то, чего не существовало, что вполне логично, ибо продавали Программный Продукт.
Когда стало ясно, что "это они поторопились", бизнесу были озвучены риски и был задан вопрос — что важнее "поставить вовремя" или "поставить качественный продукт"? Бизнес ответил "поставить вовремя"!
"ОК" — сказали программисты и реализовали вовремя.
Знаете что потом случилось?
На версию с набором проданных фич — спустя три месяца пришлось выпускать патч, после чего, спустя полгода, ещё один, но страшно было не это. Страшно то, что с трудом заработанное доверие потребителей — было подорвано. Было даже несколько отказов, а продукт своё место на рынке подрастерял настолько, что пришлось ему закрыть как минимум наше подразделение, чтобы сохранить своё (немецкое) без разгона. Англичан, кстати — тоже разогнали.
Самое смешное, что нанятое бизнес подразделение — не разогнали. Оно постепенно разошлось само спустя пару-тройку лет. Самая главная нанятая тётка — ушла в другую компанию "продвигать новые горизонты".
Ну и выводы:
Так у бухгалтерии все сроки расписаны и процессы налажены уже десятилетиями: сдача квартального отчёта, годового, выплаты зарплат и т.д. Ситуации дополнения задач в этот пул имеются, но в целом — все критические дедлайны устоявшиеся.
Сравним это со взаимоотношения бизнеса и IT (т.е. уже ситуация, что кто-то от кого-то требует сроки), а именно ситуацию, когда бизнес уже "что-то кому-то продал" и сидят довольные, празднуя с шампанским удачную сделку, но вот теперь IT должен сделать из говна конфетку ровно к сроку Х (который определили даже не проконсультировавшись с IT) или внедрить новую фичу опять же к сроку Х, которую уже продали, чтобы бизнес не выглядели жуликами. И при этом надеяться, что внедряемая фича не рухнет хотя бы на презентации.
Нифига подобного. Аргумент "ВЧЕРА" работает со всеми видами проектов при низкой культуре знания бизнеса о процессах IT.
Если имеется в виду постройки ПО по процессу "ВЧЕРА" — имеет место громадный технический долг и отсутствие выделения времени хотя бы на какой-то ГРАМОТНЫЙ рефакторинг в принципе, поэтому рефекторинг рефакторингом, но убирание старого костыля и вставка нового — рефакторингом считаться не может.
Мне вот что интересно — почему в подобных случаях "доказательств" в качестве примера обычно берут какю-то фигню в постановке задачи, которая пишется на 5-10 строк и на этом примере показывают "как всё клёво". И, типа, доказано! Вот вам и тесты и код и рефакторинг. Красота! Кушайте! Ну почему вы не кушаете?
Тогда как в реальном проекте бизнес зачастую требует фичу "чтобы это и это и ещё вот это было" и когда начинаешь писать эти 5-10-20 функций, а потом думать, что на эти 5-10-20 функций надо написать ещё 10-20-50 для тестирования — то TDD уже становится не столь привлекательным. Потому что бизнес требует ВЧЕРА, а на аргументы "тестирование", "чистый код", "рефакторинг" — смотрит на тебя как на идиота, которому нужны шашечки, а не ехать. Как будто ты фигнёй занимаешься для своего удовольствия, а единственные кто работает — это они. И они очень занятые, а у тебя так дохрена времеи, что ты в бирюльки играешь тут.
Хорошо если начальник/тим лидер — адекватный и сможет им доказать, что "это нужно", а если нет? (и один хрен — они будут на эти аргументы смотреть скептически, так что работает только начальниковское — мы будем делать так или идите в задницу и нанимайте других ПОГРОМистов).
Да я то как раз воспринимаю это естественным и считаю, что если кому-то что-то не нравится — достаточно лишь дать честно понять оппоненту, что его потуги не к месту. Но вот некоторые дамы с определённым интеллектуальным складом ума принимают это слишком близко к своей неокрепшей психике — отчего могут случаться конфликты в том числе и судебные.
А некоторые — пользуются этим, что с одной стороны запутывает ещё больше, а с другой подливает батхёрта другим.