Войти
ФлеймФорумОбщее

Как отличить шарагу от не шараги? (16 стр)

Страницы: 113 14 15 16 17 18 Следующая »
#225
0:23, 7 июня 2018

9К720
> Следует то, что чел может писать рабочий код, очевидно. Мне казалось, что
> именно это мы и пытаемся проверить на собесе
Дык челы, которые пишут рабочий код, работают в шарагах. В нешарагах пишут понятный и надежный код. Что автоматом предполагает работоспособность, но нафиг ее еще проверять, если тебе неговнокод показывают?!
А если он решение твоей задачки писал сразу в скайп, экспромтом, с телефона, и синтаксическую ошибку зевнул?!


#226
0:52, 7 июня 2018

9К720

> А юнит тесты для удешевления.
Я к тому, что Mimon был прав - код невозможно проверить юнит-тестами.

> Есть спека
Ты под спекой SSS/SRS имеешь в виду?

#227
0:52, 7 июня 2018

DanielSky
> А если он решение твоей задачки писал сразу в скайп, экспромтом, с телефона, и
> синтаксическую ошибку зевнул?!
Это значит нахер его. Это значит человек не отвечает за результат своей работы. Серьезно. Я работал с такими людьми, которые не считали нужным даже запустить код, прежде чем отдать его со словами "вот, все готово". Это значит за ними надо будет перепроверять все. Вот абсолютно все. Проще с такими не работать.

DanielSky
> понятный и надежный код. Что автоматом предполагает
> работоспособность,
Ахереть у тебя логика. Нет, правда. Я надеюсь что ты троллишь.

DanielSky
> но нафиг ее еще проверять, если тебе неговнокод показывают?!
Ну давай сойдемся на том, что у всех свои требования. В моей шараге главное надежное, оттестированное и законченное рабочее решение.
В твоей нешараге главное красиво оформленный неговнокод без авто. Можно даже с синтаксическими ошибками и некомпилящийся, всем понятно, человек со скайпа писал, ну зевнул, с кем не бывает. В следующей версии пофиксим. Может быть.
Ну окей, что. Айти очень широкое, наверное твой подход к написанию кода тоже где-то нужен.

#228
1:09, 7 июня 2018

Ghost2
> Я к тому, что Mimon был прав - код невозможно проверить юнит-тестами.
Из этого не следует, что их не нужно писать. Во первых они дают очень быструю и весьма надежную проверку, ошибка найденная юнит-тестом стоит в десятки-сотни раз дешевле чем если эту ошибку найдет интеграционный тест и в сотни-тысячи раз дешевле, если ее найдет человек, даже с зарплатой индуса. Во вторых когда ты пишешь какой-то кусок кода,  гораздо проще убедиться в его работоспобности написав юнит тесты, причем на все корнеркейзы.
Отлаживать какой-то алгоритм в живой системе зачастую очень трудно, да и на стенде очень тяжело зачастую дать входные данные. А так ты выделяешь именно этот компонент. Черт, да так просто тупо удобнее дебажить и править код.
Вот тебе живой пример.
https://gamedev.ru/flame/forum/?id=236437&page=7#m104

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

Остаются только проблемы связанные с интеграцией компонент - коннективити (русофилы, идите в пень), несоответствие протоколов между частями, некорректная работа  с ресурсами ОС, и еще гонки в многопочной среде. А вся алгоритмическая часть полностью юнит-тестами проверяется.

Ghost2
> в авиации
Вот тебе аналогию попробую привести.

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

Тут появляется Мимон и заявляет - нахер все эти ваши проверки, все равно надо проверять на настоящем самолете, поэтому я никогда детали на стенд не загоняю.


Ghost2
> Ты под спекой SSS/SRS имеешь в виду?
Нет. Под спекой я имею в виду например спецификацию cвифта (не который язык для гей-разработки, а который платежная система), протоколы межбанковского обмена и протоколы обмена внутренних систем.

#229
2:34, 7 июня 2018

DanielSky
> Хорошая демонстрация кода может дать столько же инфы, как выполнение сложной
> задачи, и полюбому не меньше, чем задача примитивная.

> не отобранный образец, а хрен знает что и не объяснил что оно делает
мастер противоречий : )

return [](){}; добавил возможность компилять некоторые функции D на лету во время исполнения

лучше бы в ispc добавил : ))
а то там объявишь soa<8> а как оно ляжет в меньшую аппаратную ширину х.з.
З.Ы. впрочем можно сразу несколько таргетов в один объектник пихать
#230
8:50, 7 июня 2018

9К720
> А вся алгоритмическая часть полностью юнит-тестами проверяется.

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

9К720
> Под спекой я имею в виду например спецификацию cвифта

А, ну теперь ясна сфера твоей работы, претензии отпадают

9К720
> Ну согласись, что тупо написать чеки гораздо, гораздо проще и быстрее

Для указанного примитивного алгоритма? У вас там совсем зеленые что ли работают?

#231
11:19, 7 июня 2018

9К720
> Это значит нахер его. Это значит человек не отвечает за результат своей работы.
> Серьезно.
Да причем тут работа, он же не работу сдает, а решение тестового задания. Которое должно требовать минимум времени, причем не рабочего, когда чел может быть не у компа. И цель которого не решить задачу практически, а дать оценить знания и навыки.

> В твоей нешараге главное красиво оформленный неговнокод без авто. Можно даже с
> синтаксическими ошибками и некомпилящийся, всем понятно, человек со скайпа
> писал, ну зевнул, с кем не бывает. В следующей версии пофиксим. Может быть.
Не выдумывай, я не коммитю в транк, не проверив работоспособность.

Sh.Tac.
> мастер противоречий
Нет противоречий, return код не демонстрировал, а только кинул ссылку на какую-то херню.

#232
14:18, 7 июня 2018

Mimon
> алгоритмическая часть является мизерной в общем объеме проекта
Чушь собачья. Алгоритмическая часть - это не только заимплеменченные примеры из седжвика.
Это вообще весь код. Вся кодобаза. Она может быть мизерной в объем объеме проекта только если ты проект программируешь мышкой в каком-нибудь cms или говне вроде informatica.
Но и тогда, в этом CMS который для тебя писали, есть тесты.

Mimon
> Для указанного примитивного алгоритма?
Да. Скомпилить программу, создать все те файлы и проверить результат займет в разы дольше времени чем писать чеки. Даже для этого примитивного алгоритма.

Mimon
> У вас там совсем зеленые что ли работают?
Очевидно, что ты у тебя нет опыта работы в  нормальной конторе, где код пилит больше одного кодерка, причем нормальный коробочный код, а не кастомизация готового CRM под одного заказчика. Либо ты настолько гениален, что ты никогда не делал ошибок в коде.

#233
14:20, 7 июня 2018

DanielSky
> Да причем тут работа, он же не работу сдает, а решение тестового задания.
> Которое должно требовать минимум времени, причем не рабочего, когда чел может
> быть не у компа. И цель которого не решить задачу практически, а дать оценить
> знания и навыки.
А при том. Это особенность человека, что он может отдать результат, от которого зависит его будущая карьера, даже не проверяя. Вот и все.

#234
14:37, 7 июня 2018

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

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

+ Показать

Но я уже объяснял, платят не за код, не за навыки, не за умения. Кому нахер нужны твои умения и навыки? Платят за решение проблем, если ты со всеми навыками создаешь проблемы вместо их решения, то нахер ты такой нужен. Я правда не понимаю. Ты можешь вообще не уметь писать код, но если твоим словам о том, что данная тебе задача будет решена можно доверять - то ты будешь востребован на рынке очень сильно. Как прекрасный менеджер, к примеру.

Если тебе на одном СТО после починки машин,забудут прикрутить двигатель, и когда ты поедешь все развалится, как ты оценишь качество работы? А там хороший мастер, с большими навыками и теоретическими познаниями.

Почему ты программистов оцениваешь по другому?


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

#235
15:22, 7 июня 2018

9К720
> Алгоритмическая часть
> Это вообще весь код

Изображение

> Скомпилить программу

А чеки у тебя не компилируются? лол

>создать все те файлы и проверить результат

Контрольные файлы на подобные случаи создают ребята из отдела тестирования и валидации, и прогоняют уже на своих инструментах твой софт в виде "black box". Они получают за это оплату. Вопросы?
Edited: В вашей "крутой" конторке вообще есть отдел тестирования?

> Либо ты настолько гениален, что ты никогда не делал ошибок в коде.

Приятно познакомиться

#236
17:07, 7 июня 2018

9К720
> А при том. Это особенность человека, что он может отдать результат, от которого
> зависит его будущая карьера, даже не проверяя. Вот и все.
Я понимаю о чем ты говоришь, но ты не правильно представляешь себе обстоятельства, которые я предположил. Человек не подсовывает черновик на авось прокатит, а открыто тебе сообщает, что он сейчас не у компа, а потом времени у него не будет, и предлагает написать решение без проверки, благо задачка тривиальна. Твои действия, будешь требовать - нет уж, извольте ради моего предложения помаяться?

#237
17:17, 7 июня 2018

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

#238
18:59, 7 июня 2018

DanielSky
> Человек не подсовывает черновик на авось прокатит, а открыто тебе сообщает, что
> он сейчас не у компа, а потом времени у него не будет
  Хочется спросить у такого человека, а ходить на работу у него время будет? :)

#239
19:47, 7 июня 2018

9К720

> Во первых они дают очень быструю и весьма надежную проверку, ошибка найденная юнит-тестом стоит в десятки-сотни раз дешевле
Ты там выше пишешь:

Если код валится только после того как туда в определенном порядке пустили два неверных сообщения и подождали ровно 5 секунд перед тем как послать третье, тоже

У нас, например, 70% найденных ошибок такого плана. Ничего, разумеется, никогда не валится, но и работает не совсем так как нужно.
25% - неправильно понятая логика работы сопрягаемого бортового оборудования. И от силы 5% на то, что можно было бы поймать юнит-тестами.
Первые мы не поймаем, на вторые мы напишем такие же ошибочные юнит-тесты, ну а практически все последние ловятся или статикой, или
на этапе отладки. Я не говорю, что они не нужны, возможно очень нужны. Но для нас цель не оправдывает средства.
Софт давно перешел некую пороговую черту, когда начинать покрывать его уже поздно. Когда я начинал его разрабатывать
десяток лет назад, даже не думал о такой фигне, а начальство не требовало.

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

Вот разработка на HDL - другое дело, там без тестбенча и верификации вообще тяжко. Если разбор сложного бага в программе
затягивается на недели, то разбор бага в железке может затянуться на месяцы. Еще хуже со схемотехникой. И совсем плохо в СВЧ и механике.
Спасает только то, что после первоначальной отладки все это трогать нужно крайне редко.

Кстати, по руководящим документам, те люди, которые разрабатывают софт, не должны принимать участие
в процессе верификации. Так что процесс
> Юнит тесты пишет автор кода
формально запрещен.

> нахер все эти ваши проверки, все равно надо проверять на настоящем самолете
Нет. Он сказал, проводя аналогии, что лопатку нельзя проверить в симуляторе лопаток.
Нужно проверить ее в симуляторе лопаток, потом в симуляторе двигателя, потом собрать двигатель,
запустить, проверить обледенение, полить водой, бросить в него курицу, а потом взорвать.
Если двигатель, прошел испытания, то нужно собрать новый, повесить на самолет.
Долго гонять на земле, потом пробовать взлететь, потом много раз взлететь.

И даже все это нифига не гарантирует то, что с лопатками все хорошо: https://en.wikipedia.org/wiki/National_Airlines_Flight_27

> Под спекой я имею в виду например спецификацию cвифта
Ну, так не интересно. А где бизнес-логика, юз-кейсы, high/low level требования?
Ты вот возьмешь t800 через пару лет работать в банк. Он сгенерит пол лимона строк кода,
покроет их юнит-тестами, которые даже волшебным образом будут проходить. Затем, спалив его на
поиске свечей от геморроя, ты его уволишь. А буквально через пару месяцев после этого начнут
лавинно падать все его юнит-тесты. Не по спеке же на свифт ты будешь во всем этом разбираться?

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

Страницы: 113 14 15 16 17 18 Следующая »
ФлеймФорумОбщее

Тема в архиве.