Здравствуйте, denisko, Вы писали:

U>> И про паттерны, чистый код и рефакторинг если и слышал,
U>>то на практике не применяет уж точно. Его код — это дикие простыни без ясной структуры и логики. Не даром потом исправляем тонну багов.
D>Паттерны это один из стилей писать код, простыня другой. С дуру, накосячить можно, что в первом, что во втором случае. Если человек довольно хорошо пишет простыни и легко имеет их модифицировать, то на выходе код получится не хуже в плане устойчивости и быстродействия, чем с использованием паттерном. Единственное, что тут будут _последствия_. Модифицировать такой код без навыков простынеписательства, которые почти утеряны среди школоты, трудно и дорого. Если он готов с этим смириться, то придется писать в простынном стиле.

У меня на проекте местами простыни по 100кб. В строках уже давно не измеряю код — только десятками килобайт. Есть опыт его поддержки. Местами коду 10 и более лет.
Есть опыт поддержки кода и без простыней. В этом же проекте есть очень качественный хороший код.
Кроме опыта работы с "простынями" у меня есть опыт дизассемблирования (отдельных участков) и дебага без сорцов.

Опыт таков:
Дизассемблированная функция — по сути та же простынь. Таковым её делают оптимизирующие (и не очень) компиляторы: они часто инлайнят участки кода, и реиспользуют области в стеке (в одном месте кода [RBP+32] может указывать на один объект, а двадцатью строками ниже на другой).

1) "Простынь" - это значит код не структурирован, не систематизирован, не имеет чёткого назначения и границ ответственности: функция может одновременно разбирать данные из xml и что-то выводить на экран, а в особо тяжёлых случаях лезть в сеть. Вследствии этого назвать её практически невозможно - нельзя дать удобоваримое имя, отражающее суть происходящего.

2) п.1 приводит к тому, что отдельные элементы функциональности часто повторяют друг друга, и часто, просто копируются из одного места в другое.

3) п.2 приводит к тому, что при поддержке такого кода (когда нужно исправить багу, или добавить функционал), изменения вносятся:
    1) не во все необходимые места, и/или
    2) в часть мест вносятся некорректно.

4) п.2 приводит к тому, что любой участок кода может влиять на любую чать функционала

5) п.1 очевидным образом усложняет дебаг только что написанного: приходится продебажить всю простынь, просто чтобы добраться до того куска, который ты поправил, или дописал.

6) п.1
 , п.3
 , п.4
     очевидным образом приводят к тому, что при любом изменении кода приходится тестировать вообще весь продукт, потому что невозможно заранее предсказать, что ты сломал, дописав кусок, или изменив какое-либо условие.

7) Всё это приводит к тому, что параллельно, в разных ветка становится практически невозможно работать даже над разными задачами: код рассыпится во время мержа, ибо 2 человека обязательно что-то поправят одновременно.

8) Всё это вместе приводит к тому, что подключить к проекту нового человека практически невозможно: одного из "старпёров" придётся надолго посадить повадырём для новичка, который к тому же то и дело будет косячить просто по незнанию

9) Всё это вместе приводит к чудовищной стоимости новых фич, и вообще к  общей дороговизне поддержки такого продукта или его участка, сравнимый по стоимости с написанием нового продукта.

10) п.7 навевает на мысли о том, почему мы ещё не мелкофт, гугл, или эппл, хотя нам уже много лет.

ЗЫ: Я категорически против простыней.

Здравствуйте, denisko, Вы писали:

U>> И про паттерны, чистый код и рефакторинг если и слышал,
U>>то на практике не применяет уж точно. Его код — это дикие простыни без ясной структуры и логики. Не даром потом исправляем тонну багов.
D>Паттерны это один из стилей писать код, простыня другой. С дуру, накосячить можно, что в первом, что во втором случае. Если человек довольно хорошо пишет простыни и легко имеет их модифицировать, то на выходе код получится не хуже в плане устойчивости и быстродействия, чем с использованием паттерном. Единственное, что тут будут _последствия_. Модифицировать такой код без навыков простынеписательства, которые почти утеряны среди школоты, трудно и дорого. Если он готов с этим смириться, то придется писать в простынном стиле.

У меня на проекте местами простыни по 100кб. В строках уже давно не измеряю код — только десятками килобайт. Есть опыт его поддержки. Местами коду 10 и более лет.
Есть опыт поддержки кода и без простыней. В этом же проекте есть очень качественный хороший код.
Кроме опыта работы с "простынями" у меня есть опыт дизассемблирования (отдельных участков) и дебага без сорцов.

Опыт таков:
Дизассемблированная функция — по сути та же простынь. Таковым её делают оптимизирующие (и не очень) компиляторы: они часто инлайнят участки кода, и реиспользуют области в стеке (в одном месте кода [RBP+32] может указывать на один объект, а двадцатью строками ниже на другой).

1) "Простынь" - это значит код не структурирован, не систематизирован,
    не имеет чёткого назначения и границ ответственности:
    функция может одновременно разбирать данные из xml и что-то выводить на экран,
    а в особо тяжёлых случаях лезть в сеть. Вследствии этого назвать её практически
    невозможно - нельзя дать удобоваримое имя, отражающее суть происходящего.

2) п.1 приводит к тому, что отдельные элементы функциональности часто
   повторяют друг друга, и часто, просто копируются из одного места в другое.

3) п.2 приводит к тому, что при поддержке такого кода (когда нужно исправить багу, или добавить функционал), изменения вносятся:
    1) не во все необходимые места, и/или
    2) в часть мест вносятся некорректно.

4) п.2 приводит к тому, что любой участок кода может влиять на любую чать функционала

5) п.1 очевидным образом усложняет дебаг только что написанного:
   приходится продебажить всю простынь, просто чтобы добраться
   до того куска, который ты поправил, или дописал.

6) п.1
 , п.3
 , п.4
     очевидным образом приводят к тому, что при любом изменении кода приходится
         тестировать вообще весь продукт, потому что невозможно заранее предсказать,
         что ты сломал, дописав кусок, или изменив какое-либо условие.

7) Всё это приводит к тому, что параллельно, в разных ветка становится
   практически невозможно работать даже над разными задачами: код рассыпится во время мержа,
   ибо 2 человека обязательно что-то поправят одновременно.

8) Всё это вместе приводит к тому, что подключить к проекту нового человека
   практически невозможно: одного из "старпёров" придётся надолго посадить
   повадырём для новичка, который к тому же то и дело будет косячить просто по незнанию

9) Всё это вместе приводит к чудовищной стоимости новых фич, и
   вообще к  общей дороговизне поддержки такого продукта или
   его участка, сравнимый по стоимости с написанием нового продукта.

10) п.7 навевает на мысли о том, почему мы ещё не мелкофт, гугл, или эппл, хотя нам уже много лет.

ЗЫ: Я категорически против простыней.