Работа

Смотря что считать отладкой. У меня отладка занимает где-то 95% времени при написании нового кода. Но тут еще все зависит от рода приложения, фреймворков и прочего. Просто если основной код не слишком нагруженный (boilerplate) то внимания он требует меньше, его пишут длинные дяди в IDE автокомплитом. Если код для общения с системой, тут отладки чуть больше. А если код реализует алгоритм со сложными структурами данных, то тут вполне нормально хорошо закопаться в отладку, особенно если с этими алгоритмами и структурами ранее не сталкивался и выработка методики подтверждения корректности занимает какое-то время.

хахаха, как у говно-кодерка от правды пригорает.

это и ваш обезьяний рокетсайнс

это для тебя оно рокетсайенс. пробежался по твоим каментам в тредах про девелопмент - да ты реально необучаемая макака задрочившая пару паттернов, но так ничего и не поняв.

если код реализует алгоритм со сложными структурами данных

Уж не знаю кто новые алгоритмы каждый день реализует, по-моему, это явно выпадает из общего случая.

У меня отладка занимает где-то 95% времени

Что ты такое пишешь? Мне пока байтики на сях перекладывать не приходится, такого никогда не происходит, причём даже тогда это никак не 95%.

Ну я говорил, что в наших реалиях если не хочешь становится ответственным специалистом и хочешь просто писать код, то шансов не превратиться в биоробота становится все меньше. Крутые специалисты нужны на более ответственных должностях в проекте, безусловно, но их нужно в разы меньше. Но тенденция по постепенному выдавливанию специалистов из разработки в консалтинг устойчивая и не останавливается. Люди хотят экономить.

Я как раз фигачу алгоритмы. Но я могу согласиться, что если пишешь boilerplate на каком-то фреймворке, то все гораздо проще.

Расскажи Яндексу как он процессами может заменить Миловидова, там лишь улыбнутся ну так это и не про тебя, и, как бы ты, петушара, ни хорохорился никогда ты не станешь таким же незаменимым. вас таких очередь за дверью.

Можешь из кожи лезть, ничтожные анонимные обиженки меня только забавляют.

Ой как тебя припекло, чушка, любо наблюдать.

обиженки на тебя штоле? так на ущербных не обижаются.

Сколько алгоритмами не занимайся, а новые каждый день не реализуешь. Нет такой необходимости как класса. Я вот анализом данных занимаюсь, типичных подходов на все случаи и фреймворка для этого у меня нет, нет и 95% времени в дебаггере, правда и код очень высокоуровневый.

Это твой личный подход к разработке, не более того. Иногда банально прощк залипнуть в дебаг и найти ошибку, чем пытаться уложить в голову нечто сложное и запутанное целиком, но всегда можно пойти вторым путём.

Твой пожар этот лепет наглядно опровергает.

Отладка=debug, кто-то называет чтение кода и чесание репы дебагом?

Да. Так исправлялась одна из самых лютых ошибок в линуксе, связанная с дисковыми накопителями, которая проявлалась раз в год и выводила раздел из строя, и которая никакими запусками и логами не обнаруживалась.

Я сказал, что в общем случае никакого дроча в дебаггер и даже усиленного залипания в лог не будет. Мб только другими словами, искать лень.

Нет, проблема заключается именно в том, что мы говорим на разных языках и подразумеваем разные вещи. Тебе почему-то видится, что прогер будет сидеть неделями и в отладчике пытаться разобрать единственную ошибку, но тебе почему-то не видится группы разрабов, которые написали новую версию софта за неделю, и теперь уже третий месяц сидят и полируют систему, исправляя в сумме сотни самых разных багов, и эти баги регулярно будут появляться в большом количестве, потому что система не стоит на месте и в ней дописывается и изменяется функционал, а некоторые баги будут висеть неиспрвленные годами, потому что никто даже не может понять, откуда у нее растут ноги. Это жизненные реалии разработки любой сложной системы.

Ну личный то личный… просто при реализации алгоритмов очень много факторов, которые влияют на качество реализации, например часто порядок инициализации переменных меняет производительность алгоритма с 100ms до 10us, и вообще очень много траха с современными компиляторами, когда они вдруг решают, что половина кода в твоей функции не нужна и не генерят последующий код. Да и со структурами данных то же самое, часто распил структуры на 2 или отказ от union’а в ущерб расходу памяти ускоряет работу кода в n раз. Короче, есть где развернуться, так как способов достижения результата очень много. А реализовывать алгоритмы для нового приложения в течение начального периода разработки приходится по несколько штук в день, а потом долго и нудно оптимизировать это все до приемлемого состояния.

Линукс уже давно вышел из-под контроля

На фоне той байки про оракл и при учёте размера ядра, никакого выхода из под контроля даже и близко нет, релизят стабильно, перманентной паники в lkml никакой нет.

И оракл релизят, и чо дальше? Линукс и оракл в этом плане мало чем отличается, просто ужасы отладки линукса еще никто так не преукрашивал, да и по ораклу есть только один гневный отзыв.

Ну вроде тестирование ядра отдельный проект и там довольно много всяких тестов и люди пишут еще, так что не настолько все плохо.

Я изначально говорил про бестолочей, которые написав новый код за пять минут потом ещё пятьдесят пять пытаются его заставить работать, упорно дебажа.

Это вполне себе классика, так как исправляя код, добавляют еще больше ошибок. Тут все решает коммерческая целесообразность и интерес. А баги будут всегда.

Сейчас все выравнивают процессами. Даже если ты мегакрут, ты не будешь лучше чем студент Вася, поэтому тебе не надо платить больше чем ему. А специалистов нанимают на руление, архитектуру и старшими, которые занимаются решением проблем, важных для всего проекта вцелом, пишут прототипы систем и подобное. Да, сейчас пока в среднем квалификация рядового разработчика выше чем рядового тестера в силу аутсорсинга и специфики работы, но ситуация имеет тенденцию к выравниванию.

Скорее это выравнивание по дну. То есть, как бы ты ни был крут - твои навыки будут только мешать тебе, потому что индусы в конторе не осилят тех продвинутых приемов и инструментов, которыми ты можешь свободно пользоваться. Ты написал вставку на асм-е - а кто ее без тебя будет поддерживать? То-то. Все грузят уголь лопатами, а тебе, видите ли, экскаватор подавай, потому что ты умеешь им пользоваться и обслуживать его - хрен тебе, махай лопатой как все, никто не будет ради тебя одного разбираться с экскаватором. Заказчик/начальник просто не хотят платить больше за то, чтобы выполнить задачу быстрее/лучше, им, зачастую, нужно выполнить задачу кое-как - и это большая часть рынка.

Потребность в софтописангии возросла, а кол-во способных кодеров не изменилось - отсюда и возникает потребность в организации работы всё менее и менее способных людей.

А специалистов нанимают на руление, архитектуру и старшими, которые занимаются решением проблем, важных для всего проекта вцелом, пишут прототипы систем и подобное

К сожалению, на уровне донных контор это действительно так. А вот что делать человеку, которому глубоко противна работа по организации труда тупых прокрастинирующих индусов?

Только я ни капли не утрирую, а действительно видел как таким образом разрабатыват в самом малом масштабе. Достаточно простой код, который укладывается в голове, который можно было просто пару раз внимательно вычитать и всё исправить, даже ни разу не запуская, отлаживали часам. Ровно как ты говоришь, ломая сломанное ещё больше и так до момента, пока рандом не сойдётся и всё не заработает.

Понятно, что на большом масштабе это неизбежно происходит, но я говорил буквально. И это не норма.

А поддержка, опять таки, 90% времени не должна занимать.

Крутые специалисты нужны на более ответственных должностях в проекте, безусловно, но их нужно в разы меньше. Но тенденция по постепенному выдавливанию специалистов из разработки в консалтинг устойчивая и не останавливается. Люди хотят экономить.

Да. Да. Качество софта и вебсайтов неуклонно падает, и всех это, судя по всему, устраивает. Я вообще думал из софтописания сваливать - и с радостью свали, если найду годный вариант.

Ну вроде тестирование ядра отдельный проект и там довольно много всяких тестов и люди пишут еще, так что не настолько все плохо.

Тестируют ядро все люди, которые пользуются им и отправляют отчеты. А это очень большое кол-во людей. Просто в оракле этот процесс выполняется в рамках единственной организации, а для линукса абсолютно тот же процесс делается распределенно руками добровольцев.

Я изначально говорил про бестолочей, которые написав новый код за пять минут потом ещё пятьдесят пять пытаются его заставить работать, упорно дебажа.

Значит, ты говорил про что-то свое, потому что писал я совсем другое:

Отладка занимает приблизительно 90% всей работы кодера

Из тобой написанного только такой сценарий и читается. Иначе 90% никак не набирается. Любой другой сценарий бы мгновенно загнулся, ибо на оставшиеся 10% остаётся слишком много работы, а значит никакой разработки нет, одна поддержка, и та под откос идёт.

Иначе 90% никак не набирается. Любой другой сценарий бы мгновенно загнулся, ибо на оставшиеся 10% остаётся слишком много работы, а значит никакой разработки нет, одна поддержка, и та под откос идёт.

Если я буду называть цифры 70-30%, то ты успокоишься? Я сейчас просто посмотрел, сколько кода я лично писал в одном проекте, и сопоставил со своей предельной осмысленной скоростью письма без отладки - примерно в три раза у меня падает производительность из-за необходимости вообще что-то отлаживать.

На этом сойдёмся.

Ну это понятно, что если считать из общего времени проекта в среднем за год, то это будет 50-70% так как есть еще всякая деятельность по ревью, стайлинг, митинги, периоды заблокирванности, объяснение очередному коллеге с наездами не по делу что он не прав и должен сдохнуть и прочее подобное.

Ну и нагрузка в проекте может быть не слишком равномерной, особенно когда он уходит в поддержку.

Где-то слышал, что изрядная часть кода ядра - это драйверы. Сама идея юнит-тестирования в данном случае просто смехотворна.

Где-то слышал, что изрядная часть кода ядра - это драйверы. Сама идея юнит-тестирования в данном случае просто смехотворна.

Да, это так, и ты можешь это проверить. Кучу драйверов к самому разному давно умершему говно лежит в основном репозитории ядра и поддерживается вместе со всем ядром. И в этих драйверах содержится астрономическое кол-во багов, которые просто никто не будет исправлять.

Там помимо этого есть еще подсистемы и API, которые тестируются. Ну и драйвер драйверу рознь. Если ты не можешь покрыть тестами какую-то часть кода (что бывает почти всегда) это не повод этого не делать вообще.

объяснение очередному коллеге с наездами не по делу что он не прав и должен сдохнуть

Хоть сколько-нибудь осмысленная и результативная работа в таком коллективе невозможна от слова совсем. Исключение: грузчики, менеджеры всех звеньев, таксисты (но тут с оговорками).

Такой юнит-тест полезен конечно, но будет запускаться один раз за всю историю ядра, потому как нужно чтобы человек был владельцем такой железки, был кернел -девелопером и был готов пускать эти тесты на своем железе ради общего дела даже после начального периода. Комбинация согласись редкая.

К сожалению реальность работы в коллективах, особенно в офисах со своей санта-барбарой, говорит об обратном. Всегда находятся люди, готовые срать остальным на голову, причем если эту голову кто-то не подставляет, случается катастрофический разрыв шаблона. Люди есть люди.

которые просто никто не будет исправлять

Мы говорили о тестировании всё-таки.

Посредством тестирования всё же пытаются баги не «исправлять», а «не вносить».

Так вот получается к изрядной доле линуксового дерева тестирование не применимо. (А ведь это именно тот редкий случай когда юнит-тестирование реально было бы полезным).

Люди есть люди

Это не свойство людей, это свойство уродов. Просто в нынешние времена последние превалируют в том числе и в программистских командах, поэтому некоторые думают, что «люди такие».

Ну помимо драйверов железок есть еще архитектуры, API ядра, подсистемы и механизмы общения драйвера с остальным ядром, и все это не зависит от наличия/отсутствия железки и неплохо тестируется. Понятно, что взаимодействие с железом непосредственно без хотя бы эмуляции этого железа не проверить, зато все остальное можно и нужно. Вероятность слома драйвера по причине изменения окружения все еще остается, но она максимально снижена. Пока есть живые железки и их пользователи, это все можно починить. И то, что из ядра выкинули, можно засунуть обратно, если ты готов это поддерживать. Но железо уходит, ломается и в итоге остается без поддержки, это норма.

После некоторого времени драйверы удаляют и из ядра, это тоже нормально, так как если это кому-то нужно, все можно вернуть и исправить. Ничто не стоит на месте. Поэтому в ядре всегда будут неработающие/неподдерживаемые драйверы и вряд ли это имеет смысл менять, так как вариант с быстрым выпиливанием кода неудобен сообществу, так как не все работают над ядром за деньги. Считать при этом что ядро не тестируют, неправильно.

Спектр задач в IT не ограничивается только вебнёй и матаном.

Не, ещё художники есть и формошлёпы. Но в бигдате и числодробилках без матана никак.