Пользователь пока ничего не рассказал о себе

Достижения

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

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

Все теги (58)

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

Все ответы (91)
  • Какой код показать заказчику/работодателю?

    @jaxel
    На что лично я бы обратил внимание:
    1. Оформление кода. Весь код должен строго придерживаться одного стиля. Идеально, если он будет соответствовать актуальному стандарту, например PSR-2. Обязательно говорящие имена переменных, никаких a, b, row, foo и прочей жести. Именование классов в соответствии с названием используемого паттерна. Код должен быть самодокументирующимся. Обязательно везде PHPDoc комменты в соответствии со стандартами. Комменты с описание особо сложных мест.

    2. Если это фреймворк - то соответствие принятым в фремворке стандартам и рекомендациям. Никакой самодеятельности.

    3. Общая архитектура проекта. Никаких портянок в контроллерах. Чёткая разбивка кода по сервисам. Никаких адовых функций по 100500 строк. Логичное разделение кода по классам. Применение подходящих паттернов для решения задач.

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

    5. Использование менеджера пакетов для проекта. Ну думаю в 2016 году без него уже никто не кодит:)

    6. Думаю разбираться в работе сложных алгоритмов я бы не стал, и ограничился тем, что перечислил выше.

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

    8. Полный самопис - это явный минус. Не использовать в наши дни хорошие готовые решения, делая вместо этого стрёмные, никому не понятные велосипеды - это глупость.

    9. На CMS код можно даже не присылать. Там в любом случае будет говнокод. Сами CMS к этому обязывают:)
    Ответ написан
    Комментировать
  • Как определить реальную рыночную стоимость проекта по разработке веб-приложения?

    @jaxel
    Очень сложно определить реальную стоимость разработки для крупных задач. В серьёзных конторах может 100-200 тысяч от бюджета уйти на составление подробного ТЗ и оценку стоимости проекта. И даже в этих случаях бывают промахи процентов в 20-30% бюджета.

    Для меня лично оценить задачу - всегда проблема. Даже по хорошему ТЗ на подробную оценку может денёк уйти. Делать такую оценку для "потенциального" заказчика - очень расточительно.

    В большинстве случаев, я оцениваю в часах время разработки понятных моментов задания, добавляю предполагаемую оценку не совсем понятных моментов, умноженную на 2, и оценку совсем не понятных моментов ТЗ, умноженную на 3. Умножаю полученное время на часовую ставку и получаю примерную стоимость проекта.

    Цифра озвучивается заказчику, как ориентир. Так как она весьма приблизительная, стараюсь договориться на почасовую оценку работы. Особенно при плохом или непонятном ТЗ.

    Удаётся не всегда. Бывает, что по этой цифре и работаем. Иногда времени уходит больше, иногда меньше. И ничего с этим не сделать.

    А по конкретным задачам может быть много нюансов.
    • У первого исполнителя могут быть готовые наработки, и он сделает заказ за 3 дня и 22к рублей.
    • У второго наработок нет, но он хороший спец, использует для задачи правильные инструменты, и сделает за 2 недели и 70к.
    • У третьего тоже нет наработок, и в добавок он не умеет выбрать правильный инструмент. Начнёт пилить без фреймворков и прочего, потратит на это пол-года и 300к рублей.
    • Четвёртый просто не поймёт сложность задания. Запросит 30к и начнёт пилить сложный кастомный прокт на вордпрессе. В итоге просто не сможет его закончить:)

    В итоге все честно оценили заказ исходя из своих возможностей, а цифра отличается в 10 раз.
    Ответ написан
    5 комментариев
  • Как стать Junior Java Developer, имея немалый опыт разработки на этом же языке?

    @jaxel
    Самый быстрый и правильный способ получить знания - это работать над реальными задачами в компании, где есть более квалифицированные коллеги. С грамотным тим-лидом, правильно построенным рабочим процессом и код ревью, ваш скилл будет расти с космической скоростью.

    Если вы пишете уже 2 года, у вас уже должен быть достаточный опыт для того, чтобы бы устроится стажёром или джуном на реальную работу. Это практически вариант с мертором, только лучше.

    Самостоятельное обучение будет хорошо только плюсом. С двумя годами опыта я бы уже не делал на него основную ставку.

    Курсы категорически не советую. Комбайн по выманиванию денег. Какой-то эффект могут дать только тем, кто пришёл с 0 знаний.
    Ответ написан
    Комментировать
  • Кто как делает html формы?

    @jaxel
    Не использовать фреймфорки в 2016 году - значит говнокодить. В symfony 2/3 отличный модуль для работы с формами.
    Ответ написан
    3 комментария
  • Какую бесплатную cms/фреймворк использовать для интернет-магазина?

    @jaxel
    Если выбор стоит между CMS и фреймворком, есть довольно простой алгоритм. Если возможности CMS решают 100% задач и быстрого дальнейшего развития не ожидается - надо брать CMS. Если же хотя бы 5% функционала придётся дописывать, лучше взять фреймворк и сделать всё под себя.

    Как показывает практика, эти 5% допилок окажутся такой головной болью в будущем, что сделать 100% функционала на фреймворке будет дешевле и быстрее.
    Ответ написан
    Комментировать

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

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