t
есть неплохая штуки типа SOLID и DRY. Вот я вижу, что автор клал на это)
Size: a a a
2021 March 21
t
возможно, докторов не учат такому
t
может им и не стоит код писать?
t
а то какое-то говно выходит
c
sergevp
Я знаю, некоторые любят заюзать побольше паттернов. И меня всегда впечатляли HelloWorld-ы, которые умудляются заюзать сразу 2 десятка паттернов, типа:
https://web.archive.org/web/20080905182121/http://www.phppatterns.com/docs/design/hello_world_in_patterns
https://github.com/code4craft/hello-design-pattern — Hello world using all 23 kinds of GoF design patterns.
Я знаю, некоторые любят заюзать побольше паттернов. И меня всегда впечатляли HelloWorld-ы, которые умудляются заюзать сразу 2 десятка паттернов, типа:
https://web.archive.org/web/20080905182121/http://www.phppatterns.com/docs/design/hello_world_in_patterns
https://github.com/code4craft/hello-design-pattern — Hello world using all 23 kinds of GoF design patterns.
t
даже когда по директориям раскладываешь поближе к структурам алгоритмы, которые непосредственно работают с этими структурами, то уже читать удобнее. Даже не нужны методы всякие. Ты читаешь один тип структурки из файла, другой, третий, зачем всё пихать явно в один модуль трансляции, раздувая его до 4к строк. Это можно сделать не так больно для людей. Да-да, я помню. Можно писать для себя. Только вот я пишу код как минимум для себя в будущем. Это уже чуть другой человек.
t
sergevp
Я знаю, некоторые любят заюзать побольше паттернов. И меня всегда впечатляли HelloWorld-ы, которые умудляются заюзать сразу 2 десятка паттернов, типа:
https://web.archive.org/web/20080905182121/http://www.phppatterns.com/docs/design/hello_world_in_patterns
https://github.com/code4craft/hello-design-pattern — Hello world using all 23 kinds of GoF design patterns.
Я знаю, некоторые любят заюзать побольше паттернов. И меня всегда впечатляли HelloWorld-ы, которые умудляются заюзать сразу 2 десятка паттернов, типа:
https://web.archive.org/web/20080905182121/http://www.phppatterns.com/docs/design/hello_world_in_patterns
https://github.com/code4craft/hello-design-pattern — Hello world using all 23 kinds of GoF design patterns.
Я знаю, что большинство не знаю ни про какие паттерны, потому что они либо "вошли в айти", либо "учёные"
t
не знают*
c
sergevp
@ttldtor> есть неплохая штуки типа SOLID и DRY
Это очень абстрактные принципы. Ими можно руководствоваться, когда ты точно не знаешь, чего ты хочешь, чтобы потом меньше переделывать. Но в отдельных конкретных случаях их НЕсоблюдение приводит к меньшему числу ошибок (особенно это касается DRY).
@ttldtor> есть неплохая штуки типа SOLID и DRY
Это очень абстрактные принципы. Ими можно руководствоваться, когда ты точно не знаешь, чего ты хочешь, чтобы потом меньше переделывать. Но в отдельных конкретных случаях их НЕсоблюдение приводит к меньшему числу ошибок (особенно это касается DRY).
t
sergevp
@ttldtor> есть неплохая штуки типа SOLID и DRY
Это очень абстрактные принципы. Ими можно руководствоваться, когда ты точно не знаешь, чего ты хочешь, чтобы потом меньше переделывать. Но в отдельных конкретных случаях их НЕсоблюдение приводит к меньшему числу ошибок (особенно это касается DRY).
@ttldtor> есть неплохая штуки типа SOLID и DRY
Это очень абстрактные принципы. Ими можно руководствоваться, когда ты точно не знаешь, чего ты хочешь, чтобы потом меньше переделывать. Но в отдельных конкретных случаях их НЕсоблюдение приводит к меньшему числу ошибок (особенно это касается DRY).
Это очень конкретный принципы, когда их применяют не на уровне программирования, а на уровне планирования проекта
t
можешь называть это дизайном
t
конкретные*
t
даже когда ты начинаешь разбивать на библиотечки, общие части, ты пользуешься этими правилами, иначе у тебя будет всё очень криво
t
либо слишком много мелких частей, либо слишком крупные
t
меня забавляет, что мне приходится объяснять такие тривиальные вещи
t
может мне больше досталось от говнокодеров?
c
sergevp
Ну, DRY конкретен. Но его бездумное соблюдение приводит к переусложнённому коду, с ненужными константами (типа `#define SECONDS_IN_MINUTE 60`), и к проблемам в будущем (ой, мы переиспользовали одну и ту же функцию во втором модуле и забыли, потом изменили её для первого модуля и второй сломался).
Ну, DRY конкретен. Но его бездумное соблюдение приводит к переусложнённому коду, с ненужными константами (типа `#define SECONDS_IN_MINUTE 60`), и к проблемам в будущем (ой, мы переиспользовали одну и ту же функцию во втором модуле и забыли, потом изменили её для первого модуля и второй сломался).
c
sergevp
А SOLID вообще абстрактен. То есть ни для какого конкретного кода нельзя однозначно ответить, удовлетворяет ли он уже принципам SOLID, или его можно ещё немного "улучшить", чтобы он им больше удовлетворял.
А SOLID вообще абстрактен. То есть ни для какого конкретного кода нельзя однозначно ответить, удовлетворяет ли он уже принципам SOLID, или его можно ещё немного "улучшить", чтобы он им больше удовлетворял.
t
кстати, я точно не знаю, какой это принцип, но параметры программы (такие как количество потоков) лучше не описывать в заголовках. Это вот прям самый настоящий конфиговский конфиг. И редко его вычисляют, потому что это может нарушить работу системы, где работает софт.
t
sergevp
А SOLID вообще абстрактен. То есть ни для какого конкретного кода нельзя однозначно ответить, удовлетворяет ли он уже принципам SOLID, или его можно ещё немного "улучшить", чтобы он им больше удовлетворял.
А SOLID вообще абстрактен. То есть ни для какого конкретного кода нельзя однозначно ответить, удовлетворяет ли он уже принципам SOLID, или его можно ещё немного "улучшить", чтобы он им больше удовлетворял.
Принцип SOLID можно параметризовать не только словом class\structure, но и module
И тогда, например, буковка S (Single responsibility) , будет иметь очень конкретные последствия, если её не учитывать
И тогда, например, буковка S (Single responsibility) , будет иметь очень конкретные последствия, если её не учитывать