Про єнотів та IT

2021-05-19 09:44:39 https://www.statlect.com/ Відкрити / Коментувати

2021-04-16 11:49:25 Корисні поради і практики:

https://github.com/alexeymezenin/laravel-best-practices/blob/master/ukrainian.md

https://github.com/jupeter/clean-code-php Відкрити / Коментувати

2021-02-04 15:12:46 #IT_guide • Читати Відкрити / Коментувати

2021-02-04 13:34:58 https://howhttps.works/ru/why-do-we-need-https/ Відкрити / Коментувати

2020-12-07 12:09:53 Про бабок Відкрити / Коментувати

2020-12-06 15:41:43 Общие принципы разработки хорошего кода, а именно про DRY, KISS, YAGNI и почему нельзя возвращать NULL. По-сути, первые 3 говорят говорят про очевидные вещи, но иногда разработчики про них забывают.

DRY
— don't repeat yourself
— нарушения принципа DRY называют WET — "Write Everything Twice" или "We enjoy typing"
— не допускай повторяющихся участков кода, на уровне функций, также не допускай классов с повторяющимся функционалом

KISS
— keep it simple, stupid или keep it short and simple
— нет смысла реализовать дополнительный функционал, который возможно когда-нибудь пригодится
— бессмысленно делать реализацию сложной бизнес-логики, которая учитывает в себе все возможные варианты
— нет смысла подключать огромную библиотеку, если вам от нее нужна только пара функций
— нужно держать компоненты своей системы (классы, методы) в максимально простом, не осложнённом, не перегруженном состоянии
— перекликается с Single responsibility, Interface Segregation принципами из SOLID

YAGNI
— you aren't gonna need it
— прежде чем писать новый компонент/функцию подумай: а нужен/на ли она тебе вообще? Может это можно не делать вообще? Или по крайней мере сделать это изящнее, проще, умнее, в рамках уже существующего/ей компонента/функции, не добавляя лишнего
— заказчик не должен оплачивать то, что он не заказывал
— бесплатных функций в продуктах не бывает
— ненужные новые функции могут впоследствии помешать добавить новые нужные
— новые функции должны быть отлажены, документированы и сопровождаться
— добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту "снежного кома"

почему нельзя возвращать NULL
— накладывается неявное ограничение на код, который должен проверять значение на NULL
— обработка ошибок вручную

Мне нравится описание Filip Hanik всех этих принципов:
— Разбивайте задачи на подзадачи которые не должны по вашему мнению длиться более 4-12 часов написания кода
— Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов
— Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
— Придумайте решение задачи сначала, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё и ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете что можно ещё меньше/ещё лучше.
— Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения два очень важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое более изящное решение решающее и старые и новые задачи. Відкрити / Коментувати

2020-12-04 17:36:48 Прочла об одном забавном баге (хотя для разработчиков он не был забавным) — как-то в Израиле проходили испытания нового процессора для автопилота от фирмы Моторолла для истребителей (да, они делали не только телефоны) и все было хорошо, пока внезапно в полете происходит общий сброс процессора, автопилот выключается на полном ходу, пилоты переходят на ручное управление и сажают истребитель. Все ломают голову, прогоняют тест за тестом - на тестовом стенде все хорошо, в полете за пределами Израиля — все хорошо, на испытаниях в Израиле — опять та же проблема, что была. Наконец, проанализировав каждую строчку кода нашли в чем была проблема. В вычислениях автопилота использовался такой параметр как высота над уровнем моря. При этом разработчики логично предположили, что он не может быть в полете равен нулю или меньше нуля — автопилот же для самолета, а не подводной лодки. Но есть такое уникальное место на Земле и, находится оно в Израиле, где земля находится ниже уровня моря — это Мертвое море. Подлетая к нему переменная получала значение сначала 0, а потом и отрицательное. Уже при значении 0 происходило деление на ноль и программный сброс процессора. Відкрити / Коментувати

2020-12-04 17:12:04 #IT_guide • Читать
Здесь я описала такие шаблоны GRASP, как Information Expert, Creator, Controller и Low Coupling и High Cohesion.
Буду только рада дискашену и/или потыканиям если что-то поняла не так Відкрити / Коментувати

2020-12-03 22:52:45 SOLID

Single responsibility
— класс отвечает за одну функцию
— код избавляется от копипасты (дубликатов)
— при дебаге проще исправлять ошибки, т.к. нет повторяющихся кусков кода

Пускай у вас есть какой-то класс Date, который отдает информацию о температуре и времени. Если какой-то Вася хочет получить информацию о времени, ему придется продублировать оба метода этого класса. То же касается и какого-то Андрея, который захочет получить информацию о температуре.
————— ————— —————
|DateTemp| копия |Date | копия |DateTime |
—————— <——— ————— ———> ——————
|- temp() | |- time() | |- time() |
—————— |- temp() | ——————
—————
Правильнее будет создать 2 отдельных класса, которые будут возвращать температуру и время соответственно.

Opened-closed
— класс должен быть открыт к расширению, и закрыт к изменениям
— почему хорошо следовать этому принципу? Если у вас был уже протестированный кусок кода и вы добавляете новый не изменяя текущий, вам не нужно тестировать старый. Скорее всего, в нем не будет багов

Liskov Substitution
— поведение наследующих классов не должно противоречить работе базовых
— подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый
— там где используется Child класс, должен подходить и его Parent

К примеру, у вас есть классы Child и Parent. Неправильной будет следующая реализация:
— используя Parent можно вызвать любой метод, а используя Child нужны дополнительные действия для вызова того же метода. Например, вызов какого-нибудь init()
— если метод getMessages() класса Parent возвращает коллекцию из базы данных, Child не должен возвращать пустой массив или null

Допустим, у вас есть классы Rectangle и Square, который наследуется от первого. В случае, если написать тест на Rectangle, который будет считать площадь функцией a*b, возникнет ошибка, т.к. в дочерном классе Square не реализована сторона b.
——— ————
|Rect | extends | Square |
——— <———— ————
|- a() | |- a() |
|- b() | ————
———

Interface Segregation
— много интерфейсов предназначенных для клиента лучше, чем один общий
— клиенты не должны зависеть от методов интерфейса, которые они не используют
— интерфейс является принадлежностью не сервера, и клиента
— при изменении одного метода интерфейса будут перекомпилироваться остальные классы, которые имплементятся от этого интерфейса, но которые этот метод даже не используют Відкрити / Коментувати

2020-04-14 18:03:03 #IT_guide • Читати
ще 10 трюків з Eloquent Відкрити / Коментувати