хм.. позволю себе несколько высказываний по поводу 'халиваров на митингах'.
Все мы технари, и все любим решать задачи и делать это красиво и "по пацански". Но есть одно замечание: Нам дают 'поиграться' всякими там штучками на коммерческих проектах (и как правило платят за это деньги). И по этому неплохо было бы соизмерять свои интересы и потребности проекта. Ну пару примеров. В команде 3 человека Ты и пару Новичков. Вот ты начинаешь применять черную магию, и тем самым вводишь в ступор своих коллег (и делаешь им не хилый комплекс неполноценности :) ). Вывод: надо писать попроще пока те двое не дорастут до твоего уровня. Или другой пример: Проект нужен 'на вчера' и вдруг кто то хочет заюзать новую, не отработанную штуковину. Как ты думаешь, стоит ли привносить неопределенность в этом, и без того не легком, случае?
Холивары очень хороши для убивания времени. Если хочется внедрить что то новенькое, то может стоит: - делать это постепенно. Дабы не травмировать коллег и иметь возможность откатится, если что то пойдет не так. - постараться получать как можно больше обратной связи. Например регулярные code review новых экспериментов - и коллеги привыкают к новым практикам, и тебе не дают згинуть в неизвестном дремучем болоте.
Автор предлагает интересный подход. Но также, он предлагает использование дикого количества статики (статических методов) для повышения удобочитаемости. После одного проекта я люто ненавижу статические методы, потому как модифицировать такой код на порядок сложнее чем нормальный.
Также автор часто разделяет код на клиентский и библиотечный. Причем делает оговорки, мол. мы усложняем библиотечный код. но при этом получаем более читаемый клиентский. Вот тут то я вижу практические трудности: во многих приложениях довольно сложно сделать такое разделение. И во многих случаях довольно сложно убедить коллег усложнить одну часть, чтобы сделать красивее другую.
IMHO: интересный подход, но пробовать надо очень осторожно. А также, не забывать про класические способы повышения удобочитаемости: например, небольшие методы с адекватными именами, разделение функциональности по классам, принцип наименьшей неожиданности и т.д.
Да, правильный комментарий про холивары, спасибо. Просто у нас очень классный проект и нам удаётся много классных штук делать и есть время на развитие. Например пишем собственный фреймворк для автоматического интеграционного тестирования. Т.е. есть время поболоваться в том числе и с POC решениями. К тому же я далеко не самый крутой на проекте, так что и устраиваю :) Но я так же понимаю, что это должно вести к положительным моментом в проекте, хороший результат проекта, мне тоже на руку, поэтому делаю это не фанатично. Например некоторые вещи сейчас рефакторим в immutable стиль. И это должно положительно сказаться на коде. У меня нет такого предубеждения насчёт static методов. Наоборот, я их люблю :) жаль только именовать нельзя при импорте, а то очень часто могут вводить в заблуждение. Насчёт разделения, у нас с этим ни на одном проекте не было проблем, все только за были. Библиотечный код обычно абстрагирован от всяких специфик типа IO, DB и т.п. поэтому его можно очень хорошо от unit тестить. А мы unit test'ы очень любим :) Я вот этот подход активно использую как раз при написании тестов, так как именно тогда может понадобиться, что-то вроде new String[] { "test1", "test2" } и array ( "test1", "test2" ) позволяет сделать код теста более компактным и лучшим для восприятия. Так как зачастую твой тест будет смотреть другой человек, которые его сломал :) И в целом тесты могут использоваться как дополнительная документация. А так да, надо осторожно и не увлекаться, код в первую очередь должен быть понятным, и размер кода ничего не говорит о понятности. Так как в таком стиле можно своять одну строчку кода из многочисленных вызовов методов, что потом полдня курить будешь.
Да, на меня оказалось, теперь жажду функционального программирования и устраиваю холивары на викли митингах :)
ОтветитьУдалитьхм.. позволю себе несколько высказываний по поводу 'халиваров на митингах'.
ОтветитьУдалитьВсе мы технари, и все любим решать задачи и делать это красиво и "по пацански". Но есть одно замечание: Нам дают 'поиграться' всякими там штучками на коммерческих проектах (и как правило платят за это деньги). И по этому неплохо было бы соизмерять свои интересы и потребности проекта. Ну пару примеров. В команде 3 человека Ты и пару Новичков. Вот ты начинаешь применять черную магию, и тем самым вводишь в ступор своих коллег (и делаешь им не хилый комплекс неполноценности :) ). Вывод: надо писать попроще пока те двое не дорастут до твоего уровня.
Или другой пример: Проект нужен 'на вчера' и вдруг кто то хочет заюзать новую, не отработанную штуковину. Как ты думаешь, стоит ли привносить неопределенность в этом, и без того не легком, случае?
Холивары очень хороши для убивания времени. Если хочется внедрить что то новенькое, то может стоит:
- делать это постепенно. Дабы не травмировать коллег и иметь возможность откатится, если что то пойдет не так.
- постараться получать как можно больше обратной связи. Например регулярные code review новых экспериментов - и коллеги привыкают к новым практикам, и тебе не дают згинуть в неизвестном дремучем болоте.
И еще, по поводу самой статьи.
ОтветитьУдалитьАвтор предлагает интересный подход. Но также, он предлагает использование дикого количества статики (статических методов) для повышения удобочитаемости. После одного проекта я люто ненавижу статические методы, потому как модифицировать такой код на порядок сложнее чем нормальный.
Также автор часто разделяет код на клиентский и библиотечный. Причем делает оговорки, мол. мы усложняем библиотечный код. но при этом получаем более читаемый клиентский. Вот тут то я вижу практические трудности: во многих приложениях довольно сложно сделать такое разделение. И во многих случаях довольно сложно убедить коллег усложнить одну часть, чтобы сделать красивее другую.
IMHO: интересный подход, но пробовать надо очень осторожно. А также, не забывать про класические способы повышения удобочитаемости: например, небольшие методы с адекватными именами, разделение функциональности по классам, принцип наименьшей неожиданности и т.д.
Да, правильный комментарий про холивары, спасибо. Просто у нас очень классный проект и нам удаётся много классных штук делать и есть время на развитие. Например пишем собственный фреймворк для автоматического интеграционного тестирования. Т.е. есть время поболоваться в том числе и с POC решениями. К тому же я далеко не самый крутой на проекте, так что и устраиваю :) Но я так же понимаю, что это должно вести к положительным моментом в проекте, хороший результат проекта, мне тоже на руку, поэтому делаю это не фанатично. Например некоторые вещи сейчас рефакторим в immutable стиль. И это должно положительно сказаться на коде.
ОтветитьУдалитьУ меня нет такого предубеждения насчёт static методов. Наоборот, я их люблю :) жаль только именовать нельзя при импорте, а то очень часто могут вводить в заблуждение. Насчёт разделения, у нас с этим ни на одном проекте не было проблем, все только за были. Библиотечный код обычно абстрагирован от всяких специфик типа IO, DB и т.п. поэтому его можно очень хорошо от unit тестить. А мы unit test'ы очень любим :) Я вот этот подход активно использую как раз при написании тестов, так как именно тогда может понадобиться, что-то вроде
new String[] { "test1", "test2" }
и
array ( "test1", "test2" )
позволяет сделать код теста более компактным и лучшим для восприятия. Так как зачастую твой тест будет смотреть другой человек, которые его сломал :) И в целом тесты могут использоваться как дополнительная документация.
А так да, надо осторожно и не увлекаться, код в первую очередь должен быть понятным, и размер кода ничего не говорит о понятности. Так как в таком стиле можно своять одну строчку кода из многочисленных вызовов методов, что потом полдня курить будешь.
Угу, я тоже про тесты вспомнил (точнее про мучительные и некрасивые методы создания конфигурации) :)
ОтветитьУдалить