Многие начинающие разработчики сталкиваются с необходимостью показать существующий опыт разработки ПО. Даже если вакансия называется «программист без опыта работы», то и без Капитана ясно, что предпочтение будет отдано претенденту, показавшему более-менее внятный код, более-менее подтверждающий наличие полезных в работе навыков.Что же делать? Показать решение типового задания с ранних курсов или дипломный проект? Возможно, этого мало? Может быть, написать какую-нибудь впечатляющую программу и заодно получить опыт разработки? Например… калькулятор или компилятор или что там обычно пишут для получения и показа опыта? А если не хватит сил закончить?
На эти вопросы и сомнения есть один почти универсальный ответ — доработка проектов с открытым кодом. Вы получаете возможность решать реальные проблемы самых разных уровней сложности, результат не только будет работать у сотен-тысяч-миллионов людей во всем мире, но его еще и можно будет показать. Эту возможность иногда упоминают, но обычно на ней не останавливаются. В этот раз — остановимся на ней.
Идея допиливать открытый код у многих наталкивается на самые разные возражения. Вот самые распространенные.
Возражение первое — зачем доделывать «чужое» вместо того чтобы сделать «свое». Очень распространено среди людей без опыта разработки ПО и часто вызвано рассказами людей старшего поколения, которые сами тоже не имеют опыта разработки. Сюжет обычно примерно такой:
1. «сынок/доченька, ты закончишь вон тот прекрасный вуз,
2. станешь ТЫЖПРОГРАММИСТОМ
3. напишешь крутую программу
4. ??????
5. ПРИБЫЛЬ — успех, деньги и вообще все твое»
Здесь все замечательно, кроме одного — разработчики обычно не пишут код с нуля, чаще всего они дорабатывают существующий. Где-то нужно разобраться в тонне кода и дописать еще тонну кода. Где-то нужно отладить тонну кода и после переставить две строки местами (даже сами строки менять не нужно). Причина проста: разработка с нуля — очень затратное удовольствие и в новом коде очень много ошибок, поэтому «не каждый день нашему брату достается белить забор» целиком, обычно — закрашивают графити.
Поэтому, если без опыта начать разрабатывать что-то более-менее сложное с нуля, можно столкнуться со следующими проблемами:
1. не удастся довести написание и отладку кода до конца, потому что это сложно, а сил пока маловато, может просто не хватить терпения
2. если пункт 1 пройден, то получилась программа с очень ограниченными возможностями, которую почти никто не будет использовать, потому что… ВНЕЗАПНО у потенциальных пользователей уже есть такая же или похожая привычная и готовая программа, а про вашу новую они не слышали, и чтобы это изменить, вам нужно основательно заниматься продвижением
3. квалифицированных разработчиков, готовых оценить качество вашего кода и дать вам обратную связь, очень мало или нет совсем, а это заметно замедляет ваш рост и может повредить в будущем — вы привыкнете писать код действительно плохо и позже озадачите работодателей и озадачитесь сами.
Если пренебречь этими проблемами, вы рискуете потратить много сил на работу, которая будет обречена на забвение (она же «работа в стол»). Если вы осознаете масштаб этих проблем и вас все устраивает или вы готовы их решать — не читайте дальше, разрабатывайте… что вы там хотели разработать?
Для сравнения, допиливая открытый код, вы:
1. можете не разрабатывать с нуля, а дорабатывать уже работающее (да, глючит, но вы же вот-вот исправите), причем доработка может быть как тривиальной (исправление несложной ошибки), так и очень сложной (какая-нибудь впечатляющая новая возможность или ускорение генерации машинного кода компилятором на 15 процентов), вы можете начинать с простого и двигаться все выше
2. если ваши правки приняты, то они попадают в давно существующий канал распространения той программы, которую вы доработали, и вы получаете продвижение результатов своей работы автоматически
3. ваши правки оказываются
4. вы получаете опыт работы с существующим кодом, его неповреждающей доработки и общения с людьми, которым надо объяснить суть правки и, может быть, ответить на возникшие вопросы, эти навыки очень важны для разработчика — оценка рискованности правок, оценка важности исправления той или иной ошибки, объяснение всем заинтересованным первого и второго помогают всем участникам разработки принимать осмысленные решения.
Итак, дорабатывая «чужой» открытый код, вы избавляетесь от целого ряда существенных препятствий. Проще начать работу, проще получить обратную связь, результат вашей работы вполне может попасть в следующий выпуск программы и постепенно оказаться у сотен-тысяч-миллионов пользователей, плюс он будет лежать в открытом для чтения репозитории и вы сможете его всем показывать. Путь становится намного менее тернистым.
Второе возражение — это же надо иметь уже развитые навыки и многие знания, тысячи их, а знаний еще нет, поэтому недостаточно сил, никак нельзя начать.
Давайте посмотрим на вот этот кусок кода (упрощенный вариант кода одной нужной многопоточной библиотеки)
DWORD waitTime;
DWORD secondsInMilliseconds;
DWORD millisecondss;
/*...............................*/
/* секунды в миллисекунды */
secondsInMilliseconds = (DWORD)interval->seconds * 1000;
/* наносекунды в миллисекунды с округлением вверх */
milliseconds = (interval->nanoseconds + 999999) / 1000000;
/*
* Многие компиляторы выдают предупреждение "условие никогда не выполняется",
* потому что переменная беззнакового типа, но проверка точно зачем-то нужна.
*/
if (0 > (waitTime = secondsInMilliseconds + milliseconds))
{
return EINVAL;
}
Видите, даже есть комментарий, что многие компиляторы выдают на этот код предупреждение, но код «зачем-то нужен». И действительно, VC++, gcc и clang выдают предупреждение на этот код, говорят, что проверка-то бессмысленна.
Спойлер: авторы хотели проверить, что сложение не дает переполнения, в случае знаковых целых этот трюк дает неопределенное поведение, но на большинстве платформ «работает», а здесь числа беззнаковые, поведение Стандартом языка определено, но проверка ничего не проверяет. Правильно так:
if (secondsInMilliseconds > UINT_MAX - milliseconds)
{
return EINVAL;
}
waitTime = secondsInMilliseconds + milliseconds;
Выше в этом же коде присутствуют умножение и сложение с константой, но там переполнение даже не пытались проверить.
Какая нужна квалификация, чтобы понять, что должен был делать этот код и хотя бы примерно как его исправлять? Пять лет опыта работы? Десять? Может быть, джвадцать?
Достаточно заинтересованного студента второго-третьего курса специализированного ВУЗа. Есть, например, один ВУЗ, где в четвертом семестре студенты по подсказкам в учебнике пишут и отлаживают программу, хранящую введенные данные в односвязном списке, звенья которого создаются в динамической памяти, при этом весь код, включая несложный распределитель памяти, нужно написать на ассемблере для x86. Достаточно сил разобраться в работе распределителя памяти, но недостаточно, чтобы разобраться с кодом выше? Да неужели.
Все равно слишком сложно? Тогда попроще — тоже по мотивам реального кода.
void* impl_calloc(size_t numberOfObjects, size_t objectSize)
{
unsigned int totalSize = numberOfObjects * objectSize;
void *p;
p = malloc( totalSize );
/* WHATEVER */
Здесь надо было использовать size_t и проверять, что нет переполнения при умножении. Какая нужна квалификация, чтобы это исправить?
И это слишком сложно? Еще проще — где-то в недрах довольно аккуратного кода очень нужной программы прямо посреди функции стоит ЭТО объявление:
std::stack<const Token*> f;
Да, конечно, все понятно. Очевидно же, что f — это f. Здесь «все работает», но разработчик, который будет отлаживать окружающий код, будет какое-то время недоумевать, что это и зачем, и почему потом добавляют именно эти указатели именно в этот объект std::stack. Здесь совсем не вредно понять, для чего переменная, придумать ей короткое осмысленное имя, согласованное с другими именами в окружающем коде, и исправить. Возможно, нужно назвать переменную fields или functions. Какая нужна квалификация, чтобы это исправить?
В открытом коде полно самых разных дефектов самой разной сложности, многие даже искать не надо, они много лет находятся на видном месте, подпрыгивают и пищат «причешите нас, ну пожалуйста».
Третье возражение — правки могут не принять. Действительно могут. Владельцы проекта могут решить, что предложенная правка по каким-то причинам не подходит (например, новая возможность не нужна). Помогает сначала посмотреть на историю изменений, чтобы понять, есть ли жизнь на Марсе, а затем отправить небольшую правку, чтобы было не так обидно. Как вариант — могут быть обязательные условия в виде отказа от авторских прав (например, в SQLite), которые технически сложно выполнить, такое бывает редко, но лучше заранее об этом узнать. В большинстве случаев все особые условия оговариваются сразу и на видном месте (например, есть раздел contributors). Не все проекты принимают правки одинаково легко, но найти подходящий проект несложно.
Четвертое возражение — там же помойка, не для этого вы столько лет учились. Не такая уж и помойка, тем более все равно разработчики обычно дорабатывают существующий код, в котором присутствуют разные дефекты в большем или меньшем количестве. Посмотрите на это с другой стороны — вы сможете разобраться в сложном непонятном (иногда очень сложном и очень непонятном) коде и улучшить его. Добавление десяти строк кода в широко используемую многопоточную библиотеку может быть намного ценнее целого калькулятора на тысячу строк.
Пятое возражение — надо же сделать что-то сложное для «присоединения» к подходящему проекту. Нет, уже не надо. Такие системы как Github позволяют предложить правки в несколько щелчков мышью. Найти дефекты можно в списке ошибок проекта, просмотром кода, статическим анализатором (например, совершенно бесплатным Cppcheck, код которого также открыт и лежит на Github) или по предупреждениям компилятора. Проект вы можете выбрать сами — например, заглянуть ненадолго внутрь библиотеки, которую ранее использовали для работы с XML в вашей курсовой работе.
Можно придумать сколько угодно возражений или начать уже допиливать открытый код.
Дмитрий Мещеряков,
департамент продуктов для разработчиков
Комментарии (51)
tangro
28.09.2015 12:24+4По третьему пункту надо добавить, что правки принимают намного живее, если, во-первых, есть открытый тикет с описанием проблемы и под ним пару человек высказалось что да, действительно, проблема, а во-вторых, на предлагаемую правку написаны тесты.
DmitryMe
28.09.2015 14:19+2Да, но очень часто многочисленные мелкие дефекты нигде не отмечены, например, потому что их быстрее исправить, чем описывать, или потому что они не «не так уж важны», чтобы тратить на них время, в результате их можно найти только в самом коде.
kyb27
28.09.2015 12:40+11К слову, практически в любом opensource проекте есть необходимость писать тесты. Так что есть возможность не только дополнять и исправлять, но и делать с нуля.
DmitryMe
28.09.2015 14:12По-моему, когда бы добавляете тесты к существующему коду, это скорее дополнение, чем разработка с нуля. Да, объем этой работы может быть самым разным в зависимости от того, насколько велик объем кода, есть ли уже тесты и в каком они состоянии.
kyb27
28.09.2015 14:46Да, это дополнения к чему-то. Суть в том, что можно написать полные программы разной сложности с нуля, не ограничивая себя каким-то чужим стилем.
Если нет каких-то особенных собственных идей, то вполне пойдет для тренировки и оттачивания умений.
VolCh
29.09.2015 10:23+1Если тестов нет, то их разработка по сути является разработкой с нуля отдельного приложения, использующего тестируемое в качестве библиотеки и(или) фреймворка.
Nashev
15.10.2015 23:48Любое приложение потому и называется «приложением», что это дополнение операционной системы до чего-то, что способно делать больше, чем она могла без него. Приложение компьютера к новому делу. Оно тоже никогда не с нуля, фактически.
Delphinum
28.09.2015 15:19-3Считаю что новичкам как раз нужно все писать с нуля. Анализ чужого кода влечет больше проблем, чем дает ответов на вопросы новичков.
fareloz
29.09.2015 10:29+3Как аналогия: большинство классиков мировой литературы сначала прочитало множество книг прежде чем написать свою первую.
Iceg
29.09.2015 13:34Разве? Прежде, чем написать первую, ставшую классикой мировой литературы — ок. Но первую ли для самого автора, хм.
Delphinum
30.09.2015 21:06-1Написание книг и программирование это совсем разные вещи. Второе это очень точная, математическая деятельность. Есть множество литературы, в которой объясняется как правильно программировать и какие ошибки могут в процессе возникнуть. Новичку куда продуктивнее будет читать подобные книги (в которых, кстати, тоже хватает примеров, куда более качественных, чем в опенсорсе) и писать что то свое с нуля, чем без теории пытаться разобраться в чужем коде.
Думаю, если бы у большинства классиков мировой литературы были бы книги с информацией о том, как нужно писать книги, а как не нужно, они согласились бы с моим подходом.Kroid
01.10.2015 07:28+2Не слишком разные на самом деле. Большая часть программистов не используют математику совсем. Думаете, много людей читают о реляционной модели прежде чем начать учить синтаксис sql? В этом смысле написание книги может потребовать даже больше умственных усилий.
Могу на собственном опыте сказать. Я прочитал кучу книг по программированию и пытался написать что-то свое с нуля. Но по-настоящему мощный скачок уровня моих навыков произошел только я начал работать программистом и стал сутками копаться в чужом коде.Delphinum
01.10.2015 13:15Могу на собственном опыте сказать
У меня все наоборот. Копаясь в чужем коде я постепенно начал деградировать и уподобляться программистам, писавшим этот код, а именно делать все быстро, некачественно, но в срок, даже используя те же приемы, что они.
Я не встречал еще в чужом коде ничего, с чем я не был знаком по книгам и статьям. Вот такой опыт.
BloodJohn
28.09.2015 15:51-21) Насколько дружелюбно сообщество к новичкам? Банально страшно лезть, зная что любое твое усилие не будет замечено/оценено. Какие проекты посоветуете, из тех, где владелец дружелюбен к новичкам?
2) cpp особенно прекрасно, когда все вокруг только и говорят о программировании на модном python. open source не очень сильно пересекается с модными технологиями.
3) OK. Я займусь рутиной в одном из open-source. Но что это мне даст в глазах работодателя? Назовите парочку работодателей. В каких проектах они рекомендуют участвовать, чтобы попасть к ним?Delphinum
28.09.2015 17:58+41. Лезть надо не для того, чтобы сообщество вас заметело и оценило, а для развития своих навыков в программировании и наблюдения за работой более опытных программистов. Сообщество не должно вас воспитывать, помогать вам.
2. А какая разница, что за язык используется?
3. Когда я последний раз искал работу, все работодатели просили предоставить пример кода в виде готового проекта (написанный мной с нуля или тот, в разработке которого я участвовал). Когда я показываю работодателю проекты с моей прошлой работы, работодатель знает, что не я один их реализовывал, но я в этом участвовал и у меня есть опыт написания подобных систем
AlexanderG
30.09.2015 17:41я показываю работодателю проекты с моей прошлой работы
Как вы справляетесь с NDA? Исходники ведь не покажешь, а слова «ну, я там че-то участвовал, разрабатывал» кажутся не очень убедительными.Delphinum
30.09.2015 21:07+1Исходники ведь не покажешь
Я не подписывал NDA, да и исходники у нас были открыты, как и вся платформа, на которой писалось.
resetnow
28.09.2015 20:22+11) В большинстве проектов, в которые я пробовал сообщать баги/отправлять патчи, относятся в целом дружелюбно, важно грамотно описать проблему и перед ее решением поискать, было ли что-то уже сделано в этом направлении. И смотреть правила приема патчей, оформления кода.
3) Мне как-то вот такое письмо пришло. Понятно, что рассылка, но как-то же выбирали профиль и ему подобные и значит, что кому-то не все равно?
VolCh
29.09.2015 10:33+22) Как раз модные технологии чаще бывают опенсорсными. В топ10 языков минимум у половины есть эталонные реализации в открытом доступе и минимум у подавляющего большинства есть открытая экосистема.
3) Покажет работодателю, что:
3.1) Вы можете заниматься рутиной добровольно
3.2) Вы можете работать с чужим кодом
3.3) Вы можете писать достаточно качественный код (если примут ваш патч), согласно принятым в конкретном проекте соглашениям
3.4) Вообще покажет ему образцы вашей работы
Iceg
28.09.2015 17:44+3Я — тот самый «начинающий разработчик». С интересом открываю подобные статьи (особенно многообещающий тег «жмите сюда — и вы приняты», наверное, через полгода именно по нему будут находить вашу статью). Чаще всего дочитываю уже без интереса :)
Капелька фидбека, если интересно.
Да, на на одном собеседовании мне как-то рекомендовали такой подход — участие в опенсорсе. Да я и сам — и до того, и после — думал об этом.
Только я в итоге предпочитаю либо потратить это время на литературу, либо на набивание шишек в написании своего супер-велосипеда (tm)(с), либо просто на изучение (с высокой вероятность) качествнного открытого кода, без попыток что-то туда коммитить. Почему? Потому что, во-первых, мотивация. Свой проект — он о том, что мне интересно. Опенсорсных я таких почти не нашёл. Вернее, нашёл, но даже мне ясно, что там (а это во-вторых) лютый говнокод и вообще, они мертвы уже по несколько лет. Или я лучше просто поковыряю исходники, на которых чему-нибудь научусь (либо прифигею от кучи всего непоняиного и неизвестного — тоже хорошо мотивиует), чем буду искать переполнение переменной или неинформативные имена переменных.
Кроме того, порог входа в новый проект достаточно велик. Я же не стану писать разработчикам с вопросами по коду, чтобы мне пояснили че там происходит, верно? Поэтому на вникание уйдёт гораздо больше времени. Это время может быть сопоставимо со временем: а) моей потери интереса к выбранному проекту либо осознанию его несостоятельности и того, что от такого кода надо держаться подальше; б) моего становления как разработчика :), и очевидно, в таком случае оно случится не благодаря этому опенсорсу.
Такие дела.Delphinum
28.09.2015 18:00-2Я же не стану писать разработчикам с вопросами по коду, чтобы мне пояснили че там происходит, верно?
В опенсорсе хватает документации, чтобы можно было разобраться в проекте без вопросов к разработчикам.Iceg
28.09.2015 18:55+4Давайте говорить правильно: иногда в некотором опенсорсе хватает документации, чтобы достаточно опытному программисту, потратив какое-то весьма ощутимое время, можно было разобраться в проекте без вопросов к разработчикам.
Delphinum
28.09.2015 19:02+3иногда в некотором опенсорсе хватает документации
Часто в рабочих проектах все пишется в спешке, без документации и тестов. К этому тоже нужно быть морально готовым.Iceg
28.09.2015 22:39Я видел вполне коммерческий чудо-код (признаюсь, даже писал), в котором без пол-литры или живых комментариев автора трудновато разобраться. Я прекрасно понимаю, что
частоиногда код пишется такой, чтобы работал ВЧЕРА, а не с мыслью о самодокументированности, поддержке и паттернах. Именно поэтому я знаю, что в таких случаях лучше спрашивать автора или кого-то, кто шарит в происходящем хаосе не меньше автора: ч.з.х.? Именно поэтому в изучаемом языке я лучше посмотрю вылизанные исходники популярной библиотеки, а не потенциально плохой код (потенциально — потому что я начинающий, я ещё не могу отличить хороший код от плохого), в который даже начинающий девелопер может внести правки. Типа, дети когда родной язык в школе учат, они читают литературу, а не проверяют сочинения своих одноклассников.Delphinum
28.09.2015 23:03Согласен, лучше изучать хороший код, чем плохой. Вы к тому, что все опенсорсные проекты с говнокодом внутри?
Iceg
28.09.2015 23:49Нет, конечно. Я о том, что хорошие и качественные проекты, в которых мне интересно было бы поучаствовать (а это те, которыми я пользуюсь, и в которых мне чего-то не хватает) достаточно сложны, чтобы новичок в них совался с доработками. А все остальные я лучше буду обходить стороной — потому что там может быть как хороший код, так и плохой. Я как начинающий разработчик не могу их отличить и буду запоминать всё, но я не хочу забивать голову дурными примерами. По аналогии с языком, факт: когда я стал меньше читать книг, и больше интернеты — местами стали проскакивать тупейшие ошибки, просто на автомате. Уверен, с кодом всё бывает так же.
Delphinum
29.09.2015 01:34чтобы новичок в них совался с доработками
Ну для начала можно суваться без доработок. Любое сообщество оценит, если вы будете писать документацию, юнит-тесты и сообщать о багах.Iceg
29.09.2015 13:47Мне кажется, вы забываете о начале разговора. Сообщество оценит, не сомневаюсь. Или не оценит, и тогда получится, что я тупо слил недели труда и времени. Другой вопрос: а работодатель оценит? А он оценит больше мой вклад в опенсорс как технического писателя — или всё таки лучше почитать книжки по основному направлению, разработке?)
Delphinum
29.09.2015 18:20+1Если бы вы пришли ко мне на собеседование и сказали, что помогаете паре-тройке опенсорсных проектов в написании документации, тестов и дебагинге, это было бы для меня большИм плюсом, нежели если бы вы показами мне красный диплом.
AlexanderG
30.09.2015 17:46или всё таки лучше почитать книжки по основному направлению, разработке
Теория без практики мертва, практика без теории слепа.
VolCh
30.09.2015 19:50+1Ну, то, что вы нашли баги в, например, ORM на языке Х или написали какие-то тесты для неё, то обычно это значит, что язык X вы используете.
Iceg
01.10.2015 12:46Я думаю, если бы я нашёл баги в ORM, то мне было бы что показать и кроме этого) Вроде же речь про начинающих, не?
Delphinum
01.10.2015 13:18+1Вы создаете несколько классов с наследованием, прописываете метаданные для ORM, радостно записываете первый десяток объектов в базу и бах — ошибка. Собираете инфу по этой ошибке и шлете сообществу. Разве для этого нужно быть профессионалом?
Iceg
01.10.2015 16:32>Вы создаете несколько классов с наследованием, прописываете метаданные для ORM, радостно записываете первый десяток объектов в базу
То есть этот абстрактный «я» использует опенсорсную разработку — но в своём проекте? Который, возможно, очередной велосипед. Кажется, с этого мы начинали разговор, не? :)
И еще есть тонкий момент между «искал и нашёл» и «случайно наткнулся» — вероятность на несколько порядков ниже.Delphinum
01.10.2015 17:08Либо используете в своем проекте, либо просто изучаете, тыкаете палкой на предмет — а завоняет ли.
вероятность на несколько порядков ниже
Это мешает вам изучать опенсорсные проекты?Iceg
01.10.2015 19:48Изучать — не мешает, и даже не помогает. Писать им тесты, документацию или код — на это тоже вообще никак не влияет. Тем не менее, я за изучение, но считаю слабовероятным остальное, почему — см. первый комментарий. У меня ощущение, что вы возражаете каждому моему комментарию, причём отдельно, забывая про всё сказанное мной в предыдущих.
Delphinum
01.10.2015 21:11+1У меня такое же ощущение относительно вас ))) Видимо мы друг друга не понимаем.
Iceg
02.10.2015 17:33Забавно) Хотя, я вас услышал, даже если и не понял.
Да и в любом случае, я свойникомуненужныйвелосипед тоже где-нибудь когда-нибудь на гитхабе выложу. Ачо, тоже опенсорц :)
Wedmer
28.09.2015 20:21+1Есть случаи, когда все таки стоит задать вопрос по непонятному куску кода. Это даже может помочь разработчику найти возможную ошибку или он расскажет вам о каком нибудь хитром приёме.
Kroid
28.09.2015 19:11Дополню: и даже без документации часто гораздо быстрее самому посмотреть в исходном коде, чем ждать ответа разработчиков.
pasha_golub
28.09.2015 20:06Да, я тоже думал, что буду писать пилотируемые миссии. И твердил как мантру, что к БД не притронусь. Реальность она всегда другая. И ОпенСорс он всегда более глубок, чем кажется на первый взгляд
Iceg
28.09.2015 22:53+4твердил как мантру, что к БД не притронусь
оценил иронию :)
pasha_golub
29.09.2015 11:38Я к тому и пишу, что он только с виду ОпенСорс, а вокруг него бурлит и кипит вполне себе капиталистическая реальность.
mickvav
29.09.2015 07:42+1По первому примеру кода — а ничего, что переполнение уже при расчёте secondsInMilliseconds может случиться, и тогда предложенная проверка не отработает ;)
DmitryMe
29.09.2015 09:44Конечно, «чего», об этом сказано в тексте абзацем ниже. Исправлена только сама неработающая проверка.
Wedmer
Мне так кажется, что не всегда нужно пытаться закоммитить код в проект. Иногда достаточно аккуратно указать на ошибки или просчеты. Несколько грамотных тикетов стоят дороже пары кривых коммитов.
DmitryMe
Не всегда, но часто стоит. Если вы только описываете проблему, то вы рассказываете «как правильно», а если исправляете ее — то показываете. Разработчикам нужно уметь и то, и другое. Владельцам проекта нужно заметно больше усилий для того, чтобы по описанию сделать исправление, чем для того, чтобы оценить готовое исправление.
Meklon
Я стараюсь баг-репорты писать. Мои минимальные навыки написания скриптов и базовый C никому нафиг не нужен. А подробный баг-репорт мне отправить несложно. Даже один баг в ядре Linux закрыли. Приятно.