• Как определять ответственность функций?

    TrueBers
    @TrueBers
    Гуглю за еду
    По своему опыту могу сказать:
    Всё это бесполезный треш, все эти описания как надо, как правильно, как делают гуру, как делают в НАСА, солиды, банды четырёх, десяти, трёхсот спартанцев и т. д. Но, ровно до того времени, пока вы сами до этого не дойдёте. А дойти до этого можно только с опытом. Когда вы пишете что-то относительно не крупное, эти все вещи можно опускать. А когда приходите к огромному проекту, всё идёт само по себе, ибо иначе вы просто не можете с этим взаимодействовать, либо если система уже достаточно хорошо спроектирована, вам приходится писать правильно, т. к. по-другому либо не получится, либо вам дадут по шапке ревьюверы.

    Если вы в любом проекте начинаете ещё до проекта строить идеальную мега-архитектуру там, где она не нужна, то это уже является в какой-то мере преждевременной оптимизацией, которую уже миллион раз обсудили. Ни одна софтварная корпорация мира не может спроектировать всё заранее, а в большинстве всё спроектировано и написано через жопу, это могу точно сказать, ибо много крупных продуктов приходилось реверсить. Вы бы знали, какое там гавно, даже в рамках правильного использования средств разработки и языков...

    Рецепт прост: пробовать, делать, строить, ломать, перестраивать, ошибаться, снова перестраивать. Тупо взять и прочитать, как кто-то там сделал и у него получилось, не прокатит. У него звёзды сошлись, а у вас, у меня, или у неё не сойдутся точно в такой же последовательности. Используйте разные языки программирования, разные парадигмы, фреймворки. Это даёт прекрасное понимание о существовании различных архитектурных решений, которое не даст ни однин теоретический паттерн.

    Я не хочу сказать, что все эти гофы и солиды не имеют смысла, они созданы для того, чтобы для начала просто с ними ознакомиться, отложить в подсознание и... благополучно забыть! Но потом, когда вдруг что-то писал и внезапно осенило: Да это же паттерн медиатор/обсервер/репозиторий/anyPattern! Вот тут и пригодится та самая книга трёх танкистов и собаки, которая просто направит в нужное русло, объяснит остальное, что не успел понять сам, и т. п.

    Всё это моё понимание, работает для меня, может не работать для кого-то другого, кто, например, запоминает 95% прочитанной книги и может уже сразу же адекватно оценить где какой подход использовать, где нужно будет масштабироваться и т.д.

    Но, я пока что таких людей не видел...
    Ответ написан
    3 комментария
  • Где вести записи разработчику?

    a1exDi
    @a1exDi
    Geek
    Если на маке сидите, то советую SnippetsLab App + Github Gist в связке.
    Ответ написан
    Комментировать
  • Git: объясните «на пальцах» разницу между rebase и cherry-pick?

    Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
    Добавлю картинок.

    git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
    (ветка devel "растворяется" в основной ветке)
    518b8dbce1cd4f96b30de9782ae38fcd.png
    git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
    (devel остается отдельной веткой, к которой можно вернуться)
    1ba8186d879d46ff85ea7c1e192328e2.png
    git chery-pick idea - забрать коммиты из ветки idea
    2717e3091f644ef2954aa2de4514f446.png
    Ответ написан
    2 комментария