24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Прочитал эту книгу. Осознал, что не знаю как вообще сейчас кодят. У меня в конторе используется методология "хуяк-хуяк и в продакшн", но меня это заебало и я хочу расти.
Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии? Какой вообще правильный процесс? Какой у вас? Используете ли вы TDD? Что почитать по тому, как надо?
>>1107098 (OP) Вообще-то "хуяк-хуяк и в продакшн" (он же аджайл и все его флаворы) - это и есть доминирующий сегодня процесс. Спринты, CI, девопс, вот это все.
Тебя что конкретно интересует-то? Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции? Что?
>>1107108 >Сам процесс непосредственно написания кода? Кодоконвенции? Это.
Думал, какую-нибудь книгу почитать, чтобы мысли в порядок привести. Слишком дохуя технологий и методологий вокруг, что начинает казаться, что я делаю что-то не так.
Или вот, допустим, надо тебе написать средний проект, условно, интернет-аукцион какой-нибудь. Какой будет примерный процесс, на уровне кодинга?
переписывать тесты когда неправильно понял заказчика или заказчик сам не понимает что ему нужно пока не увидит чтото работающее ебать продуктивное занятие
>>1107136 >написать средний проект Ну так это же не уровень кодинга, а как раз уровень проекта\дизайна, не? Уровень кодинга - это, типа, отослать один патч, например.
В "ванильном ТДД", как анон выше выразился, ты берешь чанк функциональности и начинаешь писать с юз-кейсов в топ-даун стиле. То есть тебе надо написать функцию 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 должна делать, у тебя уже есть минимальный набор тестов и минимальная имплементация в терминах (замоканных) внутренних функций. И тогда ты переходишь к одной из них и повторяешь весь процесс, и так далее, пока все не заработает без моков. То есть тесты - это на самом деле не тесты, это инструмент создания кода. Как-то так.
Спойлер: АХАХАХА НИКТО ТАК НЕ ДЕЛАЕТ ВСЕМ ЛЕНЬ ВСЕ СПЕШАТ И ВООБЩЕ НИКТО ТАК НЕ УМЕЕТ ДЕЛАТЬ ВСЕ ПРИВЫКЛИ ХУЯК-ХУЯК И ХУЯК А ТАК ДЕЛАЮТ ТОЛЬКО ТЕ КТО САМИ ПИШУТ КНИГИ ПО ТДД ДА И ТО НЕ ВСЕГДА
А, ну и да: я обычно просто открываю файл и начинаю хуярить как попало псевдокод и примеры вперемешку с комментариями, попутно играясь с реплом. Пока хуярю псевдокод - вытаскиваю мелкие функции. Когда более-менее определился, что надо сделать, делаю минимальный рабочий вариант, попутно оставляя кучу туду-комментов. Проверяю в репле, если работает - вытаскиваю из кучи говнопсевдокода и примеров основные ассерты в тесты. Потом начинаю рефакторить, попутно добавляя тесты и дописывая код вместо туду-комментов. Когда получается что-то более-менее законченное, вытаскиваю оставшиеся туду-комменты в таск-менеджер, прогоняю все тесты вчистую, коммичу. Как-то так.
Но это, конечно, если реально что-то такое, где думать\пробовать надо. Чаще просто берешь задачу, делаешь, тестишь-рефакторишь, коммитишь.
И да, с тдд в обоих случаях было бы быстрее, но я как и все привык хуяк-хуяк((
>>1107191 Ты походу путаешь юнит-тесты (которые в тдд) с функциональными\интеграционными и прочим "exhaustive" тестированием. Чтобы заказчик увидел что-то работающее, тебе нужно сперва написать что-то работающее. Тдд - это способ написания кода.
>>1107328 Ты не понял. Замени "мокать" на "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" -- еще не написана Нутыпонел.
>>1107098 (OP) Методика в общем случае одна: сначала подумал, сделал декомпозицию, набросал эскизы, потом по кусочкам сделал не особенно напрягая голову. В разных масштабах конечно, баг, фича, итерация, релиз, весь проект, нужен ли вообще этот проект, в чём смысл жизни.
Но чаще всего сама задача неясна и нужно провести несколько экспериментов, создать несколько прототипов на выброс, затем осознав цель яснее применить стандартный метод с нуля.
Ещё часто всем настолько похуй на качество кода, что берутся даже прототипы и выпускаются как есть в продакшен, чтобы клиент мог поставить уже свои эксперименты и выяснить нечто для него важное. Здесь ничего лучше хуяк и в продакшен нет. Ещё бывает так что клиент просто охуенно жадный и ему кажется что всё уже сделано и осталось всего-то ничего.
Когда некая задача становится типовой, нарабатывается конвейер, фреймворк, тулчейн — и продукт выпускается массово с небольшой кастомизацией, не таящей в себе больших рисков, и хорошо вписывающейся в наработанный конвейер.
Когда некая задача даже не требует кастомизации, выпускается готовый продукт либо SaaS.
---
То есть, везде крайне разная потребность/возможность/необходимость в затратах на стабильность кода. Неизбежно качество против дешевизны+сроков. У тебя не получится начитавшись книжек начать писать идеально в условиях недостатка времени и денег. Скилл конечно растёт со временем, и ты становишься эффективнее и дороже как специалист. Эти книжки если повезло выбрать хорошие тебе разве что укажут направление куда думать и к чему присматриваться.
Касательно самоудовлетворения, вышеперечисленные сценарии развития событий таят в себе разные уровни довольства своей работой и разные риски по прибыльности. Чаще всего безрисковая работа очень грязная, нужно терпеть.
Что касается автотестов, это не более чем инструмент. Где-то это средство стабилизации кода (waterfall). Где-то это средство экспериментирования и проектирования (TDD). Так или иначе проверить результат своей работы нужно, и здесь уже что дешевле будет — сколько времени займёт писать/поддерживать тест и сколько времени займёт вручную прощёлкать функционал тобой, коллегами, тестерами вместе взятыми за всё время жизни этого конкретного теста.
По моему личному опыту, на рефакторинг по TDD и 100% покрытие тестами готов раскошеливаться почти никто. Разве что в гитхабик красивый проект с плашками сделаешь себе чтобы показывать всем.
промышленный кодинг - это хуяк хуяк и в продакшн. если появляются время и опыт, то начинаешь писать красивее, но если сроки поджимают, задача малопонятная а проект малознакомый - то говнокодишь, что есть мочи.
>>1107098 (OP) Как сейчас кодят, тебе написали в треде. Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать.
>>1109593 >Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать. -- Василий, 11 "Б".
>>1109699 Ну ладно, TDD применима когда ты с нулевого нуля строишь замок из говна и тебе ничего пока не мешает писать как заблагорассудится. А когда нужно в один замок другой встроить - тут-то TDD и заканчивается, и начинается "хуяк-хуяк, че там тесты?".
>>1107098 (OP) Вот мой список правил, который я сам использую при программировании на любом языке: 1) Использовать как можно больше маленьких функций, процедур и методов, размером не больше экрана. 2) Использовать очевидные и достаточно длинные названия функций, методов и переменных. 3) Избегать коппипасту, отделяя её в отдельные функции. 4) Писать как можно больше тестов.
>>1109826 Тесты очень сильно помогают, так как иначе есть большой риск при написании кода сломать что-то уже работающее. Особенно актуально это бывает при групповом программировании.
>>1109826 Ничоси не помогает! Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода. Сам видел стабильно работающий проект, покрытый-перепокрытый всевозможными тестами, внутри которого творился неподдерживаемый ад и израиль. Только на тестах всё и держится там.
>>1109826 Значит тесты пишете уровня "о вот есть класс, появится ли обьект?" Если у тебя одно и тоже место отваливается после твоих правок - напиши тест, сэкономишь тонну времени. "михалыч, у нас на кассе опять чеки отвалились после того как скидку добавили на дилды"
>>1109882 Вот смотри. Тесты пишут, чтобы код рабочий был, так? То есть в работающем проекте тесты все проходятся. А если что то не работает, то одно подгоняется под другое.
>>1109880 > Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода. Если это единственная вещь для обеспечения качества кода, которая вообще есть, то да, она всегда поможет, LOL. Просто далеко не всегда это единственная вещь %%(кому я пизжу, формальные доказательства и SMT на контрактах я один тут во всей стране применяю), и тесты - это как бы last resort.
>>1110354 > Ну это пока еще стандарт. Стандарты - это Ада и Си. Все остальные хуярят как придется, без всяких стандартов.
>ООПный хуяк-хуяк и в продакшн Ты все перепутал. "Хуяк-хуяк и в продакшн" - это методология разработки (аджайл, континиус интегрейшен). К ООП это имеет отношение чуть менее чем никакое.
>>1110357 Ты понимаешь что ООП это лишь способ структурировать код, чтобы в будущем не обосраться его поддерживать? Можешь хоть в main() всё писать через вуаил иф иф иф иф иф иф иф. Но уже на паре тысяч строк ты охуешь.
>>1110518 С точки зрения компьютера - можно. Компуктеру вообще похуй где ты что пишешь. Но ты же сам будешь охуевать когда через полгода откроешь свой код.
>>1107098 (OP) >Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии? Не-а. В первую очередь это творческий процесс и ни о каком стандарте не может быть и речи. Стандарты разрабатывают для макак.
>>1107108 >Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции? Меня всё вот это интересует. Как разобраться?
>>1107098 (OP) Был энтузиастом этой книги. И других за авторством Роберта Мартина. Все тимлиды мне всегда говорили "малаца", когда по первому времени показывал свой код. Но чем дальше ты углублялся в работу, тем больше осознавал, что вообще всем похуй на эти практики. И это я говорю с опытом смены 4 работ.
>>1114964 То що тесты должны быть написаны для каждой ветки каждого оператора условия, во как. http://www.opennet.ru/opennews/art.shtml?num=47806 Добавлена поддержка измерения покрытия (coverage) тестовым кодом веток и методов. Покрытие ветки показывает то, какие ветки были выполнены в процессе выполнения тестов, а какие нет. Покрытие метода показывает какие методы были вызваны, а какие нет.
>>1107098 (OP) хуяк-хуяк -- самый правильный бизнес-процесс, т.к бизнесу насрать на маня-архитектуру. ему главное как можно быстро выйти на рынок, настрогать фич и заработать бабла
>>1128511 ну, а без робастной архитектуры у тебя проект станет неподдерживаемым через сколько правок? маняархитектура - long-term investment, если говорить на твоем (((языке)))
>>1129430 Правило трех изменений. Если ты три раза лезешь в одно и тоже место в коде, чтобы реализовать хотелки заказчика - рефактори это место в красивое, чтобы следующие правки были быстры и легки. Если же оно работает и заказчику не надо - не влезай,не трать время.
двачер рассказывает всю правду о ТДД31/01/18 Срд 16:57:05#81№1129620
> “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.”
Осознал, что не знаю как вообще сейчас кодят. У меня в конторе используется методология "хуяк-хуяк и в продакшн", но меня это заебало и я хочу расти.
Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии?
Какой вообще правильный процесс? Какой у вас?
Используете ли вы TDD? Что почитать по тому, как надо?