Comments 15
| Сколько человек не использует IDE? О боже, как приятно. Я тоже не пользуюсь IDE
Извините, но facepalm.
Извините, но facepalm.
Почему фейспалм? Я вот тоже IDE при кодинге на Python крайне редко использую, считаю это нормальным.
Да потому что мы — люди. А у каждого человека есть кошелёк Миллера. 4brain.ru/memory/_sem-pljus-minus-dva.php
И когда при очередном рефакторинге в авральном режиме с мутной головой и уставшим телом сложного участка кода без IDE забываешь поменять маленький кусочек (а блокнот тебе не высветит предупреждение, что ты, возможно, что-то забыл или не так делаешь), то через месяц, когда всё уже забудешь этот кусочек взорвётся на продакшене. И хорошо если потом так же с блокнотом быстро найдёшь проблему, что, оказывается, не тот аргумент берёшь, который надо, например, или запарываешь данные за пределами функции, потому что где-то что-то переименовал, а где-то не доглядел.
Вы считаете, что ездить на работу на лошади в большом городе (при наличии метро и личного авто) — нормально и практично? :)
Не думаете, что слишком самонадеянно и безответственно писать сложный софт, условно, для атомных станций и гордиться, что не пользуешься ни IDE, ни статическими анализаторами?
И когда при очередном рефакторинге в авральном режиме с мутной головой и уставшим телом сложного участка кода без IDE забываешь поменять маленький кусочек (а блокнот тебе не высветит предупреждение, что ты, возможно, что-то забыл или не так делаешь), то через месяц, когда всё уже забудешь этот кусочек взорвётся на продакшене. И хорошо если потом так же с блокнотом быстро найдёшь проблему, что, оказывается, не тот аргумент берёшь, который надо, например, или запарываешь данные за пределами функции, потому что где-то что-то переименовал, а где-то не доглядел.
Вы считаете, что ездить на работу на лошади в большом городе (при наличии метро и личного авто) — нормально и практично? :)
Не думаете, что слишком самонадеянно и безответственно писать сложный софт, условно, для атомных станций и гордиться, что не пользуешься ни IDE, ни статическими анализаторами?
Даже в авральном режиме на кусок бизнес-логики пишется тест, который его проверяет, а простые ошибки у меня и синтаксический проверяльщик в саблайме/виме найдет. Плюс, при отладке удаленного кода зачастую куда проще зайти по ssh и поправить в виме строчку, чем искать, где в этой IDE плагин для удаленной отладки, что он требует и не платный ли.
Тут нет никаких понтов и гордости, просто IDE не должна лишнего думать за программиста, парсить код глазами куда полезнее. Особенно когда, например, углубляешься в код сторонней кривой библиотеки и весь код, причем с тормозами, покрывается унылыми подчеркиваниями и предупреждениями от flake8/pep8, когда это абсолютно бессмысленно и ни разу не помогает.
Я ни в коем случае не говорю, что IDE не нужна, просто надо разумно подходить к вопросу, а не становиться рабом средств разработки.
Тут нет никаких понтов и гордости, просто IDE не должна лишнего думать за программиста, парсить код глазами куда полезнее. Особенно когда, например, углубляешься в код сторонней кривой библиотеки и весь код, причем с тормозами, покрывается унылыми подчеркиваниями и предупреждениями от flake8/pep8, когда это абсолютно бессмысленно и ни разу не помогает.
Я ни в коем случае не говорю, что IDE не нужна, просто надо разумно подходить к вопросу, а не становиться рабом средств разработки.
А уж сколько незабываемых впечатлений можно получить, когда в один прекрасный день IDE не справится с динамической природой Python, и что-то пропустит при рефакторинге. Авральном таком рефакторинге :) А потом этот авральный код на Python, условно, для атомной станции, в продакшн…
Человек, который не использует IDE, с большой долей вероятностью не понимает что такое ООП, т.к. основная сила IDE основана на ОО подходе к разработке.
Соответственно, если человек не понимает что такое ООП, то там появляются излишние сущности, большие уродливые контроллеры и т.д.
Соответственно, если человек не понимает что такое ООП, то там появляются излишние сущности, большие уродливые контроллеры и т.д.
Наверное, со мной что-то не так, но я не вижу вашей смелой параллели между IDE и ООП. Понимание ОО-подхода не зависит от инструментов разработки, а основано на умении проводить связи между объектами реального и виртуального мира. Плюс, IDE за программиста «Книгу Четырех» не прочитает. А если она за него будет какие-то паттерны применять автоматически — лесом такую IDE.
IDE в сравнении с текстовыми редакторами предоставляет следующие возможности:
— предоставляет поиск класса по имени
— подсказывает интерфейс класса
— говорит о том, к какому классу в иерархии относится вызванный метод
— подсказывает, когда в аргумент подставляется объект не того типа
— показывает иерархию классов по базовому классу
т.е. если вы не чувствуете надобность в этих возможностях, то скорее всего вы не проектируете систему в соответствии с ООП. Пока что мой опыт показывает, что так оно и есть. Сколько людей любителей текстовых редакторов я видел, все они писали либо простые вещи, либо процедурный(с элементами ООП) не поддерживаемый код из-за его сложности.
Но однако, то что человек использует IDE не говорит что он не делает подобного.
— предоставляет поиск класса по имени
— подсказывает интерфейс класса
— говорит о том, к какому классу в иерархии относится вызванный метод
— подсказывает, когда в аргумент подставляется объект не того типа
— показывает иерархию классов по базовому классу
т.е. если вы не чувствуете надобность в этих возможностях, то скорее всего вы не проектируете систему в соответствии с ООП. Пока что мой опыт показывает, что так оно и есть. Сколько людей любителей текстовых редакторов я видел, все они писали либо простые вещи, либо процедурный(с элементами ООП) не поддерживаемый код из-за его сложности.
Но однако, то что человек использует IDE не говорит что он не делает подобного.
Если программист глазами не видит и мозгами не помнит иерархию классов в своем приложении (или хотя бы в части, над которой он работает) — то с ним что-то не так. IDE тут ни разу ни при чем. Судя по примерам, которые вы приводите, и выводам, которые вы делаете, один из ваших основных языков — Java, в которой без классов действительно туго, но есть другие хорошие не-ООП подходы, посмотрите на тот же Erlang или Haskell. И код на них не неподдерживаемый, просто человеку, яростно придерживающемуся одной парадигмы, сложно переключить мозг на другую, вот и все.
P.S. Если уж человек в IDE пишет адский говнокод, то в текстовом редакторе, скорее всего, и подавно. А вот вариант наоборот практически не встречается.
P.S. Если уж человек в IDE пишет адский говнокод, то в текстовом редакторе, скорее всего, и подавно. А вот вариант наоборот практически не встречается.
| Если программист глазами не видит и мозгами не помнит иерархию классов в своем приложении (или хотя бы в части, над которой он работает) — то с ним что-то не так.
Тау думает только плохой программист. Хороший программист не должен помнить всё. В идеале, интерфейсы ему должны быстро всё сами рассказать. В идеале, любой программист команды должен очень быстро разобраться в работе приложения по интерфейсам.
| но есть другие хорошие не-ООП подходы, посмотрите на тот же Erlang или Haskell.
Пока что я писал лишь о ООП парадигме. Языки которые заточены под другое я не рассматривал пристально и каких либо выводов про работу с ними я делать не могу.
Тау думает только плохой программист. Хороший программист не должен помнить всё. В идеале, интерфейсы ему должны быстро всё сами рассказать. В идеале, любой программист команды должен очень быстро разобраться в работе приложения по интерфейсам.
| но есть другие хорошие не-ООП подходы, посмотрите на тот же Erlang или Haskell.
Пока что я писал лишь о ООП парадигме. Языки которые заточены под другое я не рассматривал пристально и каких либо выводов про работу с ними я делать не могу.
Первого докладчика зовут Первухин.
Контест уже кончился. Больше уже ничего не принимают
Sign up to leave a comment.
Python Meetup: апрельская встреча