• Как поддерживать две версии приложения (платная и бесплатная)?

    onqu
    @onqu
    weasy
    Конечно, можно использовать 2 ветки, конечно, можно делать все в одной ветке и понатыкать везде #ifdef FOR_NISCHEBROD, FOR_REGULAR_CLIENT, FOR_RICH_ONE, конечно, можно расставить тэги, чтобы было проще искать эти места в будущем.

    Но, при увеличении объема логики придется прибегнуть к использованию шаманского бубна, ритуалу выстрела в свою ногу и мольбы праотцам. Добавлять/править логику в этих кусках будет очень непросто.

    Другой вариант.
    Делать приложение модульным, где основное приложение является лишь каркасом с базовой функциональностью, лежит в отдельной репе, тестируется отдельно от всего, и где модули это подключаемые расширения (Компоненты, DLC, LIB, Whatever), у которых есть API интерфейс для расширения функциональности основного приложения, и каждый лежит в своей репе.
    Более того, их можно будет тестировать, как вкупе, так и отдельно от основного приложения. При сборке указываем только требуемые расширения. Нэкст лэвэл - подключать расширения динамически, то есть без сборки с приложением.
    Ответ написан
    2 комментария
  • Как вы организуете разработку сложного продукта?

    max-kuznetsov
    @max-kuznetsov
    Главный IT-архитектор
    В целом, похоже, что у вас в команде есть несколько проблем.
    Во-первых, либо есть проблемы с архитектурой, либо неверно составлен план разработки. Это может быть связано с игнорированием ограничений agile. Мне кажется, что присутствует и то, и другое.
    Во-вторых, программисты не сильно мотивированы писать качественный код, либо не имеют возможности этого делать. Возможно, у них не складывается модель предметной области, и, исправляя одну бяку, они тут же вносят новую. Есть смысл подумать о специализации конкретных разработчиков (или небольших групп разработчиков) на конкретных направлениях. Попробуйте разбить крупный проект на несколько отдельных "изолированных" проектов, в каждом из которых следует рассматривать смежные подпроекты как внешние системы. Каждому подпроекту нужна своя команда. Это сделает проект управляемым и понятным всем участникам.
    А дальше, соглашусь с Сергей Протько , "Тесты, TDD, рефакторинг, SOLID".
    Ответ написан
    3 комментария
  • Как вы организуете разработку сложного продукта?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Проект развивается итерациями и фичи нагромождаются и код, естественно, не самый изящный и простой для понимания и анализа.


    Тесты, TDD, рефакторинг, SOLID. И тогда нет боли. Но это увы далеко не на каждом проекте встретишь.

    Потому, как, тебя просят добавить или починить функцию А, ты ее чинишь, но попутно, возможно, ломаешь явно фичу Б и неявно В

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

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


    Баги это хорошо, регрессионные баги это плохо, это показатель того что с нашим кодом что-то не так. Уменьшить количество багов просто - нужно больше тестов с учетом различных инвариантов. Но иногда это избыточно, и проще просто словить и пофиксить баг.

    Так же рекомедную вам ознакомитсья с практиками экстримального программирования, там много внимания удиляется обратной связи от момента когда разработчик что-то сломал до момента обнаружения проблемы (парное программирование, TDD).
    Ответ написан
    3 комментария
  • Как вы организуете разработку сложного продукта?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Схема бизнес-процесса, модульность и документация к каждому модулю.
    Стыки модулей - должны быть помечены на схеме, сами модули - выделены.
    Ответ написан
  • Как вы относитесь к тестовому заданию ДО собеседования?

    @hsx_vlad
    К тестовым заданиям, я отношусь так же, как и работодатель к тестовым платежам. Работодатели предлагающие тестовые задания лично меня не интересуют.
    Ответ написан
    1 комментарий
  • Java, куда именно податься?

    AlPsc
    @AlPsc
    Java/high load/big data
    Во-первых, не забудьте после Шилдта прочесть книгу Джошуа Блоха "Effective Java" (в одном из соседних вопросов упоминается её русский перевод, так что он, видимо, существует) – по моему скромному мнению, это обязательное чтиво для любого Java-программиста.
    Во-вторых, если уж выбирать между Android и чем-то ещё, то надо понимать плюсы и минусы обоих путей. Напишу то, что пришло мне в голову, на полноту и истину в последней инстанции не претендую.

    Android:
    Плюсы:
    • Работы много. Очень. В том числе и удалённой.
    • Получить начальные навыки довольно легко – сейчас есть огромное количество статей, пошаговых руководств и прочих материалов, которые как позволяют учиться новому, так и быстро решать типовые задачи/проблемы.

    Минусы:
    • С точки зрения изучения Java эта среда довольно специфическая. Во-первых, используется довольно старый диалект (Java 6). (В комментариях справедливо поправили, что сейчас на Android доступна Java 7.) Во-вторых, набор библиотечных классов несколько отличается от Java SE, и это значит, что при необходимости писать приложения на "настоящей" Java просто взять и переключиться по щелчку пальцев не получится, а какая-то часть "мобильных" навыков и практик окажется бесполезной.
    • Хорошо программировать на Java значит не только знать язык, но и уметь выбирать прочие инструменты (дополнительные библиотеки и т.п.), которыми, конечно, тоже надо уметь пользоваться. В этом смысле Android тоже довольно далёк от того, к чему привыкли разработчики Java SE/EE: всякие вещи типа JDBC/Hibernate/you-name-it на Android либо отсутствуют в принципе, либо не могут быть использованы из-за ограничений среды (тот же нестандартный набор библиотечных классов). Это опять же означает, что, научившись писать на Java под Android, вы не сможете просто взять и начать разрабатывать, скажем, enterprise/backend приложения, и конкуренцию в этой области с кандидатами, у которых есть соответствующий опыт, выдержать вряд ли сможете. (Я бы ничего этого не писал, но у вопроса есть метка "карьера", так что вы сами напросились :) )
    • Большая часть компаний, занятых мобильной разработкой – сервисные, со всеми вытекающими. Лично для меня это минус, т.к. мне продуктовые компании больше по вкусу.
    Java SE/EE
    Плюсы:
    • Работы много. Очень. В том числе и удалённой.
    • Более широкие возможности применения своих навыков

    Минусы:
    • Более высокий порог вхождения
    • Несколько сложнее наработать портфолио, потому что жизненный цикл "больших" приложений зачастую всё же гораздо длиннее, чем в случае мобильной разработки, где очень большую часть работы составляют проекты для сторонних заказчиков, где изначально задана конкретная конечная цель, сразу оговариваются сроки, и т.п. (Сужу по собственному опыту работы в компании, которая занималась как раз разработкой мобильных приложений для заморских заказчиков.) Конечно, в случае с удалённой работой/сервисными компаниями это может оказаться правдой для приложений любых типов.

    Итак, выбирая Android, вы раньше сможете начать зарабатывать деньги, но "чистая" Java, на мой взгляд, даёт больше перспектив. И по сути Android-программист и Java-программист – совсем не одно и то же. Так что выбор профессионального пути зависит от того, как вы вообще видите себя в ближайшем будущем в этой профессии: хотите ли вы быстро освоиться и получить способ зарабатывать деньги, не сильно задумываясь о смене деятельности в перспективе, либо же вам интересны разные области программирования, и вам хочется многое попробовать.
    Ответ написан
    4 комментария
  • Как выбрать it направление?

    knitevision1
    @knitevision1
    Ванька Скайуокер
    Чем вам не нравится html/css/js ?
    Грамотным, хорошим ребятам с сильными знаниями этой ерунды (включая конечно же LESS/SASS/Stylus) платят до 60$/час (в редких случаях), а обычная планка для хорошего фронтендера - 40$/hour.

    Если еще напишите какой свой тулкит, фреймворк, так вообще за 100$/час будут брать...

    И вообще, учить что-то, СПЕЦИАЛЬНО для заработка денег - заведомо убогое и тупиковое занятие. Вам должно быть интересно, вам должно это нравится, вы сами должны по 15 часов в день на голом энтузиазме сидеть и копаться, а не спрашивать на тостере, что лучше учить, чтобы $$$ капали. Бизнес молодость, блять?

    А, ну если вы пользуетесь словосочетанием "делаю сайты", то с вами всё ясно, yet another Indus.
    Ответ написан
    1 комментарий
  • Какие дисциплины изучать программисту чтобы меньше зависеть от языков и технологий?

    vvpoloskin
    @vvpoloskin
    Инженер связи
    Идите в грузчики - нет никакой зависимости от языков программирования, практически не надо изучать ничего нового, если только на погрузчик сдавать.
    Ответ написан
    Комментировать
  • Как, когда и нужно ли вообще закрывать connection к базе в singleton классе?

    dima117
    @dima117
    Разработчик интерфейсов
    Зависит от того, насколько часто приложение обращается к БД.
    Если часто, то лучше использовать одно общее соединение. Если редко, то лучше закрывать, чтобы освободить ресурсы.

    Например, в веб-приложениях, как правило, открывается отдельное соединение на каждый HTTP-запрос и в нем выполняются несколько SQL запросов.

    Также почитайте про connection pool.
    Грубо говоря, это способ оптимизации приложения, при котором есть некоторый пулл соединений. При открытии соединения, если такое уже есть в пулле, оно берется оттуда (соответственно, не тратятся ресурсы на его инициализацию). При закрытии соединения оно возвращается в пулл и может быть использовано повторно. Инфраструктура .NET Framework управляет пуллом соединений в соответствии с указанными Вами настройками.
    Ответ написан
    Комментировать
  • Как эффективно подтянуть теорию и навыки c#?

    @smet4ik
    На курсы забить - специалисту будет там делать не чего, все проходил от работы(для сертификатов). Рихтера - читать, это большой плюс к пониманию работы платформы, если что-то не понятно - не парится и не думать о себе плохо, ничего страшного по мере освоения платформы придет.
    Лучше всего осваивать - писать код - желательно боевой, лучше всего на работе, Вы же находили вакансии по которым проходите, не занижайте себе планку - Вы работающий программист, наверняка и на 1с приходилось решать сложные и интересные задачи, вы уже умнеете писать код, не стоит зацикливаться на пробелах, если это действительно пробелы - разберетесь, поправят, погуглите. Не поверите сколько приходит народа на хорошие вакансии с очень сомнительным скилом и проходят. И наоборот многие и хорошие разработчики, умеющие писать, считают что они что-то где-то не знают, что у них есть пробелы и тп. не приходят на собеседования, не меняют работу, которая не нравится. пробелы будут главное умение разобраться и применить.
    Если все-таки сомневаетесь - посмотрите требования вакансий - возьмите оттуда основные технологии и напишите, любую из своих задач на них, не полностью все - а одну интересную задачу - но с начала и до конца и обязательно чтоб она работала, не просто наброски, а рабочий вариант - как для сдачи в бой, если что-то не понятно читайте помимо Рихтера, что нибудь в роде - "Бла-бля в действии", "Эфективный бла-бла", "Бла-бла для профессионалов" и + поиск в интернете, решая конкретную задачу и круг поиска уже и проще.
    Ответ написан
    Комментировать