Контакты

Достижения

Все достижения (7)

Наибольший вклад в теги

Все теги (57)

Лучшие ответы пользователя

Все ответы (80)
  • С чего начинать проектировать приложение?

    max-kuznetsov
    @max-kuznetsov
    Системный архитектор
    Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, и кто/что будет их потреблять.

    Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.

    Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

    Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

    Между слоем сервисов и слоем доступа к данным нарисуйте большой контур и назовите его слоем бизнес-логики. В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.

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

    Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

    А дальше - детально прорабатывайте каждый маленький квадратик. Всё.
    Ответ написан
  • Карьера программиста после 30+. Миф или реальность?

    max-kuznetsov
    @max-kuznetsov
    Системный архитектор
    Боже, сколько страшилок понаписали!

    Дай-ка и я своё слово вставлю.

    Я начинал свою профессиональную карьеру дважды. Первый раз в 2002-м году. На тот момент мне было 26. Работал с Delphi. Дослужился до ведущего разработчика. Но пришлось сменить направление деятельности. И второй раз снова начал с простого программиста, осваивающего Java и .NET. Это было уже в 35. Сейчас работаю архитектором.

    От одного хорошего человека слышал, что главный инструмент разработчика - его голова и опыт. Я бы ещё добавил сюда интуицию и кругозор. Опыт в начале пути стремится к нулю, но голова в 35 работает лучше, чем в 20, интуиция и кругозор значительно более развиты.

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

    Юность имеет свои преимущества, но они не решающие. И недостатков у молодых программистов тоже много. Так что я бы не стал говорить, что у Вас всё плохо. В 30+ жизнь только начинается. Это я точно знаю!

    P.S. У нас в проектах работают люди разного возраста и пола. Программисты в 30 и старше - хорошее ядро команды. Они вносят стабильность. В том числе и в код. Но иногда нужно их мотивировать на то, чтобы пробовать что-то новое. И тут важно присутствие молодёжи.
    Ответ написан
  • Как развиваться, если команда слабая?

    max-kuznetsov
    @max-kuznetsov
    Системный архитектор
    Вот Вы только ВУЗ закончили, и уже жалуетесь, что разработчики вокруг слабые. Что ж Вы говорить будете, когда архитектором станете? :(

    Это я к тому, что (1) любое развитие начинается с личности, а не с команды, и (2) если Вы хотите достичь вершин, то работа с теми, кто слабее Вас, должна стать неотъемлемой частью Вашего бытия. И Вы должны быть этого достойны. Никто не хочет иметь в команде чванливого супергероя, но мудрый и терпеливый наставник, способный вовремя подставить плечо более слабому - это очень важная роль. Так что, если действительно хотите развиваться, в первую очередь займитесь своими личными качествами. Поверьте, они часто более важны, чем умение писать оптимальный код.

    Что касается кода, то есть несколько направлений (скорее всего, этим Вам придётся заниматься в свободное время):
    • читайте и экспериментируйте; вам нужен широкий кругозор и глубокие знания в ключевых областях (таких, как особенности реализации типов, производительность и т.п.);
    • возьмите какой-то качественный проект с открытым кодом и проведите анализ кода - наверняка найдёте много интересного;
    • займитесь фрилансом: и денюжка лишняя не помешает, и головомойки периодические от тимлидов заказчика себе обеспечите.


    Ну и наверняка ещё что-то можно в этот список добавить. Было бы желание. А вот жаловаться - бросьте!
    Ответ написан
  • Где хранить данные об уровне доступа пользователя, в Сессии или в Базе данных?

    max-kuznetsov
    @max-kuznetsov
    Системный архитектор
    Как правило, информацию о доступе пользователя проверяют каждый раз при поступлении от него нового запроса. Делается это из-за того, что с момента предыдущего запроса пользователя могли блокировать, или изменить его права. Если хранить информацию об уровне доступа в сессии, то до её истечения заблокированный пользователь будет продолжать пользоваться всеми разрешениями, которые у него были на момент начала сессии. А при умелом пользовании запросами сессия может жить очень долго )))
    Ответ написан
  • Как правильно развиваться в программировании?

    max-kuznetsov
    @max-kuznetsov
    Системный архитектор
    Даю пункты:
    1. Понять, кем надо стать лет через 5.
    2. Понять основные компетенции, которые к тому моменту нужно иметь.
    3. Расставить приоритеты освоения компетенций.
    4. Вкладывать время, силы и деньги в получение нужных компетенций.
    5. Не реже раза в год пересматривать цель и список компетенций.

    У Вас есть опыт работы с C++. Отсюда можно пойти в системное программирование, в прикладное программирование, в архитектуру ПО, в аналитику, в управление. Решите для себя, что Вам ближе.

    К сожалению, более подробно план не дам. Его детализация зависит от Вашей цели.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (2)