>какой-то золотой стандарт в индустрии
ооп, мань
> 2018
> ооп
Уже даже не смешно.
Вообще-то "хуяк-хуяк и в продакшн" (он же аджайл и все его флаворы) - это и есть доминирующий сегодня процесс. Спринты, CI, девопс, вот это все.
Тебя что конкретно интересует-то? Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции? Что?
и в чём проблема?
Имхо, проебу все эстимейты, если TDD в ванильном виде попытаюсь заюзать.
>Сам процесс непосредственно написания кода? Кодоконвенции?
Это.
Думал, какую-нибудь книгу почитать, чтобы мысли в порядок привести.
Слишком дохуя технологий и методологий вокруг, что начинает казаться, что я делаю что-то не так.
Или вот, допустим, надо тебе написать средний проект, условно, интернет-аукцион какой-нибудь.
Какой будет примерный процесс, на уровне кодинга?
1
переписывать тесты когда неправильно понял заказчика или заказчик сам не понимает что ему нужно пока не увидит чтото работающее ебать продуктивное занятие
В ооп.
мимокапитан
>написать средний проект
Ну так это же не уровень кодинга, а как раз уровень проекта\дизайна, не? Уровень кодинга - это, типа, отослать один патч, например.
В "ванильном ТДД", как анон выше выразился, ты берешь чанк функциональности и начинаешь писать с юз-кейсов в топ-даун стиле. То есть тебе надо написать функцию foo, например. Ты начинаешь думать, что она вообще должна делать и что от тебя требуется. Пока думаешь - записываешь свои мысли в коде. Типа, "тэк блэт, если нам пришел frobnicated, то мы хуярим запрос к базе и возвращаем , а если не frobnicated, то что мы делаем?.. тээк... эксепшн корочи кидаем!" - и пока ты это думаешь, ты это сразу записываешь в виде тестов (у меня псевдокод): given frobnicated x, mocking query(x) = "hui": foo x => "hui". given unfrobnicated x, foo x => throws Exception. Тэк блэт, стоп, а если нулл пришел? given x = null... тэк, возвращаем дефолтный frob: foo x = frob... так, а откуда мы этот frob получим? Ага, значит у нас там должна быть внутри функция bar, и она возвращает дефолтный frob, и нам еще конфиг оказывается надо передавать! Тэк, ок: given conf = {...}, mocking bar(conf) = frob, foo conf x = frob. Тэк, блэт...
Ну и вот таким макаром ты мокаешь все внутренние функции и пишешь свой foo в их терминах. И у тебя получается очень красивый, высокоуровневый код на одном уровне абстракции (который нихуя не работает, потому что ты замоканные функции еще не написал, а только замокал). Но как раз потому что ты их еще не написал, ты не можешь зависеть от деталей реализации, поэтому код и получается высокоуровневый и красивый. Ну и вот, типа когда ты понял, что твоя foo должна делать, у тебя уже есть минимальный набор тестов и минимальная имплементация в терминах (замоканных) внутренних функций. И тогда ты переходишь к одной из них и повторяешь весь процесс, и так далее, пока все не заработает без моков. То есть тесты - это на самом деле не тесты, это инструмент создания кода. Как-то так.
Спойлер: АХАХАХА НИКТО ТАК НЕ ДЕЛАЕТ ВСЕМ ЛЕНЬ ВСЕ СПЕШАТ И ВООБЩЕ НИКТО ТАК НЕ УМЕЕТ ДЕЛАТЬ ВСЕ ПРИВЫКЛИ ХУЯК-ХУЯК И ХУЯК А ТАК ДЕЛАЮТ ТОЛЬКО ТЕ КТО САМИ ПИШУТ КНИГИ ПО ТДД ДА И ТО НЕ ВСЕГДА
А, ну и да: я обычно просто открываю файл и начинаю хуярить как попало псевдокод и примеры вперемешку с комментариями, попутно играясь с реплом. Пока хуярю псевдокод - вытаскиваю мелкие функции. Когда более-менее определился, что надо сделать, делаю минимальный рабочий вариант, попутно оставляя кучу туду-комментов. Проверяю в репле, если работает - вытаскиваю из кучи говнопсевдокода и примеров основные ассерты в тесты. Потом начинаю рефакторить, попутно добавляя тесты и дописывая код вместо туду-комментов. Когда получается что-то более-менее законченное, вытаскиваю оставшиеся туду-комменты в таск-менеджер, прогоняю все тесты вчистую, коммичу. Как-то так.
Но это, конечно, если реально что-то такое, где думать\пробовать надо. Чаще просто берешь задачу, делаешь, тестишь-рефакторишь, коммитишь.
И да, с тдд в обоих случаях было бы быстрее, но я как и все привык хуяк-хуяк((
Но это, конечно, если реально что-то такое, где думать\пробовать надо. Чаще просто берешь задачу, делаешь, тестишь-рефакторишь, коммитишь.
И да, с тдд в обоих случаях было бы быстрее, но я как и все привык хуяк-хуяк((
>Что почитать по тому, как надо?
Спасибо, примерно начинаю понимать.
Ну да, примерно это и имею ввиду.
>Почти 2k18
>Мокать
Отдели чистую логику от сайд эффектов, и тебе не придется ничего мокать.
Ты походу путаешь юнит-тесты (которые в тдд) с функциональными\интеграционными и прочим "exhaustive" тестированием. Чтобы заказчик увидел что-то работающее, тебе нужно сперва написать что-то работающее. Тдд - это способ написания кода.
Ты не понял. Замени "мокать" на "stub'ать" и перечитай тот пост. Согласен, тут есть путаница в терминах, я просто все виды "test doubles" называю моками. То есть это не про стейт.
Идиотский пример:
ensure: sum [1 2 3] == 6
given that: x uberplus y => x+y
sum [] = 0
sum x:xs = x uberplus (sum xs) -- uberplus еще не написана, но тест sum уже проходит - начинаешь работать над uberplus
Или даже:
ensure: shoutHello "joe" == "HELLO JOE" -- hello mike
given: upperCase "joe" => "JOE" -- еще не написана
Нутыпонел.
Вообще, это все в sicp описывается.
В ванильном виде TDD для функциональных языков заходит, за счет минимизации сайд-эффектов и т.п. и т.д..
Методика в общем случае одна: сначала подумал, сделал декомпозицию, набросал эскизы, потом по кусочкам сделал не особенно напрягая голову. В разных масштабах конечно, баг, фича, итерация, релиз, весь проект, нужен ли вообще этот проект, в чём смысл жизни.
Но чаще всего сама задача неясна и нужно провести несколько экспериментов, создать несколько прототипов на выброс, затем осознав цель яснее применить стандартный метод с нуля.
Ещё часто всем настолько похуй на качество кода, что берутся даже прототипы и выпускаются как есть в продакшен, чтобы клиент мог поставить уже свои эксперименты и выяснить нечто для него важное. Здесь ничего лучше хуяк и в продакшен нет. Ещё бывает так что клиент просто охуенно жадный и ему кажется что всё уже сделано и осталось всего-то ничего.
Когда некая задача становится типовой, нарабатывается конвейер, фреймворк, тулчейн — и продукт выпускается массово с небольшой кастомизацией, не таящей в себе больших рисков, и хорошо вписывающейся в наработанный конвейер.
Когда некая задача даже не требует кастомизации, выпускается готовый продукт либо SaaS.
---
То есть, везде крайне разная потребность/возможность/необходимость в затратах на стабильность кода. Неизбежно качество против дешевизны+сроков. У тебя не получится начитавшись книжек начать писать идеально в условиях недостатка времени и денег. Скилл конечно растёт со временем, и ты становишься эффективнее и дороже как специалист. Эти книжки если повезло выбрать хорошие тебе разве что укажут направление куда думать и к чему присматриваться.
Касательно самоудовлетворения, вышеперечисленные сценарии развития событий таят в себе разные уровни довольства своей работой и разные риски по прибыльности. Чаще всего безрисковая работа очень грязная, нужно терпеть.
Что касается автотестов, это не более чем инструмент. Где-то это средство стабилизации кода (waterfall). Где-то это средство экспериментирования и проектирования (TDD). Так или иначе проверить результат своей работы нужно, и здесь уже что дешевле будет — сколько времени займёт писать/поддерживать тест и сколько времени займёт вручную прощёлкать функционал тобой, коллегами, тестерами вместе взятыми за всё время жизни этого конкретного теста.
По моему личному опыту, на рефакторинг по TDD и 100% покрытие тестами готов раскошеливаться почти никто. Разве что в гитхабик красивый проект с плашками сделаешь себе чтобы показывать всем.
Берешь и кодишь правильно без задней мысли.
промышленный кодинг - это хуяк хуяк и в продакшн. если появляются время и опыт, то начинаешь писать красивее, но если сроки поджимают, задача малопонятная а проект малознакомый - то говнокодишь, что есть мочи.
>но если сроки поджимают, задача малопонятная а проект малознакомый - то говнокодишь, что есть мочи.
Вот иди нахуй с такими советами.
ну и продолжай жрать борщи на шее у мамки хули.
Интересно причем тут мамка и ее шея...
Спасибо за ответы.
Ааа, бля, как я проиграл с пикчи
Как сейчас кодят, тебе написали в треде. Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать.
>Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать.
-- Василий, 11 "Б".
Кодить правильно - молча
TDD - манятеория. Стандарт - компромисс.
Ну ладно, TDD применима когда ты с нулевого нуля строишь замок из говна и тебе ничего пока не мешает писать как заблагорассудится. А когда нужно в один замок другой встроить - тут-то TDD и заканчивается, и начинается "хуяк-хуяк, че там тесты?".
Вот мой список правил, который я сам использую при программировании на любом языке:
1) Использовать как можно больше маленьких функций, процедур и методов, размером не больше экрана.
2) Использовать очевидные и достаточно длинные названия функций, методов и переменных.
3) Избегать коппипасту, отделяя её в отдельные функции.
4) Писать как можно больше тестов.
Детектор на PHP написан?
Этого мало. 4 нихрена не помогает.
Тесты очень сильно помогают, так как иначе есть большой риск при написании кода сломать что-то уже работающее. Особенно актуально это бывает при групповом программировании.
Двачую все пункты.
Ничоси не помогает! Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода. Сам видел стабильно работающий проект, покрытый-перепокрытый всевозможными тестами, внутри которого творился неподдерживаемый ад и израиль. Только на тестах всё и держится там.
Тесты = код. А значит в тестах могут быть баги. При чем как твои, так и бизнес-логики.
Ну охуеть теперь - человек может ошибаться - вот это поворот, как дальше жить?
Нет, на С++.
Значит тесты пишете уровня "о вот есть класс, появится ли обьект?"
Если у тебя одно и тоже место отваливается после твоих правок - напиши тест, сэкономишь тонну времени.
"михалыч, у нас на кассе опять чеки отвалились после того как скидку добавили на дилды"
Вот смотри. Тесты пишут, чтобы код рабочий был, так? То есть в работающем проекте тесты все проходятся. А если что то не работает, то одно подгоняется под другое.
> Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода.
Если это единственная вещь для обеспечения качества кода, которая вообще есть, то да, она всегда поможет, LOL. Просто далеко не всегда это единственная вещь %%(кому я пизжу, формальные доказательства и SMT на контрактах я один тут во всей стране применяю), и тесты - это как бы last resort.
Бля, разметка.
>одно подгоняется под другое.
Тащемта это ответ на вопрос треда.
Ну это пока еще стандарт. ООПный хуяк-хуяк и в продакшн
Как там по ООП, можно прямо в классе планировщика задач хуякать свой код или планировщик должен вызвать его откуда-то? Или "по ситуации"?
> Ну это пока еще стандарт.
Стандарты - это Ада и Си. Все остальные хуярят как придется, без всяких стандартов.
>ООПный хуяк-хуяк и в продакшн
Ты все перепутал. "Хуяк-хуяк и в продакшн" - это методология разработки (аджайл, континиус интегрейшен). К ООП это имеет отношение чуть менее чем никакое.
Ты понимаешь что ООП это лишь способ структурировать код, чтобы в будущем не обосраться его поддерживать? Можешь хоть в main() всё писать через вуаил иф иф иф иф иф иф иф. Но уже на паре тысяч строк ты охуешь.
Я вот все думаю составить список уродов от мира IT и их блогов.
>ООП это лишь способ структурировать код
Неверно. Объекты подразумевают определенную (хуевую в общем случае) модель управления состоянием.
Для структурирования кода используются неймспейсы.
Понимаю, я тебя спрашиваю - можно или нет? Или можно "иногда"?
С точки зрения компьютера - можно.
Компуктеру вообще похуй где ты что пишешь.
Но ты же сам будешь охуевать когда через полгода откроешь свой код.
Хватит вилять, ООП для кого придумали? Не для компуктера же, вот и ответь мне на вопрос.
>ООП для кого придумали
Ты не поверишь, это — ..............
>Используете ли вы TDD
ну если кроме как в юнит тесте не проверить свою писанину, то приходится писать тест и код почти одновременно
но переписывать потом тесты и искать что в них сломалось когда меняют спецификацию тот еще геморрой
>Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии?
Не-а. В первую очередь это творческий процесс и ни о каком стандарте не может быть и речи. Стандарты разрабатывают для макак.
>творческий процесс
Суть одноразового быдлокода. За стандартомакакой не больно поддерживать хотя бы.
В таком случае о каком росте может идти речь?
>Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции?
Меня всё вот это интересует. Как разобраться?
e
Был энтузиастом этой книги. И других за авторством Роберта Мартина.
Все тимлиды мне всегда говорили "малаца", когда по первому времени показывал свой код.
Но чем дальше ты углублялся в работу, тем больше осознавал, что вообще всем похуй на эти практики. И это я говорю с опытом смены 4 работ.
А что сложного в написании тестов.
>юзер нажимает на кнопку
>юзер видит загрузку
>юзер видит таблику "пошёл нахуй"
Три строчки.
Книготред рядом. Я для кого это всё десять лет собирал?..
То що тесты должны быть написаны для каждой ветки каждого оператора условия, во как.
http://www.opennet.ru/opennews/art.shtml?num=47806
Добавлена поддержка измерения покрытия (coverage) тестовым кодом веток и методов. Покрытие ветки показывает то, какие ветки были выполнены в процессе выполнения тестов, а какие нет. Покрытие метода показывает какие методы были вызваны, а какие нет.
Про тесты смотреть сюда - https://www.sqlite.org/testing.html
1
Сколько ты напишешь тестов проверяющих деление на ноль?
Уточни - тесты для функции, суть которой делить на ноль. Или просто протестировать деление на ноль, как оно себя ведёт?
Функцию, типы переменных x, y => Int32 | Float | Nil.
Уточнение, суть функции в делении. Задача -протестировать случаи, когда одна из переменных окажется нулем.
>как надо?
Как Макконнелл написал.
/thread
хуяк-хуяк -- самый правильный бизнес-процесс, т.к бизнесу насрать на маня-архитектуру. ему главное как можно быстро выйти на рынок, настрогать фич и заработать бабла
Для контор уровня "Ашот и сыновья".
Для лбого бизнеса важна именно скорость изменений. Чтобы не приходилось каждую фичу ждать по пол года
ну, а без робастной архитектуры у тебя проект станет неподдерживаемым через сколько правок?
маняархитектура - long-term investment, если говорить на твоем (((языке)))
Правило трех изменений. Если ты три раза лезешь в одно и тоже место в коде, чтобы реализовать хотелки заказчика - рефактори это место в красивое, чтобы следующие правки были быстры и легки. Если же оно работает и заказчику не надо - не влезай,не трать время.
> “TDD is not about good citizenship. You are not immoral if you don’t TDD. You’re not not a good looker forwarder or a protector of the future. It’s not about citizenship. TDD isn’t even about raising the quality of your code. Now TDD very often does increase the quality of teams that aren’t doing it to begin with, but that’s actually neither here nor there, because TDD isn’t about that. TDD is about more value faster.
> The other thing it’s not about? It’s not about art and it’s not about craftsmanship. It’s not about the excellence of our high standards. The reason we test drive is by test driving, we go faster. We put more value into the field faster than if we didn’t do TDD. And that is the money premise. We’re in this for the money.”
> The other thing it’s not about? It’s not about art and it’s not about craftsmanship. It’s not about the excellence of our high standards. The reason we test drive is by test driving, we go faster. We put more value into the field faster than if we didn’t do TDD. And that is the money premise. We’re in this for the money.”
Хороший совет.
чё за SMT?
Кодят быдлокодеры. Программисты пишут.
По идее ровно один. Делитель = 0 -> Ожидаемое поведение (возврат нула, магического числа, эксепшон)
Ага, блять. И не "последний" а "крайний", не "плавают", а "ходят", не "корабль", а "судно".
Программисты программируют ебасосина
а сколько нужно тестов на присвание значения переменной?
int a = 1
Осознал, что не знаю как вообще сейчас кодят. У меня в конторе используется методология "хуяк-хуяк и в продакшн", но меня это заебало и я хочу расти.
Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии?
Какой вообще правильный процесс? Какой у вас?
Используете ли вы TDD? Что почитать по тому, как надо?