- 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)));-
C++ / Говнокод #16055
+17
Пример из книги 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 Мая 2014
Follow us!
Может быть на старом 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.
Вот и верь после этого книжкам ;(
написанный автором либы - Христофором Хохловым
кто такой John Torjo, любящий покер и быстрые машины (уже подозрительно), чтобы читать его книжку
Если читать книги успешных людей, то и сам придешь к успеху.
А по официальному ману я не въехал в strand'ы (видимо я совсем тупой). Все встало на свои места только когда я попробовал запустить этот кривожопый пример из книжки, а затем пофиксил его.
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 строк качественного кода.
Запускаю скрипт раз в день. Получаю 1к строк качественного кода.
Не умею в пхп. Мужики, только не бейте, лучше обоссыте.
Да и вам лучше не палиться, если в пхп умеете. Так что всем лучше будет.
Ого, даже разорванный цикл работает? Круто.
> using namespace std
В этом нет ничего плохого после всех инклудов в сипипишнике.
Даже в сипипишнике есть проблемы: например сборка завалится, когда в std добавят что-нибудь одноименное с чем-то из твоего кода или остальных заюзанных неймспейсов. Яркий пример - using namespace boost + using namespace std + shared_ptr - так на stackoverflow чел показывал удобство using namespace. А через пару лет его коммент стал отличным примером, почему так делать не стоит :)
Но да, это легко фиксится, и вообще мелочь, по сравнению с using namespace в ашках, да еще и где-нибудь в глобальном неймспейсе.
Так все равно макрос вызовется, да ещё и не скомпилируется.
Только так:
(::std::min)(a,b);
И это хорошо, хоть проблему замечу ;)
>(::std::min)(a,b);
http://ideone.com/Fj0aHQ
<?php и ?> это не ограничители. Они просто переключают режим парсера между raw и php, поэтому можно писать непарные <?php ... </script>, <% ... ?> или вообще не писать ?> в конце файла (это даже считается хорошим тоном в php-only модулях, т.к. не высирает лишний энтер). И, емнип, все, что спарсено в raw режиме, в байткоде превращается в банальное echo, т.е. наши коды равносильны.
> using namespace std
Ну-ну :)
> Да и вам лучше не палиться, если в пхп умеете.
Что ж ты сразу то не сказал. Я уже успел написать код, а потом это прочитал.
разве что если он программирует на J
а так - это разумная оценка в час
но ты ведь и не набираешь строку кода целую минуту?
Открыл редактор
Копался в системе контроля версий, вспоминая на чем остановился
Написал std::
Пришлось отвлечься на совещание
Написал cout
Пару минут чесал репу, вспоминая, как вывести число в хексе
Загуглил на stackoverflow решение, по дороге попалась вкладка с хабром
Полчаса читал хабр
Написал << std::setw(2)
Поспорил с коллегой
Написал << std::setfill('0')
Отвлекся на телефонный звонок
Написал << std::hex
А вот и время обеда
На сытый желудок не работается, почитал хабр
Дописал << std::endl
Заметил, что кончился чай, сходил за кипятком
Поставил точку с запятой
Пока код компилируется, решил заглянуть на хабр
А вот и рабочий день подошел к концу
и долго эта фигня со средой будет продолжаться??
на самом деле, если программист не может за рабочий месяц написать мелкий проект на 20к строк (что как раз около 1к строк в сутки, и в т.ч. проектирование и отладка), то он дармоедствует
Имхо, считать по строкам, это какая-то индусятина.
Надо по числу полных выражений; /green
матерных
если ты не знаешь, как её решать, зачем берёшь этот контракт?
если ты знаешь, как решать задачу, то несложно разбить её на этапы и оценить, сколько надо будет потратить времени на изложение решения конкретного этапа в виде кода
изложение решения - и есть объем кода, который необходимо написать
если программист способен, имея в голове решение, излагать со скоростью 50 строк в рабочий день, то либо на это есть причины - его язык настолько ёмкий, что на с++ это аналогично 1к строк, либо третья черепаха просто пиздит
если ты не знаешь, как её решать, зачем берёшь этот контракт?
Есть конкуренты у конкурентов запилина какая то фича, пишут такск дословно прикрутить тоже самое. И тут пофигу знаешь как решать не знаешь чешешь репу гуглишь и пилишь.
20000/(24*31) = 27 строк всего в час /green
Как в прыщелисе добавить панель ббкодов в окно ввода?
минуснул
у меня столько получалось только когда я бездумно портировал с копипастой весь день
очевидно, ты решал новые для себя задачи - т.е. рожал решение
преклоняемся перед твоим опытом
кстати, Тарас, а что ты программируешь на работе?
>минуснул
То есть по сути один человек за месяц 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.
Которые должны при этом охуительно работать.
Вот сам гит:
$ git ls-files *.c | xargs cat | wc -l
102055
Дефейкт сможет за полгода накодить.
а сколько времени заняла реализация первой версии? учитывая, что это был новый проект? (я серьезно не знаю, но думаю, около полугода, не больше)
не знаю, чем ты занят на работе, но лично я, тратя на sql, pl/sql, наверное, 10% своего рабочего времени, пишу ну точно около 5к строк в месяц
причем это sql - более емкий язык, чем кресты
Всё остальное документация, локализация и модули для взаимодействия с внешним миром. Типа этого:
# git-p4.py -- A tool for bidirectional operation between a Perforce depot and git.
Сам же Гит написан на чистом си.
$ git ls-files *.h | xargs cat | wc -l
8896
>я серьезно не знаю, но думаю, около полугода, не больше)
http://www.ohloh.net/p/git
Ну и за первые полгода командой в 20-30 контрибьюторов они написали.... барабанная дробь.... сколько же они написали до выхода 1.0 в декабре 2005? А всего 35К строк кода. За полгода-то. Целой командой. Из которых половина shell,perl-скрипты
Вот Линус, вот лентяй.
Ну распределенные команды работающие за бесплатно в свободное от уроков время не считаем.
Ну там бессменный мейтейнер Junio Hamano, и он занимается только гитом.
http://www.ohloh.net/accounts/gitster
Допустим он сам, в одиночку git писал. И тогда получается всего 3К строк в месяц на кодера, за 9 лет непрерывного труда.
Или взять первые 8 месяцев - с апреля по декабрь. 36К/8=4.5К коммитов/мес.
500 строк js + документация
написано бормандом в свободное время за 2 дня - причем, насколько я помню, вы фичреквестами уже в процессе дополняли
притом, что js не его родной язык, и, скорее всего, вообще был его первым опытом написания юзерскрипта
что ты мне тут втираешь? а то я не знаю, сколько может написать программист.
если тебе платят зарплату за 50 строк качественного кода в сутки, когда проект в активной фазе - их можно мизинцем ноги набирать, поплёвывая в потолок - то ты просто хорошо устроился
>>много>> Есть такое эмпирическое наблюдение, что программист в день может родить всего 50-100 строк качественного кода.
Дык очевидно, что это усреднённое значение. Один/два дня ещё можно быть в потоке и выдавливать много кода, если задача ясна. Но ведь потом запросто можно неделю рефакторить, чинить свои и чужие баги и т.п.
Мне вообще не особо нравится добавлять новый код (хоть это иногда и весело), мне больше нравится реструктурировать и сокращать старый для достижения аналогичного функционала.
Опять же, много времени занимают исследования. Иногда нужно несколько дней ковырять маны, чтобы грамотно написать 10 строк, решающих задачу.
this.
Причем иногда неделя чтения манов и написание 10 строк заменяет пять недель написания по 1000 строк каждый день
а, ну да
ясен хер, что пока проект новый, то скорость выше, но это длится недолго
Ололо, документация. Звучит круто, а на деле сраненькое руководство юзера и комменты.
> а так - это разумная оценка в час
> 1к строк в сутки
У вас программисты 10-20 часов в сутки работают? Этак же никакой личной жизни не будет.
другое дело - должен каждый месяц
нет, работают по 8-9
на самом деле со сменой работы в прошлом году для меня открылись совсем другие пределы
на старой работе мы полгода делали столько, сколько на новой делаем за месяц-два
> другое дело - должен
А знаю такие работы. Премии урезают всему предприятию по самое не могу, хотя вроде обещали гору и маленькую тележку
нестандартная - в индивидуальном порядке
на выходных поработать - экстраординарно, за это щедрая доплата (за год управления отделом - единичный случай)
наверное, в банках платят бонусы лучше
и это всего лишь от увеличения кол-ва ядер.
Я, по приблизительным расчётам, могу нагадить 1k строк за три часа. Ну, это при условии чёткой постановки задания, а не как обычно "ну, бля, сделай чё-нибудь"
тут никто не поверит
> тут никто не поверит
[шёпотом]я еще и документирую для доксиджена. только тсс, никому![/шёпотом]
Создал опрос, посмотрим.
>а так - это разумная оценка в час
Это когда уже понятно что и как писать. Перед тем как это написать надо понять что от тебя хотят, почитать не сделал ли кто-то это за тебя, подумать что пишешь, как это оптимальнее сделать, написать, отладить, покрыть тестами.
А заявления в стиле: "ололо я вчера написал овер 1К и там нету ни единого разрыва бага!!!" меня крайне настораживают. Откуда он знает что в коде который он написал вчера нет багов? Ведь они могут всплыть завтра.
Заметил если пишешь за день слишком много кода, назавтра понимаешь что половина или большая его часть ненужное бойлерплейтное фуфло, велосипед, говнокод, а задачу можно решить гораздо проще.
В общем 1К кода в день конечно можно родить, но вот только потом всё-равно его придется допилить/переписать.
ну т.е. решение задачи, с которой сталкиваешься впервые
мне кажется, что в зависимости от разнообразия задач программиста за 1-3 года работы в его специализации становится всё сложнее удивить
> не решал до тебя
кстати, это задача для тим лида, обратить внимание, что велосипедить тут ни к чему, либо, наоборот, рассказать, почему надо велосипедить
кстати, от известного жавоёба, где неизбежного бойлерплейта нагенерить хоть на 10к в день, непристало слышать жалобы, что 1к непосильный труд
Для быдлоынтыпрайза правило 50-100 строк конечно не работает. Там можно срать over9K - перекладывать данные туда-сюда с базы на клиента, с клиента в базу. Ебошить по накатанной. Это не есть интелектуальный труд.
>от известного жавоёба, где неизбежного бойлерплейта нагенерить хоть на 10к в день, непристало слышать жалобы, что 1к непосильный труд
Всяких геттеров, сеттеров, фабрик можно насрать хуёву тучу. Но они не будут качественным кодом.
Я бы не сказал что бойлерплейт неизбежнен. Наоборот грамотной композицией и проектированием его можно и нужно побеждать.
Вот взять тот же ынтырпрайз. Можно раз написать 100 строк кода, зато потом при решении шаблонных задач писать придется значительно меньше - допустим 3-5 строк.
Вот качество тех 100 строк оно выше, ибо code reuse. И написать такое сложнее - надо думать. Качество и польза от одноразового кода, который невозможно использовать повторно стремится к нулю.
Ну и еще немного вброшу. Тут че-то все как-то среднее интересно считают... Почему-то среднее арифметическое берется как эталон, хотя в таком случае скорее нужно было использовать медиану, или моуд (хз как это по-русски, самый популярный элемент, мб?). Считать среднее арифметическое можно только если доказать, что квадратная стандартная ошибка относительно ожидания - не большая (т.е. хотя бы на порядок меньше), что исследуемый феномен ергодичный (т.е. что проследив временные изменения одного члена популяции можно их экстраполировать на всю популяцию и наоборот), что распределение ведет себя каким-нибудь "хорошим" образом, так, что мы можем с большой долей уверенности что-то там предсказывать.
Я чет сильно сомневаюсь в том, что хотя бы одно из приведенных выше условий выполняется. Кроме того, добавлю, что судя по дельтам, количество строк в день может быть и отрицательным числом. Вобщем, даже если удасться найти среднее арифметическое числа строк в день, то этот показатель будет абсолютно бессмысленным.
мода.
Стертор, балбес, учись, как надо троллить
кстати, от нехуй делать зашел посмотреть сколько LOC наговнякали 1 беко за ~2 месяца, 1 фронтоёб за ~3 месяца в новом свежем проекте и в нём же я sql примерно за 3 недели:
Т.е. условно 300+ отлаженных строк в средний рабочий день человек может родить, если не отвлекаться на говнокодики, что естесно, и означает, что бывают дни где не только 1к, но и по 2к, а бывают, где минус 100.
И в этом проекте, замечу, было дохера ресёрча - вовлекли кучу новых необъезженных технологий, а с беком ещё и конструктивные срачи по полдня вместо кодинга.
- могу себе представить, сколько там автонагенерено
четверть указанной статистики нагенерено на фронте, ок
Ты вот добавляешь исходник в IDE типа вижуалки или икскода, там обычно строк 20-30 уже есть каких-то оверрайднутых методов для класса, посчитай, сколько такого нагенерено на 301 файле в вашем проекте?
Вижуалка ещё позволяет (да и другие IDE) экономить время благодаря сниппетам. Это больше вопрос того, кто как владеет инструментом, но всякий инструмент это поддерживает по-разному и с разной степенью удобства.
Ещё бывает банальная копипаста и stackoverflow driver development, отсутствие code reuse (у вас фронт и бэк модели каждый держит свою копию или вы всё же их чем-то генерите?)
Ну и конечно с apache thrift, protobuf и т.д. loc можно раздуть до космических размеров, вопрос в том, сколько из этого написано руками и есть ли смысл считать это метрикой
Что-то не уловил, какая разница. Если все if () { в полезном не дублирующем коде вставила IDE, их не надо считать? Может быть за ними программист не должен следить? Они как-то облегчают задачу?
Мы же тут не скорость печатания обсуждаем. Ты бы тогда ещё буквы начал считать, а то ты ведь не всё набираешь, кое-что автодополнением вставляется. А программист, сука, сидит себе прохлаждается.
Вообще, размер кода очень сильно зависит от вербозности языка и от инструментов для его генерации.
На условной Java 6 можно высирать тонны кода который ничего не делает, но размуеется не вручную, а жмакая кнопочки в Intellij IDEA.
Студия тоже умеет всякие сниппеты для WPF например, и там достаточно много букв.
Снипет `propa` раскрылся в
и такой хуйни можно насниппить тонну. У меня правда знания 2012 года, мб уже всё и не так.
С Java еще хуже. Ты написал филды у класса, и IDE сгенерила тебе аксесоры/мутаторы, equals, hashCode, toString и пр.
А потом ты сделал рефакторниг "замена наследования делегированим" и получил ручное делегирование каждого метода.
В буквальном смысле сотни строк кода, которые ты не писал, и которые просто "церемония".
Ну и тяжелый ООПизм голмозга заставляет плодить сущности на пустом месте
Судя по всему, это размер конечного результата, а не аггрегация по коммитам.
Можно, кстати, ещё разбивочку по test/src ?
и в вашу полемику TDD вступать не хочу в т.ч. именно поэтому
потому что сначала ставить разжёванную задачу, по которой сначала написать тест, а потом уже её исполнять - это часто роскошь, ни в какие дедлайны не вписаться с этим (к сожалению)
Я так и думал, спасибо.
В общем-то, много кода ≠ хорошо. Особенно, если на этот код нет ни одного теста.
Ну и подозреваю, что 50% процентов этого кода состоит из фигурных скобок¹ и override ToString/HashCode/Equals/Compare etc. которые в нормальных языках одной строчкой пишутся.
ну начинается
про J я ещё 4 года назад написал
давайте тогда сосредоточимся, что непосредственно выдавилось из меня
в 88 create table, 27 create function нет много возможности набойлерплейтить, нафигурноскобить, и всё написано руками (слава автодополнению в интеллий, конечно)
и таки да, просто так обмазаться говном и въебать схему бд без проектирования не очень возможно (это когда надо, как тут говорилось выше, сначала неделю думать, а потом час писать)
хз чем посчитать более объективный показатель
cloc вроде умеет стриппить коменты, но делает это в виде файлов, я не хочу засирать временными файлами дерево в проекте
да и коменты тоже надо написать, время потратить
> много кода ≠ хорошо
бывает, что не написать через мало кода
в макете под сотню вьюх, большая часть заимплементирована, на беке - с полсотни POST уже (я уж не стану хвалиться кучей гетов, а то обвинят, что это круды по шаблону нахуярили)
день первый: нахуярил пару сотен строк – "заебись, хватит на сегодня", (если это лаба, то это был последний день);
день второй: вчера до поздна занимался всякой хуйнёй – не выспался, написал пару десятков строк и пошёл спать, проснулся вечером – написал несколько строк, и опять стал хуйнёй страдать, остальные дни та же хуйня;
всё остальное дохуяривается в последние 1-2 дня перед сдачей, иногда даже после того как должен был сдать.
wrong.
Написать тесты, написать под них код, параллельно отлаживая.
Писать тесты на готовый код, это как напяливать гандон, после того, как уже кончил. Чей это афоризм?
Если пи говорил про процесс кодинга, значит 99.99% вероятности, имел ввиду юнит-тесты. Иначе это задача тестировщика, а не программиста. Юнит-тесты же в свою очередь имеют исчезающе мало смысла, будучи натянутыми на существующий код. (Такие тесты подойдут разве что для того, чтобы убедиться, что ты грубо не сломал существующий код.) Смысл тест-дривен девелопмента в том, чтобы предварительно писать тесты (это может делать другой человек, не тот, кто потом под них реализует функционал), а потом и IDE видеть красные кружочки. Когда они преврятятся в зелёные, задача выполнена.
> Ты дибил, или прикалываешься?
Пошёл нахуй.
А откуда ты знаешь, что они завалятся, если ты не проверял? Серьёзно, очень часто было, что я писал фикс, потом писал тест на этот фикс, который проходил.
После этого меня терзали сомнения, я откатывал фикс и прогонял тест снова.
ТЕСТ ВСЁ ЕЩЁ ПРОХОДИЛ.
Если не проверять, что тесты ломаются на сломанном коде, можно получить кучу тестов, которые ничего не проверяют.
Надо всегда проверять причинно-следственную связь:
Сломанный код → Test NOK
Рабочий код → Test OK
Нормально ставить задачу, лол.
Если ты знаешь, что именно у тебя должно получиться, то всегда можешь заранее написать тесты. Если сложно представить себе решение во всех тонкостях, или задача слишком большая, можно исповедовать принцип: каждый раз, когда собрался написать класс, метод или функцию, этому должно предшествовать написание соответствующего сеста.
Если у тебя в процессе разработки возникают ситуации, когда ты не знаешь, каким должен быть функционалл, или можешь в процессе решать, каким именно он должен быть, значит это a) очень хуёво поставленная задача (из такой фирмы лучше свалить) или б) код для себя чисто по фану, которому позволительно быть каким угодно. Но это уж точно никакой не тдд.
З.Ы. По-моему у тебя уже карго-культ ТДД начинается.
Нет, я имею ввиду, если его использовать — то использовать так. Раз Пи сказал «написать тесты» — значит он об этом? Или так, по приколу написать, чтобы были?
Добавим к этому ещё договорённость о том, что именно покрывать а что не покрывать тестами (спросить у тимлида), и получится, надеюсь, адекватный взгляд. Не?
Такое может происходить, только когда никто нахуй не знает, что в итоге должно получиться. Ты что, сам себе задачу ставишь? Ну тогда тебе никакой тдд не нужен. В ситуации, когда аналитики собрали техзадание с заказчика, запретили ему просить играть со шрифтами посреди процесса, передали тимлиду и тот начал спринт, такой хуйни быть не должно.
Энивей, даже если так, то когда пилишь новый функционал, не
поменял функционал → завалились тесты → изменил тесты под новый функционал
а наоборот
поменял текущие рабочие тесты на новые, в соответствии с требуемым новым поведением функционала → тесты завалились на текущем функционале → допилил покуда не тесты не ок
ОБратный подход — это не ТДД. Это просто код с тестами. Такой девелопмент не ДРАЙВЯТ тесты, а наоборот, в каком-то подчиненном к нему положении находятся.
> Я щаетаю такую схему разработки нормальной
Ну ок.
> Давай, удачи там.
Ого, ничего себе.
Писать тесты, которые работают на реализации – не научно. Надо сначала проверить, что тесты без реализации/ с багой не подходят, а уже потом проверять, что они работают с исправленным кодом.
Под этими аккаунтами вроде сёма сидит, да?
Спалился человек, никогда не поддерживавший чужой код, понятия не имеющий о CI и CD, стоимость работы которого — кастрюля супа за 5 евро в неделю. Благодарим за ценнейшие замечания.
> что показать нихуя не понимающему в коде начальству
Да, именно для этого, пошёл нахуй.
Дохуища там комментариев.
Да и получить информацию о нём можно из множества других источников (гайды по ядру, фак для кернел хакеров, ньюсгруп, ирка). А тест дривен-девелопмента там не было изначально, там другой подход. Как видишь, справляются.
Или ты не про linux, а про окружение GNU/Linux?
Ну там с каждой софтиной обстоит по-разному. Найдётся прилично софта без тестов и комментариев в коде, но исходник какого-нибудь cat и так прочитать не трудно. Найдётся софт, покрытого тестами и отлично документированного.
А с каким эталоном мы сравниваем? С майкрософтовским кодом, из которого недавно здесь выдирали комментарии со словом fuck? Или может с божественно-прекрасно оттестированным и закомментированным кодом MacOS, который никто не видел?
А ты почему с ним дело имел, откуда впечатление?
Прямо как раньше пересказывали всякие сказки и легенды...
Не помню, давно это было. Может быть сейчас они и написали хоть один коммент помимо лицензии...
И была ведь у кого-то задача такая в таск-трекере… ))
Это же явно почерк любителя несвежего "PHP", условно назовём его Конардо.
> Всё ещё использовать TDD
> Не использовать MDD
Зачем вообще тесты? Надо пилить модель, все* возможные кобенации которой будут проверены модел-чекером за неделю-другую, пока ты сам пишешь статью на конференцию.
*Однако скоп всё равно в какой-то мере придётся придумывать
Люди там много пиздят про тестирование, а потом брешь код, а там три теста, и те пол года как на CI красные.
да, мой однострочный шаблон тоже был раскрыт компилятором в тыщу разных функций
А что?