- 1
- 2
- 3
- 4
- 5
io_service::strand strand_one(service), strand_two(service);
for (int i = 0; i < 5; ++i)
service.post(strand_one.wrap(boost::bind(func, i)));
for (int i = 5; i < 10; ++i)
service.post(strand_two.wrap(boost::bind(func, i)));
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+17
io_service::strand strand_one(service), strand_two(service);
for (int i = 0; i < 5; ++i)
service.post(strand_one.wrap(boost::bind(func, i)));
for (int i = 5; i < 10; ++i)
service.post(strand_two.wrap(boost::bind(func, i)));
Пример из книги Boost.Asio C++ Network Programming.
In the preceding code, we made sure that the first five and the last five were serialized namely, "func called, i = 0" is called before "func called, i = 1", which is called before "func called, i = 2", and so on. The same goes for "func called, i = 5", which is called before "func called, i = 6", and "func called, i = 6" is called before "func called, i = 7", and so on.
"А вот хуй тебе!", - сказал четырёхъядерный процессор, и выполнил коллбеки внутри strand'ов в случайном порядке.
bormand 25.05.2014 09:28 # +2
Может быть на старом boost'е этот код когда-то и работал... Но в мане явно написано:
Note that in the following case: the completion of the first async operation will perform s.dispatch(a), and the second will perform s.dispatch(b), but the order in which those are performed is unspecified. That is, you cannot state whether one happens-before the other. Therefore none of the above conditions are met and no ordering guarantee is made.
Вот и верь после этого книжкам ;(
defecate-plusplus 25.05.2014 11:42 # +4
написанный автором либы - Христофором Хохловым
кто такой John Torjo, любящий покер и быстрые машины (уже подозрительно), чтобы читать его книжку
bormand 25.05.2014 12:23 # +3
Если читать книги успешных людей, то и сам придешь к успеху.
А по официальному ману я не въехал в strand'ы (видимо я совсем тупой). Все встало на свои места только когда я попробовал запустить этот кривожопый пример из книжки, а затем пофиксил его.
3.14159265 25.05.2014 17:27 # +7
Hello everyone,
My name is John Torjo, and I'm a C++aholic. Yesterday, I did 1K+ lines of code, and there were no bugs... And of course, I used templates...
Есть такое эмпирическое наблюдение, что программист в день может родить всего 50-100 строк качественного кода.
laMer007 25.05.2014 18:34 # 0
Запускаю скрипт раз в день. Получаю 1к строк качественного кода.
Не умею в пхп. Мужики, только не бейте, лучше обоссыте.
Да и вам лучше не палиться, если в пхп умеете. Так что всем лучше будет.
bormand 25.05.2014 18:45 # +3
laMer007 25.05.2014 19:02 # 0
Ого, даже разорванный цикл работает? Круто.
> using namespace std
В этом нет ничего плохого после всех инклудов в сипипишнике.
bormand 25.05.2014 19:42 # +2
Даже в сипипишнике есть проблемы: например сборка завалится, когда в std добавят что-нибудь одноименное с чем-то из твоего кода или остальных заюзанных неймспейсов. Яркий пример - using namespace boost + using namespace std + shared_ptr - так на stackoverflow чел показывал удобство using namespace. А через пару лет его коммент стал отличным примером, почему так делать не стоит :)
Но да, это легко фиксится, и вообще мелочь, по сравнению с using namespace в ашках, да еще и где-нибудь в глобальном неймспейсе.
bormand 25.05.2014 19:49 # +2
laMer007 25.05.2014 19:58 # +3
Так все равно макрос вызовется, да ещё и не скомпилируется.
Только так:
(::std::min)(a,b);
bormand 25.05.2014 20:01 # +1
И это хорошо, хоть проблему замечу ;)
laMer007 25.05.2014 20:19 # 0
>(::std::min)(a,b);
bormand 25.05.2014 20:26 # +3
laMer007 25.05.2014 20:32 # +1
laMer007 25.05.2014 20:35 # +2
http://ideone.com/Fj0aHQ
1024-- 25.05.2014 20:41 # +2
laMer007 25.05.2014 20:44 # 0
bormand 25.05.2014 21:03 # 0
bormand 25.05.2014 19:56 # +1
<?php и ?> это не ограничители. Они просто переключают режим парсера между raw и php, поэтому можно писать непарные <?php ... </script>, <% ... ?> или вообще не писать ?> в конце файла (это даже считается хорошим тоном в php-only модулях, т.к. не высирает лишний энтер). И, емнип, все, что спарсено в raw режиме, в байткоде превращается в банальное echo, т.е. наши коды равносильны.
guest8 03.09.2018 23:01 # −999
bormand 25.05.2014 18:50 # +3
> using namespace std
Ну-ну :)
> Да и вам лучше не палиться, если в пхп умеете.
Что ж ты сразу то не сказал. Я уже успел написать код, а потом это прочитал.
defecate-plusplus 25.05.2014 19:25 # −1
разве что если он программирует на J
а так - это разумная оценка в час
absolut 25.05.2014 21:04 # +2
defecate-plusplus 25.05.2014 21:06 # +2
но ты ведь и не набираешь строку кода целую минуту?
bormand 25.05.2014 21:15 # +5
Открыл редактор
Копался в системе контроля версий, вспоминая на чем остановился
Написал std::
Пришлось отвлечься на совещание
Написал cout
Пару минут чесал репу, вспоминая, как вывести число в хексе
Загуглил на stackoverflow решение, по дороге попалась вкладка с хабром
Полчаса читал хабр
Написал << std::setw(2)
Поспорил с коллегой
Написал << std::setfill('0')
Отвлекся на телефонный звонок
Написал << std::hex
А вот и время обеда
На сытый желудок не работается, почитал хабр
Дописал << std::endl
Заметил, что кончился чай, сходил за кипятком
Поставил точку с запятой
Пока код компилируется, решил заглянуть на хабр
А вот и рабочий день подошел к концу
defecate-plusplus 25.05.2014 21:18 # −5
и долго эта фигня со средой будет продолжаться??
на самом деле, если программист не может за рабочий месяц написать мелкий проект на 20к строк (что как раз около 1к строк в сутки, и в т.ч. проектирование и отладка), то он дармоедствует
absolut 25.05.2014 21:28 # +4
Имхо, считать по строкам, это какая-то индусятина.
laMer007 25.05.2014 21:38 # 0
Надо по числу полных выражений; /green
матерных
defecate-plusplus 25.05.2014 21:41 # 0
absolut 25.05.2014 21:59 # +1
defecate-plusplus 25.05.2014 22:09 # 0
если ты не знаешь, как её решать, зачем берёшь этот контракт?
если ты знаешь, как решать задачу, то несложно разбить её на этапы и оценить, сколько надо будет потратить времени на изложение решения конкретного этапа в виде кода
изложение решения - и есть объем кода, который необходимо написать
если программист способен, имея в голове решение, излагать со скоростью 50 строк в рабочий день, то либо на это есть причины - его язык настолько ёмкий, что на с++ это аналогично 1к строк, либо третья черепаха просто пиздит
Vasiliy 27.05.2014 15:54 # +2
если ты не знаешь, как её решать, зачем берёшь этот контракт?
Есть конкуренты у конкурентов запилина какая то фича, пишут такск дословно прикрутить тоже самое. И тут пофигу знаешь как решать не знаешь чешешь репу гуглишь и пилишь.
laMer007 25.05.2014 21:55 # 0
20000/(24*31) = 27 строк всего в час /green
guest 26.05.2014 13:10 # 0
Как в прыщелисе добавить панель ббкодов в окно ввода?
TarasB 25.05.2014 22:26 # +6
минуснул
у меня столько получалось только когда я бездумно портировал с копипастой весь день
defecate-plusplus 25.05.2014 22:33 # +2
очевидно, ты решал новые для себя задачи - т.е. рожал решение
преклоняемся перед твоим опытом
кстати, Тарас, а что ты программируешь на работе?
3.14159265 25.05.2014 23:26 # +3
>минуснул
То есть по сути один человек за месяц 20K, то есть тим из 5 человек смогут >миллиона строк сделать за год
20K*12*5=240K*5=1.2M
http://dailyinfographic.com/wp-content/uploads/2013/10/1276_lines_of_code2-640x1833.png
То есть (если вести речь о качественном коде) при таких темпах можно впятером за год наебашить CryEngine 2, или Linux Kernel 2.2.
Которые должны при этом охуительно работать.
bormand 25.05.2014 23:33 # 0
3.14159265 26.05.2014 00:11 # +3
Вот сам гит:
$ git ls-files *.c | xargs cat | wc -l
102055
Дефейкт сможет за полгода накодить.
defecate-plusplus 26.05.2014 00:28 # 0
а сколько времени заняла реализация первой версии? учитывая, что это был новый проект? (я серьезно не знаю, но думаю, около полугода, не больше)
не знаю, чем ты занят на работе, но лично я, тратя на sql, pl/sql, наверное, 10% своего рабочего времени, пишу ну точно около 5к строк в месяц
причем это sql - более емкий язык, чем кресты
3.14159265 26.05.2014 00:32 # +2
Всё остальное документация, локализация и модули для взаимодействия с внешним миром. Типа этого:
# git-p4.py -- A tool for bidirectional operation between a Perforce depot and git.
Сам же Гит написан на чистом си.
$ git ls-files *.h | xargs cat | wc -l
8896
3.14159265 26.05.2014 01:11 # +3
>я серьезно не знаю, но думаю, около полугода, не больше)
http://www.ohloh.net/p/git
Ну и за первые полгода командой в 20-30 контрибьюторов они написали.... барабанная дробь.... сколько же они написали до выхода 1.0 в декабре 2005? А всего 35К строк кода. За полгода-то. Целой командой. Из которых половина shell,perl-скрипты
Вот Линус, вот лентяй.
laMer007 26.05.2014 01:19 # 0
Ну распределенные команды работающие за бесплатно в свободное от уроков время не считаем.
3.14159265 26.05.2014 01:30 # +2
Ну там бессменный мейтейнер Junio Hamano, и он занимается только гитом.
http://www.ohloh.net/accounts/gitster
Допустим он сам, в одиночку git писал. И тогда получается всего 3К строк в месяц на кодера, за 9 лет непрерывного труда.
Или взять первые 8 месяцев - с апреля по декабрь. 36К/8=4.5К коммитов/мес.
defecate-plusplus 26.05.2014 07:30 # 0
500 строк js + документация
написано бормандом в свободное время за 2 дня - причем, насколько я помню, вы фичреквестами уже в процессе дополняли
притом, что js не его родной язык, и, скорее всего, вообще был его первым опытом написания юзерскрипта
что ты мне тут втираешь? а то я не знаю, сколько может написать программист.
если тебе платят зарплату за 50 строк качественного кода в сутки, когда проект в активной фазе - их можно мизинцем ноги набирать, поплёвывая в потолок - то ты просто хорошо устроился
roman-kashitsyn 26.05.2014 10:14 # +6
>>много>> Есть такое эмпирическое наблюдение, что программист в день может родить всего 50-100 строк качественного кода.
Дык очевидно, что это усреднённое значение. Один/два дня ещё можно быть в потоке и выдавливать много кода, если задача ясна. Но ведь потом запросто можно неделю рефакторить, чинить свои и чужие баги и т.п.
Мне вообще не особо нравится добавлять новый код (хоть это иногда и весело), мне больше нравится реструктурировать и сокращать старый для достижения аналогичного функционала.
Опять же, много времени занимают исследования. Иногда нужно несколько дней ковырять маны, чтобы грамотно написать 10 строк, решающих задачу.
guest6 09.09.2023 00:57 # 0
this.
Причем иногда неделя чтения манов и написание 10 строк заменяет пять недель написания по 1000 строк каждый день
TarasB 26.05.2014 10:59 # 0
а, ну да
ясен хер, что пока проект новый, то скорость выше, но это длится недолго
guest 26.05.2014 13:13 # 0
bormand 26.05.2014 15:15 # +1
Ололо, документация. Звучит круто, а на деле сраненькое руководство юзера и комменты.
Abbath 25.05.2014 23:03 # +1
absolut 26.05.2014 06:32 # 0
laMer007 25.05.2014 21:36 # +1
> а так - это разумная оценка в час
> 1к строк в сутки
У вас программисты 10-20 часов в сутки работают? Этак же никакой личной жизни не будет.
defecate-plusplus 25.05.2014 21:47 # 0
другое дело - должен каждый месяц
нет, работают по 8-9
на самом деле со сменой работы в прошлом году для меня открылись совсем другие пределы
на старой работе мы полгода делали столько, сколько на новой делаем за месяц-два
laMer007 25.05.2014 21:53 # +1
> другое дело - должен
А знаю такие работы. Премии урезают всему предприятию по самое не могу, хотя вроде обещали гору и маленькую тележку
defecate-plusplus 25.05.2014 21:58 # 0
нестандартная - в индивидуальном порядке
на выходных поработать - экстраординарно, за это щедрая доплата (за год управления отделом - единичный случай)
наверное, в банках платят бонусы лучше
absolut 25.05.2014 22:01 # +2
и это всего лишь от увеличения кол-ва ядер.
Xom94ok 25.05.2014 21:54 # 0
Я, по приблизительным расчётам, могу нагадить 1k строк за три часа. Ну, это при условии чёткой постановки задания, а не как обычно "ну, бля, сделай чё-нибудь"
defecate-plusplus 25.05.2014 22:02 # +2
тут никто не поверит
Xom94ok 25.05.2014 22:18 # +2
> тут никто не поверит
[шёпотом]я еще и документирую для доксиджена. только тсс, никому![/шёпотом]
laMer007 25.05.2014 22:24 # 0
Создал опрос, посмотрим.
bormand 26.05.2014 12:41 # +1
eth0 27.05.2014 19:46 # +1
3.14159265 25.05.2014 22:35 # +3
>а так - это разумная оценка в час
Это когда уже понятно что и как писать. Перед тем как это написать надо понять что от тебя хотят, почитать не сделал ли кто-то это за тебя, подумать что пишешь, как это оптимальнее сделать, написать, отладить, покрыть тестами.
А заявления в стиле: "ололо я вчера написал овер 1К и там нету ни единого разрыва бага!!!" меня крайне настораживают. Откуда он знает что в коде который он написал вчера нет багов? Ведь они могут всплыть завтра.
Заметил если пишешь за день слишком много кода, назавтра понимаешь что половина или большая его часть ненужное бойлерплейтное фуфло, велосипед, говнокод, а задачу можно решить гораздо проще.
В общем 1К кода в день конечно можно родить, но вот только потом всё-равно его придется допилить/переписать.
defecate-plusplus 25.05.2014 22:42 # 0
ну т.е. решение задачи, с которой сталкиваешься впервые
мне кажется, что в зависимости от разнообразия задач программиста за 1-3 года работы в его специализации становится всё сложнее удивить
> не решал до тебя
кстати, это задача для тим лида, обратить внимание, что велосипедить тут ни к чему, либо, наоборот, рассказать, почему надо велосипедить
кстати, от известного жавоёба, где неизбежного бойлерплейта нагенерить хоть на 10к в день, непристало слышать жалобы, что 1к непосильный труд
3.14159265 25.05.2014 22:56 # +4
Для быдлоынтыпрайза правило 50-100 строк конечно не работает. Там можно срать over9K - перекладывать данные туда-сюда с базы на клиента, с клиента в базу. Ебошить по накатанной. Это не есть интелектуальный труд.
>от известного жавоёба, где неизбежного бойлерплейта нагенерить хоть на 10к в день, непристало слышать жалобы, что 1к непосильный труд
Всяких геттеров, сеттеров, фабрик можно насрать хуёву тучу. Но они не будут качественным кодом.
Я бы не сказал что бойлерплейт неизбежнен. Наоборот грамотной композицией и проектированием его можно и нужно побеждать.
Вот взять тот же ынтырпрайз. Можно раз написать 100 строк кода, зато потом при решении шаблонных задач писать придется значительно меньше - допустим 3-5 строк.
Вот качество тех 100 строк оно выше, ибо code reuse. И написать такое сложнее - надо думать. Качество и польза от одноразового кода, который невозможно использовать повторно стремится к нулю.
guest 26.05.2014 13:08 # 0
wvxvw 26.05.2014 09:58 # 0
Ну и еще немного вброшу. Тут че-то все как-то среднее интересно считают... Почему-то среднее арифметическое берется как эталон, хотя в таком случае скорее нужно было использовать медиану, или моуд (хз как это по-русски, самый популярный элемент, мб?). Считать среднее арифметическое можно только если доказать, что квадратная стандартная ошибка относительно ожидания - не большая (т.е. хотя бы на порядок меньше), что исследуемый феномен ергодичный (т.е. что проследив временные изменения одного члена популяции можно их экстраполировать на всю популяцию и наоборот), что распределение ведет себя каким-нибудь "хорошим" образом, так, что мы можем с большой долей уверенности что-то там предсказывать.
Я чет сильно сомневаюсь в том, что хотя бы одно из приведенных выше условий выполняется. Кроме того, добавлю, что судя по дельтам, количество строк в день может быть и отрицательным числом. Вобщем, даже если удасться найти среднее арифметическое числа строк в день, то этот показатель будет абсолютно бессмысленным.
guest 27.05.2014 14:35 # +4
мода.
Desktop 02.09.2018 12:22 # 0
Стертор, балбес, учись, как надо троллить
defecate-plusplus 03.09.2018 10:05 # 0
кстати, от нехуй делать зашел посмотреть сколько LOC наговнякали 1 беко за ~2 месяца, 1 фронтоёб за ~3 месяца в новом свежем проекте и в нём же я sql примерно за 3 недели:
Т.е. условно 300+ отлаженных строк в средний рабочий день человек может родить, если не отвлекаться на говнокодики, что естесно, и означает, что бывают дни где не только 1к, но и по 2к, а бывают, где минус 100.
И в этом проекте, замечу, было дохера ресёрча - вовлекли кучу новых необъезженных технологий, а с беком ещё и конструктивные срачи по полдня вместо кодинга.
Desktop 03.09.2018 10:17 # 0
- могу себе представить, сколько там автонагенерено
defecate-plusplus 03.09.2018 11:36 # 0
четверть указанной статистики нагенерено на фронте, ок
Desktop 03.09.2018 11:55 # 0
Ты вот добавляешь исходник в IDE типа вижуалки или икскода, там обычно строк 20-30 уже есть каких-то оверрайднутых методов для класса, посчитай, сколько такого нагенерено на 301 файле в вашем проекте?
Вижуалка ещё позволяет (да и другие IDE) экономить время благодаря сниппетам. Это больше вопрос того, кто как владеет инструментом, но всякий инструмент это поддерживает по-разному и с разной степенью удобства.
Ещё бывает банальная копипаста и stackoverflow driver development, отсутствие code reuse (у вас фронт и бэк модели каждый держит свою копию или вы всё же их чем-то генерите?)
Ну и конечно с apache thrift, protobuf и т.д. loc можно раздуть до космических размеров, вопрос в том, сколько из этого написано руками и есть ли смысл считать это метрикой
vistefan 03.09.2018 12:06 # 0
Что-то не уловил, какая разница. Если все if () { в полезном не дублирующем коде вставила IDE, их не надо считать? Может быть за ними программист не должен следить? Они как-то облегчают задачу?
Мы же тут не скорость печатания обсуждаем. Ты бы тогда ещё буквы начал считать, а то ты ведь не всё набираешь, кое-что автодополнением вставляется. А программист, сука, сидит себе прохлаждается.
Desktop 03.09.2018 12:15 # 0
roman-kashitsyn 03.09.2018 12:41 # +1
guest6 09.09.2023 00:55 # 0
Вообще, размер кода очень сильно зависит от вербозности языка и от инструментов для его генерации.
На условной Java 6 можно высирать тонны кода который ничего не делает, но размуеется не вручную, а жмакая кнопочки в Intellij IDEA.
Студия тоже умеет всякие сниппеты для WPF например, и там достаточно много букв.
ropuJIJIa 09.09.2023 00:59 # 0
guest6 09.09.2023 01:05 # 0
Снипет `propa` раскрылся в
и такой хуйни можно насниппить тонну. У меня правда знания 2012 года, мб уже всё и не так.
С Java еще хуже. Ты написал филды у класса, и IDE сгенерила тебе аксесоры/мутаторы, equals, hashCode, toString и пр.
А потом ты сделал рефакторниг "замена наследования делегированим" и получил ручное делегирование каждого метода.
В буквальном смысле сотни строк кода, которые ты не писал, и которые просто "церемония".
Ну и тяжелый ООПизм голмозга заставляет плодить сущности на пустом месте
guest8 03.09.2018 11:18 # −999
guest8 03.09.2018 11:45 # −999
vistefan 03.09.2018 11:38 # 0
roman-kashitsyn 03.09.2018 11:40 # 0
Судя по всему, это размер конечного результата, а не аггрегация по коммитам.
roman-kashitsyn 03.09.2018 11:45 # 0
Можно, кстати, ещё разбивочку по test/src ?
defecate-plusplus 03.09.2018 11:58 # 0
и в вашу полемику TDD вступать не хочу в т.ч. именно поэтому
потому что сначала ставить разжёванную задачу, по которой сначала написать тест, а потом уже её исполнять - это часто роскошь, ни в какие дедлайны не вписаться с этим (к сожалению)
roman-kashitsyn 03.09.2018 12:07 # 0
Я так и думал, спасибо.
В общем-то, много кода ≠ хорошо. Особенно, если на этот код нет ни одного теста.
Ну и подозреваю, что 50% процентов этого кода состоит из фигурных скобок¹ и override ToString/HashCode/Equals/Compare etc. которые в нормальных языках одной строчкой пишутся.
defecate-plusplus 03.09.2018 12:39 # 0
ну начинается
про J я ещё 4 года назад написал
давайте тогда сосредоточимся, что непосредственно выдавилось из меня
в 88 create table, 27 create function нет много возможности набойлерплейтить, нафигурноскобить, и всё написано руками (слава автодополнению в интеллий, конечно)
и таки да, просто так обмазаться говном и въебать схему бд без проектирования не очень возможно (это когда надо, как тут говорилось выше, сначала неделю думать, а потом час писать)
хз чем посчитать более объективный показатель
cloc вроде умеет стриппить коменты, но делает это в виде файлов, я не хочу засирать временными файлами дерево в проекте
да и коменты тоже надо написать, время потратить
> много кода ≠ хорошо
бывает, что не написать через мало кода
в макете под сотню вьюх, большая часть заимплементирована, на беке - с полсотни POST уже (я уж не стану хвалиться кучей гетов, а то обвинят, что это круды по шаблону нахуярили)
CHayT 03.09.2018 13:26 # 0
ASMOZDOT 03.09.2018 14:01 # 0
день первый: нахуярил пару сотен строк – "заебись, хватит на сегодня", (если это лаба, то это был последний день);
день второй: вчера до поздна занимался всякой хуйнёй – не выспался, написал пару десятков строк и пошёл спать, проснулся вечером – написал несколько строк, и опять стал хуйнёй страдать, остальные дни та же хуйня;
всё остальное дохуяривается в последние 1-2 дня перед сдачей, иногда даже после того как должен был сдать.
guest8 03.09.2018 14:06 # −999
Desktop 03.09.2018 14:22 # 0
ASMOZDOT 03.09.2018 14:37 # 0
Stefan 02.09.2018 16:19 # −1
wrong.
Написать тесты, написать под них код, параллельно отлаживая.
Писать тесты на готовый код, это как напяливать гандон, после того, как уже кончил. Чей это афоризм?
guest8 02.09.2018 17:26 # −999
g0_1494078705717 02.09.2018 17:36 # −2
Stefan 02.09.2018 18:53 # 0
Если пи говорил про процесс кодинга, значит 99.99% вероятности, имел ввиду юнит-тесты. Иначе это задача тестировщика, а не программиста. Юнит-тесты же в свою очередь имеют исчезающе мало смысла, будучи натянутыми на существующий код. (Такие тесты подойдут разве что для того, чтобы убедиться, что ты грубо не сломал существующий код.) Смысл тест-дривен девелопмента в том, чтобы предварительно писать тесты (это может делать другой человек, не тот, кто потом под них реализует функционал), а потом и IDE видеть красные кружочки. Когда они преврятятся в зелёные, задача выполнена.
> Ты дибил, или прикалываешься?
Пошёл нахуй.
guest8 02.09.2018 20:11 # −999
roman-kashitsyn 02.09.2018 21:18 # 0
А откуда ты знаешь, что они завалятся, если ты не проверял? Серьёзно, очень часто было, что я писал фикс, потом писал тест на этот фикс, который проходил.
После этого меня терзали сомнения, я откатывал фикс и прогонял тест снова.
ТЕСТ ВСЁ ЕЩЁ ПРОХОДИЛ.
Если не проверять, что тесты ломаются на сломанном коде, можно получить кучу тестов, которые ничего не проверяют.
Надо всегда проверять причинно-следственную связь:
Сломанный код → Test NOK
Рабочий код → Test OK
guest8 02.09.2018 21:42 # −999
Stefan 02.09.2018 22:27 # 0
Нормально ставить задачу, лол.
Если ты знаешь, что именно у тебя должно получиться, то всегда можешь заранее написать тесты. Если сложно представить себе решение во всех тонкостях, или задача слишком большая, можно исповедовать принцип: каждый раз, когда собрался написать класс, метод или функцию, этому должно предшествовать написание соответствующего сеста.
Если у тебя в процессе разработки возникают ситуации, когда ты не знаешь, каким должен быть функционалл, или можешь в процессе решать, каким именно он должен быть, значит это a) очень хуёво поставленная задача (из такой фирмы лучше свалить) или б) код для себя чисто по фану, которому позволительно быть каким угодно. Но это уж точно никакой не тдд.
bormand 02.09.2018 22:43 # 0
З.Ы. По-моему у тебя уже карго-культ ТДД начинается.
Stefan 02.09.2018 22:47 # 0
Нет, я имею ввиду, если его использовать — то использовать так. Раз Пи сказал «написать тесты» — значит он об этом? Или так, по приколу написать, чтобы были?
Добавим к этому ещё договорённость о том, что именно покрывать а что не покрывать тестами (спросить у тимлида), и получится, надеюсь, адекватный взгляд. Не?
bormand 02.09.2018 22:55 # 0
Stefan 02.09.2018 22:32 # 0
Такое может происходить, только когда никто нахуй не знает, что в итоге должно получиться. Ты что, сам себе задачу ставишь? Ну тогда тебе никакой тдд не нужен. В ситуации, когда аналитики собрали техзадание с заказчика, запретили ему просить играть со шрифтами посреди процесса, передали тимлиду и тот начал спринт, такой хуйни быть не должно.
Энивей, даже если так, то когда пилишь новый функционал, не
поменял функционал → завалились тесты → изменил тесты под новый функционал
а наоборот
поменял текущие рабочие тесты на новые, в соответствии с требуемым новым поведением функционала → тесты завалились на текущем функционале → допилил покуда не тесты не ок
ОБратный подход — это не ТДД. Это просто код с тестами. Такой девелопмент не ДРАЙВЯТ тесты, а наоборот, в каком-то подчиненном к нему положении находятся.
> Я щаетаю такую схему разработки нормальной
Ну ок.
> Давай, удачи там.
Ого, ничего себе.
roman-kashitsyn 02.09.2018 17:36 # −1
Писать тесты, которые работают на реализации – не научно. Надо сначала проверить, что тесты без реализации/ с багой не подходят, а уже потом проверять, что они работают с исправленным кодом.
g0_1494078705717 02.09.2018 17:55 # −2
Stefan 02.09.2018 18:55 # +1
Под этими аккаунтами вроде сёма сидит, да?
Спалился человек, никогда не поддерживавший чужой код, понятия не имеющий о CI и CD, стоимость работы которого — кастрюля супа за 5 евро в неделю. Благодарим за ценнейшие замечания.
> что показать нихуя не понимающему в коде начальству
Да, именно для этого, пошёл нахуй.
guest8 02.09.2018 19:51 # −999
Stefan 02.09.2018 22:44 # 0
Дохуища там комментариев.
Да и получить информацию о нём можно из множества других источников (гайды по ядру, фак для кернел хакеров, ньюсгруп, ирка). А тест дривен-девелопмента там не было изначально, там другой подход. Как видишь, справляются.
Или ты не про linux, а про окружение GNU/Linux?
Ну там с каждой софтиной обстоит по-разному. Найдётся прилично софта без тестов и комментариев в коде, но исходник какого-нибудь cat и так прочитать не трудно. Найдётся софт, покрытого тестами и отлично документированного.
А с каким эталоном мы сравниваем? С майкрософтовским кодом, из которого недавно здесь выдирали комментарии со словом fuck? Или может с божественно-прекрасно оттестированным и закомментированным кодом MacOS, который никто не видел?
bormand 02.09.2018 22:52 # 0
Stefan 02.09.2018 22:55 # 0
А ты почему с ним дело имел, откуда впечатление?
bormand 02.09.2018 23:00 # 0
Прямо как раньше пересказывали всякие сказки и легенды...
Не помню, давно это было. Может быть сейчас они и написали хоть один коммент помимо лицензии...
Stefan 02.09.2018 23:02 # 0
bormand 02.09.2018 23:05 # 0
guest8 03.09.2018 18:09 # −999
guest8 04.09.2018 15:04 # −999
guest8 04.09.2018 15:08 # −999
guest8 04.09.2018 15:14 # −999
guest8 04.09.2018 02:02 # −999
guest8 04.09.2018 02:58 # −999
bormand 04.09.2018 07:14 # 0
guest8 04.09.2018 11:42 # −999
guest8 04.09.2018 12:15 # −999
vistefan 04.09.2018 15:56 # 0
И была ведь у кого-то задача такая в таск-трекере… ))
guest8 04.09.2018 17:03 # −999
guest8 04.09.2018 17:06 # −999
guest8 04.09.2018 12:21 # −999
roman-kashitsyn 02.09.2018 19:53 # 0
Это же явно почерк любителя несвежего "PHP", условно назовём его Конардо.
guest8 02.09.2018 20:25 # −999
guest8 03.09.2018 11:19 # −999
3oJIoTou_xyu 03.09.2018 12:06 # 0
guest8 03.09.2018 13:01 # −999
guest8 03.09.2018 18:14 # −999
guest8 03.09.2018 20:12 # −999
guest8 03.09.2018 20:13 # −999
guest8 03.09.2018 20:15 # −999
guest8 03.09.2018 20:16 # −999
guest8 03.09.2018 20:18 # −999
guest8 03.09.2018 20:40 # −999
guest8 03.09.2018 22:24 # −999
guest8 03.09.2018 22:43 # −999
Elvenfighter 03.09.2018 23:56 # −1
Konardyan 04.09.2018 00:31 # −102
guest8 03.09.2018 20:16 # −999
guest8 03.09.2018 20:18 # −999
CHayT 02.09.2018 22:40 # 0
> Всё ещё использовать TDD
> Не использовать MDD
Зачем вообще тесты? Надо пилить модель, все* возможные кобенации которой будут проверены модел-чекером за неделю-другую, пока ты сам пишешь статью на конференцию.
*Однако скоп всё равно в какой-то мере придётся придумывать
roman-kashitsyn 03.09.2018 11:24 # 0
CHayT 03.09.2018 12:04 # 0
Desktop 09.09.2023 01:07 # 0
guest6 09.09.2023 01:17 # 0
Люди там много пиздят про тестирование, а потом брешь код, а там три теста, и те пол года как на CI красные.
Lure Of Chaos 25.05.2014 21:25 # +8
bzz 26.05.2014 23:07 # +2
guest6 09.09.2023 01:25 # 0
да, мой однострочный шаблон тоже был раскрыт компилятором в тыщу разных функций
А что?
Desktop 09.09.2023 00:46 # 0