Лучшие модели для «исследовательского» кода?

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

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

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

По сути, те же свойства также полезны для большинства одноразовых исследовательских программ. Вы не хотите создавать функции, которые вам не нужны. Вы не хотите тратить время на написание, например, поддерживаемого кода, если знаете, что он не будет поддерживаться. Вы хотите использовать среду, которая уменьшает объем шаблонного кода и настройки и которая, возможно, автоматически генерирует для вас много кода, который «достаточно хорош» для вашего демонстрационного примера (на ум приходит Ruby on Rails и его функции создания шаблонов).

Мой карьерный рост зависит от того, напишу ли я «плохой» код!?

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

РЕДАКТИРОВАТЬ: конечно, это не означает, что допустимо писать код, в котором вы не уверены, правильно ли вы реализовали указанный алгоритм . Обеспечение того, что вы действительно показали то, что, как вы утверждаете, показали, является обязательным , особенно в исследовательском коде.

Я исследователь и разработчик-самоучка. Я сделал существенные проекты, которые были в основном основаны на программном обеспечении. Хотя моя работа далека от самых «хардкорных» вещей с точки зрения сложности и масштаба, проекты были достаточно большими, чтобы наивные ошибки (например, отсутствие контроля версий или плохое документирование кода) были очень болезненными. В итоге я изучил немало «лучших практик» методом проб и ошибок.

Я также был получателем «необслуживаемого кода, переданного коллеге-исследователю»:

мой промышленный опыт мешал моему исследованию

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

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

Допустим, спикер на научной конференции, описывая вычислительную часть своего исследования, сказал одно из следующего:

" Код, который я написал для этого исследования, по общему признанию... "

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

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

В академических кругах цель состоит в том, чтобы (...) в кратчайшие сроки.

Да, но " не короче ". Вы не пропускаете жизненно важные контрольные эксперименты, потому что «контроль требует времени». Вы не можете экономить на качестве кода по очень похожим причинам.

Кажется, что нет мотивации писать [хороший код]

Потому что это эндемическая проблема академических кругов. Хотя компьютеры использовались в науке на протяжении десятилетий, кажется, что алгоритмы стали важной частью исследований только в последнее десятилетие или около того (возможно, из-за «больших данных»). Когда вы основываете свое исследование на коде, этот код должен быть хорошего качества. Недостаточно просто запустить какой-нибудь глючный скрипт только для записи и покончить с этим. Сообщество разработчиков программного обеспечения давно во всем этом разобралось, но научное сообщество еще не прижилось — я думаю, причина в том, что большинство ученых не имеют формального бэкграунда в разработке программного обеспечения, и не было достаточно громких скандалов в исследованиях, вызванных из-за плохой практики программирования (например, ключевые результаты высококлассной статьи оказываются артефактами, вызванными ошибками).

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

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

К сожалению, вы можете не получить вознаграждение за дополнительную работу. Вас могут даже наказать, потому что, как вы говорите, хороший код занимает больше времени, и другие могут не видеть дальше этого. Ваш PI или коллеги могут не понять, почему вы так медленнее. Лучшее, что вы можете сделать, это объяснить им необходимость хороших практик.

Очевидно, что есть исключения. Например, вам не нужно беспокоиться о переносимости или обратной совместимости со старыми версиями ОС для кода, предназначенного для работы на выделенном лабораторном компьютере (хотя нежелательно писать свой код таким образом, чтобы он работал только в очень экзотическом среду, которую другие ученые не смогут легко реконструировать). Но в целом я считаю, что отраслевые практики все еще применимы, и исключения можно легко обнаружить, приложив немного критического мышления. Тем не менее, есть также полезная публикация под названием " Best Practices for Scientific Computing ", в которой подробно рассматривается этот вопрос.

В конечном счете, это этическое решение, которое вы должны принять. Вы заботитесь о том, чтобы заниматься наукой превыше всего? Следуйте рекомендациям. Вы хотите срезать углы, которых не должны (в этическом смысле), сэкономить время или избежать трений с коллегами? Я не мог бы рекомендовать вам сделать это, в принципе. Но очевидно, что многие люди это делают, и, возможно, на практике некоторые ученые вынуждены это делать — хотя, опять же, разве неспособность заниматься хорошей наукой в ​​силу обстоятельств оправдывает плохую науку?

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

Я либо трачу слишком много времени (без необходимости) на доведение моего «исследовательского» кода до отраслевого качества

Не. Сделайте это как можно лучше в течение предложенного периода времени. Стремление к 100% совершенству, которое потребует вдвое больше времени, не стоит того. В этом смысле исследования точно такие же, как и промышленность.

Следовательно, «академический» код, который я написал, имеет низкое качество.

Это не означает, что весь академический код имеет низкое качество. Если вы посмотрите статьи на конференциях по алгоритмам или системах параллельной обработки, вы увидите, что разработчики продумали даже мучительные детали, такие как переупорядочение данных для уменьшения количества промахов кэша, SIMD, программирование графического процессора, хранилище SSD и т. д. Обычно передовые исследования алгоритмов CS занимают несколько лет. впереди в принятии новых методов, аппаратных технологий, прежде чем любой из этих методов действительно попадет в отрасль. С другой стороны, на более теоретических конференциях по CS код в основном является инструментом, и поэтому он не обязательно должен быть передовым. Итак, качество связано с аудиторией вашего продуктового кода (точно так же, как и индустрия).

Кто-нибудь знает о формальных методологиях для «исследовательского» кода?

Я никогда не слышал о каких-либо методах, специально предназначенных для исследования кода. Тем не менее, вы можете использовать практики из вашей отрасли (когда они действительно ускоряют процесс написания программного обеспечения). Например, система управления версиями ускоряет разработку и минимизирует ошибки/потери данных. С другой стороны, UNIT-тесты занимают много времени, которого у вас может и не быть. Неформальная вики для ошибок, документации, функций может стоить дополнительного времени, поскольку она также ускоряет написание фактической исследовательской работы. И наоборот, полноценная база данных ошибок (bugzilla) может не стоить дополнительного времени и усилий.

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

tl;dr Некоторые части отраслевых «лучших практик» хорошо вписываются, а другие части неэффективны в исследовательской среде. Сохраняйте то, что хорошо работает в этой среде.

Я физик-экспериментатор элементарных частиц, и мы пишем много кода, и большая его часть — большие проекты, написанные многими разрозненными программистами.

Некоторая часть обычного отраслевого набора инструментов, который мы используем с энтузиазмом

• Контроль версий
• Отслеживание ошибок
• Автоматизированные системы сборки и тестирования

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

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

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

• Модульное тестирование разрежено и обычно концентрируется на нижних уровнях системы, но регрессионное тестирование встречается чаще.

• У большинства проектов есть стандарты кодирования, но они, как правило, слабо определены и слабо соблюдаются.

Другие простые вещи не проявляются много.

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

• Раньше было правдой, что строгий контроль регистрации мешал распространению экспериментальных сегментов кода, и мы просто время от времени замораживали новые проверки разработки, чтобы получить благословенный релиз (ситуация, которая отображала HEAD/trunk/что-то еще). предложение «используйте на свой страх и риск»). С появлением распределенного контроля версий все больше внимания уделяется контролю регистрации для официальной магистрали.

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

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

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

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

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

Наконец, правильная разработка программного обеспечения — это прекрасное искусство, которым очень трудно овладеть. Даже в отраслевых условиях уродливое программное обеспечение встречается в изобилии (когда оно написано профессионалами!). Средний исследователь не имеет формального обучения написанию программного обеспечения.

Мой карьерный рост зависит от того, напишу ли я «плохой» код!?

Как исследователю, вам не платят за разработку программного обеспечения (к сожалению). Как идеалист, мне хочется верить, что со временем это изменится, но пока источники финансирования заботятся только о бумагах.

«Ремесло» разработки программного обеспечения — обширная тема, но где лучшая практика для академических исследований? Никто не пишет модульные тесты для кода конференции!

Модульные тесты служат двум основным целям: (i) подтверждают, что код работает правильно и (ii) быстро находят и устраняют проблемы, особенно после структурных изменений и рефакторинга (долгосрочное преимущество для крупных инфраструктур). Поскольку исследовательское программное обеспечение обычно довольно мало, первое преимущество является единственным, которое действительно имеет значение. Представляется, что это преимущество либо слишком мало, либо его недооценивают (опять же, напомним, что большинство исследователей не инженеры -программисты).

Кто-нибудь встречал их в похожей ситуации? Кто-нибудь знает о формальных методологиях для «исследовательского» кода?

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

Вместо того, чтобы говорить о различиях с отраслевой разработкой программного обеспечения (в которой у меня нет опыта), я хотел бы поговорить о том, что вы должны делать в академических кругах. Я буду предполагать, что ваш код существует не сам по себе, а связан с каким-то научным утверждением, таким как «E. coli разделяет геном foo с людьми» или «Алгоритм A превосходит алгоритм B в сценарии Z».

• Лучшее усилие

  Хотя вашей целью не является продуктивное использование с привязкой к нему дохода, вы должны иметь разумную степень уверенности в том, что ваш код делает то, что вы заявляете, и может быть понят (проверен экспертами!) заинтересованными сторонами. То есть писать понятный код, комментировать и документировать. И (юнит-) тест.

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

• Доступность

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

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

  Рассмотрите возможность размещения своего кода на Github или аналогичной платформе (например, вашей собственной ). Таким образом, вы можете легко публиковать обновления и собирать ошибки. См. также здесь и здесь .

• Лицензирование

  Вы должны сказать что-то о том, что другие (в частности, коллеги-исследователи) могут или не могут делать с вашим кодом. Вы можете использовать любую лицензию (я бы сказал, что она должна разрешать, по крайней мере, свободы GPL). CRAPL стоит посмотреть .

• Справедливая оценка

  Если ваш алгоритм/код является артефактом, который вы предлагаете (как лучший), вы должны сравнить его с существующими решениями. Обязательно используйте сопоставимые входные данные, повторите эксперимент для альтернатив и следуйте основным экспериментальным методам (например, ознакомьтесь с работой МакГеока). Убедитесь, что ваше сравнение включает принятые стандарты в вашей области, если таковые имеются; если ваш подход дает другие результаты, вы должны объяснить, почему (это нормально/правильно/лучше).

Доступность, пожалуй, самый важный пункт. Код исследования должен быть общим. Я думаю, что это невозможно переоценить, и это одна из главных проблем во всей вычислительной науке. Помимо, скажем, физики, у нас есть возможность легко делиться и воспроизводить (большинство) экспериментальных установок — мы должны этим пользоваться.

Лично я не понимаю, почему любая статья, которая основывает свои утверждения на вычислениях, которые рецензенты (и другие стороны) не могут воспроизвести, имеет какое-либо право на публикацию.

Одно напоминание для всех типов теории:

Остерегайтесь ошибок в приведенном выше коде; Я только доказал, что это правильно, не пробовал.
_{Дональд Э. Кнут}

Я думаю, ваша проблема в том, что вы видите качество как бинарное.

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

Целями качества могут быть:

• Время безотказной работы
  
  • Вас наверное это не волнует
• Надежность
  • Вам нужно будет работать с большим количеством разных наборов данных или это будет один?
• Возможность повторного использования
  • Будет ли процессинг включен в следующую проблему, над которой вы будете работать?
• Возможность проверки
  • Работает ли он так, как должен? Что бы это значило, если бы вы опубликовали, а это неправда?
• Возможность проверки
  • Выдает ли он правильный ответ? [Надеюсь, это имеет значение. ]
  • Другой способ проверки правильности ответа может означать, что не имеет значения, ошибочна ли логика.
• Необходимо поддерживать
  • Себя
  • Другой эксперт
  • Какой-то случайный студент
  • Или обязательно выбросить.
• Подходит для обнародования для использования другими для проверки или повторного использования вашей работы.
• И т. д.

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

Меня направил на этот вопрос парень в ответ на мой запрос на разъяснение «Почему они использовали тип с плавающей запятой в качестве ключа для хэша». Сейчас мне это не показалось хорошей идеей. Немного повозившись взад-вперед, спрашивающий направил меня сюда как причину, по которой они это сделали.

Это было интересно, как и сам вопрос.

Вас уговаривают писать плохой код для достижения определенных академических целей? Да еще на курсах CS могу добавить. По крайней мере плохо с точки зрения понятности. Однако, как мы все слишком хорошо знаем, нас «уговорили» писать такой же плохой код в коммерческой среде, или наших лордов и хозяев убедили написать для них плохой код....

Не говоря уже о тривиальных реализациях алгоритмов. Например, следует ли использовать i и j в качестве переменных цикла в алгоритме пузырьковой сортировки или вообще использовать пузырьковую сортировку. Мой ответ на ваш вопрос будет другим. Как хорошие принципы разработки программного обеспечения помогают вам в достижении ваших целей?

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

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

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

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

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

Перефразируя Гэндальфа: «Будь проще, будь в безопасности».

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

В любой коммерческой или академической среде выбор более низкого качества является как преимуществом, так и затратами, изучите и то, и другое....

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

• Академия -> прототипы.
• Промышленность -> продукты.

Продукты и прототипы не должны рассматриваться в соответствии с одними и теми же стандартами.

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

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

---- Редактировать

Мой карьерный рост зависит от того, напишу ли я «плохой» код!?

Уход из академии напомнил мне, что существует нечто иное, чем бумажно-ориентированный метод работы, которому обучают аспирантов (и результаты которого часто имеют меньшее количество читателей, чем количество соавторов).

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

Кроме того, это не только проблема, связанная с кодированием!

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

У меня проблема с постановкой вопроса:

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

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

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

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

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