HowToCode — Адаптация системного подхода к разработке для React и TypeScript

[Vadem]

Спасибо за статью. А можно ссылку на курс в личку?

[yadg]

Добрый день. Видимо по правилам песочницы ссылки из статьи удалили.
Ссылка на курс — edx.org/course/how-to-code-simple-data
Ссылка на книгу — htdp.org/2003-09-26/Book/

[Vadem]

Спасибо!

[LyuMih]

@yagd Тоже интересно посмотреть курс. Буду благодарен за ссылку на него или название

[funca]

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

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

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

[vsh797]

Проектирование наперед всей задачи сверху-вниз

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

[vsh797]

Это две стороны одной медали. Вам все равно нужно сначала сформировать виденье, что вы в итоге хотите получить. А его детали вы можете прояснять итерационно уже в ходе решения.

[yadg]

Вы абсолютно правы в том, что жизнь всегда вносит свои коррективы. Именно поэтому, всё, что описано в статье — ни в коем случае не обязательные требования, а только рекомендации, которые вы можете применять, а можете не применять в той или иной ситуации.
В любом случае, на мой взгляд, «Даже плохой план (алгоритм разработки) лучше его отсутствия»

[DeepHill]

Интересно на какой курс вы ссылаетесь изначально ( ссылка удалена почему-то)

[yadg]

Добрый день.
Ссылка на курс — edx.org/course/how-to-code-simple-data
Ссылка на книгу — htdp.org/2003-09-26/Book

[IAmAbbit]

Подскажите, пожалуйста, как можно найти упомянутый курс

[yadg]

Добрый день.
Ссылка на курс — edx.org/course/how-to-code-simple-data

[kellas]

Давайте только не применять эти правила если код функции меньше хотя бы 20 строк и от результата ее ничего не зависит )

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

ну и просто пример нормального рабочего решения без заморочек.

const getWorkDuration = (worktimeFrom, worktimeTo) => {
    let diff = new Date('1/1/1 '+worktimeTo).getTime() - new Date('1/1/1 '+worktimeFrom).getTime()
    if (diff < 0) diff += 24*60*60*1000

    const [hh,mm] = new Date(diff).toISOString().substr(11,5).split(':')

    return `${Number(hh)}ч` + (Number(mm) ? ` ${Number(mm)}мин` : '')
}

Такое не нуждается в тестах — потому что тут просто форматирование входящих данных то есть нет никакой логики, никакое состояние не меняется.