Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
1) В репозитории отсутствует .gitignore !
2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться.
А откуда такие мысли?
А если знал, то зачем делал? Мазохист?
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Карма — нашефсё.
...
Мужик не выдержал, взмолился: -Господи, сколько можно!?
А с неба в ответ: — Ну не нравишься ты мне мужик. Не нравишься...
ЗЫ. И где вы такие компании находите...
_____________________
С уважением,
Stanislav V. Zudin
Ни в кармы ни в господей я не верю, а вот в тотальный контроль определенных организаций — очень даже.
Похоже где-то их поимели, вот они и раздосадованы.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
???>Ни в кармы ни в господей я не верю, а вот в тотальный контроль определенных организаций — очень даже.
???>Похоже где-то их поимели, вот они и раздосадованы.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Скажи им спасибо, что еще причину отказа детально озвучили. Хотя на их месте я бы этого не делал, с такими компетентными комментами.
Если это крупный бодишоп, то вместе с тобой тестовых заданий могло быть отправлено от 2-х до бесконечности. И каждого отбривать, рука устанет. Вот и копипастят универсальный ответ.
Можно еще про пробелы вместо табов, внутренние классы или 2! класса в одной файле (как вариант enum и class), lack of comments — вообще простор для воображения. Можно сказать, что код должен быть самодокументируемым, а можно сказать, что не каждый метод откомментен. Ой, да столько еще до--к есть у и без того уставших ревьюров, что угодить всем — значит расходовть энергию впустую. Поэтому забей и райдуйся, что с такими задротами не придется сидеть 40+ часов в неделю.
Справделивости ради, на одном из последних проектов, было двух-этапное codereview. Сначала все члены команды докапывались, а после сам TL. За каждый пробел и запятую.
И за джитигнор в том чилсе, и за spacing межде строк. Чем больше компания — тем больше бюрократия, и на такие вещи там пристально смотрят. А сам TL, у которого главный приоритет — поскорей отрапортовать "мы работаем над этим", может и не вникать в структуру проекта, из-за орг. вопросов. Пробелы, форматирование, эксепшены, строки в логах и строки в UI, 1-2px пропущено в отступах меток, имена идентификаторов...ну у него видимо целый список есть "приоритетных" комментариев, когда нужно кого то пнуть.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Это в России вакансия или в США или еще где?
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, ???, Вы писали:
_>???>Ни в кармы ни в господей я не верю, а вот в тотальный контроль определенных организаций — очень даже. _>???>Похоже где-то их поимели, вот они и раздосадованы.
_>Image: I0QPEKc.gif
Твоя картинка демонстрирует классический случай смещенной активности. К обсуждаемой теме это не имеет отношения
L>Скажи им спасибо, что еще причину отказа детально озвучили. Хотя на их месте я бы этого не делал, с такими компетентными комментами. L>Если это крупный бодишоп, то вместе с тобой тестовых заданий могло быть отправлено от 2-х до бесконечности. И каждого отбривать, рука устанет. Вот и копипастят универсальный ответ.
Нет, это не бадишоп. Это одна шарага из европы сидят на газо-невтянных заказах.
Эти причины что они озвучили не копи-паст, а тщательный поиск к чему придраться. Мне сразу вспоминается один случай, когда придрались к тому, что я сделал комменты для метода, но потом метод модифицировал изменив кол-во или тип входных параметров, а комменты поправить забыл. И это было преподнесено как просто полнейший пипец!
Настораживает уже заранее предугадываемое поведение.
Здравствуйте, licedey, Вы писали:
L>Справделивости ради, на одном из последних проектов, было двух-этапное codereview. Сначала все члены команды докапывались, а после сам TL. За каждый пробел и запятую. L>И за джитигнор в том чилсе, и за spacing межде строк. Чем больше компания — тем больше бюрократия, и на такие вещи там пристально смотрят. А сам TL, у которого главный приоритет — поскорей отрапортовать "мы работаем над этим", может и не вникать в структуру проекта, из-за орг. вопросов. Пробелы, форматирование, эксепшены, строки в логах и строки в UI, 1-2px пропущено в отступах меток, имена идентификаторов...ну у него видимо целый список есть "приоритетных" комментариев, когда нужно кого то пнуть.
Ну у меня в MS так было. Я после пары итераций и хренового ревью просто забил и стал делать как все — вместо того, чтобы исправить проблему и пройти 9 кругов ада, переименовывая переменные, чтобы всем угодить, пишешь вежливую отписку, почему при всем желании мы ничего сделать не можем, и все довольны. Меньше работы ревьюерам, меньше работы тестерам, ты — герой дня. Люди потом сильно удивлялись, когда я после года побежал оттуда без оглядки — думали, что я наконец "влился в команду".
???>Нет, это не бадишоп. Это одна шарага из европы сидят на газо-невтянных заказах.
???>Эти причины что они озвучили не копи-паст, а тщательный поиск к чему придраться. Мне сразу вспоминается один случай, когда придрались к тому, что я сделал комменты для метода, но потом метод модифицировал изменив кол-во или тип входных параметров, а комменты поправить забыл. И это было преподнесено как просто полнейший пипец!
???>Настораживает уже заранее предугадываемое поведение.
Помоему ты принимаешь все близко к сердцу. У шараги свои причины тебя не брать. Если дело дошло то тестового, то а) они тянули время, набивая базу кандидатов б) менее приоритетно, хотели посмотреть какие крутые фичи ты им покажешь.
У меня был опыт решения задачи в google doc'ах для 2-х компаний. 1-ая долго думала и отказала, потому что я замялся на JS-коде, хотя специализация backend. Вторые, сами на меня вышли, потом прошел все этапы интервью, потом в доксах начал писать код с ошибками. Взяли с руками все равно Лидом. Потом ждали еще 1.5 месяца, пока я приму окончательное решение по офферу. Не надо по одной компании делать вывод — что ты плохой разраб. Скорее всего им выгодней было взять другого кандидата, условного Васю.
Формула проста — зарлата+опыт+(опционально авторитет). Видимо по этим показателям, Вася оказался им выгоднее.
Например если бы мыщъгх,VladD2 или любой старожил из местных, не оставили .gitignore или не добавили лишних спейсов в твоем задании — они бы им не отказали, поверь . Их бы за одно имя взяли, без собеседования.
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Тогда уж и задание выкладывай. Может быть тебя всего две вещи просили сделать
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Я тоже пинаю своих писателей за запятые без пробелов и за пустые строки от балды. Если в проекте используется определенный стиль кодирования, то ему надо следовать. Это совсем несложно.
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Рунглиш детектед
Второе нарушение весьма серьезное: если ты форматируешь тяп-ляп, то и логику, скорей всего, пишешь так же. А людям с тонкой душевной организацией потом придётся с этим жить.
Здравствуйте, Lazy Bear, Вы писали:
LB>???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
LB>Я тоже пинаю своих писателей за запятые без пробелов и за пустые строки от балды. Если в проекте используется определенный стиль кодирования, то ему надо следовать. Это совсем несложно.
Для этого есть автоматические средства пинания, раз настроил и радуешься.
Здравствуйте, Lazy Bear, Вы писали:
LB>Я тоже пинаю своих писателей за запятые без пробелов и за пустые строки от балды. Если в проекте используется определенный стиль кодирования, то ему надо следовать. Это совсем несложно.
Одно дело пинать на ревью, другое — не принять из-за этого на работу.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
Да что там "попадались". Я сам был таким. Ну смотрите — у вас работу по проекту не разгрести,
тут присылают ещё левого кода тысяч пять строк написаного в марсианской логике (показывая крутизну автора),
надо код БЫСТРО изучить и выдать осмысленные комментарии.
Что делаешь первым делом — составляешь письмо-ответ на несколько абзацев, исходя из coding guidelines,
и готово — формально работу провёл, можно этот таск списать как выполненный. Деньги-то платят только с реальных проектов.
Здравствуйте, licedey, Вы писали:
L>Здравствуйте, ???, Вы писали:
L>???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
L>???>1) В репозитории отсутствует .gitignore ! L>???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
L>Скажи им спасибо, что еще причину отказа детально озвучили. Хотя на их месте я бы этого не делал, с такими компетентными комментами. L>Если это крупный бодишоп, то вместе с тобой тестовых заданий могло быть отправлено от 2-х до бесконечности. И каждого отбривать, рука устанет. Вот и копипастят универсальный ответ. L>Можно еще про пробелы вместо табов, внутренние классы или 2! класса в одной файле (как вариант enum и class), lack of comments — вообще простор для воображения. Можно сказать, что код должен быть самодокументируемым, а можно сказать, что не каждый метод откомментен. Ой, да столько еще до--к есть у и без того уставших ревьюров, что угодить всем — значит расходовть энергию впустую. Поэтому забей и райдуйся, что с такими задротами не придется сидеть 40+ часов в неделю.
L>Справделивости ради, на одном из последних проектов, было двух-этапное codereview. Сначала все члены команды докапывались, а после сам TL. За каждый пробел и запятую. L>И за джитигнор в том чилсе, и за spacing межде строк. Чем больше компания — тем больше бюрократия, и на такие вещи там пристально смотрят. А сам TL, у которого главный приоритет — поскорей отрапортовать "мы работаем над этим", может и не вникать в структуру проекта, из-за орг. вопросов. Пробелы, форматирование, эксепшены, строки в логах и строки в UI, 1-2px пропущено в отступах меток, имена идентификаторов...ну у него видимо целый список есть "приоритетных" комментариев, когда нужно кого то пнуть.
кстати "spacing межде строк" это плохо или хорошо?
Здравствуйте, 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 и позже? (Не знаю, когда они начали поддерживать флешки).
Я тоже не знаю — это от моих знакомых маководов пришло.
Всё сказанное выше — личное мнение, если не указано обратное.
???>Ради интереса выполнил тестовое задание одной компании, изначально зная, что они будут искать к чему придраться. И вот наконец получил отказ с причинами:
???>1) В репозитории отсутствует .gitignore !
???>2) Llack of attention to detail on spacing and layout (sometimes two lines between methods, sometimes one)
).
