DEV beta •
  • Войти
  • Регистрация

Что такое ценное программное обеспечение?

Юзабилити 65 дней назад ( 5 февраля 2021)

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

Что такое ценное программное обеспечение?

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

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

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

  2. Часть вторая: напишите код, который будет обрабатывать все возможные входные данные, определенные в первой части, и давать правильные выходные данные. Это будет «функциональность».

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

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

Давайте рассмотрим каждую из этих трех частей более подробно.

Часть первая: требования

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

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

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

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

Часть вторая: функциональность

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

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

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

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

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

Часть третья: рефакторинг

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

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

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

Вы меняете названия переменных - запускаете тесты. Если все хорошо, продолжайте. Вы меняете название методов - запускаете тесты. Вы извлекаете метод или новый класс - вы запускаете тесты.

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

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

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

Это приводит нас к TDD (разработка через тестирование).

По материалам:

  • A simple process to boost productivity while developing software
  • Экстремальное программирование
  • Разработка через тестирование

~

# разработка
German (Герман) +9
94
+3

Читать

Почему так важен UX?
Минимализм и простота (веб-дизайн 2021 года)
Минималистичный интерфейс
Комментарии (1)
Evg 5 февраля 2021 в 08:11 # +2

На AreaDev процесс находится где-то в середине второго пункта. Третья часть: реорганизуйте код, чтобы сделать его максимально полезным вообще не делалась. Код необходимо отдать человеку, для которого php является «родным» языком. А далее, отдать на проверку по безопасности. Вот почему, говорю - работы очень много.

[-] [+] Ответить
Комментарии скрыты...
+ Добавить комментарий
Юзабилити Юзабилити
+ 97 Создан: 2020-12-23 08:20:24
Юзабилити (UX/ UI) Из меня плохой писатель, буду писать редко. Только замечания, предложения.

Комментарии

01
Даешь революцию! А то расслабились, шуточки все. ) Ладно пошел далее...
+ 2 — вчера в 10:14
02
Ого сколько букв. ) It's amazing!
+ 3 — вчера в 10:04
03
Tildes да, Python + PostgreSQL. Ссылку где-то у них в документации можно...
+ 2 — 8 апреля 2021
04
А они Open source?
+ 1 — 8 апреля 2021
05
Интересные материалы, где вы только их находите. :)
+ 2 — 7 апреля 2021
все...

О блоге

О блоге Правила

Информация

Все блоги Статистика блогов

Другое

Участники Комментарии

Соц. сети

AreaDev © 2021 — скрипт мультиблога
↑