Какой стиль программирования выбрать, чтобы не вникать спустя время в проект?
Речь исключительно о php.
Написал класс для работы с определенной моделью. Как правило, это методы по работе с БД по данной модели.
Через год надо что-то поправить, внести изменения и долго времени уходит на "вспомнить как оно работает".
И часто бывает, что времени на это "вспомнить" уходит прилично.
Может есть какие-то общие правила для написания такого кода, который налету понятен?
1. ООП
2. Грамотное наименование переменных, методов и классов
3. Небольшие комментарии в коде
4. Документация в джире или где-либо еще по сложным юзкейсам приложения.
Использовать фреймворк (в смысле на котором вы всегда работаете) и однородный стиль работы с конкретным слоем, чтобы не вникать, а сразу ЗНАТЬ как поправить...
Ну тут я еще может напортачил.
К примеру метод update принимает массив
Выглядит это так:
public funftion update(array $param){
}
И как выяснилось, МОЙ ЖЕ!!!! код и сохраняет и обновляет одним методом. Отличается запрос лишь тем, передаю ли я в массиве параметр id => 1 или нет. Я долго матерился конечно)
Дополню еще одним советом:
Писать самодокументируемый код, комментарии для которого не нужны. Исключением являются ситуации, когда используется сложная и/или не очевидная логика. Самодокументирование это такой подход к написанию кода, когда имена переменных говорят о том, что они в себе содержат, а имена функций и методов о том, что они делают. Код строится просто и линейно, чтобы разработчик сразу понимал, что делает та или иная часть и что именно тут содержится.
Александр, берешь любой фреймворк и лезешь в его кишки. Все понятно и без документации, но с ней куда проще и быстрее. И с примерами, с авторами, ссылками на документацию с оф.свйта и много других полезностей. Не говоря уже о документировании миграций и тестов, компонент бизнес-логики и интеграции
Тут как раз речь о том, что применимо для всех языков, а не только для PHP.
Если будете применять устоявшиеся практики и паттерны; не изобретать велосипеды, а искать и интегрировать имеющиеся решения; а также уместно комментировать код и вести документацию - через год поблагодарите себя, даже если не придётся возвращаться к написанному и править, потому что вырастите в целом как востребованный специалист.
Забыли, что делает проект
Запускаем тесты
Смотрим, возможно остались ошибки с todo
Фиксим их
По пути смотрим на юзерстори
Находим место, где требуется внести правку в юзерстори
И далее по циклу
Если вы не понимаете, что написано в вашем классе - значит он написан плохо
Перепишите его, так чтоб с первого взгляда на код вы могли понять, что он делает
sim3x, чего тут непонятного? я тоже придумал какой-то известный только мне термин и аппелирую к нему :) хочешь чтобы тебя понял говори развернуто и по возможности по русски
Антон Шаманов, ты же заявил, что это слово выдумали и никто его не знает, а сейчас пишешь, что оно всем знакомо. И о каких связях user story спрашиваешь, если не знаешь что это? Так что вперед, самообразовывайся, google в помощь.
комментарии к коду особенно в местах с нестандартными хаками очень помогают ) вроде "эта строка тут нужна чтобы обеспечить совместимость со старыми версиями метода x"
+ длинные функции/методы - зло - пусть отдельный метод и не служит для избавления от дублирования кода, но он увеличивает читабельность кода
