Допустим есть некая бизнес-сущность, которая содержит необходимые для работы сервиса поля. И тут вы думаете как бы на будущее — а вдруг добавим то и то и нужно будет такое поле еще — давай сразу сделаю, чтобы уже было готово и в случае если таки решим добавить ту фишку — поле уже будет, как бы круть.
Делаете так?
Понял что почти всегда это ни к чему хорошему не приводит. Потом будущее разворачивается таким образом, что поля все равно придется добавить 2 а то и 5 и немного других. Что все равно на 5 шагов вперед не получается предвидеть.
Здравствуйте, Shmj, Вы писали:
S>Допустим есть некая бизнес-сущность, которая содержит необходимые для работы сервиса поля. И тут вы думаете как бы на будущее — а вдруг добавим то и то и нужно будет такое поле еще — давай сразу сделаю, чтобы уже было готово и в случае если таки решим добавить ту фишку — поле уже будет, как бы круть.
Вместо enum Sex { Male, Female, Undetected } sex, к примеру, VARIANT sex, вместо одного поля total в БД — total, totalAlt, totaltAlt3, так что ли?
Здравствуйте, Shmj, Вы писали:
S>Допустим есть некая бизнес-сущность, которая содержит необходимые для работы сервиса поля. И тут вы думаете как бы на будущее — а вдруг добавим то и то и нужно будет такое поле еще — давай сразу сделаю, чтобы уже было готово и в случае если таки решим добавить ту фишку — поле уже будет, как бы круть.
S>Делаете так?
Здравствуйте, Shmj, Вы писали:
S>Допустим есть некая бизнес-сущность, которая содержит необходимые для работы сервиса поля. И тут вы думаете как бы на будущее — а вдруг добавим то и то и нужно будет такое поле еще — давай сразу сделаю, чтобы уже было готово и в случае если таки решим добавить ту фишку — поле уже будет, как бы круть.
S>Делаете так?
Нет.
S>Понял что почти всегда это ни к чему хорошему не приводит. Потом будущее разворачивается таким образом, что поля все равно придется добавить 2 а то и 5 и немного других. Что все равно на 5 шагов вперед не получается предвидеть.
S>Кто что скажет?
Стараюсь писать код и прочее так, чтобы те изменения в будущем, которые я могу предполагать, было бы просто реализовывать. Т.е. чтобы не пришлось что-то крупно переписывать. Могу где-то немножко переусложнить архитектуру, если уверен, что это пригодится в будущем. Это максимум, но и то скрепя сердце.
А так я ярый поклонник принципа — отсечь всё ненужное, пока не останется всё нужное.
Задел на будующее — правильные архитектура (на всех уровнях) и технологии.
А что касается полей, свойств, методов — чтобы разработчик не придумал в плане "что будет дальше", бизнес придумает свое и часто совсем не то, что разработчик может предположить.
Ответ зависит от масштаба гадания, от структуры команды, от отношений между бизнесом и программистом, от амбиций и темперамента программиста. Можно рассмотреть 2 крайности:
1. Общение между программистом и бизнесом ограничено тикетами в джире. В каждый момент времени программист знает только на 1 небольшой шаг вперёд (типа "неделя работы"). В этом случае пытаться что-то там угадать про будущее — бестолковая затея.
2. Программист и бизнес постоянно ведут диалог, бизнес объясняет цели бизнеса, программист объясняет что софт может сделать для достижения этих целей, в каком порядке что можно напрограммировать, зарелизить, и т.д. В этом случае у программиста не возникает желания гадать, т.к. он обладает хорошим таким жирным контекстом происходящего (да ещё и является автором большой его части) — и этот контекст более-менее определяет работу на следующие несколько месяцев например.
В некоторых случаях его делают, вроде зарезервированных членов структуры, параметров функции, поля в протоколе передачи данных, и т.д., когда где-то намертво фиксируется ABI, и потом изменения делаются в рамках него.
Можно насмотреться на такое, например, в WinAPI или ещё каком-то апи.
Однако многим приложений не нужен фиксированный ABI, кроме как для бинарного формата файлов или ещё какой (бинарной) сериализации.
Самодельная сериализация тоже не всем нужна, если можно обойтись расширяемым языком разметки.
Нет, никогда. Если у меня есть в голове какие-то мысли на будущее, я просто пишу код так, чтобы потом его было проще доработать. Второй момент — архитектурные требования а-ля масштабируемость системы. Тоже как бы "ненужный код и задел на будущее".
Нет.
S>Понял что почти всегда это ни к чему хорошему не приводит. Потом будущее разворачивается таким образом, что поля все равно придется добавить 2 а то и 5 и немного других. Что все равно на 5 шагов вперед не получается предвидеть.
Здравствуйте, Doc, Вы писали:
НС>>Что такое "правильная архитектура"? Doc>Которая удовлетворяет текущим требованиям проекта и открыта для расширения в дальнейшем.
Здравствуйте, Shmj, Вы писали:
S>Допустим есть некая бизнес-сущность, которая содержит необходимые для работы сервиса поля. И тут вы думаете как бы на будущее — а вдруг добавим то и то и нужно будет такое поле еще — давай сразу сделаю, чтобы уже было готово и в случае если таки решим добавить ту фишку — поле уже будет, как бы круть.
Добавить про запас поле — нет. Тут особо не угадаешь какое.
С другой стороны, если, например, поле описано как бинарное, но при этом выглядит что там могут быть и другие варианты чем да/нет, и очень вероятно, что потом они потребуются — это предпочитаю сразу заложить enum, а не bool, потому что потом менять весьма неудобно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Как то слишком уж обще.
Согласен, обще. Но в этом IMHO и смысл — правильная архитерура позволяет минимизировать затраты по поддержке и развитию. А детали уже свои на каждом уровне (от общей архитертуры до дизайна конкретных серсисов и приложений).
