Pull to refresh
0
0
Максим Осипов @codemax

Java Developer

Send message
Если при выборе языка/платформы для очередного проекта вы на первое место уровень некоего «фана» (ассоциации с этим словом в контексте JavaScript лично у меня не самые позитивные), то я даже и не знаю, что и сказать.

И все-таки, что вы подразумеваете под этим словом?
Одно дело на логотипе шрифт поменять и совсем другое — весь текст перевести на него. В первом случае дискомфорт должен быть минимальным.
По одному комментарию с каждого — это насколько мы «впали в обсуждение»? И да, «обсуждалась» тут скорее не личность, а явление ;) Многим уже, к сожалению, знакомое. И здесь, и на том самом ЛОРе.
Скорее даже заядлый поехавший. Пара нормальных ответов и затем скатывание в истерику и брызганье слюной. И не только слюной, да. Даже для заядлых ЛОРовцев это не нормально.
Да и помимо «ответили» там еще куча разных факторов.
И вообще, там, на JavaScript Guide, на фоновой картинке слева код на PHP, а не на JS. Мой перфекционизм возмущен! :)
Человек, который хорошо знает JS, пойдет работать в контору, где ему хорошо заплатят за его знания и предложат интересные для него задачи. JQ там или не JQ — для действительно грамотного спеца это играет далеко не самую важную роль.

Нет во фреймворках ничего страшного. Даже в самописном — если там поддерживают чистоту и ясность кода. А вот как раз «макаки» так и будут рассуждать: если единственный изученный ими фреймворк отсутствует в описании вакансии, компания сразу отправляется в сад, да :)
На хрюшке, емнип, вообще никакого дотнета не предустановлено. Устанавливать все равно придется, даже второй. И вообще, на хрюшу все уже почти забили — а тут какая-никакая, а есть возможность софтину запустить без танцев с бубном.
Рабочие инструменты можно содержать в порядке… или нет. Да, это многое скажет о квалификации плотника. Но никто о состоянии инструментов «на полке» программиста здесь почему-то не говорит. Ярлыки навешиваются лишь за факт использования инструмента. Так что это уже не аналогичные ситуации. А если еще и вспомнить, что все аналогии лгут… :)

Точно так же сам факт использования Vim'а не делает никого ни «настоящим профи», ни «вымирающим видом». Настоящий профи использует свои инструменты для эффективного достижения качественного результата. Какими бы эти инструменты ни были. Капитанство, но тем не менее.
Пользуйтесь своим инструментом. И не нужно раздражаться. Вас никто не принуждает использовать IDE. Меня никто не заставляет использовать Vim. Альтернативы существуют, и это нормально, этому радоваться нужно. А не развешивать ярлыки направо и налево.
Попытка сделать любой вывод о квалификации по используемому инструменту выглядит весьма сомнительно.
Причем зачастую это мнение самих «ресурсов».
Возможно, это потому что c9.io не рождает для себя новый инстанс всего браузера, а работает в уже запущенном :)
Есть декомпозиция и модульность и что? Предлагаете каждого разработчика посадить в свой загончик с его «родными» модулями и остальных туда не пускать? Нет, конечно, нельзя так делать.

Декомпозиция и модульность не отменяет необходимости разобраться в новом чужом коде/модуле. Если детали реализации не нужны, хватит и документации. А если я хочу узнать, как это сделано (ищу причину дефекта, например), удобные средства навигации по коду + отладка помогут мне сделать это эффективнее. Ничего постыдного в этом не вижу.
Никто и не спорит, что делать рефакторинг следует тогда, когда полностью разобрался в окружающем коде и его проблемах (не на пустом же месте возникла идея рефакторинга). А иначе это и не рефакторинг, а беспорядочное движение сущностей в коде :)

Тем не менее, имея надежные автоматические средства, делать это удобнее и быстрее. Мне в этом помогает IDE, кому-то — vim с соответствующими плагинами и конфигом.

Мне лишь довольно странно читать от некоторых участников дискуссии комментарии вида: «если вы используете IDE, значит, вы либо в говнокоде по уши, либо разработчик хреновый, либо и то, и другое».
Если кейс с NPE не был увиден и предусмотрен разработчиком, то и теста на него не будет. Ни до написания кода, ни после. TDD и его вариации здесь не при чем.
Есть проекты и 10+, и чуть меньше, и с кодом там все нормально. Не идеально, есть к чему стремиться, но уж точно не говнокод и не полный аут. Но вот беда — кода много, много бизнес-логики и всего такого. И пишет его не один Вася, который вроде бы в состоянии всё запомнить (на самом деле нет), а целая команда из 10+ человек. И чтобы поработать в той части кода, где ты еще ни разу не был/недавно что-то существенно поменяли, очень хорошо помогают все эти плюшки IDE. Можно быстро окинуть взглядом общую структуру и после этого перейти к деталям. Возможно, что-то придется порефакторить — опять же IDE поможет не допустить глупых ошибок. (Тесты еще помогут, но это уже отдельный разговор, тесты не смогут заменить всё.)

И то, что вся структура кода не помещается у человека в голове, не говорит о том, что он недостаточно крут или что это — говнокод. Это всё очень странные попытки пристыдить тех, кто пользуется удобствами IDE.
И при чем тут тесты? Понимаете, если человек не увидел возможность использования null-значения и не сделал соответствующую проверку, то он и тест на это не написал бы, т.к. он не видит этого кейса. Тесты обычно пишут, чтобы в будущем не сломать заложенное при изначальной разработке поведение. Ну и пишут еще тест, когда NPE уже всплыло, чтобы больше такого не было.
Delphi на компьютер заказчика? Вот это поворот. Я даже представить себе не могу, зачем это может понадобиться. Помнится только, что в Borland C++ Builder по дефолту надо было набор либ с собой таскать, но выключалось это одной галкой в настройках компоновщика.

Я, конечно, давно не тыкал палочкой это вот всё, но… это какие-то неправильные рекомендации :)

Information

Rating
Does not participate
Location
Челябинск, Челябинская обл., Россия
Date of birth
Registered
Activity