В карьере каждого программиста случаются взлеты и падения. Наверняка у каждого есть пара запоротых проектов, каких-то конфликтных ситуаций, о которых сожалеешь, миллион проваленных по срокам задач, десятки технических решений, которые противоречили потребностям заказчика, многочисленные ситуации, когда вы поддались давлению, может быть, не совсем корректные увольнения и т.д. и т.п. С некоторыми людьми работа доставляет истинное удовольствие, их можно назвать профессионалами. С другими коллегами все идет наперекосяк. Почему такое происходит? Что входит в понятие “профессионал”?
За свою более чем 42-летнюю карьеру Роберт Мартин прошел огонь, воду и медные трубы и выработал принципы, которые, по его мнению, должен придерживаться программист, чтобы быть успешным профессионалом. В книге “Идеальный программист” он не боится делиться многочисленными примерами своих провалов и советами, как стоило бы действовать в таких ситуациях.
Внутри - тест, по которому вы сможете понять, насколько вы являетесь профессионалом по версии Р. Мартина.
Рецепты автора мало кого оставят равнодушными. Для многих они окажутся естественными. Многие найдут их просто безумными и глупыми. Что значит я не должен делать ошибки? Ошибки - это же нормально! А вот Роберт Мартин считает, что не нормально. Может ли хороший, но безответственный разработчик завалить проект? Что значит я должен в свободное от работы время много работать над развитием своих профессиональных знаний и навыков? Нет, я буду изучать нужные технологии прямо на боевом проекте! Профессионально ли вы повели себя, когда в последний раз согласились “постараться” под давлением менеджера?
Лично я в своей карьере наступил, наверное, на все возможные грабли. Я думаю, что эта книга была бы мне очень полезна и помогла бы мне из многих сложных ситуаций выйти гораздо лучше (или в них не попадать). Рекомендую всем эту книгу к прочтению.
Тем кто не читал или кто читал давно предлагаю пройти тест на предмет, насколько ваши принципы и ценности соотносятся с мнением Роберта Мартина. (Обращаю ваше внимание, что тест составлен только по первым двум главам).
Согласны ли вы с автором? Какой у вас опыт? Считаете ли вы, что советы Роберта Мартина правильные? Можете ли вы привести пример реальной ситуации, которая бы подтверждала правильность мнения Р. Мартина (или наоборот опровергала бы его). В целом было бы интересно в комментариях услышать примеры ваших факапов, но если есть пример ситуаций, из которых вы выбрались с честью и на которых можно чему-то научиться, - тоже пойдет.
Мы ищем таланты
В данный момент ЛАНИТ создает e-commerce интернет-площадку для продажи имущества. Ее можно сравнить с Amazon, но только на месте продавцов - государственные организации. Они будут выставлять на торги земельные участки, здания, автомобили и многое другое. Важно обеспечить максимальную прозрачность и открытость торгов, чтобы покупатели могли найти то, что нужно именно им, а государство - продать имущество по адекватной цене. Проект интересен и с технической точки зрения. Система будет функционировать под высокой нагрузкой - 24x7x365.
Если кому-то интересно поработать в высокотехнологичной команде, исповедующей принципы Канбан-метода и DevOps, то пишите мне в личку или нашим рекрутерам.
Комментарии (110)
andi123
10.08.2021 10:48+8Легко и просто быть профессионалом в компании других профессионалов.
Но в реальной жизни всегда приходится делать выбор, стоять на месте пока профессионалов подвезут или двигаться вперед. Если профессионализм рассматривать не как цель, а как путь. Тогда да, можно стремиться, но в текущий момент профессионалом тебя назвать будет нельзя.
Неожиданно подумалось, что по форме это практически религия. Не греши и будет тебе царствие. Ну а так как ты все равно грешник испытывай стыд и лучше старайся. А цель все равно будет за горизонтом как ни беги.
OnYourLips
10.08.2021 20:35+11У нас команды профессионалов (средний уровень выше сеньора в нашей), но я бы не хотел такого тимлида, как он.
Читал его книгу "Идеальный программист" много лет назад, на середине бросил, так как был не согласен с его манерой навязывания своей точки зрения. Мне он показался язвительным душнилой, не принимающим мнения, отличные от его мнений.Книгу читал очень давно, но помню через время его снисходительное отношение к менеджерам и аналитикам и "обязанность" программиста работать за них, "чтобы эти бестолочи ничего не испортили". Его основная проблема — отсутствие доверия к коллегам и синдром Д'Артаньяна.
По тесту 5/16, при этом "правильный" с точки зрения Мартина ответ почти всегда явный, но отвечал так, как считаю правильным лично я (выбирал наиболее близкий, в вакууме).
mad_god
10.08.2021 22:26-2Иногда нужно побыть и язвительным душнилой.
Говоришь: "Не стройте мост из этого материала, он развалится". А тебе говорят: "Какой-то вы токсичный, прислушивайтесь к молодым специалистам".
Говоришь: "Не поднимайте голову над окопами, застрелят же". А они всё равно поднимают. Наверное, надо и прикрикнуть в этом случае, нет?
OnYourLips
10.08.2021 23:32+3А почему вы считаете, что разбираетесь значительно лучше своих коллег в том, что является их профессиональной сферой, а вашей не является?
Тут либо огромный перекос в навыках сотрудников разных ролей (и, соответственно, полный и абсолютно всем ясный бардак в компании), либо некомпетентности коллег на самом деле нет, и она только кажется отдельно взятому ошибающемуся Д'Артаньяну.
В первом случае стоит валить, а во втором менять себя. Был в обоих ситуациях, к слову :)
Во втором случае переосмыслил и теперь стараюсь правильно выбирать работодателя, а уже после выбора максимально доверяю коллегам и уважаю их.
Gorthauer87
10.08.2021 11:03+28Тест прошёл, но какой блин из меня профессионал, не всегда согласен с мнением автора.
Он оказался из секты тех, кто верит в 100 процентное тестовое покрытие. Это многое говорит и о его профессионализме.
GospodinKolhoznik
10.08.2021 11:33+10Злые языки говорят, что он открыл компанию, где весь код писался по его принципам. Однако компанию это не спасло от банкротства.
Ну по крайней мере на почве писательства книг мужик явно преуспел.
sergeyns
10.08.2021 12:05+9Ну как говориться, если хотите стать миллионером, то напишите книжку "Как стать миллионером"
Savochkin Автор
10.08.2021 19:05-4Ну вообще логика автора достаточно категоричная, но в целом заставляет задуматься:
Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны? мне кажется логично...
Как вам гарантировать что функция будет работать? по мнению автора - это только написать автоматизированный тест. Вроде тоже логично, тк ручное тестирование - это долго, субъективно... сначала может и можно что-то протестить руками, но после некоторого времени протестировать руками все затронутые варианты становится просто невозможно
отсюда автор делает вывод, что нужно асимптотически стремиться к 100%... те понятно что 100% вы не получите, но цель ставить - 100%... ставить себе достаточный критерий, например, 70% - по логике автора неправильно
Сразу скажу, что я тут не рву на себе рубашку чтобы защитить точку зрения автора, на моем текущем проекте покрытие чуть более 70%, но фиг знает, может большее покрытие окажется более экономически эффективным.
Вообще у меня знакомый в фейсбуке работает, так у них в команде нет тестеров вообще. Разработчики сами все тестируют и выкатываю в прод. Как они это делают? У них это высокое покрытие кода автотестами + всякие там канареечные релизы. Честно говоря не знаю насколько это распространенная практика в интернет-компаниях, может тут есть кто от туда - поделитесь опытом? Может из гугла кто? или Яндекса? или из еще каких-то ИТ-компаний лидеров есть тут?
Gorthauer87
10.08.2021 21:51+6Так проблема как раз в категоричности автора, а его пункт про тесты просто наиболее ярко её показывает.
Излишняя категоричность это признак непрофессионализма. Так то.
Savochkin Автор
12.08.2021 21:07Почему категоричность - это признак непрофессионализма?
Gorthauer87
13.08.2021 01:30Это как минимум где-то рядом с максимализмом или фанатизмом. Думаю понятно, насколько эти качества могут быть опасны. Особенно, если они прямо ярко проявляются.
sshikov
10.08.2021 23:30+4>Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны?
Нет. Простой пример — у моего кода примерно 150 потребителей. Это разные команды, они используют каждая примерно (циферки условные) 1/5 объема фич кода. Таким образом, если я выпущу новую версию, в которой даже половина фич не работают (но я при этом точно знаю, какие именно), зато остальные скажем стали работать в 10 раз быстрее, то значительная часть потребителей будет весьма довольна, а остальные просто подождут выпуска еще одной версии.
И что может быть лучшим критерием, чем удовлетворенность потребителя? Выбирая между мнением Мартина и потребителя я лично не особо задумаюсь, к кому прислушаться.
А ваш пример про фейсбук вообще не очень удачный. У фейсбука в продакшн грубо говоря, может быть одна версия продукта. А у меня в продакшн условно 20 версий одновременно у 150 потребителей. Наверное, если взять whatsapp, то у них тоже много версий в эксплуатации, и разных потребителей столько, сколько людей с телефонами, так что главное, о чем я говорю — что продукты бывают разные. И критерии к ним применяются тоже разные.
Кроме того, у фейсбука на сайте иногда не работает десятки фич, так что к их мнению я бы, мягко говоря, вообще не очень прислушивался.Savochkin Автор
12.08.2021 09:15-1Представьте вы решили открыть свой бизнес и вам нужно чтобы вам запили ios приложение. Вы долго думали как вы будете его монетизировать, как привлекать пользователей и тд и тп. Оценили какие фичи вам нужны и когда. Наняли разработчика, он согласился все сделать, вы ему оплатили. А потом в он вам в оговоренную дату приносит приложение, но там 1/3 фич не работает.
А когда вы его спрашиваете - а почему так - он говорит, ну не страшно, подождите следующей версии, я тут решил что часть фич вам не очень нужна...
Не думаю, что вам это очень понравится.
Я понимаю бывают разные ситуации, форс-мажоры, но это исключение, а не правило. Скорее всего в случае форс -мажора я бы предпочел, чтобы разработчик как можно раньше бы рассказал о проблеме и я смог бы что-то предпринять - что-то переиграть, сам придумать какие фичи мне меньше нужны и тд и тп
sshikov
12.08.2021 10:29+2Вы не читали мой ответ целиком, правда же? :)
>продукты бывают разные. И критерии к ним применяются тоже разные.
Если для вашего приложения вам нужны все фичи — у вас другая ситуация, нежели у меня. Из этого ничего ровным счетом не следует по поводу моего профессионализма.
>форс-мажоры, но это исключение, а не правило.
Не вижу причин, почему это исключение? Для продуктов того типа, который я делаю, вполне нормально, что некоторые фичи не работают в некоторых версиях. Почему так? Потому что я знаю, сколько у меня потребителей, и их не бесконечно много, как пользователей у IOS приложения. И это свойство продукта, а не разработчика.
>Не думаю, что вам это очень понравится.
Заказчика устраивает. Вам в данном случае — это заказчику, а не мне как разработчику.Savochkin Автор
12.08.2021 11:49читал, хорошо давайте по вашему примеру
те у вас есть продукт, в котором есть , например, 100 фич
в какой-то момент времени вы с заказчиком принимаете решение, что вам нужно оптимизировать 90 фич - они будут работать быстрее/лучше, но при этом сломаются оставшиеся 10
заказчика и пользователей это устраивает, ок
вы ударили по рукам, вы начинаете работать
скажите, те 90 фич которые вы пообещали сделать, вы должны действительно сделать? или вы допускаете, что когда вы выдадите релиз, то из них процентов 30% могут не работать?
насколько обрадуется заказчик /пользователь, когда они получат от вас релиз и в нем будут работать только 50 фич, а остальные окажутся сломаны?
sshikov
12.08.2021 17:56+1>те у вас есть продукт, в котором есть, например, 100 фич
на самом деле возможно их 5 или 10. т.е. в общем-то я их вполне могу держать в голове, или записать. Я к тому, что тут нет экспоненциального роста сочетаний фич, когда непонятно, работает ли сочетание Ф11 и Ф87.
>скажите, те 90 фич которые вы пообещали сделать, вы должны действительно сделать?
Есть список того, что кто-то хочет. В нем есть приоритеты. Есть размеры команды, т.е. мы не можем делать 100 фич в месяц ну никак. Поэтому вполне вероятно, что какие-то фичи не будут сделаны никогда. Или просто потеряют актуальность, потому что будет найдено другое решение, лучшее. Но это вполне обычно вообще для проектов внутри компании. Делается то что нужнее.
>насколько обрадуется заказчик /пользователь, когда они получат от вас релиз и в нем будут работать только 50 фич, а остальные окажутся сломаны?
Оно на самом деле все-же не так выглядит. Ну вот реальный пример — у меня есть поддержка двух или трех СУБД. И 150 потребителей. Один или два или пять из них говорят — нам нужна вот такая доработка. Это потребители большие и важные, поэтому у доработки приоритет высокий. Они все на MS SQL. Мы им делаем версию, где поддержка оракла просто не тестируется, потому что мы заранее знаем, что не будем ее там внедрять, они ее довольные ставят — и у всех все вообще замечательно. Остальные, которым нужны (потенциально) сломанные фичи, просто не приходит в голову ставить себе эту версию, потому что они ее не заказывали, и не ждут. Ну т.е. оракл может быть даже не сломан — но мы его не проверяем, потому что зачем?
Ну т.е. при условии, что на версии большими буквами написано «на оракле не ставить» — какие вы видите потенциальные проблемы? Ну да, такой процесс годится не везде. Но для определенных проектов вполне себе годен.Savochkin Автор
12.08.2021 21:06Мне кажется то, что вы сейчас описали - это не совсем то о чем мы говорили выше. Мы говорили про то, что фичи которые вы пообещали сделать (или сказали, что сделали) - они должны быть реально сделаны.
Если разработчик говорит, что сделал фичу, а потом оказывается, что она не работает полностью или частично, то это не гуд.
В вашем примере вы в реальности у пользователей оракла ничего не сломали, для них просто релиз еще в работе. Это нормально, мы тоже так делаем - мы например не совсем готовые фичи часто выносим в продакшен, но в скрытом виде...
sshikov
12.08.2021 21:17+1>Мы говорили про то, что фичи которые вы пообещали сделать (ил
и сказали, что сделали) — они должны быть реально сделаны.
Сказали, что сделали и обещали в начале цикла — это вообще слегка разные вещи. Должны быть сделаны те, что фактически сделаны, протестированы, и анонсированы в release notes.
>В вашем примере вы в реальности у пользователей оракла ничего не сломали, для них просто релиз еще в работе.
Возможно что и так. Даже скорее всего — но тем не менее, по факту, если оно будет сломано полностью, это не является серьезной проблемой, потому что я точно знаю — кому можно этим пользоваться, а кому нет. В каком-то смысле мы даже можем выпускать экспериментальные вещи, которые работают в каких-то случаях, и не работают в других.
Опять же — на мой взгляд, это особенность проекта, что в нашей ситуации так можно. В другом проекте так скорее всего будет нельзя. Поэтому я и говорю, что продукты и проекты разные, где-то бывает не совсем так, как себе Мартин представляет, и это совершенно не значит что тут непрофессионалы априори. Реально надо смотреть, доволен ли заказчик или потребитель.Savochkin Автор
12.08.2021 21:31ничего принципиально не отличается у вас
ну давайте прямо совсем в лоб
допустим вы знаете что вашему VIP пользователю очень нужны 5 фич, вот позарез и прямо сейчас
вы их делаете и выпускаете в продакшен ( ну или они себе устанавливают)
если вы их реализовали отдали пользователям, то согласны же вы что эти 5 фич должны же работать полностью? а если они не работают, то это для вас должно быть как профессионала некоторым разочарованием?
неужели вы допускаете, что можете отдать пользователям 5 нужных и важных фич и при этом они могут не работать?
sshikov
12.08.2021 21:50Ну я согласен, что это в значительной степени дело формулировок. Просто, изначальная формулировка была вот:
>Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны?
Речь как раз про заранее, и про то, кто что допускает. Если заказчик или потребитель это решают, и их это устраивает — это одно, если программист по своему усмотрению — это другое. Ну и при этом, заказчика должен устраивать тот темп и качество (которое не только числом фич измеряется, обычно), с которыми реализуется продукт. То есть, вообще, все оценки, хорошо или плохо, они в большей степени должны исходить от заказчика. По сути, число неработающих фич это просто показатель качества. А кому как не заказчику его оценивать?
>а если они не работают, то это для вас должно быть как профессионала некоторым разочарованием?
Конечно. Но этому может быть много разных причин.
Скажем, считается нехорошим тоном тестировать в проме, правда? С другой стороны, в моем случае мои 150 потребителей — это 150 интеграций, с разными системами. И они все 150 существуют только там, в проме. В частности потому, что стенды разработки и тестирования примерно на порядок-другой меньше по всем параметрам. Поэтому 150 живых интеграций на них никогда не было и не будет — никто не готов платить столько денег за второй стенд, идентичный пром, столько же ядер и дисков, и еще 150 стендов для каждой участвующей системы, и кучу лицензий для них всех.
Да даже и не за стенд — я не могу вот себе официально установить где-то Oracle 11g, потому что эта версия уже не поддерживается, при этом промышленные системы на ней никуда не делись. То есть реальные особенности такой системы, когда они вдруг всплывают, я могу воспроизвести только в реальном окружении. Это накладывает свои отпечатки.
npokypatop
10.08.2021 12:05+7Тест прошла, таки 16 лет в индустрии, работодатели не жалуются, сейчас как подтвержу звание разраба. Ага, сейчас! Теория всегда далека от практики, увы
100% покрытия повеселили, как можно покрыть тестами то, что предсказать невозможно?
Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
Не согласная я, в общем, это все же тест про сферического программиста в вакууме, и даже не разработчика.
Savochkin Автор
10.08.2021 19:11+4>> Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
эээ ну там все совсем по другому вообще-то, даже есть пояснение в ответах ))
автор считает, что профессионал должен сам держать в руках свою карьеру, а не уповать на дядю, он должен сам стремиться развиваться и изучать то, что он считает правильным... если работодатель помогает, супер, это хорошо
мне кажется тут больше вопрос про пассивную/активную жизненную позицию в вопросе своей карьеры
Savochkin Автор
10.08.2021 19:40+1>> Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
это про черную пятницу?
ну вот я тоже так подумал, что все виноваты кроме я, но с другой стороны... например, заказчик, что он такого сделал? он просто сделал заказ, потом передумал. Все норм, имеет право.
Заказчик говорил, что функциональность будет простой, а потом усложнял и усложнял? Ну это просто классика жанра, такое вообще каждый раз почти происходит. Ошибка в том, что разработчик - соглашался (из лучших побуждений). Я много раз на это попадался но вот, думаю, это не свидетельствовало обо мне как он профессионале...
Автор считает, что разработчик профессионал должен говорить "Да, я успею" только если он действительно понимает что он успеет. Или даже он должен дать вероятностную оценку (об этом в других главах книги). Если он не понимает задачи/рисков, то он должен сказать - "я не знаю". Это будет сигнал для того, чтобы заказчик/менеджер уточнили бы требования и тд и тп.
Самое ужасное, по мнению автора, это то, что разработчик начал ухудшать качество. Тут просто у Р. Мартина есть мнение, что самое быстрое - это двигаться через максимальное качество. Почему - можно в книге почитать.
Кстати, в данном примере заказчик то не пострадал, им приложение и не понадобилось. Больше всего пострадал сам разработчик, который работал по 20 часов впустую.
Вообще прочитайте сами этот кейс в книге - там он анализируется гораздо более глубоко. Плюс почитайте саму реальную ситуацию - http://raptureinvenice.com/is-good-code-impossible/.Alexander63
11.08.2021 10:55+2По тесту - работа полностью оплачена. У заказчика сменились приоритеты, фирма выполнила заказ и получила оплату, разработчик получил за дикие переработки несколько месячных окладов.
По мне так - нормальная ситуация. По автору - разраб так делать не должен, фу фу фу ..
iiwabor
10.08.2021 12:14+6Стать профессионалом - это не главная цель в жизни, на мой взгляд. Гораздо важнее научится соблюдать баланс работа/личная жизнь.
tommyangelo27
10.08.2021 12:21+3При прохождении теста заметил интересный момент — на некоторые вопросы я понимаю, какой ответ соответствует профессионалу, и к чему надо стремиться. Но при этом, в реальной жизни я не всегда себя так веду. Причины разные — начиная от ситуации на конкретном проекте и заканчивая собственным эмоциональным состоянием.
Yaris
10.08.2021 12:48+3Примерно в половине вопросов не было нужного варианта, либо не хватало чекбоксов вместо radio button. Ну и 100% покрытие авто-тестами - это хорошо, это одно может обеспечить работой целые поколения.
navferty
10.08.2021 20:46+3Я вот даже поспорил бы с тем, что 100% - это хорошо. На любом крупном проекте (от 100 тыс. строк кода, если взять порог, указанный в одной из книг "дяди Боба") будет такой код, который покрывать тестами нерационально. Например, инфраструктурный/конфигурационный код, или код, который отвечает за интеграцию со сторонней системой (адаптер). Конечно, такие места должны содержать минимум логики, но стремление к 100% покрытию может привести к тестам ради тестов, ценность которых == 0, которые были написаны только для галочки. Отмечу, что эти тесты разработчик пишет в рабочее время, и за это время заплатил бизнес.
Также часто встречается ситуация, когда требования до конца не ясны, но функциональность нужно реализовать уже сейчас. Писать тесты на то, что почти гарантированно будет меняться в ближайшем будущем - тоже нерационально.
Поэтому считаю целевой уровень 70-80% оптимальным, это задаёт высокую планку: почти весь код с бизнес-логикой, скорее всего, будет покрыт тестами, но будет запас для того, чтобы не упарываться с "тестами ради тестов".
vedenin1980
10.08.2021 21:00+1Я вот даже поспорил бы с тем, что 100% — это хорошо.
Так это же был явный сарказмэто одно может обеспечить работой целые поколения.
Savochkin Автор
12.08.2021 21:12>> Поэтому считаю целевой уровень 70-80% оптимальным, это задаёт высокую планку: почти весь код с бизнес-логикой, скорее всего, будет покрыт тестами, но будет запас для того, чтобы не упарываться с "тестами ради тестов".
расскажите про ваш опыт? какое покрытие на вашем текущем проекте?удавалось ли вам достигнуть 80%? какие впечатления?
ktod
10.08.2021 13:24+4Поработать честных 5-6 часов на проекте и еще поработать 4 часа над над развитием навыков дома, а потом и выходные захватить? Жить когда? Мы работаем чтобы жить, а не живем, чтоб работать. Понятно, что работа тоже в удовольствие. Однако, скажем нет рабовладельцам.
зы: Да и вообще, в 45 на пенсию пора.
yewuv
10.08.2021 13:25+8По-мнению автора профессионалы оттачивают свои навыки на тренировке, а в ходе проектной деятельности их уже только применяют. Он приводит пример — хотели бы вы лечь к хирургу на операцию, который в ходе операции будет отрабатывать к-н приемы? Музыканты совершенствуют свое мастерство на репетициях, а не на концертах.
Вот только репетиции и отработка операций это часть рабочего времени хирурга и музыканта. И подобных передергов в этом тесте куча.tommyangelo27
10.08.2021 17:55+2Жаль, было бы неплохо порепетировать написание кода всей командой в рабочее время… Заранее, перед написанием реального кода.
DirectoriX
10.08.2021 19:37+2Да нет же, это хирургу нужно на досуге, после работы, операции проводить, мастерство повышать.
Savochkin Автор
12.08.2021 09:18наверное, здесь автор имеет ввиду музыканта, который зарабатывает концертами
vedenin1980
10.08.2021 13:41+6Как-то на одном проекте нужно было добиться 100% покрытия unit-test'ами, так вот 90% времени я потратил на покрытие того, что все равно никак сломатсья не могло (ну из разряда, есть чисто dto класс, которые просто хранит значения и никогда не будет содержать ничего другого, но мы проверяем, что записав значение, мы его же получим).
HellWalk
11.08.2021 11:00+1все равно никак сломатсья не могло
Раз столкнулся с хитрым багом, который пришлось долго выявлять, суть которого оказалась в том, что модель при простом создании и сохранении (без изменений) уже отличалась от изначальной.
По этому, я бы не стал говорить о том, что какой-то код не может сломаться. Практика показывает, что могут сломаться даже элементарные вещи.
vedenin1980
11.08.2021 11:53+1сломаться даже элементарные
Может, только скорее всего тесты это не покажут. Например, у нас к каждого data объекта генерировалось автоматически toString для отладки, мы знаем, что программе они никогда не используются и нужны только человеку в debug или логах.
С точки зрения формального 100% покрытия мы должны написать тесты на каждый сгенеренный метод, а потом их постоянно исправлять. Что хуже всего даже если мы добавим новое поле объекта и забудем его добавить в toString, в тестах мы его тоже можем забыть. Поэтому ничего полезного они даже для будущих изменений не несут.
Вообще, нужно понимать, что 100% покрытие тестами и легкость рефакторинга проекта вообще говоря взаимопротивопложенные понятия — если на каждый рефакторинг требуется сделать в 10 раз больше работы по изменению тестов — рефакторинг будет очень тяжелым.
То есть с одной стороны тесты до рефаторинга должны быть, чтобы видеть, что ничего не сломлось, с другой стороны тестов должно быть не очень много и они должны позволять достаточно быстро их поменять, иначе каждый рафакторинг будет огромной траты сил и времени.HellWalk
16.08.2021 10:06Может, только скорее всего тесты это не покажут
Если тесты не показывают ошибки в коде - значит код или тесты написаны плохо.
И как раз тесты в этом плане учат писать надежный код. Например, при написании тестов приходишь к выводу (и не я один), что, например, использовать afterSave()/beforeSave() в моделях Yii2 это плохой подход - потому что эти методы изолированно покрыть тестами нельзя.
Да и вообще, что Yii2 очень плохой фреймворк - потому что внутри методов постоянно встречается обращение к глобальному публичному Yii::$app объекту. Что, опять же, ломает изолированность метода, и, соответственно надежность теста на этот метод.
IkaR49
10.08.2021 14:08+2Прошел всё, но вместо того чтобы нажать на кнопку просмотра результатов случайно перезагрузил страницу. Второй раз проходить лень. Не люблю гуглоопросники.
LynXzp
10.08.2021 14:10+4100% покрытие это бессмысленно т.к. почти недостижимо и одновременно, как бы это не казалось странным, не покрывает все случаи. Допустим простой код:
if(a) b(); else c();
if(d) e(); else f();
if(g) h(); else i();
Сколько надо дать комбинаций входных параметром чтобы пройтись по всем веткам (сделать 100% покрытие)? 2+2+2=6. Но сколько всего возможных комбинаций выполнения веток программы? 2*2*2=8. На любой не тривиальной программе комбинаций запредельно большое количество. Хорошо если вызовы b() c()… stateless, а если stateful?
yukon39
10.08.2021 16:05+1Если поведение вашего "простого" кода не может быть столь же просто протестировано, то ваш код совсем не простой. Впрочем, Мартин позаботился, и у него есть для вас другая книга "Чистый код".
Simonis
10.08.2021 16:33Справедливости ради. Проектировать нужно так чтобы реализации, конфигурации и абстракции лежали отдельно и не были жёстко связаны. Конкретно в вашем случае нужно стремиться к тому чтобы тесты было возможно независимо реализовать для c f I и отдельно для b e h и тогда ни какие комбинации вам не будут страшны. Удивитесь, но степень покрытия при этом будет те же 100%
LynXzp
10.08.2021 16:45+2чтобы тесты было возможно независимо реализовать
Что делать со state машиной?Simonis
11.08.2021 06:00if(a) b(); else c(); fn real_implementation_b() { //do some staff } fn real_implementation_c() { //do some staff } fn stub_implementation_b() { //empty } fn stub_implementation_c() { //empty } fn wrong_way_implementation_b() { //throw Exception } fn wrong_way_implementation_c() { //throw Exception }1)unit test for real_implementation_b
2)unit test for real_implementation_c
3)unit test for a == true if(a) stub_implementation_b(); else wrong_way_implementation_c();
4)unit test for a == false if(a) wrong_way_implementation_b(); stub_implementation_c();
LynXzp
12.08.2021 00:43Я имел в виду что не только «a, b, c» взаимосвязаны, а все «a, b, c,… i». Например обработка какого-то протокола. Обработка следующих байт может зависеть от предыдущих, от флагов в пакете, от состояния после принятия предыдущего пакета и т.д.
Мне однажды пришлось сделать реализацию парсера очень маленького подможества xml (10-20 тегов), но чтобы он работал в т.ч. и на битых данных когда тег может не распознаться. Там такое количество условий в коде вышло что страшно. И несколько разных проходов парсером по данным и все в зависимости от предыдущей ситуации. Собственно говоря после написания и отладки этого кода я и пошел изучать юнит тестирование. (На самом деле получилось проще чем можно подумать, но связанность почти полная)Simonis
13.08.2021 06:29Честно говоря, мне кажется я не до конца понимаю. Если разговор о том что есть глобальный контекст который неявно влияет на b и с, а так же неявно изменяется внутри то это уже само по себе 'запах' 'не идеального' архетиктурного решения. Если мы говорим что у b и с есть большой набор параметров то это совсем не проблема. Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Грубо говоря, у вас рекурентный алгоритм который на вход получается параметры настроек и предыдущее состояние. Оценить юнит тестами работоспособность такого, как мне кажется, не сложно.
Внутри юнит теста вы можете легко задать начальное состояние системы, выполнить функцию и оценить состояние системы после.
В рамках текущего проекта в интеграционных тестах мы используем in memory db. В базе могут быть десятки различные сетов данных (а могут и не быть например). Этим мы задаём начальное состояние системы. Далее запускаем выполнение некой функции и проверяем конечное состояние в bd. С учётом что есть множество параметров которые для системы в целом могут быть заданы через конфиги и подсасывается например из переменных окружения.
Не совсем понимаю чем мой кейс принципиально отличается от вашего. Разве что уровнем исследуемых абстракций. У вас нужно протестировать функцию изменяющую состояние чего-то. У нас нужно проверить влияние/работу апи многослойного приложения.
vedenin1980
13.08.2021 11:57Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Проблема, что их будет не несколько. Комбинаторный взрыв же.
Представим, что у нас очень сложная функция, которая зависит от всех аргументов (а их штук 20) и каждый аргумент может принимать, скажем, 10 разных значений (это мы еще сильно ограничили, вещественные вообще имеют бесконечное количество значений). Функция в будущем может поменяться, так что мы не знаем какие значения важны, какие независимы и т.д., то есть для настоящего 100% покрытия нам нужно перебрать все варианты.
Можете подсчитать сколько нужно сделать тест кейсов, чтобы гарантировать, что мы перебрали все комбинации возможных аргументов и их значений? Обратите внимание, это всего лишь одна единственная функция.Simonis
15.08.2021 15:35Вы описали обычный реквест со стороны фронта к нашему бекенду. Приблизительно 20 параметров с огромным разбросом значений для многих из них. С параметрами пагинации со скрытой зависимостью от конкретного пользователя делающего запрос и общего состояния системы зависящего ещё много от чего.
Никто, находящийся в здравом уме, не будет тестировать каждый реквест для каждого значения входящего int double etc параметров. Вы будете тестировать функцию вычисления чисел Фибоначчи для каждого n ? Ну тогда вы сам себе Злостный Буратино.
Если вы не знаете какие значения важны значит вы не понимаете что делаете. Это часть искусства разработки тестов - умение определять важные пограничные условия.
Вы путаете. Тестирование всех комбинаций параметров и покрытие тестами.
Я не собираюсь гарантировать перебор всех возможных комбинаций потому что это глупость и трата времени. Я желаю гарантировать актуальные для приложения кейсы и дополнять кейсы в случае появления новых (тдд).
Это работа инженера гарантировать что он выполнил работы по внедрению нового функционала без регрессии на имевшийся ранее функционал.
100% покрытия говорит о выполнении всех веток а не всех теоретически возможных комбинаций. Ещё раз, потому что это бессмысленно и бывает только в теории. В крайне редких случаях на практике. Лично я с таким не сталкивался, но не отрицаю возможности таких случаев. Просто для них необходимо разрабатывать соответствующий подход в тестировании. Например крутящиеся вечно мутационные тесты с логированием падений и дальнейшем разборе, фиксации в тестах падающих кейсов. Даже нейронные сети с миллионами параметров умудряются тестировать вероятностными моделями. Ошибки первого/второго рода.
Пишите чистые функции. Детерминируйте состояния. Разбиваете сложные системы на независимые и простые. Разбиваете стейт машины на непересекающиеся простые.
Это все большое имхо, но в мире где 99% новых приложений это spa - аргументы о сложности и принципиальной невозможности покрывать функционал тестами малоубедительны. Ещё раз, это имхо.
Лично я не сторонник тдд и более того во многом его презираю. Особенно прицел на покрытие в 100%. Просто не нужно мешать холодное и мягкое.
LynXzp
13.08.2021 23:51О, спасибо, это я Вас не правильно понимал, теперь понял, был не прав с состоянием, его можно считать параметром, но сути это не меняет. Как заметил vedenin1980 тестирование даже одного метода может вылиться в невероятное количество тестов только для покрытия одних граничных случаев. Но под обычной метрикой 100% тестирования обычно понимают чтобы в тестах выполнился каждый оператор (так анализаторы уровень покрытия считают). И это далеко не то же самое чтобы протестировать n случаев входного параметра A, на m случаев входного параметра B, на…
Это то что я и имел в виду в первом сообщении. 100% тестирования каждого оператора добиться муторно, а еще это никак не полное тестирование всех граничных условий. И лучше покрыть пару дополнительных случаев чем все геттеры и сеттеры, как пишут выше.
Да конечно, такой код плохой где много параметров еще и которые могут изменится, и мы, программисты, стараемся спроектировать чтобы такого было поменьше, но увы не можем гарантированно исключить такое полностью.Simonis
15.08.2021 15:38Ответил выше.
Добавлю про сетеры и гетеры.
Пример сетеров и гетеров для входных параметров. В тестах вы обычно создаёте значения параметров через сетеры и через гетеры получаете значения при выполнении->Они покрываются тестами автоматически при покрытии тестами самого реквеста. Магия.
PsihXMak
10.08.2021 14:47+3Хаха, 5 правильных ответов. Вычёркивайте меня из профессионалов q(≧▽≦q)
(Видимо, автор книги живёт в своей вселенной с розовыми пони и единорогами)
siarheiblr
10.08.2021 14:55+11Безумно повеселил кейс с одноразовым приложением для чёрной пятницы.
Ага, я так и представляю Профессионала, который закатывает истерику по поводу того, что ему не дают для этой фигни полгода разрабатывать архитектуру и обеспечивать 100% покрытие тестами. Как и переносить релиз (зачем бизнес, какой бизнес, у нас тут покрытие не 100%). И тут же утверждения, что надо понимать, что и зачем ты делаешь.
Какой-то тест из Страны Розовых Единорогов.
tarekd
10.08.2021 16:56+5Не хотел бы я иметь в своей команде такого "профессионала". Проходишь к Васе с проблемой, а Вася тебе в ответ: я не буду делать костыль и закрывать проблему, нам нужно полностью переписать приложение, покрыть его тестами на 100%, потом 3 недели на QA.
Пример который лезет в голову:
NASA, несомненно там работают одни "профессионалы", которые покрывают всё тестами на 146% и своим "профессионализмом" оставили страну без пилотируемых полетов на 10 лет
SpaceX, где используют Linux, быстрое прототипирование и нацелены на результат, а не на способ его достижения https://youtu.be/bvim4rsNHkQ
Приятно работать с людьми, с которыми можно договориться и обсудить что реально а что нет. Ответ от разработчика типа "можем сделать патч за 2 часа, но будет какашка и никаких гарантий по граничным случаям, а можем сделать правильно за 2 недели" для меня более приемлем, дальше ответственность на тимлиде за принятое решение.
Savochkin Автор
10.08.2021 19:51+1Быстрое прототипирование никак не противоречит подходу Р. Мартина. Мало того, любимый автором подход XP прямо просто построен на том, чтобы делать маленькие фичи и быстро выпускать их в продакшен и получать обратную связь и тд.
Я как раз недавно читал книгу про Маска/SpaceX и там описано, что они на каждом своем запуске делают небольшие изменения и улучшения и очень много собирают телеметрии. А вы подумайте, сможете ли вы использовать "подход SpaceX" без автотестов? Если вы хотите делать небольшие изменения и выпускать их в продакшен, то вы просто обречены автоматизировать все и вся, в том числе и автотесты.
tarekd
10.08.2021 23:56+1Я не против автотестов и автоматизации всё и вся. Я против категоричности, которая присутствует в "правильных" вариантах ответов в опроснике. Не существует единственного "идеального" подхода. Посмотрите видео по ссылке, SpaceX потеряли десятки ступеней, прежде чем посадили ступень идеально. Не всё сразу делается идеально, не все сценарии можно покрыть. Как раз это я и хотел подчеркнуть сравнивая SpaceX и NASA. Вторые стараются сделать всё сразу идеально.
Когда горит задница, надо тушить, а не думать как же идеально потушить её. А уже потом основательно разбираться почему она загорелась.
Заглянул в оглавление, выглядит как будто не для профессионалов, а для детей в детском саду. Не хватает только главы как правильно ходить в туалет. Музыка, в книге для программистов? Может мне еще скажут какой IDE использовать и какую клавиатуру приобрести.
P.S. В чем разница с https://www.litres.ru/robert-s-martin/idealnyy-programmist-kak-stat-professionalom-razrabotki-po/? А то у меня лежит купленная.
TionRus
11.08.2021 03:49-1Кстати вот для SpaceX конкретно, автотесты имеют смысл, они в любом случае много тестируют, и скорее всего вручную, и переложить часть этой работы на машину выглядит неплохой идеей.
Savochkin Автор
11.08.2021 08:28+2>> Посмотрите видео по ссылке, SpaceX потеряли десятки ступеней, прежде чем посадили ступень идеально.
>> Как раз это я и хотел подчеркнуть сравнивая SpaceX и NASA. Вторые стараются сделать всё сразу идеально.
мне кажется мы тут про разное "идеально" говорим. Если SpaceX запускает ракету, то это не значит, что они ее делают тяп ляп... ну, например, плохо болтами двигатель прикручивают ))
если им что-то не известно, то они готовят эксперимент для того, чтобы опровергнуть или подтвердить гипотезу...
при этом если эксперимент в итоге окажется провальным по какой-то глупости или неряшливости (типа сборщик посчитал, что 30% болтов может отвалиться и фиг с ним), то я думаю, что это будет расценено как большой провал и всем мало не покажется )))
HellWalk
11.08.2021 11:26+4Проходишь к Васе с проблемой, а Вася тебе в ответ: я не буду делать костыль и закрывать проблему,
Я тот самый Вася, и сейчас расскажу, почему отказываюсь решать задачи костылями:
У вас, менеджеров, сроки горят всегда. Вам всегда срочно, и что самое главное - этой срочности нельзя угодить: делаешь за месяц - долго, надо за 2 недели. Делаешь за 2 недели - долго, надо за неделю, делаешь за неделю - и опять долго...
Практика показывает, что через год таких вот решений задач через костыли резко вырастает количество багов на проде. А кого будут ругать за это? Правильно, меня, разработчика. И при этом слова "а я весь год работал в сжатых сроках, мне не давали писать код по нормальному" - никого интересовать не будут. Более того, в лицо чаще всего и не говорят, а говорят за спиной "нет, ну вы представляете, какой Вася криворукий программист, наделал столько костылей и багов в коде - как его еще не уволили" - надо ли мне оно? Разумеется нет.
Программист учит менеджеров как им работать с людьми? Нет. Вот и пусть менеджеры не учат программистов, как им писать код.
sshikov
11.08.2021 17:08+1Кстати, делать как Вася это не так просто. Неопытный программист как раз скорее прогнется под запросы менеджера. Поэтому как раз человека, который спобен менеджеру так сказать, я бы назвал профессионалом. Он может ошибаться в данном конкретном случае — но он понимает, что завтра жизненный цикл не закочится, и ему с этим кодом жить дальше. Опять же — это вероятно значит, что он не намерен завтра срулить туда, где больше платят.
tarekd
11.08.2021 19:56Это ж в каких компаниях так? Аутсорс?
Я инженер, и пишу код на равных с инженерами. То что иногда делается как быстрая заплатка, заносится сразу в бэклог на рефакторинг/переделку на будущее. И называется осознанный технический долг. Размер технического долга всегда под контроллем. Порой даже выделяем отдельные спринты (обычно когда многие в отпусках и пилить новые фичи не имеет смысла) и разбираем техдолг.
Я нигде не писал что всегда нужно делать самым быстрым способом.
Попробую донести что я имел в виду изначально (мне сложно выражать свои мысли, не писатель я).
Приятно работать с людьми, с которыми можно найти несколько вариантов решения проблемы. И которые иногда могут пойти на хак, чтобы решить проблему. Если такое происходит, то я со своей стороны всегда ищу причину почему это так, и почему пришлось делать быструю заплатку.
Очень часто, как Вы правильно заметили, это исходит от ребят из бизнес команды. Пришел какой то срочный запрос от клиента, кто-то банально о чем то забыл, и так далее. Нужно разбираться в процессах и стараться уменьшать количество подобных явлений. Но не все сразу, учимся и эволюционируем с каждым отдельным случаем.
RomeoGolf
10.08.2021 18:13+2Отвечал честно (понимая, что ожидается) — получилось 6/10 и 2/6.
Руководитель обращает внимание на… проблему… и просит дать перечень конкретных действий
После пары таких «понятия не имею» будешь крудошлепать или переводить на фортран чужие формулы. Ничего ответственного не доверят, и правильно сделают.
Правильный ответ
Скажу, что не имею понятия в данный момент, что можно сделать и не могу обещать никаких сроковРуководитель обращает внимание на… проблему… и просит дать перечень конкретных действий по оптимизации уже послезавтра. При этом вы знаете, что сценарий… включает в себя вызов… процедуры СУБД, сопровождением которой занимается Павел.
А дожидаясь Павла уже ничего нельзя посмотреть? А может там, грубо говоря, тупо запятая не там стоит, или больше с меньше поменяно? Или, работая совместно с Павлом (достаточно тесно, чтобы звонить ему в отпуске), не удосужился хотя бы чуть разобраться в этой части на уровне «читаю со словарем»? Дожидаться придется и так, но можно чуть пошевелить-то чем-нибудь…
Правильный ответ
Придется дождаться Павла для получения рекомендаций по процедуре. К послезавтра получится подготовить только предложения по оптимизации java-сервиса и формы отображенияВаша компания получила… контракт на разработку… Вы успеваете к сроку, но Заказчик сообщает, что… он не будет выпускать приложение. Однако работа вам полностью оплачена. Кто в данной ситуации повел себя непрофессионально?
А чой-то? Работа выполнена, код попахивает, но вполне рабочий. Дайте время — он и попахивать перестанет. И полностью соблюден принцип «не навреди», ибо некому. И гонорар получен. Мы все-таки работу работать пришли, а не объяснять заказчику, почему он, наваривающийся на черных пятницах и способный выкинуть кучу бабла на неиспользуемый заказ, такой дурак и неудачник.
Правильный ответ
ВыМенеджер говорит, что фича должна быть готова через два дня и этот дедлайн очень важно выдержать. Вы точно знаете, что этого времени мало. Выберите вариант, который наиболее близко соответствует вашему поведению на реальном проекте.
Опять же, после пары таких «настаиваний» не доверят ничего серьезного. И далеко не пару раз было, что выполнял за два дня работу, на которую по хорошему неделю-полторы надо. Честно предупредив, что можно не успеть. Но успевал.
Правильный ответ
Я сообщаю менеджеру, что двух дней мало и настаиваю на том, что работа не будет выполнена к дедлайну
Про 100% покрытие тестами уже только ленивый не сказал. Непрерывный рефакторинг — туда же.
А клятва Гиппократа принципу известного стоика не противоречит ващще никак. Делай, что должно — и не вреди.Savochkin Автор
10.08.2021 20:00+1>> После пары таких «понятия не имею» будешь крудошлепать или переводить на фортран чужие формулы. Ничего ответственного не доверят, и правильно сделают.
по условию вопроса вы не знаете, что можно сделать, чтобы решить проблему
даже наоборот, вы считаете, что решить ее не удастся
автор считает, что если вы в этом случае руководителю скажете, что вы все же знаете как решить проблему - то вы его просто обманете...звучит логичноRomeoGolf
10.08.2021 20:10+6Я не скажу, что знаю, как решать. Я скажу, что не знаю, как решать, но это не значит, что я не буду ее решать. У меня, черт подери, 85% задач — я не знаю, как решать! Работа такая. А поэтому сейчас мне надо подробности, в чем именно проблема, чтоб сузить зону поиска, а потом я предприму следующие шаги: 1, 2… И, например, часа через 4 либо исправлю ошибку, либо дам примерный срок на доработку, либо скажу, что больше тут ничего не выжмешь. А не «понятия не имею, что тут, понятия не имею, сколько надо» — это может сказать любой детсадовец в штанах на лямках. Да, я неимоверно не люблю оценивать сроки. Но профессионализм и в этом тоже, а не только в топтании батонов.
Savochkin Автор
10.08.2021 20:27+1ну так все правильно, ровно так Р. Мартин и советует делать
но сначала вы должны сказать, что в данный момент не знаете как ее решить, но дальше уже будете продолжать разговор... предлагать варианты что можно сделать и тд и тпRomeoGolf
10.08.2021 20:41Я сообщаю менеджеру, что двух дней мало, но так как дедлайн очень важно выдержать, то соглашаюсь попробовать приложить все усилия успеть вовремя
vsПравильный ответ
Почувствуйте разницу! Представьте, что вы на планерке/митинге/летучке/стендапе/оперативке (нужное подчеркнуть). У вас от силы полчаса на то, чтобы накидать план ближайших действий. «Настаиваю» в упомянутых условиях непременно упирается в «контрНастаиваю» (нет, уж ты непременно сделай!) или в поиск менее «настойчивого» специалиста и с учетом этого занимает минут 20. Вы, как профессионал, настаивать пришли или работать? Я буду ворчать, вонять, всем токсично рассказывать, что так дела не делаются, и я точно сорву сроки, потому что тут не меньше недели надо, но это будет в процессе и после работы.
Я сообщаю менеджеру, что двух дней мало и настаиваю на том, что работа не будет выполнена к дедлайну
Давайте вернемся к любимым Мартином хирургам. Вы бы предпочли, чтоб хирург сказал «неоперабельно, я настаиваю» и ждал уговоров, или все-таки дал шанс выжить и попробовал? В нашей работе встречаются такие «два дня», которые не из-за хотелок заказчика, у которого навар в черную пятницу срывается, а, скажем, всплыл косяк в медицинском приборе или самолете, или АЭС, или еще где. Примеры грубые, но все же.
Не очень давно поругался немного с начальником. Именно такая ситуация — «у тебя 2 дня», а работы недели на полторы. Взялся, сказав, что это вообще не реально. Сделал. За 2 дня. Ругался в процессе и несколько дней после. А потом на «ну ты хоть понимаешь, что тут было не меньше недели работы» получил «а я потому к тебе и подошел, а не пацанам отдал». Может, профессионализм — он ближе сюда?Savochkin Автор
10.08.2021 20:55+1у Мартина целая глава есть про то, что не надо пытаться...
это разработчик думает, что я сказал попытаюсь, значит он ничего не обещал, а с точки зрения менеджера это часто означает - да я обещаю, что сделаю
конечно, он пишет, что и сам менеджер в этом случае поступает непрофессионально, тк это распространённый косяк
по мнению Мартина лучше исключить всякие недомолвки и сказать четко свою позицию, что-то типа - я не гарантирую выполнение к данному сроку по тому-то и тому-то, наиболее вероятный срок такой-то, пессимистичный срок такой-то... вот что я предлагаю сделать дальше, чтобы внести большую ясность
как вы видите речь вовсе не про "воняние" и неадкват, а просто четко артикулировать положение вещей
RomeoGolf
10.08.2021 21:04+1Это дао программирования. Лучший код — ненаписанный код.
Недеяние на самом деле есть именно деяние, притом весьма активное, соответствующее законам природы — соответствующее дао
И все это очень хорошо, и в этом много мудрости и философии, но что вы будете кушать зимой? Пуговицы от штанов? За настаивание на том, что не надо и пытаться и размахивание томиком Мартина зарплатку не платят. Хотя… Вы в этой статье к себе зовете. Если у вас так работают, я бы хотел попробовать :-)
Хотя, делая за 2 дня действительно важную и правда срочную работу, иногда кажется, что все-таки не в одних деньгах дело. Да и уровень будет расти только тогда, когда отодвигаешь границы попыток в область невозможного. Раньше говорили «выше головы не прыгнешь», а Лацискене уже за 2 метра прыгает.
tommyangelo27
10.08.2021 22:29+1Давайте вернемся к любимым Мартином хирургам. Вы бы предпочли, чтоб хирург сказал «неоперабельно, я настаиваю» и ждал уговоров, или все-таки дал шанс выжить и попробовал?
Но при этом негативный исход намного более вероятен (по условиям задачи). Может в такой ситуации всё же можно попробовать консервативное лечение?RomeoGolf
11.08.2021 04:29Вы цепляетесь к словам в аналогии. Остается еще фамилию хирурга назвать… Да, негативный исход более вероятен. Но если не делать вообще ничего — негативный исход неизбежен. А пока «настаивают» и выбирают другие методы (кстати, какие консервативные методы можно предложить взамен отладки и кодинга?), время уходит, а это ресурс невозобновляемый. И военно-морской пушной зверь все ближе…
tommyangelo27
11.08.2021 08:17+1Вы цепляетесь к словам в аналогии
Совсем нет, я просто продолжаю её. Если вообще без аналогий — у меня в карьере неоднократно случались ситуции, когда лично я говорил «Попробую, но ничего не обещаю», потом тратил полдня-день-два, и действительно ничего не удавалось сделать. Иногда даже приходилось останавливаться совсем и говорить «Тут ничего не поделаешь, данная реализация не позволяет сделать то, что вы хотите».
Итог — время (ресурс невозобновляемый) потеряно на задачу, которая изначально была нерешаема, а другие задачи, решаемые, задерживались. И проект от этого страдал.
Savochkin Автор
11.08.2021 08:38+2я бы даже еще такую аналогию предложил:
вы приходите к хирургу, он видит и понимает, что операцию он сделать не сможет
если он вам прямо скажет об этом, то у вас есть вариант пойти найти другого хирурга, например, или вы можете ообще отказаться от операции и решить что лучше "дожить" так, чем рисковать
если же данный хирург ничего вам не скажет, а просто решит "попытаться", то он лишает вас возможности выбора и не факт, что сделает лучше тем самым
если вернуться к софту, то мне кажется идея Мартина именно в этом - профессионал должен честно дать обратную связь на основе которой менеджер/заказчик могли бы также предпринимать свои шаги
если разработчик просто молча соглашается и не доносит реальной ситуации, то он тем самым может навредить
во всяком случае, я, как менеджер, предпочел бы разработчика, который мне будет говорить "правду"
RomeoGolf
11.08.2021 09:19Профессионал делает из нерешаемой задачи решаемую. Настаивать на невозможности решения может кто угодно. Про «молча соглашается» — это вы только что придумали, я этого ни разу не утверждал, более того, везде говорил обратное.
А возьмите, как менеджер, меня, как программиста, на работу? Я умею профессионально отказываться решать любые задачи на любом языке программирования, профессионально (и аргументированно) настаивать на невозможности их решения и профессионально говорить «правду»…
Savochkin Автор
10.08.2021 20:03+2>> Опять же, после пары таких «настаиваний» не доверят ничего серьезного. И далеко не пару раз было, что выполнял за два дня работу, на которую по хорошему неделю-полторы надо. Честно предупредив, что можно не успеть. Но успевал.
Вот честно предупредив - это и есть "настаивал". Настаивал - это не значит, сел и плакал пока не дадут 2 недели. Это значит, что четко описал риски и диапазон наиболее вероятных сроков и риски. Мне кажется это логично, Заказчику лучше знать риски - так он сможет сам решить что с ними делать, принять или как-то попробовать устранить.
RomeoGolf
10.08.2021 20:13+2Вариант «Я сообщаю менеджеру, что двух дней мало, но так как дедлайн очень важно выдержать, то соглашаюсь попробовать приложить все усилия успеть вовремя» считается неправильным. А это — честно предупредил и попробовал. В правильном варианте надо (судя по отметенному неправильному) именно что кричать «я — идеальный программист из Артаньяна, а вы идите в дупу, потому что двух дней тут мало, Я сказал!»
sarapinit
10.08.2021 19:10+2Коллеги, я новичок в IT, занимаюсь разработкой менее 42 лет. Объясните мне, пожалуйста, вот что. Почему мнение Роберта Мартина стоит считать значимым? И еще такой, вопрос, хотели бы вы чтобы он побыл какое-то время вашим ментором? А если не он, то кого из авторов вы бы хотели пригласить к себе в качестве ментора, если бы была такая возможность?
assad77
10.08.2021 21:38+1По поводу менторства не знаю, но с удовольствием лично обсудил каждый пункт.
Например непрерывный рефакторинг, вопросы по срокам очень интересны.
Идеальный программист это скорее зло как и идеальный код. Просто нужно понимать почему идешь на компромиссы.
Но, например, ценность непрерывного рефакторинга от меня ускользает. Особенно в крупных кодовых базах с совместным использованием кода.
Если же пишешь код один, то, честно говоря, вообще это все это ерунда. Делаешь как делается. В этом случае ты сам понимаешь что нужно.
Aleksandr-JS-Developer
10.08.2021 21:45А вы как думаете? Инстинкт самовыживания и лень.
Смотрите, человек долго что-то делал, добился "успехов", стал консультантом (не обычным, а международным!).Собстно, раз он вроде жив, зарабатывает, пишет книги (точно очень умный мужик, правда?), то его модель поведения удачная и вам подсознательно неплохо бы её повторить. Не надо ничего придумывать нового, вот оно, на блюдечке. Только вот закавыка в том, что обстоятельства - другие, люди вокруг - другие, ситуация в мире - другая, время - другое да и в конце-концов вы - другой.
Отсюда вывод, что мода на "истории успеха человека Х" основана на старом-добром инстинкте самовыживания и лени. А по-факту повторить её не представляется возможным ввиду абсолютно другого контекста.
Плохо смотреть такие истории? Не знаю. Но скорее "нет", чем "да". Что-то полезное вы для себя найдёте. Но ломать какие-то свои фундаменты ради следования идеям человека с абсолютно другим контекстом, как по мне, опасно.
Вся история развития человечества основана на принципе увидил-повторил. Вася в условном мезозое животных не убивал сразу, а приводил домой и спаривал. Теперь у Васи есть стадо и он не умрёт с голоду зимой. Перспектива неплоха, согласитесь. Так почему-бы не повторить?
sshikov
10.08.2021 23:45>Коллеги, я новичок в IT, занимаюсь разработкой менее 42 лет.
>Почему мнение Роберта Мартина стоит считать значимым?
Я занимаюсь разработкой чуть более 42 лет. И мой ответ простой — никто не знает всех сторон разработки. А их много, и они разные. Более того, он написал множество книг, а мой опыт мне подсказывает, что это такая же работа, как программирование, и она отнимает кучу времени. Вывод — много времени Р. Мартин потратил на написание книг, а не на разработку. Повышалась ли его квалификация, как разработчика, в это время? Очевидного ответа у меня нет. Вы бы хотели, чтобы вашим ментором стал писатель, или разработчик?
Так стоит ли? Простой ответ — стоит попытаться понять, на что он обращает внимание, какие вопросы ставит и как пытается отвечать, особенно если при этом вы, как новичок, их себе даже не задавали еще. Прочитав книги, вы все равно не приобретете авторский 42-летний опыт. И даже что-то возможно просто не получится понять.sarapinit
11.08.2021 07:25Вы бы хотели, чтобы вашим ментором стал писатель, или разработчик?
Хотел бы чтобы им был тот кто может научить). К Мартину бы не пошел, кажется что у него очень «черно-белое» отношение к разработке. А вот к Макконеллу, с удовольствием.sshikov
11.08.2021 10:29>К Мартину бы не пошел, кажется что у него очень «черно-белое» отношение к разработке.
Есть такое. Но меня скорее смущает то, что он очень много времени уделяет не разработке. Это непременно сказывается на самой разработке.
sarapinit
11.08.2021 07:31Я занимаюсь разработкой чуть более 42 лет
Это долгий срок, даже дольше чем я живу) Поделитесь, если не секрет, остался ли у вас интерес к профессии или вы продолжаете это дело по инерции? Сейчас тренд на разочарование в IT, многие демостративно уходят.
Интересно узнать мнение человека, который остается.sshikov
11.08.2021 10:27Остался. Я все еще узнаю много нового, даже в своем хорошо знакомом деле. Я попутно являюсь владельцем продукта — но разработка это то, чем я хочу заниматься. Как владелец продукта я вижу слишком много бюрократии, и других вещей, которыми заниматьсяч не хочется.
Aleksandr-JS-Developer
10.08.2021 21:29+2Интересно, что под "Профессионалом" все (даже Википедия) подразумевают высококлассного специалиста, истинного знатока своего дела, идеал, к которому надо стремиться.
Хотя, имхо, слово "Профессионал" имеет происхождение от слова "Профессия" и подразумевает человека, который достиг такого уровня, что знания в какой-то области позволяют ему зарабатывать, работая только в этой области...
MacIn
10.08.2021 22:52Из любопытства прошел, но вопросы странные.
Отчасти вопросы продублированы по сути (например, про отсутствующего коллегу и подобные «дедлайн завтра»- все о том, что не стоит приносить качество в угоду срокам).
Часть вопросов нужно воспринимать в контексте работодателя. Например, о самосовершенствовании — из «правильных» ответов на вопросы следует, что хороший специалист «где-то там, дома сам» будет по 40 часов в неделю повышать свою квалификацию, а потом придет с новым знанием на проект. Нет, нанимателю это удобно: вот мне надо реализовать какой-то протокол, по этой логике я должен перед сном проштудировать RFC, попробовать завести pet-project, где в виде MVP реализую нужное, а потом приду и в рабочие 8 часов Блестяще Решу Задачу.
Пасибки, но нет: свободного времени в сутках — меньше 8 часов, и жизнь конечна. Разумеется, я изучаю что-то по профессии, но из сугубо интересного мне.
mvv-rus
10.08.2021 23:03Что-то мне этот разговор за профессионалов навеял воспоминания про старую-старую статью про Настоящих Программистов. Вот эту: «Настоящие программисты не используют Паскаль».
Пока существуют плохо поставленные задачи, странные
ошибки и нереалистические расписания машинного времени, будут
находится настоящие программисты, желающие взять на себя и
решить проблему, оставив документацию на потом.
Да здравствует Фортран!
onets
11.08.2021 00:11+5Ерунда какая-то...
У профессионального программиста не бывает семьи, потому что он изучает новые технологии во вне рабочее время.
В смысле я должен испытывать удивление и огорчение, что у меня багу нашли? В моем коде тестировщики находили такие баги, что даже я не догадался бы, что такое возможно, лично написав код. Это может вызывать только восхищение из профессионализмом.
100% покрытия кода тестами - это как достичь скорости света. Уйма энергии в никуда, правило Парето и тут хорошо работает.
Может пускай Павел пишет читабельный код в хранимках? Да и пока я не заглянул в код хранимки - я не могу сказать разберусь иои нет. И вообще, хранимки у нас теперь антипаттерн.
Вопросы про менеджеров - полностью зависит от того, какой человек этот менеждер. Некоторым достаточно сказать «я попробую, но не обещаю», а не стучать на него высшему руководству.
TionRus
11.08.2021 03:38+2Заголовок провокационный. И в тест включена "дичь", похоже намеренно, чтобы было как можно больше комментариев и обсуждений.
Pavel1114
11.08.2021 06:10Рад что на хабр не верят слепо авторитетам.
Начинал одно время смотреть видео «дядюшки Боба». Но не зашло — категоричность высказываний по любому поводу сразу отталкивает и настораживает. Хотя человек он очевидно очень умный.yukon39
11.08.2021 11:00Такой метод довольно удачен при работе на широкую аудиторию:
Внушаемой аудитории транслируются максимы, к которым потом отдельные представители этой аудитории будут стремится.
Критичная аудитория получив набор максим переосмыслит их и применит к себе.
ИМХО, у обсуждаемой книги полное название "Идеальный <сферический> программист <в вакууме>" - недостижимый идеал, который и должен быть сформулирован в категоричной форме.
А вот реальность и путь к этому идеалу у каждого свои.
megahertz
11.08.2021 08:34+2Надо понимать, что Дядя Боб использует очень популярный в западной мотивирующей литературе принцип авторитетного мнения, когда какой-то подход описывается как единственно верный. Такие, главные секреты успеха. Подобные книги обычно гораздо лучше продаются, потому-что достаточно легко читаются, не заставляют читателя напрягать мозг. Плохо это или хорошо решает каждый для себя. Ценность этого теста минимальна, он больше подходит для развлечения. Тем-не менее, если критически рассматривать его книги, то можно почерпнуть много полезного для себя.
StanEgo
11.08.2021 22:08Все пропало... столько лет стараний и стертые до крови пальцы... Звание идеального ушло от меня куда в вакуум, осталось довольствоваться скромным титулом реального программиста.
n0isy
Вычёркивайте меня из профессионалов: мне стало скучно на 3-4 вопросе, а там их 3 страницы...
PsyHaSTe
Same here. Кроме того вопрос "Какой уровень покрытия кода автоматизированными тестами вы считаете достаточным?" с конкретными вариантами ответа, и отсутствует ответ "никакой". Видимо, Мартина обошли стороной системы с 200% покрытия кода, которые все равно падают с багами.
sshikov
>системы с 200% покрытия кода
Еще не надо забывать, что код бывает сильно разный. Бывают одноразовые скрипты, для решения конкретной задачи, которые глупо покрывать тестами даже на 1%, потому что это будет пустая трата времени и денег.
Gorthauer87
Так как тесты могут работать неправильно, то нужны ещё и тесты на тесты, но и они могут быть некорректными... O shi!
Я молчу про то, что тогда уж нужно покрытие всех веток в логике приложения, что вообще то часто недостижимая задача.
mapron
Я тут работал в проекте с весьма неплохим покрытием тестами.
И заметил что после правок в одном модуле тест не падает, хотя точно должен.
По итогу выяснил что (в неявном виде) проверка в конце сводилась к
EXPECT_EQ(calculatedData, calculatedData) (понятно что без дебага теста выяснить что он сравнивает данные сами с собой не удавалось).
Я поправил тест и выяснил что он не работал уже очень давно)
Собственно я к чему. По метрикам — все прекрасно. Покрытие — отличное, все ветки кода выполняются. А по факту да, тест ничего не проверяет кроме того что програма не упала на выполнении)
HellWalk
Добавление мутационных тестов покажет, на сколько юнит тесты написаны качественно.
sshikov
Но гарантии правильности кода не даст все равно :)
HellWalk
Если тесты не гарантируют надежности кода - значит код или тесты написаны плохо.
Например, на каком-нибудь Yii2 фреймворке, где в каждом втором методе, внутри происходит обращение к глобальному Yii::$app объекту, в котором может быть что угодно - да, обнуляет ценность юнит-тестов.
Только проблема тут не в тестах, а в плохих фреймворках. И как раз написание тестов и стремление к надежному коду - учит отличать хорошие подходы от плохих.
sshikov
>Если тесты не гарантируют надежности кода
Насколько я понимаю, гарантировать невозможно. Т.е. это упирается в проблему завершения, которая не решается в общем случае.
Psionic
Вот именно по этому я со скепсисом отношусь к методике юнит тестирования и автотестпирования. Тест тоже программа - и она тоже может содержать ошибки и так бывает что содержит.
Vilaine
Ожидаемо, учитывая то, как Р. Мартин относится к типизации (очень скептически, дескать, программист разбирётся и без анализатора что ему делать, типчики устарели).
По этой же причине не могу серьёзно учитывать его мнения в том, кто какой профессионал =)
spiceginger
Вычеркивайте меня тоже. Этот тест никакого отношения к Мартину не имеет.
Savochkin Автор
Почему?
spiceginger
Какой вы программист?
пришел, увидел, наследил
Это правда по Р.Мартину?
Savochkin Автор
Ну это вы привели один из неправильных вариантов на вопрос "Каким главным принципом должен руководствоваться профессиональный разработчик". А так да, про принцип Р. Мартин пишет в главе 1 стр 23.