Сообщение Re: Рассказ о Крутом Манагере от 22.01.2015 5:21
Изменено 22.01.2015 6:20 netch80
стиль
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Позвольте мне расширить аналогию.
ЮЛ>Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly.
ЮЛ>Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути.
ЮЛ>Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
ЮЛ>Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
ЮЛ>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
ЮЛ>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?
ЮЛ>Позвольте мне расширить аналогию.
ЮЛ>Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly.
ЮЛ>Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути.
ЮЛ>Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
ЮЛ>Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
ЮЛ>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
ЮЛ>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?
Re: Рассказ о Крутом Манагере
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Позвольте мне расширить аналогию.
ЮЛ>Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly.
ЮЛ>Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути. Это действительно так, или Вы преувеличили?
ЮЛ>Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
ЮЛ>Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
ЮЛ>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ мест не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
ЮЛ>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?
ЮЛ>Позвольте мне расширить аналогию.
ЮЛ>Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly.
ЮЛ>Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути. Это действительно так, или Вы преувеличили?
ЮЛ>Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
ЮЛ>Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
ЮЛ>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ мест не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
ЮЛ>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?