аджайл фо лайф
Расскажите по простому про этот ваш аджайл
Добавь книгу Роберта Мартина "Чистый код".
я крутой, а вы не очень
Разработка идет итерациями, как правило по 2 недели. Соль в том, что в конце каждой итерации имеем рабочую версию софта. Эту врсию можно дать заказчику, чтобы он понял, то ли это, чего он хотел. Он может внести изменения в требования, которые будут реализованы в следующих итерациях. Таким образом имеем быструю обратную связь и реализуем в первую очередь самый важный функционал.
А если рабочая копия не готова? Вот случился какой-то затык, который не дает реализовать что-то.
И это, если я правильно понял, получается так, что заказчик заказывает программу, договаривается о сроках и оплате, а потом раз в две недели может просить дополнительный функционал за те же деньги?
Если что-то сделать не успели, то это учитывается при планировании следующей итерации. Для каждой задачи анализируется сложность в неких условных пунктах. Если сейчас что-то не успели, значит на следующей итерации нужно взять меньше пунктов. У Мартина есть хорошая книга на тему - "Быстрая разработка ПО".
Аноны, как научиться программировать хорошо?
Есть тут упарывающие TDD? Как оно?
Есть еще какая-то штука под названием BDD, но никто внятно не может объяснить чем оно отличается (кроме того что тесты надо называть не просто testHui(), а teshHuiVstaetKogdaVidishGolujyEOT(), но как по мне это не тянет на отдельную парадигму)
Есть еще какая-то штука под названием BDD, но никто внятно не может объяснить чем оно отличается (кроме того что тесты надо называть не просто testHui(), а teshHuiVstaetKogdaVidishGolujyEOT(), но как по мне это не тянет на отдельную парадигму)
Один мальчик выложил на GitHub в open source облачный распределенный BigData IoT SaaS мэшап с TDD, BDD, DDD, ATDD, STDD, DRY, CQRS, SPoF, EAFP, IoC, DI, DVCS, YAGNI, TMTOWTDI, convention over configuration, zero configuration, SEO, Scrum, microservices, Docker, Cassandra, Hadoop, Cucumber, responsive isomorphic Angular, machine learning, data mining, loose coupling, event sourcing, FRP и Kanban. Но без MongoDB. Потом его все равно в ад забрали, конечно.
Если абстрактно, то BDD - это ближе к функциональному тестированию. Отсюда и название - Behaviour DD.
TDD же - чисто модульное тестирование.
Тесты - прувинг для бедных. Дискасс.
> прувинг для бедных
Поясни
Прочесть "Рефакторинг" Фаулера, "Искусство программирования для Unix" Рэймонда, "объектно-ориентированный анализ и проектирование" Буча и много практиковаться, попутно изучая опен сурс код более-менее известных и стабильных приложений.
Тесты легко писать, но они покрывают только некоторые, очень частные случаи; прувинг просто так не запилишь, но он покрывает абсолютно все возможные варианты.
мимодругойанон
Двачую + "Чистый код" Мартина.
От простыней коллег, которые таких фамилий не слышали, с методами по 100 строк и комментами через каждые две строки жопа горит.
Что лучше, DRY KISS или AGILE GRASP?
TDD вроде нихуя не определяет какие именно тесты должны быть. Никто не мешает тебе в частности сперва помимо юнит тестов написать и несколько более высокоуровневых (хотя при отсутствии кода это может быть и слегка нетривиально).
Все равно короче непонятно нахуй это BDD выделяют во что-то отдельное, более продвинутое чем TDD, более того есть некие фреймворки которые себя позиционируют именно как BDD фреймворк, хотя единственная принципиальная разница которую я в них нашел - возможность вместо Assert.assertEquals(1, x) написать что-то типа x should be (1), что в общем-то примитивный сахарок и на суть не влияет вообще никак.
Адепты BDD чотатам кукарекают на тему того что "можно писать тесты в терминах почти-естественных языков, понятных бизнесу", но это чем-то напоминает влажные мечты в духе "вот щас мы разработаем новый язык программирования, почти как естественный, на котором даже неспециалист сможет описать логику программы, и программисты резко станут нинужны".
>DRY KISS
Мне кажется это взаимоисключающие параграфы
Прувинг покрывает только те варианты которые ты доказываешь.
Быть любопытным, иметь мозги и пользоваться ими, не верить слепо тем кто имеет МНЕНИЕ.
> От простыней коллег, которые таких фамилий не слышали, с методами по 100 строк и комментами через каждые две строки жопа горит
От простыней коллег, которые не могут решить простую задачу не прибегая к ООП, жопа горит.
От простыней коллег, которые пишут класс там где можно написать 2-3 обычные функции, жопа горит.
От простыней коллег, у которых функции и методы модифицируют больше одной вещи из внешнего скоупа, да еще и что-то потом возвращают кроме null/None, жопа горит.
От простыней коллег, которые не понимают что чем больше состояний в которых программа может находиться тем больше вероятность ошибки, жопа горит.
> От простыней...
И от этого всего тоже. И обо всем этом, тащемта, у Мартина и написано.
> стоит ли покрывать всё тестами
Не стоит, анон уже видел код когда тестировались условные итераторы, не ну а че ВДРУГ НЕ ЗАРАБОТАЮТ, было немножко смешно и грустно.
Ну и немножко оффтопика (нет):
Профилактика анального зуда
Так как анальный зуд сопровождается расчесыванием, нужно обязательно прекратить расчесывать анальное отверстие, потому что новые царапины приводят к новому зуду. Выпейте перед сном антигистамин, чтобы помочь уменьшить Ваш ночной анальный зуд. Не давайте антигистаминные препараты вашему ребенку до консультации с врачом.
Принимайте теплую сидячую ванну 3 раза каждый день и после каждого опорожнения кишечника. После ванны, тщательно высушите анус. Вы можете также использовать фен для волос, установленный на самый минимум тепла.
Избегайте продуктов, которые могут вызвать или увеличить ректальный зуд, такие как кофе, крепкий чай, кола, алкогольные напитки, шоколад, помидоры, пряные продукты, и чрезмерное количество витамина С , в течение как минимум 2 недели. Постепенно добавляйте продукты в ваш рацион , один за раз, чтобы помочь определить причину анального зуда.
Обрежьте ногти покороче, это поможет избежать сильных царапин, когда ваш анальный зуд будет нетерпимым и вы все-таки начнете чесать раздраженную область. Наденьте перед сном хлопчатобумажные перчатки или носки, чтобы помочь остановить появление бессознательных царапин, которые могут возникнуть во время сна .
Контролируйте свой стресс. Нахождение в состоянии стресса и жизнь с чувством тревоги или волнения, может привести некоторых людей к тому, что они будут испытывать зуд кожи. Если вы обнаружили, что чешете при тревоге анальную область, попытаться найти возможность для расслабления в течение дня, а главное, перед сном.
Профилактика анального зуда
Так как анальный зуд сопровождается расчесыванием, нужно обязательно прекратить расчесывать анальное отверстие, потому что новые царапины приводят к новому зуду. Выпейте перед сном антигистамин, чтобы помочь уменьшить Ваш ночной анальный зуд. Не давайте антигистаминные препараты вашему ребенку до консультации с врачом.
Принимайте теплую сидячую ванну 3 раза каждый день и после каждого опорожнения кишечника. После ванны, тщательно высушите анус. Вы можете также использовать фен для волос, установленный на самый минимум тепла.
Избегайте продуктов, которые могут вызвать или увеличить ректальный зуд, такие как кофе, крепкий чай, кола, алкогольные напитки, шоколад, помидоры, пряные продукты, и чрезмерное количество витамина С , в течение как минимум 2 недели. Постепенно добавляйте продукты в ваш рацион , один за раз, чтобы помочь определить причину анального зуда.
Обрежьте ногти покороче, это поможет избежать сильных царапин, когда ваш анальный зуд будет нетерпимым и вы все-таки начнете чесать раздраженную область. Наденьте перед сном хлопчатобумажные перчатки или носки, чтобы помочь остановить появление бессознательных царапин, которые могут возникнуть во время сна .
Контролируйте свой стресс. Нахождение в состоянии стресса и жизнь с чувством тревоги или волнения, может привести некоторых людей к тому, что они будут испытывать зуд кожи. Если вы обнаружили, что чешете при тревоге анальную область, попытаться найти возможность для расслабления в течение дня, а главное, перед сном.
Я вот не понимаю TDD. То есть я понимаю, как оно устроено, какая от него польза. Но не понимаю, как его можно применять в сложных проектах. То есть, если в программе условных 10тыс строк кода, то надо 30 тыс строк тестов.
И все равно тест - это какая-то подгонка. Тесты обычно проверяют какую-то элементарщину.
Интересно, есть ли крупный проект, в котором реализованы эти тесты?
Вот специально для тебя откопал доклад, там чуваки через TDD сделали онлайн банкинг для крупного банка. У них почти полторы тысячи тестов и всего пяток разработчиков, отдела QA и ручного тестирования нет вообще.
https://www.youtube.com/watch?v=PZq_J1AuSL0
> если в программе условных 10тыс строк кода, то надо 30 тыс строк тестов.
Совсем не факт. Но даже несмотря на то что количество кода увеличивается, общий цикл разработки ПО сокращается. Так как помимо фазы написания кода (которая в итоге будет чуть длиннее) есть еще фазы отладки, тестирования, фазы деплоя, последующее исправление ошибок и выкладки патчей. И вот все эти фазы за счет качественного тестирования кода будут сильно меньше, в итоге ты выиграешь по времени.
иди и не пизди мне тут. Сколько ты крупных проектов знаешь написанных по TDD? А если хуяк заказчик реверс сделает на 180 градусов, ты тоже будешь все свои тесты переписывать ? Проблема TDD в том, что нужно писать много кода под тесты. Короче это уже тухлая утопия ( кстати сомнительно относился к нему , когда он только появился) .
Посмотрел я это видео. Как бы всё хорошо и понятно, но:
что-то я ему не особо верю. Ну вот не верю я, что без тестировщиков можно создать полноценное приложение. Они написали там кучу тестов, но где гарантия, что эти тесты покрывают все случаи?
Тем более, глава проекта должен поверить, что вот их тесты и тесты тестировщиков делают одно и то же, поэтому от тестирования тестировщиками можно отказаться.
А так он говорит умные вещи,типа заменяйте всякие сервера их эмуляциями, разбивайте задачу на участки, и пишите тесты под конкретный участок и тд
>Ну вот не верю я, что без тестировщиков можно создать полноценное приложение.
Ну тут я тебе свой опыт могу привести, я в одно рыло например сделал связку из приложения для андроида которое работает как MPOS-терминал (к смартфону подключается считыватель банковских карточек и можно оплачивать всякую хуйню, дешевле чем отдельный хардверный POS) и веб-приложение для сбора и мониторинга статистики.
Пилим его уже год (я единственный программист, кроме меня пара сооснователей-американцев которые его впаривают), оно уже в продакшене. Не TDD (и я уже жалею об этом), но тесты я пишу.
Нужно понимать что автоматизированные тесты это почти полная замена тестировщикам. Ведь живые тестеры они по сути делают все то же самое, у них есть сценарии тестирования и они вручную прокликивают кнопочки и смотрят на результаты. И это все неплохо автоматизируется, так как интеллектуальностью там даже не пахнет.
Конечно мы и сами наши приложения проверяем вручную, полностью от ручных тестов избавиться нельзя. Но при наличии большого количества автоматических - их становится достаточно немного чтобы с ними можно было справиться самостоятельно.
> но где гарантия, что эти тесты покрывают все случаи?
Нет такой гарантии. Да и с чего бы она вообще должна быть? Где гарантия что любой другой вид тестирования покрывает все случаи?
Автоматические тесты - это просто автоматизация и удешевление процесса тестирования, в целом повышающие качество ПО. Но ни в коем случае не являющиеся серебряной пулей. И их тоже в общем-то надо уметь готовить, так как можно понаписать сотню тестов которые будут тестировать не то что надо.
> Не TDD (и я уже жалею об этом),
я не тот анон, но вот скажи мне, пожалуйста, как ты собираешься сложные штуки через tdd писать.
То есть, общее представление о задаче очевидно есть.
Но в какие классы пойдет логика, как вообще все будет организовано -- как это вот определишь вот так сходу? Еще до первой строчки кода. Тут ведь с первого раза не получится скорее всего, придется переписывать и писать тесты для таких черновиков это пустая трата времени.
Для веба я могу представить что в рамках мвс и фреймворка просто варишься и не забиваешь себе голову подобными вопросами. Написал тест для валидации, написал валидацию. Просто и примитивно.
Но ведь программирование это не только веб, даже микросервисы надо уметь правильно писать, не говоря уже о каких-то средне-больших проектах.
>Но в какие классы пойдет логика, как вообще все будет организовано -- как это вот определишь вот так сходу? Еще до первой строчки кода. Тут ведь с первого раза не получится скорее всего, придется переписывать и писать тесты для таких черновиков это пустая трата времени.
Ну как я делал в одном из небольших проектов. Задача - написать сервис который принимает USSD запросы с телефона клиента (прилетают они мне в виде HTTP POST от оператора связи), на основе этих запросов уточняет у клиента какие-то параметры, затем шлет запросы ко всяким платежным АПИ (такая вот система управления электронным кошельком с телефона).
Сперва у меня есть общее понимание системы + набор USSD запросов которые могут мне прислать. Окей, пишем первые пару тестов которые проверяют как работает мое апи в целом. Что в нем есть нужные эндпоинты, что они работают только если переданы нужные параметры и нужный тип запроса и т.п. Добавляем один-два теста для правильно сформированных запросов. Затем делаем чтобы тесты выполнялись (пока просто тупо захардкодив ответы где надо). Итого у меня есть скелет веб-сервера с нужными путями и параметрами.
Дальше я решаю что у меня например сессия для общения с клиентом будет в виде актора (писал я это все на Scala). А в сессии будет стейт машина, состояния которой будут отдельными классами, реализующими логику в этом состоянии. Например стейт "проверка пин-кода" будет ожидать от клиента USSD с пином от его кошелька и проверять его. Веб сервер соответственно будет слать актору пришедшие в этой сессии сообщения и возвращать клиенту то, что актор прислал в ответ.
Окей, обрисовалось что мы будем писать и тестировать дальше. Например тот же стейт с проверкой пина. Пишем тесты на этот класс - что если он получает сообщение с правильным пином то делается одно, с неправильным - другое, ну и так далее. Все это обильно посыпаем Mock-объектами для взаимодействия с другими апи. Так один за другим сперва пишем тесты на все стейты, затем реализуем их.
Потом когда отдельные кирпичики системы готовы и протестированы - начинаем собирать из них систему в целом. Пишем тесты которые воспроизводят уже целую последовательность действий от клиентов, например сперва получаем сообщение об инициализации сессии, затем команду на отправку денег на указанный счет, затем выбор банка-получателя, затем пин от кошелька для подтверждения. На их основе реализуем и проверяем переключение состояний в стейт машине.
Вот как-то так. В итоге у нас есть и юнит-тесты (которые чекают отдельные методы и обработку отдельных сообщений) и интеграционные (которые тестируют всю последовательность платежа из нескольких операций), мы уверены что как минимум все базовые сценарии нашего приложения работают как надо, при этом у нас хорошее (по факту около 70%) тестовое покрытие. И как человек, делающий все стадии от написания кода до внедрения в одно лицо, я могу сказать что хотя кода я действительно раза в полтора больше написал, но внедрение, отладка и тестирование в итоге заняли намного меньше времени, и багов в приложении почти не было (было несколько проблем которые я просто не предусмотрел, но все о чем я подумал заранее и что покрыл тестами - работало).
спасибо, информативно.
1) Есть ли в этом видео примеры тестов (код)?
2) Отличаются ли они от assert 1+1==2?
Ванга-мод:нет/да+нет, TDD бессмысленная параша для ебанутых
>ли в этом видео примеры тестов (код)
Нет конечно. Это же не видео для студентов нихуя не знающих что такое тесты и которым надо все вплоть до синтаксиса объяснять.
>организовать свою работу, чтобы она приносила радость,
мамкин теоретик детектед. От тебя ничего не зависит. Ты работаешь с кучей других ебланов и разгребаешь говно, оставленное другими ебланами до тебя. И у тебя сроки и менеджер мудак. Вот это реальная жизнь, сынок.
>От простыней коллег
И все, дальше можно не продолжать. Коллеги мудаки, а я умный. Разумеется остальные коллеги думают то же самое про твои простыни.
Поясните за иммутабельность. Я понимаю иммутабельность это хорошо и все дела, но вот зачем в каждой строчке вставлять const (или его аналоги)? Как можно случайно поменять переменную? Только если пустить кота за клавиатуру и дать покодить вместо себя.
>иммутабельность
Во-первых, можно забыть и случайно изменить переменную
во-вторых, другой программист, когда будет читать твой код, поймет, что это константа.
>иммутабельность это хорошо и все дела
Иммутабельность хороша только в тех языках где она нормально поддерживается. Например где можно создать новую иммутабельную коллекцию на основе старой, при этом они будут шарить общую часть, а не создавать полную копию.
Иначе быстро обосрешься с говнокодом и перерасходом памяти.
Судя по тому что ты говоришь о const - это какие-нибудь плюсы? Там лучше не заморачиваться с этой хуйней как мне кажется.
Поясните за создание частично прозрачных для кликов окон. Ну, типа, окно состоит из двух частей: на одной всякие нажимаемые кнопочки, а вторая полупрозачная и пропускает сквозь себя клики в окно ниже.
Надеюсь, не проебался с тредом.
Надеюсь, не проебался с тредом.
overlay windows
Я имею в виду локальные переменные. Пример на картинке. Хотел найти код где каждая строчка засрана, но что то никак, но такое точно встречается.
Еще например JS добавили const и let (которые хуй проссышь чем отличаются) и карго-культисты теперь будут вставлять их везде.
>Только если пустить кота за клавиатуру и дать покодить вместо себя.
Ты так говоришь, как будто никогда не давал коту покодить вместо себя.
Мимокот
Ну в таком случае чего бы финал и не использовать.
Во-первых, иногда компилятор может использовать какие-то более агрессивные оптимизации если будет знать, что значение точно не изменится.
Во-вторых в той же джаве final будет требоваться при использовании всяких замыканий, так как использовать во вложенном классе можно только final переменные из внешнего скоупа.
В-третьих это подсказка программисту, да, что это значение не изменится где-то в дебрях кода. Так как вполне может найтись какой-нибудь индус, который решит не заводить новую переменную для своих нужд, а использовать уже вроде бы не нужную существующую.
В-четвертых те же файналы IDE автоматически добавляет когда ты делаешь рефакторинги типа выделения выражения в отдельную переменную.
Короче не сказать чтобы это все было сильно принципиально, так, чуточку лучше.
>Ну в таком случае чего бы финал и не использовать.
Лал, чет вспомнилось обсуждение одного вопроса по коду с одной пиздой
- А почему ХХХ?
- А почему бы и нет?
Ты случайно не пизда?
Ебучий даун, final надо использовать везде, где это возможно, и не использовать ТОЛЬКО ЛИШЬ ТАМ, где это реально мешает, то есть её вопрос более корректный.
Эта каргоманя порвалась, несите следующую.
Final дает некие плюсы которые я указал
Отсутствие final у переменной изначально задуманной как константа не дает никаких плюсов.
Написать пять символов думаю пальцы у тебя не отсохнут, да и IDE поможет.
Так что позиция финальщиков вполне понятна и объяснима.
>Во-первых, иногда компилятор может использовать какие-то более агрессивные оптимизации если будет знать, что значение точно не изменится.
Нет компилятор и сам может понять где неизменяемость. Иначе как бы он мог проверять корректность этих объявлений?
>Во-вторых в той же джаве final будет требоваться при использовании всяких замыканий, так как использовать во вложенном классе можно только final переменные из внешнего скоупа.
В принципе валидно. Но вроде бы они исправили этот бред на "принципиально final". Или может быть это в шарпе так сделано, что как бы намекает.
>В-третьих это подсказка программисту, да, что это значение не изменится где-то в дебрях кода. Так как вполне может найтись какой-нибудь индус, который решит не заводить новую переменную для своих нужд, а использовать уже вроде бы не нужную существующую.
Ну это вообще пушка. Аргумент с котом.
>В-четвертых те же файналы IDE автоматически добавляет когда ты делаешь рефакторинги типа выделения выражения в отдельную переменную.
Не аргумент. Может быть завтра этот фад пройдет и они перестанут это вставлять. В любом случае IDE всегда высерают тонны неведомой хуйни.
>Отсутствие final у переменной изначально задуманной как константа не дает никаких плюсов.
>Написать пять символов думаю пальцы у тебя не отсохнут, да и IDE поможет.
Только ты забываешь про читаемость кода.
И да делать что-то абсолютно бессмысленное подзаебывает.
Почему бы не вставлять в каждой второй строчке по комментарию с предложением из "Войны и мира"? Не помешает же.
>есть ли альтернатива технике "хуяк-хуяк и в продакшн"
Под натиском постоянно меняющихся на 180 градусов требований и ограниченности времени? Даже если бы время у тебя было не ограничено, тебя бы заебало вместо очередного простого костыля переписывать половину приложения опять.
>Даже если бы время у тебя было не ограничено, тебя бы заебало вместо очередного простого костыля переписывать половину приложения опять.
Вот только с костыльным подходом тебя очень быстро заебет потом вылавливать миллион багов, когда один неудачно вставленный костыль ВНЕЗАПНО ломает десяток других.
ОЙ А ДАВАЙТЕ
@
ПЕРЕПИШЕМ ЭТИ 10К СТРОК КОДА
@
КОТОРЫЕ ПИСАЛ ВАСИЛИЙ ПЕТРОВИЧ
@
КОТОРЫЙ УЖЕ НЕ РАБОТАЕТ У НАС 10 ЛЕТ
@
И ВООБЩЕ ОН УМЕР
>Только ты забываешь про читаемость кода.
Ты идиот? const и final - это подсказка для компилятора, для себя, для читателя и пользователя твоего кода, что ты в своей функции не будешь менять значение этого параметра. От этого наоборот читаемость кода улучшиться, просто ты у нас тупенький, до тебя все долго доходит.
>Или может быть это в шарпе так сделано, что как бы намекает.
Везде так сделано, идиот. Например, программисты на плюсах тоже советуют передавать неизменяемые аргументы по константной ссылке. На шарпе тоже самое.
Если не собираешься изменять значение переменной, то обязательно объяви ее константой.
>улучшиться
>гуманитарный дебил вещает с днищекурсов
Гуманитарий с днищекурсов тут только ты, раз final и const для тебя это сложно и непонятно.
>это подсказка для компилятора
нет
>для себя
ой дибилка
a + b // skladivaem a i b
А давайте обсудим сами технологии и техники программирования, не связывая их с конкретными языками.
Будем выяснять, как лучше организовать свою работу, чтобы она приносила радость, как писать код, за который потом не стыдно, стоит ли покрывать всё тестами или без них быстрее, какие паттерны надо использовать, да и зачем они вообще нужны, есть ли альтернатива технике "хуяк-хуяк и в продакшн", как стать по-настоящему первоклассным программистом.
Правила треда
1) Мы обсуждаем технологии, а не языки.
2) Холивары на тему крутости языка мы не устраиваем.
3) Мы не ищем оптимальный язык программирования.
4) Мы разбираемся, как стать хорошим программистом, а не рассказываем другим, что они - говно.
5) Мы не меряемся своими проектами, зарплатами, должностями, но не против дать несколько советов
Список книг для прочтения
Стив Макконнелл "Совершенный код"
Эндрю Хант, Дэвид Томас "Программист-прагматик. Путь от подмастерья к мастеру"
Чад Фаулер "Программист-фанатик"
Принимаются дополнения и замечания к списку книг.
LET THE THREAD BEGIN