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

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

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

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

Узнайте, как создавать вещи для людей

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

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

Придерживайтесь нескольких языков. Овладейте ими.

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

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

Не следите за ажиотажем

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

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

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

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

Придерживайтесь стиля

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

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

Реализуйте минимально жизнеспособное решение

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

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

Избегайте сложностей

Я не использую препроцессоры CSS или HTML, такие как HAML или Sass (если они работают на вас, отлично, пожалуйста, используйте их и будьте продуктивными!) - мой стиль кодирования и доработки приложений требует много усилий, и мне легче, если Я могу возиться с этими вещами на низком уровне (например, просто копируя и вставляя стили, которые я испортил в инструментах разработки браузера, напрямую в файл CSS).

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

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

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

Кодирование ›Конфигурация

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

Ваш мозг настроен на поиск легкого выхода. Он скажет вам просто добавить в него компонент или библиотеку, и большинство программистов согласятся. Зачем изобретать велосипед? Сильно страдаете от НИЗ?

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

Вы программист, а не конфигуратор.

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

Вы будете удивлены, как мало времени вы на самом деле тратите на кодирование по сравнению с тем, сколько времени уходит на выбор библиотек и их настройку.

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

Никогда не переставай учиться

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

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

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

Изначально этот пост был размещен в моем блоге по адресу http://mir.aculo.us/2015/08/25/how-to-actually-ship-software-that-actually-works.

Хотите раскрутить свой собственный бизнес в сфере программного обеспечения или продуктов?
Не знаете, с чего начать?
Получите Бесплатное руководство Эми Хой из 7 частей уже сегодня!