Отделение по сравнению с YAGNI
Благодаря некоторому программисту, чувак, я все заработал. Я напишу это здесь для ясности.
Сначала я добавил все файлы .o в add_executable. После этого я добавил язык в команду проекта, но он не работал, все еще имел
CMake Error: CMake can not determine linker language for target: myProject
CMake Error: Cannot determine link language for target "myProject"
, поэтому я добавил set_target_properties. Сначала название проекта, затем PROPERTIES, затем то, что я хотел установить: LINKER_LANGUAGE, затем язык.
Мой файл в итоге выглядел так:
cmake_minimum_required(VERSION 3.12)
project(myProject)
set(CMAKE_CXX_STANDARD 14)
add_executable(myProject
first.o
second.o
third.o
fourth.o)
set_target_properties(myProject PROPERTIES LINKER_LANGUAGE CXX )
9 ответов
Это кажется мне, отделение и YAGNI являются очень дополнительными достоинствами. (Я просто заметил ответ Rob, и кажется, что мы находимся на той же странице здесь.) Вопрос состоит в том, сколько отделения необходимо сделать, и YAGNI является хорошим принципом, чтобы помочь определить ответ. (Для тех, кто говорит о поблочном тестировании - если необходимо разъединиться, чтобы сделать модульный тест, затем очевидно, не применяется YAGNI.)
Я действительно искренне сомневаюсь относительно людей, которые говорят, что "всегда" разъединяются. Возможно, они всегда делают каждый раз, когда они думают о нем. Но я никогда не видел программу, где дополнительные слои абстракции не могли быть добавлены где-нибудь, и я искренне сомневаюсь, что существует нетривиальный пример такой программы там. Все чертят линию где-нибудь.
На основе моего опыта у меня есть код deoupled и затем никогда не используемый в своих интересах дополнительная гибкость почти так же часто, как я оставил код связанным и затем должен был возвратиться и изменить его позже. Я не уверен, означает ли это, что я хорошо сбалансирован или одинаково прерван оба направления.
Я (почти) всегда разъединяюсь. Каждый раз, когда я сделал это, я нашел это полезным, и (почти) каждый раз, когда я не сделал я должен был сделать это позже. Я также нашел хорошим способом сократить число ошибок.
Я сказал бы, что они не делают. Отделение о сокращении ненужных зависимостей в рамках кода и закручивания доступов через чистые, четко определенные интерфейсы. "Вы не собирается нуждаться, это" является полезный принцип, который обычно отговаривает от сверхрасширяемости и чрезмерно широкой архитектуры решения, где нет никакого очевидного и текущего варианта использования.
Практический результат их - то, что у Вас есть система, где намного легче осуществить рефакторинг и поддержать отдельные компоненты, непреднамеренно не вызывая волновой эффект через целое приложение, и где нет никаких излишне сложных аспектов к дизайну - это столь просто, как требуется, чтобы отвечать текущим требованиям.
Если бы "поблочное тестирование является болью в заднице", затем я сказал бы, что Вам действительно нужен он. Большую часть времени отделение может быть достигнуто с фактически нулевой стоимостью также, итак, почему Вы не хотели бы делать это?
Кроме того, одна из моих самых больших проблем, когда работа над новой кодовой базой должна отделить код, прежде чем я смогу начать писать модульные тесты, когда введение интерфейса где-нибудь или использование внедрения зависимости могли сэкономить много времени
Отделение ради отделения может быть плохим. Создание тестируемых компонентов очень важно все же.
Твердая часть истории должна знать, в когда и каком количестве отделения Вы нуждаетесь.
Как Ваш тег говорит, это очень субъективно. Это опирается полностью на Вашу собственную техническую мудрость для решения то, в чем Вы "не собираетесь нуждаться". Вам, возможно, понадобится связь в одном случае, но Вы не будете в другом. Кто должен сказать? Вы, конечно.
Для решения, таким образом субъективного, затем, не может быть инструкции для предписания.
Ну, YAGNI является немного больше, чем поддельная упрощенная фраза людьми бросок вокруг. Отделение, однако, является довольно хорошо понятым понятием. YAGNI, кажется, подразумевает, что каждый - своего рода экстрасенс. Это просто программирует клише, которое никогда не является хорошей идеей. Честно говоря, существует случай, который будет сделан этим, YAGNI, вероятно, не связан с отделением вообще. Связь обычно "более быстра" и, "кто знает, являетесь ли Вы Вами, испытывают необходимость в отделенном решении; Вы не собираетесь изменять X компонентов так или иначе!"
YAGNI путаница :)... действительно, у нас не должно быть всего кода, смешанного для движения "быстрее".
Модульные тесты действительно помогают на чувстве, когда оно связано (учитывая, каждый понимает хорошо, что является модульным тестом по сравнению с другими типами тестов). Если Вы вместо этого делаете это с, "Вы не можете разделить компоненты" мышление, можно легко добраться для добавления материала, в котором Вы не собираетесь нуждаться :)
Я сказал бы, что YAGNI входит, когда Вы начинаете скручивать и изменять логику все вокруг вне фактических сценариев использования, текущая реализация призывает. Позволяет говорят, что у Вас есть некоторый код, который использует пару внешних платежных поставщиков что обе работы с перенаправлениями на внешний сайт. Нормально иметь дизайн, который содержит все в чистоте, но я не думаю, что нормально начинать думать о поставщиках, которых мы не знаем, будет ли когда-либо поддерживаться, которые имеют много другого способа обработать интеграцию и связанный рабочий процесс.
ЯГНИ - это практическое правило (а не религия). Разделение - это более или менее техника (а не религия). Так что на самом деле они не связаны и не противоречат друг другу.
YAGNI о прагматизме. Предположим, вам что-то не нужно, пока вы это не сделаете.
Обычно предполагается, что YAGNI приводит к развязке. Если вы вообще не применяете этот нож, вы в конечном итоге предполагаете, что вам нужны классы, которые знают все о поведении друг друга, прежде чем вы продемонстрируете, что это правда.
«Разъединение» (или «слабая пара») это глагол, поэтому он требует работы. ЯГНИ - это предположение, к которому вы приспосабливаетесь, когда обнаруживаете, что оно больше не соответствует действительности.