Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, Lazy Bear, Вы писали:
LB>>???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
LB>>Я тоже пинаю своих писателей за запятые без пробелов и за пустые строки от балды. Если в проекте используется определенный стиль кодирования, то ему надо следовать. Это совсем несложно.
GIV>Для этого есть автоматические средства пинания, раз настроил и радуешься.
Точно, спасибо за напоминание. Лень-матушка все никак не дает это сделать. Вроде люди косячат нечасто, поэтому неохота возиться с настройками. Займусь.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
А почему сразу «идиоты»? Вон, Джобс станки на своём заводе красил в идеально белый цвет. Зачем? Атмосфера безупречной чистоты поощряет perfection, якобы. Тут логика может быть похожей — раз автор мирится с imperfection в пробелах, смирится и с «так сойдёт» в алгоритмах/архитектуре/whatever.
P.S. Я бы так не делал, поскольку знаю человека, который все пробелы, комментарии и линии вылижет, но легко пропустит несовершенство алгоритма (это я). Но, может, им такие как я пока не встречались.
Здравствуйте, 463C21E2, Вы писали:
CE>Здравствуйте, ???, Вы писали:
CE>???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
CE>???>1) В репозитории отсутствует .gitignore ! CE>???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
CE>А почему сразу «идиоты»? Вон, Джобс станки на своём заводе красил в идеально белый цвет. Зачем? Атмосфера безупречной чистоты поощряет perfection, якобы. Тут логика может быть похожей — раз автор мирится с imperfection в пробелах, смирится и с «так сойдёт» в алгоритмах/архитектуре/whatever.
наверное именно поэтому finder в одной из версий mac os вытирал исходные файлы при перемещении на флэшку, даже если перемещение не удалось, т.к. на флэшке недостаточно места
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, licedey, Вы писали:
P>>Здравствуйте, licedey, Вы писали: P>>кстати "spacing межде строк" это плохо или хорошо? L>Это ниочем. Повод дать разгоняющего пендаля, отбрить кандидата, докопаться к коду.
Это о чем-то. Почитай "Clean code", там это освещается в самом начале.
Здравствуйте, binnom, Вы писали:
B>Это о чем-то. Почитай "Clean code", там это освещается в самом начале.
Ты вот думаешь я за 15 лет в IT не знал про эту книгу или пишу в одну строчку?
Пробелы и прочая мелочь — это рай для ревьюеров, которым надо создать ИБД для тех кто выше, или пнуть тех кто ниже.
???>Эти причины что они озвучили не копи-паст, а тщательный поиск к чему придраться. Мне сразу вспоминается один случай, когда придрались к тому, что я сделал комменты для метода, но потом метод модифицировал изменив кол-во или тип входных параметров, а комменты поправить забыл. И это было преподнесено как просто полнейший пипец!
Ну это кстати действительно пипец. Неактуальные комменты хуже их отсутствия, ибо могут вводить в заблуждение.
Я вот чего не понял — ты же знал, что твой код будут рассматривать под микроскопом. Неужели было трудно проверить перед отправкой? Я ещё понимаю, когда такие косяки бывают в текущей работе — там да, то ли руки не дошли, то ли ещё что-то, но подразумевается, что перед кодфризом всё будет ещё раз перепроверено и исправлено. А вот решение тестового задания — это уже законченый проект, и там не должно быть подобного. Внимание к деталям — оооочень важная черта разработчиков, и к сожалению, очень часто отсутствующая (каюсь, я и сам грешен, более того, я ещё со школы таким был — мог правильно написать ход решения сложнейшей задачи, но в процессе умудриться "потерять" какой-нить минус у переменной ).
P.S. Сам никогда тестовых заданий не выполнял из принципа, и никогда не просил ни одного кандидата написать чего-то, даже отдалённо напоминающего реальный код в процессе интервью.
Здравствуйте, koandrew, Вы писали:
K>Я вот чего не понял — ты же знал, что твой код будут рассматривать под микроскопом. Неужели было трудно проверить перед отправкой? Я ещё понимаю, когда такие косяки бывают в текущей работе — там да, то ли руки не дошли, то ли ещё что-то, но подразумевается, что перед кодфризом всё будет ещё раз перепроверено и исправлено. А вот решение тестового задания — это уже законченый проект, и там не должно быть подобного. Внимание к деталям — оооочень важная черта разработчиков, и к сожалению, очень часто отсутствующая (каюсь, я и сам грешен, более того, я ещё со школы таким был — мог правильно написать ход решения сложнейшей задачи, но в процессе умудриться "потерять" какой-нить минус у переменной ).
Тут такая фишка... Чем больше внимания Вы уделяете деталям, тем меньше внимания остается на стратегию. Поэтому программист с вниманием к деталям за день напишет отличную реализацию алгоритма сортировки, проверяющую все граничные условия, а программист с вниманием к стратегии за 15 минут разберется, как приспособить для этих целей существуюую и давно проверенную реализацию из какой-нибудь библиотеки. Поэтому тут надо очень аккуратно; в идеале "внимание к деталям" надо уметь включать и выключать в зависимости от ситуации.
Кстати, если в описании вакансии кто-то указывает attention to detail, то это обычно означает, что нужен человек, который не будет соваться в принятие решений, а будет копать, куда скажут; и с точки зрения саморазвития такие места лучше обходить.
Здравствуйте, bazis1, Вы писали:
B>Кстати, если в описании вакансии кто-то указывает attention to detail, то это обычно означает, что нужен человек, который не будет соваться в принятие решений, а будет копать, куда скажут; и с точки зрения саморазвития такие места лучше обходить.
Мой опыт свидетельствует об обратном. Такие товарищи бесценны на этапе планирования, т.к. сразу смогут указать на какие-то мелочи, которые потом окажутся совсем не мелочами. А вот как раз копателям оно не нужно от слова "совсем" — им достаточно просто исполнять инструкции.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, bazis1, Вы писали:
B>>Кстати, если в описании вакансии кто-то указывает attention to detail, то это обычно означает, что нужен человек, который не будет соваться в принятие решений, а будет копать, куда скажут; и с точки зрения саморазвития такие места лучше обходить. K>Мой опыт свидетельствует об обратном. Такие товарищи бесценны на этапе планирования, т.к. сразу смогут указать на какие-то мелочи, которые потом окажутся совсем не мелочами. А вот как раз копателям оно не нужно от слова "совсем" — им достаточно просто исполнять инструкции.
Тогда мы говорим о слегка разных вещах. ИМХО, то, о чем говорите Вы — это знание предметной области. Когда еще на этапе проектирования человек знает, где будут грабли и как их обойти. А attention to detail — это, по-моему, как раз умение замечать невооруженным взглядом детали, которые обычно отлавливаются тестами или отладчиком.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
Опять ты ищешь проблемы в других, когда надо искать в себе
Здравствуйте, bazis1, Вы писали:
B>Тогда мы говорим о слегка разных вещах. ИМХО, то, о чем говорите Вы — это знание предметной области.
Необязательно. Более того, на моей текущей работе найти человека "со стороны", который бы знал предметную область, почти невозможно.
B>Когда еще на этапе проектирования человек знает, где будут грабли и как их обойти. А attention to detail — это, по-моему, как раз умение замечать невооруженным взглядом детали, которые обычно отлавливаются тестами или отладчиком.
Нет, скорее я имею в виду, когда человек на этапе обсуждения дизайна сможет указать на какие-то косяки, о которых часто забывают или даже сознательно их игнорируют как "такого не может быть потому, что этого не может быть". Такие веши, как граничные условия, сетевые задержки, юзабилити гуя и т.п.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Покажи задание и свою работу. Выглядит так, как будто товарищи догадались, как ты о них думаешь и решили в ответ подкинуть дров в топку.
Часто бывают шутники, каждая строчка кода содержит юмора и троллинга на поколение вперёд. Когда шутник нарывается на другого такого шутника, встречается всякое.
Здравствуйте, koandrew, Вы писали:
B>>Тогда мы говорим о слегка разных вещах. ИМХО, то, о чем говорите Вы — это знание предметной области. K>Необязательно. Более того, на моей текущей работе найти человека "со стороны", который бы знал предметную область, почти невозможно.
Не знаю, наверное, зависит от предметной области.
K>Нет, скорее я имею в виду, когда человек на этапе обсуждения дизайна сможет указать на какие-то косяки, о которых часто забывают или даже сознательно их игнорируют как "такого не может быть потому, что этого не может быть". Такие веши, как граничные условия, сетевые задержки, юзабилити гуя и т.п.
Хороший вопрос. На практике я часто встречался с другой крайностью — когда люди начинают глубоко копать в детали, граничные условия, задержки и т.п. В итоге идеально дизайнят один компонент из многих, после чего время/интерес кончаются и остальное делается на "лишь бы успеть". В итоге получается грубо говоря система с идеально оптимизированной работой с сетью, жутко тормозящая на дисковой подсистеме, потому что о ней подумать времени уже не было. Или система, где каждый модуль по отдельности близок к идеалу, а все вместе тормозит, так как на реальных задачах модули используются совсем не так, как планировалось при детальном обсуждении.
В одной из фирм, которой я работал, внимание к оформлению(пробелы, запятые) было очень большим. Пинали за это больно и упорно.
Вывод они сделали соответствующий: "опытный программист, а оформлять код единообразно так и не научился". Дальше больше — "невнимателен к деталям". Сложно сказать насколько они идиоты.
Здравствуйте, bazis1, Вы писали:
B>Не знаю, наверное, зависит от предметной области.
Именно. И как только проекты выходят за рамки "yet another опердень" или "интернет-магазин", то вероятность найти человека с domain knowledge начинает быстро стремиться к нулю.
B>Хороший вопрос. На практике я часто встречался с другой крайностью — когда люди начинают глубоко копать в детали, граничные условия, задержки и т.п. В итоге идеально дизайнят один компонент из многих, после чего время/интерес кончаются и остальное делается на "лишь бы успеть". В итоге получается грубо говоря система с идеально оптимизированной работой с сетью, жутко тормозящая на дисковой подсистеме, потому что о ней подумать времени уже не было. Или система, где каждый модуль по отдельности близок к идеалу, а все вместе тормозит, так как на реальных задачах модули используются совсем не так, как планировалось при детальном обсуждении.
Если такое случается, то это косяк ПМа/архитекта, и разработчик тут обычно виноват лишь косвенно.
Здравствуйте, bazis1, Вы писали:
B>Кстати, если в описании вакансии кто-то указывает attention to detail, то это обычно означает, что нужен человек, который не будет соваться в принятие решений, а будет копать, куда скажут; и с точки зрения саморазвития такие места лучше обходить.
Интересно. Я наблюдал такие команды, действительно в описании вакансии стоит "внимание к деталям" и разные в общем-то правильные хотелки как структуры данных, например. Но почему-то стагнация и гниение, активное противодействие экспериментам и извращениям (в хорошем смысле). Например, я практически шантажом втолкнул паттерн Visitor в один проект. Давние обиды на меня за использование async io в приёмнике котировок "сложно". Люди хотят как по старинке, плодить потоки пачками.
B>Хороший вопрос. На практике я часто встречался с другой крайностью — когда люди начинают глубоко копать в детали, граничные условия, задержки и т.п. В итоге идеально дизайнят один компонент из многих, после чего время/интерес кончаются и остальное делается на "лишь бы успеть". В итоге получается грубо говоря система с идеально оптимизированной работой с сетью, жутко тормозящая на дисковой подсистеме, потому что о ней подумать времени уже не было. Или система, где каждый модуль по отдельности близок к идеалу, а все вместе тормозит, так как на реальных задачах модули используются совсем не так, как планировалось при детальном обсуждении.
Здравствуйте, Философ, Вы писали:
CE>>А почему сразу «идиоты»? Вон, Джобс станки на своём заводе красил в идеально белый цвет. Зачем? Атмосфера безупречной чистоты поощряет perfection, якобы. Тут логика может быть похожей — раз автор мирится с imperfection в пробелах, смирится и с «так сойдёт» в алгоритмах/архитектуре/whatever.
Ф>наверное именно поэтому finder в одной из версий mac os вытирал исходные файлы при перемещении на флэшку, даже если перемещение не удалось, т.к. на флэшке недостаточно места
А что за версия? MacOS X и позже? (Не знаю, когда они начали поддерживать флешки).
Здравствуйте, 463C21E2, Вы писали:
Ф>>наверное именно поэтому finder в одной из версий mac os вытирал исходные файлы при перемещении на флэшку, даже если перемещение не удалось, т.к. на флэшке недостаточно места
CE>А что за версия? MacOS X и позже? (Не знаю, когда они начали поддерживать флешки).
Я тоже не знаю — это от моих знакомых маководов пришло.
Всё сказанное выше — личное мнение, если не указано обратное.
).
