Ответ 1

Сколько подготовки слишком много, мало ли мало?

В зависимости от опыта и сложности проекта/размера. С гибким подходом вы должны план для самого простого приложения, которое дает вашему клиенту (или пользователю) некоторую ценность и вписывается в короткий цикл (1-3 недели). У вас уже есть прототип и макет поэтому ваши варианты использования и требования несколько ясны. Но вы все равно должны планировать подмножество вашего приложения, которое будет выполнено в течение определенного срока. Если вы планируете большой фронт, вы столкнетесь с серьезными проблемами, которые, вероятно, замедлят вас. Это потому, что вы пытаетесь разработать программное обеспечение для решения этой проблемы. Но достаточно часто вы найдете гораздо более простое решение, если вам действительно нужно справиться с проблемой или исчезнут, потому что некоторые требования изменились или упростились. Представьте, что вы пишете приложение для блога. Очевидно, вам нужен виджет WYSIWYG. Наверху вы проводите время оценивать существующие решения или даже писать их самостоятельно. В итоге получается, что большинству пользователей нравится придерживаться простого текста или просить упростить разметку. Вы потратили 3 дня на несколько недель. Начните очень простые и простые, вы узнаете, когда люди нуждаются в чем-то более фантастическом.

Какую работу с высокой прибылью мы должны сосредоточить в начале нашего проекта?

Не уверен в этом вопросе. Если вы говорите о базе данных и OO-дизайне, то это Не может быть высокой окупаемости. Обычно простая схема db объединяется внутри минут и развивается с течением времени (включая рефакторинг, нормализацию). То же самое касается вашей архитектуры. Это опять же зависит от вашего опыта, если вы мало знаете о нормализации данных или как применять MVC (даже на очень низком уровне), тогда вы должны немного.

Как мы должны судить о том, над чем стоит работать, кодекс (а не функции) на данном этапе развития?

Держите его простым. Изучение полной структуры стека (например, Symfony или Cake) может сэкономить много времени, но все они имеют приличную кривую обучения, и вы столкнетесь с проблемами, которые не являются тривиальными (по крайней мере, для масштабирования/производительности). Достойная абстрактная кодовая база не всегда не нужны и не полезны, для меня достаточно, если это можно проверить. С небольшими проектами хобби или Экспериментальные вещи Я охватываю простоту PHP.

Стоит ли тратить время на реализацию таких вещей, как xCSS и другие системы, которые облегчат запись чистого кода с самого начала?

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

С годами я все более консервативен в отношении таких инструментов и библиотек. Обычно вы столкнетесь с некоторыми ограничениями или проблемами и должны выполнять уродливые обходные пути или вам нужно копать и понимать весь источник. Если это дает вам какая-то огромная ценность, это может стоить того, но, как я уже сказал, xCSS - это игрушка.

Как бы вы объяснили ему значение мелкозернистых задач и совершили небольшие атомные изменения.

Возможно, это недоразумение от одного из вас или обоих. Тонкозернистый не означает, что вы должны совершать каждый приемник/сеттер или любой новый метод отдельно. Обычно это логично когерентная фиксация (которая должна работать).

Примеры:

• ошибка # 2134 исправлена: пароль администратора пуст
• добавлена ​​основная модель книги с тестами
• добавлена ​​логика к модели книги, все тесты проходят
• добавлен еще один тестовый тест
• перенесенная кодовая база в книгу
• удаленный старый файл funcs_book.php
• реорганизованный фронт-контроллер для поддержки функций как контроллера

Коммиты и комментарии должны упростить поиск, когда были введены ошибки или когда codebase изменилась. Хорошим правилом является наличие в качестве комментариев одного лайнера, что весьма полезно для анализировать журналы SCM. С большими и некогерентными фиксациями, которые содержат подробные или даже анонимные комментарии вы практически вынуждены смотреть на набор изменений. Также возможно экспортировать определенные изменения в виде патчей, которые легко применять к другим ветвей или даже репозиториев.

Что вы сделали с кодом, который привел к более раннему времени на корабле?

• не бойтесь бросать старый или нечитаемый код (с помощью SCM)
• использовать библиотеки поставщиков только для сложных или сложных задач.
• рефакторинг регулярно
• Не заставляйте его выглядеть причудливым, упростите его.
• охватывайте свой язык. иногда функция > класс

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

Думайте целостный. Простой графический интерфейс с лаконичными функциями работает хорошо, потому что он доступен и легко понять. Легко понять базовый цикл в трех строках, но абстрактное дерево объектов, в котором задействованы десятки косвенных задач. Многие разработчики этого не признают, но это действительно сложно. Отличная планировка дизайна кода впереди мертва. Рефакторинг и модульное тестирование должны вести ваш дизайн в развивающемся приложении. Однако, имея ручку и бумагу под рукой для мозгового штурма в течение нескольких минут для решения всегда здорово.

Ответ 2

Отличный зритель 37-го уровня!

Вот цитата из их онлайн-книги Получение реальности:

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

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

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

Это нормально [взломать некоторые плохие код, который все еще функционирует] из время от времени. Фактически, это часто необходимую технику, которая поможет вам сделать целая вещь Get-Real-ASAP. Но ты по-прежнему необходимо признать это заплатите его в какой-то момент путем уборки до волосатого кода или перепроектировать так называемая страница.

Короче говоря, запустите реализацию xCSS в начале, но убедитесь, что вы вернетесь к нему на более позднем этапе. Прочитайте главы 9 и 10 в разделе "Интерфейс" и "Код".

Наконец, моя любимая цитата из книги:

Постройте половину продукта, а не половину продукт. То, что вы действительно хотите сделать, это построить половину продукта, который ударяет по заднице.

Надеюсь, вы, ребята, создадите отличный продукт, который вы можете продемонстрировать миру. Устранение таких проблем быстро - еще один отличный способ сэкономить время!:)

Ответ 3

У меня нет конкретных ответов на ваши точки, но, на мой взгляд, "слишком много" - это что-то вне того, что дает вам "рабочий код"

Получите самый маленький, самый средний бит всего и запустив ASAP!

Пусть код будет уродливым - он будет заменен в любом случае Пусть дизайн выглядит как дно собаки - он все равно будет заменен Пусть вещи будут неутвержденными и небезопасными - все равно будет заменено

Идея состоит в том, чтобы как можно скорее запустить и запустить внутренний прототип. Если его можно пропустить и по-прежнему "использовать ядро ​​идеи" в браузере или еще что-то, то пропустите его.

Как только у вас есть что-то работающее, независимо от того, насколько неприятным, этот шаг 1 завершен.

Шаг 2 - круговой - вернитесь к тому, что вы уже написали, и сделайте его лучше. Затем перейдите к шагу 2

Единственная часть, которую я не пропустил на шаге 1, - это модульные тесты, и это потому, что я использую модульные тесты, чтобы изложить свою идею о том, какой код должен делать, прежде чем я его закодирую. Как только unit test пройдет, эта часть будет выполнена - NEXT!

Этап 2 включает в себя переписывание кода, поэтому он очищает и обрабатывает больше случаев краев, и он более легко обновляется, поддерживается и строится. Все они связаны с модульными тестами (и обычно включают переписывание модульных тестов).

В принципе, ваш друг прав - за исключением случаев, когда речь идет об тестировании на единицу/интеграцию

Ответ 4

Я бы сказал, что главной темой, на которой вам нужно сосредоточиться, чтобы убедить вашего друга, является "Agile Estimating and Planning". Многие считают, что "Agile" означает строгое планирование, что неверно. Scrum - основа разработки программного обеспечения на основе гибких принципов предполагает, что каждый проект начинается с плана выпуска. На большинство ваших вопросов будет дан ответ на основе руководства Scrum.

Сколько приготовлено слишком много

Давайте сделаем шаг назад, чтобы понять, что означает "prep", он имеет более глубокий смысл, чем просто один огромный сеанс планирования и дизайна. Prep будет означать - планирование выпуска Scrum, планирование Sprint или Iteration, планирование ежедневных встреч. Вы действительно никогда не прекращаете свою "подготовительную" работу, это продолжается. В тот момент, когда вы не планируете, это тот момент, когда вы планируете потерпеть неудачу. Планирование выпуска Scrum обычно требует не более 15-20% времени, затраченного организацией на создание традиционного плана выпуска. На этой встрече я предлагаю вам написать историю пользователей Business EPIC и техническую информацию о EPIC User, а также быстро разбить их на куски. Вам не нужно вдаваться в детали, детали будут учтены в планировании Sprint. Во время планирования Sprint просто выходите за высокопоставленные пользовательские истории до нужного уровня детализации и обязуйтесь завершить их в своей текущей итерации. Планирование Sprint не должно превышать 4 часов для 2-недельной итерации. И ежедневные собрания Scrum sync up будут продолжаться только 15 минут, так как это всего лишь 2 из вас, это может быть короче.

как мало мало?

Вы бы знали, что вы слишком подготовили слишком мало, когда вы взорвались с препятствиями, когда на самом деле пытаетесь выполнить работу во время итерации. Когда все идет достаточно гладко, вы знаете, что потратили нужное количество времени на подготовку.

Какую работу с высокой прибылью мы должны сосредоточить в начале нашего проекта?

Попробуйте сосредоточиться на ответе на этот простой вопрос ниже: "Как мы можем наилучшим образом превратить видение в выигрышный продукт?" Бизнес-история EPIC, техническая история EPIC - это будет ваше видение продукта с технической и инфраструктурной точки зрения. Например, вы собираетесь использовать TDD, план непрерывной интеграции, план контроля версий и т.д. Вы никогда не сможете игнорировать их, сколько вы пытаетесь. Другое дело, выяснить, кто ваши пользователи продуктов. ROI и штрафа за высокопоставленные пользовательские истории. Done Criteria для вашего продукта, который также применим к небольшому фрагменту вашего продукта. Я могу продолжать и продолжать, поэтому я остановлюсь здесь.

Как мы должны судить о том, над чем стоит работать, кодекс (а не функции) на данном этапе развития?

Разумный код, самая достойная вещь для работы - это часть кода, требуемая для кодирования, чтобы получить самую высокую ценность, которая работает и поставляется. Вы можете сделать это, вычислив ROI и штраф за то, чтобы не сделать это. Вы должны будете знать, кем будут пользователи, преимущества этой функции для пользователей и влияние на пользователей, если эта функция будет или не будет доставлена. Повысить рентабельность инвестиций и пенальти - повысить ценность. Я знаю, что это легче сказать, чем сделать, но кто сказал, что программное обеспечение было легко?

Стоит ли тратить время на реализацию таких вещей, как xCSS и другие системы, которые облегчат запись чистого кода с самого начала?

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

Как бы вы объяснили ему значение мелкозернистых задач и совершили небольшие атомные изменения.

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

Я бы объяснил это так: подумайте о своем продукте как многослойном пироге. Прежде чем вы начнете строить весь торт, вам нужно знать, какой он будет торт, и сколько разных слоев он будет иметь. Вкус - это макетные экраны и истории пользователей EPIC, а слои - из технической истории EPIC. Слоями будут база данных, средняя посуда, код на стороне сервера, html, скины и т.д. Теперь создание полного торта за один раз было бы плохой идеей, потому что любители торта часто меняют свое мнение о том, какой торт они хотят есть. Целый пирог может занять больше времени, чем небольшой кусочек, и что, если после того, как вы построите целое, скажем, шоколадный торт, клиент попросит морковный пирог? Это сделало бы для некоторого выброса торта или кода:) Вместо этого, почему бы не построить один небольшой вертикальный срез за раз, пусть клиент попробует его, получит некоторую обратную связь, соответствующим образом изменит следующий фрагмент и продолжит добавлять срез срезом для создания целого торт, который клиент действительно хочет!

Что вы сделали с кодом, который привел к более раннему времени на корабле?

Используемые развязанные конструкции, использование наследования интерфейсов больше, чем наследование классов, обзор кода, TDD, PMD, Checkstyle, Pair, Collaboration with customer, список можно продолжить. Все это приведет вас к тому, что ваш продукт будет "Готово". Чем больше перечисленных выше предметов вы пропустите позже, тем дальше вы нажимаете дату своего корабля. Я бы предпочел поставить вкусный и высококачественный небольшой кусочек торта клиенту, а не низкое качество, еще не сделанное срез.

Ответ 5

Найдите 5-10 человек, которые, по вашему мнению, будут заинтересованы в вашем сайте, чтобы опробовать его. Если вы не можете этого сделать, вам нечего спорить.

Получение данных перед пользователями должно касаться двух проблем:

• У вас есть достаточно возможностей, чтобы пользователи "получали" вашу программу.
• Сделайте пользовательский интерфейс привлекательным и производительность достаточно хорошим, чтобы они знали, что вы делаете.

Похоже, что незнакомые люди будут более критичными и никогда не вернутся на ваш сайт, если их отложить. Те, кто ближе к вам, дадут вам второй или третий шанс. Если вы хотите создать клон FaceBook, вам, по крайней мере, нужно будет загружать фотографии и делиться ими. Ожидание 20 сек. на главной странице, чтобы загрузить изображение вашего кота, требуя от пользователя вручную ввести полный путь к файлу и за 5 минут загрузить файл с размером в 100 КБ, отправит пользователям щелчок.

Ответ 6

Поскольку намерение состоит в том, чтобы быстро выпустить и опираться на него, я бы сказал, что первостепенное значение имеет использование технологий, которые вы знаете лучше всего. Если вы отличный программист OO, используйте OO. Если вы действительно понимаете базы данных, потратите несколько часов на разработку схемы.

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

Слишком много подготовки - это когда вы тратите часы/дни на что-то и не находят ответа. Решение: Идите с первым впечатлением.

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

Нет, вам не стоит ничего изучать (например, xCSS), что вы еще не знаете хорошо. Лучше использовать то, что вы понимаете, и уточнять эти знания с течением времени и , а затем нанять настоящих экспертов.

Сказав все вышеизложенное, одна вещь, с которой я всегда начинаю, состоит в том, чтобы иметь слои, чтобы поддерживать БД в логике и отдельном пользовательском интерфейсе. Когда я начал с PHP, я бы хотел, чтобы у меня была небольшая структура для выполнения всего утомительного материала (Db и т.д.), У меня его не было, поэтому в итоге я опубликовал свою работу как open source. Я бы, конечно, предложил читать как я мог бы построить Db/Logic/UI, используя мою инфраструктуру в качестве примера.