Прочитал эту книгу. Осознал, что не знаю как вообще сейчас кодят. У меня в конторе используется методология "хуяк-хуяк и в продакшн", но меня это заебало и я хочу расти. Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии? Какой вообще правильный процесс? Какой у вас?Используете ли вы TDD? Что почитать по тому, как надо?
>>1107098 (OP)>какой-то золотой стандарт в индустрииооп, мань
>>1107102> 2018> оопУже даже не смешно.
>>1107098 (OP)Вообще-то "хуяк-хуяк и в продакшн" (он же аджайл и все его флаворы) - это и есть доминирующий сегодня процесс. Спринты, CI, девопс, вот это все.Тебя что конкретно интересует-то? Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции? Что?
>>1107103и в чём проблема?
Имхо, проебу все эстимейты, если TDD в ванильном виде попытаюсь заюзать.
>>1107108>Сам процесс непосредственно написания кода? Кодоконвенции?Это.Думал, какую-нибудь книгу почитать, чтобы мысли в порядок привести. Слишком дохуя технологий и методологий вокруг, что начинает казаться, что я делаю что-то не так.Или вот, допустим, надо тебе написать средний проект, условно, интернет-аукцион какой-нибудь.Какой будет примерный процесс, на уровне кодинга?
1
>>1107121переписывать тесты когда неправильно понял заказчика или заказчик сам не понимает что ему нужно пока не увидит чтото работающее ебать продуктивное занятие
>>1107110В ооп.мимокапитан
>>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 должна делать, у тебя уже есть минимальный набор тестов и минимальная имплементация в терминах (замоканных) внутренних функций. И тогда ты переходишь к одной из них и повторяешь весь процесс, и так далее, пока все не заработает без моков. То есть тесты - это на самом деле не тесты, это инструмент создания кода. Как-то так.Спойлер: АХАХАХА НИКТО ТАК НЕ ДЕЛАЕТ ВСЕМ ЛЕНЬ ВСЕ СПЕШАТ И ВООБЩЕ НИКТО ТАК НЕ УМЕЕТ ДЕЛАТЬ ВСЕ ПРИВЫКЛИ ХУЯК-ХУЯК И ХУЯК А ТАК ДЕЛАЮТ ТОЛЬКО ТЕ КТО САМИ ПИШУТ КНИГИ ПО ТДД ДА И ТО НЕ ВСЕГДА
А, ну и да: я обычно просто открываю файл и начинаю хуярить как попало псевдокод и примеры вперемешку с комментариями, попутно играясь с реплом. Пока хуярю псевдокод - вытаскиваю мелкие функции. Когда более-менее определился, что надо сделать, делаю минимальный рабочий вариант, попутно оставляя кучу туду-комментов. Проверяю в репле, если работает - вытаскиваю из кучи говнопсевдокода и примеров основные ассерты в тесты. Потом начинаю рефакторить, попутно добавляя тесты и дописывая код вместо туду-комментов. Когда получается что-то более-менее законченное, вытаскиваю оставшиеся туду-комменты в таск-менеджер, прогоняю все тесты вчистую, коммичу. Как-то так.Но это, конечно, если реально что-то такое, где думать\пробовать надо. Чаще просто берешь задачу, делаешь, тестишь-рефакторишь, коммитишь.И да, с тдд в обоих случаях было бы быстрее, но я как и все привык хуяк-хуяк((
>>1107098 (OP)>Что почитать по тому, как надо?
>>1107221>>1107231Спасибо, примерно начинаю понимать.
>>1107191Ну да, примерно это и имею ввиду.
>>1107221>Почти 2k18>МокатьОтдели чистую логику от сайд эффектов, и тебе не придется ничего мокать.
>>1107191Ты походу путаешь юнит-тесты (которые в тдд) с функциональными\интеграционными и прочим "exhaustive" тестированием. Чтобы заказчик увидел что-то работающее, тебе нужно сперва написать что-то работающее. Тдд - это способ написания кода.>>1107328Ты не понял. Замени "мокать" на "stub'ать" и перечитай тот пост. Согласен, тут есть путаница в терминах, я просто все виды "test doubles" называю моками. То есть это не про стейт.Идиотский пример:ensure: sum [1 2 3] == 6given that: x uberplus y => x+ysum [] = 0sum x:xs = x uberplus (sum xs) -- uberplus еще не написана, но тест sum уже проходит - начинаешь работать над uberplusИли даже:ensure: shoutHello "joe" == "HELLO JOE" -- hello mikegiven: upperCase "joe" => "JOE" -- еще не написанаНутыпонел.
Вообще, это все в sicp описывается.
>>1107121В ванильном виде TDD для функциональных языков заходит, за счет минимизации сайд-эффектов и т.п. и т.д..
>>1107098 (OP)Методика в общем случае одна: сначала подумал, сделал декомпозицию, набросал эскизы, потом по кусочкам сделал не особенно напрягая голову. В разных масштабах конечно, баг, фича, итерация, релиз, весь проект, нужен ли вообще этот проект, в чём смысл жизни.Но чаще всего сама задача неясна и нужно провести несколько экспериментов, создать несколько прототипов на выброс, затем осознав цель яснее применить стандартный метод с нуля.Ещё часто всем настолько похуй на качество кода, что берутся даже прототипы и выпускаются как есть в продакшен, чтобы клиент мог поставить уже свои эксперименты и выяснить нечто для него важное. Здесь ничего лучше хуяк и в продакшен нет. Ещё бывает так что клиент просто охуенно жадный и ему кажется что всё уже сделано и осталось всего-то ничего.Когда некая задача становится типовой, нарабатывается конвейер, фреймворк, тулчейн — и продукт выпускается массово с небольшой кастомизацией, не таящей в себе больших рисков, и хорошо вписывающейся в наработанный конвейер.Когда некая задача даже не требует кастомизации, выпускается готовый продукт либо SaaS.---То есть, везде крайне разная потребность/возможность/необходимость в затратах на стабильность кода. Неизбежно качество против дешевизны+сроков. У тебя не получится начитавшись книжек начать писать идеально в условиях недостатка времени и денег. Скилл конечно растёт со временем, и ты становишься эффективнее и дороже как специалист. Эти книжки если повезло выбрать хорошие тебе разве что укажут направление куда думать и к чему присматриваться.Касательно самоудовлетворения, вышеперечисленные сценарии развития событий таят в себе разные уровни довольства своей работой и разные риски по прибыльности. Чаще всего безрисковая работа очень грязная, нужно терпеть.Что касается автотестов, это не более чем инструмент. Где-то это средство стабилизации кода (waterfall). Где-то это средство экспериментирования и проектирования (TDD). Так или иначе проверить результат своей работы нужно, и здесь уже что дешевле будет — сколько времени займёт писать/поддерживать тест и сколько времени займёт вручную прощёлкать функционал тобой, коллегами, тестерами вместе взятыми за всё время жизни этого конкретного теста.По моему личному опыту, на рефакторинг по TDD и 100% покрытие тестами готов раскошеливаться почти никто. Разве что в гитхабик красивый проект с плашками сделаешь себе чтобы показывать всем.
Берешь и кодишь правильно без задней мысли.
промышленный кодинг - это хуяк хуяк и в продакшн. если появляются время и опыт, то начинаешь писать красивее, но если сроки поджимают, задача малопонятная а проект малознакомый - то говнокодишь, что есть мочи.
>>1107630>но если сроки поджимают, задача малопонятная а проект малознакомый - то говнокодишь, что есть мочи.Вот иди нахуй с такими советами.
>>1107635ну и продолжай жрать борщи на шее у мамки хули.
>>1107638Интересно причем тут мамка и ее шея...
>>1107624
Спасибо за ответы.
>>1107918Ааа, бля, как я проиграл с пикчи
>>1107098 (OP)Как сейчас кодят, тебе написали в треде. Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать.
>>1109593>Как надо кодить, чтобы не было проебов сроков на второй и далее итерации - могу рассказать, но это никому не нужно и даже вредно знать. -- Василий, 11 "Б".
>>1107098 (OP)Кодить правильно - молча
>>1107098 (OP)TDD - манятеория. Стандарт - компромисс.
>>1109699Ну ладно, TDD применима когда ты с нулевого нуля строишь замок из говна и тебе ничего пока не мешает писать как заблагорассудится. А когда нужно в один замок другой встроить - тут-то TDD и заканчивается, и начинается "хуяк-хуяк, че там тесты?".
>>1107098 (OP)Вот мой список правил, который я сам использую при программировании на любом языке:1) Использовать как можно больше маленьких функций, процедур и методов, размером не больше экрана. 2) Использовать очевидные и достаточно длинные названия функций, методов и переменных.3) Избегать коппипасту, отделяя её в отдельные функции. 4) Писать как можно больше тестов.
>>1109605Детектор на PHP написан?
>>1109823Этого мало. 4 нихрена не помогает.
>>1109826Тесты очень сильно помогают, так как иначе есть большой риск при написании кода сломать что-то уже работающее. Особенно актуально это бывает при групповом программировании.
>>1109823Двачую все пункты.>>1109826Ничоси не помогает! Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода. Сам видел стабильно работающий проект, покрытый-перепокрытый всевозможными тестами, внутри которого творился неподдерживаемый ад и израиль. Только на тестах всё и держится там.
>>1109828Тесты = код. А значит в тестах могут быть баги. При чем как твои, так и бизнес-логики.
>>1109882Ну охуеть теперь - человек может ошибаться - вот это поворот, как дальше жить?
>>1109825Нет, на С++.
>>1109826Значит тесты пишете уровня "о вот есть класс, появится ли обьект?"Если у тебя одно и тоже место отваливается после твоих правок - напиши тест, сэкономишь тонну времени."михалыч, у нас на кассе опять чеки отвалились после того как скидку добавили на дилды"
>>1109882Вот смотри. Тесты пишут, чтобы код рабочий был, так? То есть в работающем проекте тесты все проходятся. А если что то не работает, то одно подгоняется под другое.
>>1109880> Да это единственная вещь, которая тебе всегда поможет, вне зависимости от качества кода.Если это единственная вещь для обеспечения качества кода, которая вообще есть, то да, она всегда поможет, LOL. Просто далеко не всегда это единственная вещь %%(кому я пизжу, формальные доказательства и SMT на контрактах я один тут во всей стране применяю), и тесты - это как бы last resort.
>>1110105Бля, разметка.
>>1110017>одно подгоняется под другое.
>>1110155Тащемта это ответ на вопрос треда.
>>1107103Ну это пока еще стандарт. ООПный хуяк-хуяк и в продакшн
>>1110354Как там по ООП, можно прямо в классе планировщика задач хуякать свой код или планировщик должен вызвать его откуда-то? Или "по ситуации"?
Рекомендую этот блог. Тут тебя научат как правильно кодитьhttp://www.yegor256.com/
>>1110354> Ну это пока еще стандарт.Стандарты - это Ада и Си. Все остальные хуярят как придется, без всяких стандартов.>ООПный хуяк-хуяк и в продакшнТы все перепутал. "Хуяк-хуяк и в продакшн" - это методология разработки (аджайл, континиус интегрейшен). К ООП это имеет отношение чуть менее чем никакое.
>>1110357Ты понимаешь что ООП это лишь способ структурировать код, чтобы в будущем не обосраться его поддерживать? Можешь хоть в main() всё писать через вуаил иф иф иф иф иф иф иф. Но уже на паре тысяч строк ты охуешь.
>>1110403Я вот все думаю составить список уродов от мира IT и их блогов.
>>1110454>ООП это лишь способ структурировать кодНеверно. Объекты подразумевают определенную (хуевую в общем случае) модель управления состоянием.Для структурирования кода используются неймспейсы.
>>1110454Понимаю, я тебя спрашиваю - можно или нет? Или можно "иногда"?
>>1110518С точки зрения компьютера - можно.Компуктеру вообще похуй где ты что пишешь.Но ты же сам будешь охуевать когда через полгода откроешь свой код.
>>1110625Хватит вилять, ООП для кого придумали? Не для компуктера же, вот и ответь мне на вопрос.
>>1110759>ООП для кого придумалиТы не поверишь, это — ..............
>>1107098 (OP)>Используете ли вы TDDну если кроме как в юнит тесте не проверить свою писанину, то приходится писать тест и код почти одновременноно переписывать потом тесты и искать что в них сломалось когда меняют спецификацию тот еще геморрой
>>1107098 (OP)>Я понимаю, что каждый кодит по-своему, но всё же должен быть какой-то золотой стандарт в индустрии?Не-а. В первую очередь это творческий процесс и ни о каком стандарте не может быть и речи. Стандарты разрабатывают для макак.
>>1112510>творческий процессСуть одноразового быдлокода. За стандартомакакой не больно поддерживать хотя бы.
>>1112572В таком случае о каком росте может идти речь?
>>1107108>Проджект менеджмент? Дизайн архитектуры? Сам процесс непосредственно написания кода? Кодоконвенции?Меня всё вот это интересует. Как разобраться?
e
>>1107098 (OP)Был энтузиастом этой книги. И других за авторством Роберта Мартина.Все тимлиды мне всегда говорили "малаца", когда по первому времени показывал свой код.Но чем дальше ты углублялся в работу, тем больше осознавал, что вообще всем похуй на эти практики. И это я говорю с опытом смены 4 работ.
>>1107121А что сложного в написании тестов.>юзер нажимает на кнопку>юзер видит загрузку>юзер видит таблику "пошёл нахуй"Три строчки.
>>1112749Книготред рядом. Я для кого это всё десять лет собирал?..
>>1114964То що тесты должны быть написаны для каждой ветки каждого оператора условия, во как.http://www.opennet.ru/opennews/art.shtml?num=47806Добавлена поддержка измерения покрытия (coverage) тестовым кодом веток и методов. Покрытие ветки показывает то, какие ветки были выполнены в процессе выполнения тестов, а какие нет. Покрытие метода показывает какие методы были вызваны, а какие нет.
>>1107098 (OP)Про тесты смотреть сюда - https://www.sqlite.org/testing.html
>>1114964Сколько ты напишешь тестов проверяющих деление на ноль?
>>1127559Уточни - тесты для функции, суть которой делить на ноль. Или просто протестировать деление на ноль, как оно себя ведёт?
>>1127776Функцию, типы переменных x, y => Int32 | Float | Nil.
>>1127893Уточнение, суть функции в делении. Задача -протестировать случаи, когда одна из переменных окажется нулем.
>>1107098 (OP)>как надо?Как Макконнелл написал./thread
>>1107098 (OP)хуяк-хуяк -- самый правильный бизнес-процесс, т.к бизнесу насрать на маня-архитектуру. ему главное как можно быстро выйти на рынок, настрогать фич и заработать бабла
>>1128341Для контор уровня "Ашот и сыновья".
>>1128445Для лбого бизнеса важна именно скорость изменений. Чтобы не приходилось каждую фичу ждать по пол года
>>1128511ну, а без робастной архитектуры у тебя проект станет неподдерживаемым через сколько правок?маняархитектура - long-term investment, если говорить на твоем (((языке)))
>>1129430Правило трех изменений. Если ты три раза лезешь в одно и тоже место в коде, чтобы реализовать хотелки заказчика - рефактори это место в красивое, чтобы следующие правки были быстры и легки. Если же оно работает и заказчику не надо - не влезай,не трать время.
> “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.”
>>1129459Хороший совет.
>>1110105чё за SMT?
Кодят быдлокодеры. Программисты пишут.
>>1127559По идее ровно один. Делитель = 0 -> Ожидаемое поведение (возврат нула, магического числа, эксепшон)
>>1154920Ага, блять. И не "последний" а "крайний", не "плавают", а "ходят", не "корабль", а "судно".
>>1154920Программисты программируют ебасосина
>>1154965а сколько нужно тестов на присвание значения переменной?int a = 1
