Почитал весь этот радикализм, это все от непонимания.
Программирование сложная инженерная область, потому как разработчик может сделать все что угодно и практически ни чем не ограничен. Единственный ресурс это время. Расходуя это время программист может строить людбые хрустальные замки и велосипеды, цена деньги в час — и все! При такой свободе действий создать шедевр может только гений, разумно используя весь технический арсенал, который со временем расширяется с гигантской скоростью. В шедевре ничего не бывает лишнего, не бывает избыточной красоты, ненужных вещей и красивости, красота в минимальности и простоте, достичь которую очень сложно. (Пример шедевра автоматическое оружие Калашникова)
Остальная серость, включая меня, ругает инструменты, не достаточно глубоко разбирается в сущности проблемы, назначении инструмента, кругозора инструментов и создает что-то монстроузное.
В начале 2000 когда язык придерживался только одной парадигмы, было трудно выйти за рамки. Сейчас C#, Java, C++ консолидируют возможности, которые должны быть использованы уместно. null reference это плохо, это не плохо, просто надо знать как им пользоваться и сейчас для этого куча готовых инструментов. If-Then-Else Is a Code Smell, г-но это тогда, когда он не уместно используется и так везде.
В отличии от программирования производство не позволяет создавать кучу инструментов и создание чего либо делается стандартным набором инструментов и стандартными процессами, по этому там революционеров меньше.
В общем всем радикалистам подумайте о том, для чего это создавалось, кем и какую проблему решали.
Ерунда. Чтобы побороть легаси, необходимо сначала найти и выделить наиболее проблемные участки кода, которые необходимо переделать и выкатить. Написание тестов один из инструментов, не более.
Вы пишите какую-то логику? Она делает что-то полезное для клиента? Клиент за неё заплатил? Она может сломаться? Клиент расстроится?
Все очень и очень сильно зависит. На некоторые фейлы или некорректную работу можно забить. Тесты все лишь проверка контракта и песочница для предотвращения повтороного проявление одних и тех же дефектов.
Поэтому людям надо помочь. Надо дать инструмент, который поможет им преодолеть свои слабости — как колесо, плуг и револьвер.
Это примерно как посыл продавана БАДов, любой инструмент имеет граничные условия применения, преимущества и недостатки.
Преимущества как правило понятны, а вот с недостатками все сложнее и о них говорят мало.
TDD — это про разработку (test driven DEVELOPMENT). Это способ создания кода таким, чтобы он был НЕ legacy. Таким, чтобы его было возможно поддерживать: отлаживать, исправлять, рефакторить, дорабатывать. На данный момент это единственный известный человечеству способ. Всё остальное — от лукавого, не дайте себя обмануть.
TDD и легаси проблемы совершенно разного уровня и характера. Legacy — это когда при помощи текущего кода делают не свойственную ему задачу и никакое TDD и тестирование от этого не спасет.
Безусловно, нужно стремиться к максимальному покрытию. Все эти разговоры про 30% или 70% покрытие — от непонимания. Надо стремиться к 100% (хоть это и недостижимый предел).
…
Всем известно, что 100% покрытие невозможно, но не все правильно понимают, почему. Вовсе не потому, что «надо тестировать только критичное», «незачем тестировать геттеры» и «у нас есть дела поважнее».
100% покрытие тестами еще один миф, покрывать тестами нужно по заранее известным критериям: важность, проблемность, трудность обнаружения ошибки. Стремиться к 100% покрытию напоминает продавцов БАД. Метрика покрытия тестами просто некоторый индикатор кода, не более.
Ты пишешь красный тест 10 минут, делаешь его зелёным 10 минут, рефакторишь 10 минут. Никто, конечно, не замеряет это время точно — иногда это 5:30:0, а иногда 180:5:60. Неважно. Важно, что ты с таким же темпом, с предсказуемой скоростью сможешь менять код и через месяц, и через год
теоретический бред. Это возможно лишь тогда, когда допиливается мини-фича к текущему фреймворку. Когда приходится реализовывать новый кейс на текущем коде, в первую очередь важно понять что укладывается в текущий дизайн и логику, а что нет. А уж потом писать тесты.
Изначально тестами покрывают простые сценарии, а уж потом со временем появления дефектов, эти дефекты воспроизводят тестами. Вообще хороший дизайн и программы делают люди, а не методологии, по считаю, что важность и полезность TDD сильно преувеличена и не оговорены рамки где его целесообразно применять.
Я еще проще скажу, человек вообще должен быть хорошим :) Но советы из серии «чистить зубы по утрам, полезно для здоровья» бесполезны и не информативны, пусть даже и расписано как это все полезно. Покажите ваши зубы и стоматолога — этого достаточно.
Очень много букафф.
Для себя я вывел простые правила
1. Продавец должен быть экспертом в своем товаре.
Не зная товар сложно что либо предложить или подсказать. Желательно знать товар в исторический перспективе и концептов на будущее. В целом это не очень сложно.
2. Продавец должен уметь выяснить и понять, что хочет покупатель и его интерес. Товар в данном случае это инструмент удовлетворения интереса покупателя.
Люди в разный момент бывают разные, кому-то надо помочь подобрать, кому-то посоветовать, кому-то просто продать. Сложно определить какое намерение у покупателя и на что он настроен.
3. Продавец должен быть незаметным, но всегда рядом.
Тут тоже надо понимать кто приходит. Если клиент постоянный, то с ним диалог вести проще, если же впервые, возможно ему надо бывает надо просто осмотреться, без постороннего внимания.
Успех и качество проектов на 99% зависит от руководства и команды. Совет «надо чистить зубы 2 раза в день» очевинден и бесполезнен. Процессо-оринетированность в IT видимо какой-то скрам/аджаил говлоного мозга.
Лучший продукт — делают лучшие люди. С точки зрения эффективности очень важно «определить» человека на свое место(роль/позиция), работая на котором от него будет максимум пользы. Продукт это командный резульат и куда сложнее сформировать команду и управлять ее жизнью и взаимоотношениями членов, нежели, чем по 15 минут как роботы отвечать на 3 тупых вопроса.
Порой выбешивает представление менджмента в IT: апогеем управления считается внедрение скрама, оджайла, тикетов, доски и прочей бутафории. От навешивания наклеек и синих спорт брызговиков спарцо машина спортивной не будет и быстрее не поедет.
Тут все просто. Есть бизнес, он обслуживает определенную аудиторию. Есть запрос на новую фичу от клиента/заказчика. Если для сервиса/продукта эта новая фича в будущем может сгенерировать прибыль, то наверное ее стоит делать, если же фича не консистентна, бесперспективна, не является целевой, с точки зрения системы, от нее надо отказаться. Решение в этом случае остаетается за владельцем бизнеса.
Клиенториентированность это все теория, в реальности, надо всегда задуываться на сколько нам надо/полезно, то что от нас требуют. Да — делаем. Нет — досвидос.
Корпоративная культура очередной булшит менеджеров-менеджеров. Все культура зависит от руководителей, если руководство в адеквате, то принимаемые решения будут адекватными, в противном случае: неправильные пчелы делают неправильный мед (с).
В моем понимании DevOps — это такой Software Any key, который знает как работает софт и знает как работает окружение и поддерживает работоспособность сервера.
Если брать по-старинке, то это отдел эксплуатации. В маленьких компаниях этим занимаются как правило админы+разработчики.
«Методология DevOps» — маркетинговый булшит.
По мне документация это иерархичное описание от простого к сложному, с наличием кросс ссылок, Diff к предыдущей версии. Для меня простым было бы писать в xml или WSWYG, но тот же конфлюенс — убог.
Архитектурно для
Идеально редактируешь у себя на компе, потом commit, и веб сервер уже подхватывает изменения и отображает. Для редактирования нужен редактор, который умеет отображать код как браузер. Все остальное, что пробовал — неудобно.
Ведущим просто необходимо заниматься тех. поддержкой. Это позволит «почувствовать» всю боль пользователя. На практике очень часто сталкивался с тем, что команда пишет софт без детального понимания того, как продуктом пользуются люди. В результате образуется пропасть между представлением в головах и реальным использованием.
Люди которые создают программный продукт должны не то, что ументь программировать, они должны понимать как этот продукт вообще создается, надо понимать сам процесс. Первоклассным разработчиком быть не нужно, но опыт считаю должен быть.
Статья ни о чем. Много воды смысла нуль. Автоматизированное тестирование и TDD тоже надо применять с умом. Почему вы не раскрываете деталей и условий когда это хорошо и когда плохо?
Разрабатывать по TDD? Иди поучи свою жену щи варить. Что нам говорит TDD, сначала пишем тест. Он не проходит. Имплементируем функционал — проходит. Такой подход иррационален. Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие. Учитывая что бизнес логика меняется, то со временем придется еще поддерживать и тесты.
Как на мой взгляд должно производиться тестирование. Чем важнее и «базовее» компонент, тем лучше он должен быть покрыт тестами. TDD хорошо подходит для некоторых фич фреймворков.
Интеграционное тестирование хорошо подходит для критических вещей всего продукта.
Автоматизацию надо начинать с рутинных или приемочных тестов, без которых продукт выпускать смысла нет. В идеале можно использовать DSL подход, и прямо в требовании писать сценарий на DSL для тестирования.
Например проводник винды: select menu «File», submenu «New». Keyboard «My Folder». Check: Explorer.FolderExists("%PATH%\My Folder").
Например у нас в приложении есть большое количество независимых окон, автоматизировали сценарий открытия окна, пока кодом, следующий шаг выделить DSL и дать возможность тестерам писать DSL.
В целом полезная статья.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
А у меня такой вопрос, почему нельзя всем этим теплом греть, какую либо воду? пусть тепло переносится как переноится, только охлаждение испарителя будет осуществляться водой?
А вам не кажется что дело не в программистах, а в консерватории? Никто не говорит о реализации хоп хоп и в продакшен.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
Мне не нравится ни кандидат ни интервьювер. Интервьювер убивает свое время, потому как перед ним человек, который затягивает тривиальную задачу в условиях неопределенных требований. Надо скопировать файл, предусматриваешь более менее очевидные кейсы и делаешь.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
Программирование сложная инженерная область, потому как разработчик может сделать все что угодно и практически ни чем не ограничен. Единственный ресурс это время. Расходуя это время программист может строить людбые хрустальные замки и велосипеды, цена деньги в час — и все! При такой свободе действий создать шедевр может только гений, разумно используя весь технический арсенал, который со временем расширяется с гигантской скоростью. В шедевре ничего не бывает лишнего, не бывает избыточной красоты, ненужных вещей и красивости, красота в минимальности и простоте, достичь которую очень сложно. (Пример шедевра автоматическое оружие Калашникова)
Остальная серость, включая меня, ругает инструменты, не достаточно глубоко разбирается в сущности проблемы, назначении инструмента, кругозора инструментов и создает что-то монстроузное.
В начале 2000 когда язык придерживался только одной парадигмы, было трудно выйти за рамки. Сейчас C#, Java, C++ консолидируют возможности, которые должны быть использованы уместно. null reference это плохо, это не плохо, просто надо знать как им пользоваться и сейчас для этого куча готовых инструментов. If-Then-Else Is a Code Smell, г-но это тогда, когда он не уместно используется и так везде.
В отличии от программирования производство не позволяет создавать кучу инструментов и создание чего либо делается стандартным набором инструментов и стандартными процессами, по этому там революционеров меньше.
В общем всем радикалистам подумайте о том, для чего это создавалось, кем и какую проблему решали.
Все очень и очень сильно зависит. На некоторые фейлы или некорректную работу можно забить. Тесты все лишь проверка контракта и песочница для предотвращения повтороного проявление одних и тех же дефектов.
Это примерно как посыл продавана БАДов, любой инструмент имеет граничные условия применения, преимущества и недостатки.
Преимущества как правило понятны, а вот с недостатками все сложнее и о них говорят мало.
100% покрытие тестами еще один миф, покрывать тестами нужно по заранее известным критериям: важность, проблемность, трудность обнаружения ошибки. Стремиться к 100% покрытию напоминает продавцов БАД. Метрика покрытия тестами просто некоторый индикатор кода, не более.
теоретический бред. Это возможно лишь тогда, когда допиливается мини-фича к текущему фреймворку. Когда приходится реализовывать новый кейс на текущем коде, в первую очередь важно понять что укладывается в текущий дизайн и логику, а что нет. А уж потом писать тесты.
Изначально тестами покрывают простые сценарии, а уж потом со временем появления дефектов, эти дефекты воспроизводят тестами. Вообще хороший дизайн и программы делают люди, а не методологии, по считаю, что важность и полезность TDD сильно преувеличена и не оговорены рамки где его целесообразно применять.
Для себя я вывел простые правила
1. Продавец должен быть экспертом в своем товаре.
Не зная товар сложно что либо предложить или подсказать. Желательно знать товар в исторический перспективе и концептов на будущее. В целом это не очень сложно.
2. Продавец должен уметь выяснить и понять, что хочет покупатель и его интерес. Товар в данном случае это инструмент удовлетворения интереса покупателя.
Люди в разный момент бывают разные, кому-то надо помочь подобрать, кому-то посоветовать, кому-то просто продать. Сложно определить какое намерение у покупателя и на что он настроен.
3. Продавец должен быть незаметным, но всегда рядом.
Тут тоже надо понимать кто приходит. Если клиент постоянный, то с ним диалог вести проще, если же впервые, возможно ему надо бывает надо просто осмотреться, без постороннего внимания.
Лучший продукт — делают лучшие люди. С точки зрения эффективности очень важно «определить» человека на свое место(роль/позиция), работая на котором от него будет максимум пользы. Продукт это командный резульат и куда сложнее сформировать команду и управлять ее жизнью и взаимоотношениями членов, нежели, чем по 15 минут как роботы отвечать на 3 тупых вопроса.
Порой выбешивает представление менджмента в IT: апогеем управления считается внедрение скрама, оджайла, тикетов, доски и прочей бутафории. От навешивания наклеек и синих спорт брызговиков спарцо машина спортивной не будет и быстрее не поедет.
Клиенториентированность это все теория, в реальности, надо всегда задуываться на сколько нам надо/полезно, то что от нас требуют. Да — делаем. Нет — досвидос.
Если брать по-старинке, то это отдел эксплуатации. В маленьких компаниях этим занимаются как правило админы+разработчики.
«Методология DevOps» — маркетинговый булшит.
Архитектурно для
Идеально редактируешь у себя на компе, потом commit, и веб сервер уже подхватывает изменения и отображает. Для редактирования нужен редактор, который умеет отображать код как браузер. Все остальное, что пробовал — неудобно.
Разрабатывать по TDD? Иди поучи свою жену щи варить. Что нам говорит TDD, сначала пишем тест. Он не проходит. Имплементируем функционал — проходит. Такой подход иррационален. Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие. Учитывая что бизнес логика меняется, то со временем придется еще поддерживать и тесты.
Как на мой взгляд должно производиться тестирование. Чем важнее и «базовее» компонент, тем лучше он должен быть покрыт тестами. TDD хорошо подходит для некоторых фич фреймворков.
Интеграционное тестирование хорошо подходит для критических вещей всего продукта.
Автоматизацию надо начинать с рутинных или приемочных тестов, без которых продукт выпускать смысла нет. В идеале можно использовать DSL подход, и прямо в требовании писать сценарий на DSL для тестирования.
Например проводник винды: select menu «File», submenu «New». Keyboard «My Folder». Check: Explorer.FolderExists("%PATH%\My Folder").
Например у нас в приложении есть большое количество независимых окон, автоматизировали сценарий открытия окна, пока кодом, следующий шаг выделить DSL и дать возможность тестерам писать DSL.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.