Как создавать софт, который действительно работает?
Вы на самом деле думаете, что у вас есть все для создания классного софта? Я открою вам один секрет: это нелегко и требует больших усилий, но всему этому можно научиться.
Вот мой список того, что необходимо для разработки проектов программного обеспечения, которое действительно хорошо продается и хорошо работает:
Научитесь создавать продукт для людей
Создание продукта для людей – это такое же умение, как и многие другие, и ему можно научиться. Я не имею ввиду визуальный дизайн (хотя это тоже является частью процесса). Я говорю скорее о том, чтобы распознать проблему и понять, как обеспечить такое взаимодействие человека с компьютером, которое гарантирует пользователю успешное решение проблем без каких-либо затруднений, вместо того, чтобы просто создавать самое что ни на есть стандартное CRUD-приложение для работы с базами данных, которое включает несколько типичных UI-компонентов.
Для этого на первых порах можно делать следующее: анализировать софт других разработчиков и то, какие задачи вам нужно решить с помощью данных программ, и что вам нужно сделать, чтобы решить их. Например, как много кликов мышкой мне нужно сделать в программе для работы с электронной почтой для того, чтобы написать ответ? Сколько мне нужно прочитать меток? Как часто мне нужно переключаться между мышью и клавиатурой? Помогает ли мне это в решении общеизвестных задач. Как насчет поиска всех вложений из писем от определенного человека – вы будете удивлены тем, как трудно это сделать с использованием ПО!
Освойте и используйте несколько языков
Если другой язык (или другая среда разработки) является лучшим решением или дает вам большие преимущества, то используйте его. Часто овладение очередным инструментом не стоит дополнительных усилий.
Не стоит недооценивать значение чего-то нового для рабочей среды: все новинки должны быть проверены, задействованы, защищены, должен быть произведен контроль – а это может занять годы.
Не ведитесь на рекламу
Используйте то, что является для вас наилучшим. Если ваша продуктивность высока на PHP, то и работайте с PHP. Конечно, иногда технологии на самом деле способны увеличить продуктивность или дать другие существенные преимущества, но я не преувеличу, если скажу о том, что это огромная редкость – такое встречается, пожалуй, раз или два в десятилетие.
Не попадитесь на крючок, поверив, что основная идея хороша только потому, что существует множество вариаций конкретной технологии. На самом деле это может указывать на то, что люди отчаянно ищут технологическое решение для неправильного подхода.
Для примера, MVC на стороне клиента для практически любого типа функциональности веб-приложения добавляет оверхэд (потому что при большем количестве слоев и необходимо больше интерфейсов между ними), уменьшает продуктивность (нужно писать больше кода, а слои усложняют процесс устранения ошибок) и на деле не улучшает пользовательский опыт.
Дизайн пользовательского интерфейса – это тяжелая работа, и использование MVC на стороне клиента не сотворит для вас магии.
Придерживайтесь одного стиля
Вместе с языками, фреймворками, библиотеками меняется и то, как вы используете язык – подобно сезонам. Один месяц вы вовсю использовали замыкания (closure), а в следующем узнаете, что это уже устарело.
Попробуйте уменьшить когнитивный стресс во время написания кода и отладки, чтобы вы могли спокойно думать над решением проблем, которые вам действительно надо решить.
Внедряйте минимально жизнеспособное решение
С этим нельзя переборщить: во время написания кода не пишите ничего, в чем код на самом деле не нуждается для нормальной работы. Не думайте заранее о том, как вы сможете расширить его в будущем. Все равно вся будет так, как вы не предполагали. Сосредоточьтесь на коде, который работает, и лучше пишите тесты, нежели тратить время на абстрактные предположения.
И не забывайте: код не высечен в камне. Его несложно реорганизовать или переписать позже, когда вам действительно нужно будет изменить или расширить его, и когда вы будете знать реальные требования.
Избегайте сложностей
Я не использую такие препроцессоры CSS или HTML, как HAML или Sass (если вам удобно с ними работать, то используйте их на здоровье и повышайте свою продуктивность!) – мой стиль написания кода и «полировки» приложений требует много возни и переделок, и для меня намного проще возиться с кодом на низшем уровне (например, просто копируя и вставляя стили и работая со средствами разработки в браузере напрямую в файле CSS).
И хотя мне очень нравится CoffeeScript, для меня все же легче просто полностью написать JavaScript. Для меня недостаточны преимущества в виде немного более чистой синтаксической конструкции и лучших языковых возможностей, чтобы потом разбираться с дополнительными шагами компиляции, более сложными настройками и дополнительным уровнем абстракции при отладке.
Все эти сложности – относительны. То, что мне кажется ужасно сложным, вы можете воспринимать как простое и естественное. Чтобы понять, какие виды работ являются для вас наилучшими, потребуется время.
Будьте честны с собой – если вы чувствуете неудобство в использовании того или иного инструмента, то, возможно, не стоит пытаться приспособить это к вашему стилю работы. Просто найдите то, что вам лучше подходит.
Кодирование > Конфигурация
Легко попасть впросак, чрезмерно полагаясь на код, написанный другими людьми. Должно быть (как вы полагаете), если многие используют этот код, то он должен быть качественным. Ведь правда? Между прочим, именно поэтому большинство людей пользуются Windows. Это то, что называется «разумной достаточностью» (satisficing), или стремление к чему-то, что кажется для достаточным для человека.
Ваш мозг всегда старается найти самое легкое решение. Он скажет вам забыть о каком-либо компоненте или библиотеки, и большинство программистов согласятся с этим. Зачем заново изобретать велосипед и страдать от известного синдрома «Придумано не нами» (Not Invented Here)?
Выбор уже готового компонента – это практически всегда не самый оптимальный путь для решения проблемы. Подобные инструменты решат вашу проблему на 80%. А затем внезапно обнаружится, что для этой простой, казалось бы, вещи, которая выглядела такой простой, нет возможности конфигурации. И теперь вам нужно заняться реорганизацией исходного кода и исправлением ошибок в выбранной библиотеке, и в конечном итоге сделать разветвление кода. После этого вам нужно понять, как правильно выполнить тесты, и здесь вдруг выясняется, что возможность проведения тестов просто-напросто отсутствует. А затем… И все в том же духе.
Не забывайте, что вы программист, а не конфигуратор
Попробуйте отслеживать время и то, чем именно вы занимаетесь во время программирования. Сюда входят: размышления о способе внедрения специфической фичи, разработка человеко-машинных интерфейсов и обеспечения взаимодействия, создание планов и списков задач для внедрения определенной функции, выбор инструментов и библиотек, облегчающих работу, создание прототипов, написание самого кода, тестирование и выполнение итераций для поиска ошибок и обеспечения должной функциональности.
Вы будете удивлены тем, как мало времени вы потратили на само написание кода по сравнению с тем, сколько ушло на выбор и настройку библиотек.
Вы могли бы сэкономить кучу времени, если будете просто писать код с нуля. Я выяснил, что написание кода часто помогает мне лучше понять область проблемы, заставляю думать о пограничных случаях. Ничего подобного никогда бы не произошло, если бы я выбрал уже готовую библиотеку, которая сделает всю работу за меня.
Никогда не переставайте учиться
Возможно, наилучший способ быть всегда в теме, это время от времени выполнять различные сайд-проекты. Это отличный вариант для того, чтобы насладиться знакомством с новыми штуками без внесения «технологического беспорядка» в свой рабочий проект.
Например, напишите микробиблиотеку с открытым исходным кодом (или даже две) и используйте ее для того, чтобы делиться с другими людьми вещами, которые вы научились использовать в работе.
Экспериментируйте и переделывайте те или иные элементы, чтобы не утратить радость программирования – создания различных вещей из ничего.
7 правил написания программ, которые не умрут вместе с вами
Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Жизнь заканчивается, но программы не обязательно должны умирать.
После серии моих твитов на тему того, как нужно писать программы, меня попросили раскрыть эту тему. Предупреждаю, что редко в каком проекте удаётся чётко следовать всем семи правилам. У меня самого это часто не получается. Но чем больше правил вы соблюдаете, тем больше ваши программы проживут. Каждый символ добавляет что-то к общей экосистеме, и наша задача, как инженеров, поддерживать экосистему в чистоте и порядке.
Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости.
Разве вы хотите оставить после своей смерти миру ещё больше SEGFAULT-ов? Хотите ли вы, чтобы сисадмины занимались починкой систем, которые сломались из-за вашего дерьмового кода? Чтобы ваш менеджер проектов вспоминал вас как инженера, работа которого бесила пользователей?
Ничего плохого в быстром продвижении вперёд нет, но в какой-то момент нужно осознать, что низкокачественный код далеко вас не уведёт.
Когда вы приходите к врачу, тот сначала задаёт вам много вопросов, чтобы понять, что с вами случилось. Он не выписывает лекарства перед постановкой диагноза. Точно так же важно разобраться, действительно ли с вашим кодом что-то не так.
1. Накат обновлений отнимает много времени и сил?
2. Система рушится даже от небольшого обновления?
3. Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей?
4. Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?
5. Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?
Если вы ответили «да» – эта статья для вас. Читайте, а лучше прочтите два раза.
1. Делите на модули
Мозг человека – сложное устройство, сложнее любого процессора, при этом он не справляется с решением сложных задач. Допустим, сложно сразу умножить 13*35. Но если разделить эти операции на простые: 35*10 + 30*3 + 5*3 = 455, то подсчёт упрощается. Разбивая задачу на простые и независимые, мы приходим к ответу.
Так же и с программами. Разбейте программу на несколько частей, файлов, директорий. проектов. Все зависимости выведите в одно место, используйте принцип MVC или его вариант. Такой код и читать проще, и отлаживать легче. В большинстве случаев отладка приведёт вас к нескольким строкам кода, а не к файлу из тысячи строк. Накатывая апдейты одного модуля, вы не сломаете всю остальную систему.
2. Тестируйте
Такая реакция естественна, потому что нас учили, будто тесты не являются частью программирования. Вас учат шаблонам в С++, но не тому, как их тестировать. В этом и проблема. Некоторые считают, что тесты над писать до самой программы.
Мне всё равно, когда вы пишете тесты, если вы их пишете. Не надо геройствовать, начните с простого (print(add(1, 1) == 2)), а затем уже переходите на фреймворк для тестов в вашем языке.
Тогда вы начнёте понимать сложность вашей программы, учиться делить её на модули, части, которые можно тестировать по отдельности. Получается, что используя тесты, вы уже будете выполнять два из семи правил.
3. Непрерывная интеграция
Тесты должны успешно отрабатывать, причём в разных окружениях (например, в разных версиях Python). Также тесты надо проводить после каждого изменения. Вместо того, чтобы делать это вручную из командной строки, удобнее и быстрее создать платформу для непрерывной интеграции.
Непрерывная интеграция (НИ) – это практика разработки, при которой код интегрируется в репозиторий несколько раз в день. Каждый раз проверяется автоматически, что позволяет отслеживать проблемы на ранней стадии.
Для своих проектов я использую TravisCI и Drone.io. Когда я делаю новое дополнение кода, платформа делает билд и выполняет тесты.
4. Автоматизируйте
У больших проектов всегда есть куча мелких вспомогательных задач. Некоторые люди делают текстовики с командами и копируют их оттуда. Но проще освоить скрипты на bash (и/или Python). Вот некоторые задачи, которые необходимо автоматизировать скриптами:
— преобразование README.md в другие форматы
— автоматическое тестирование (включая создание тестовых серверов и данных, удаление временных файлов и т.д.)
— заливка кода на сервер разработки
— размещение программы на продакшене
— автоматическое обновление зависимостей
5. Избыточность
Первое, что вы видите на git-scm.com:
Git – бесплатная распределённая система контроля версий с открытым исходным кодом, предназначенная для работы как с малыми, так и очень большими проектами, с высокой скоростью и эффективностью.
Распределённая. Это ключевое слово. Ущипните себя, если вы хоститесь только на гитхабе. Потому, что это единая точка отказа. Если гитхаб падает, или во время push-операции вы повредили файлы, ваш процесс разработки останавливается.
Залогиньтесь на Bitbucket и выполните следующее в вашем репозитории:
Теперь, когда вы заливаете код, изменения идут как на Github, так и на Bitbucket. Никогда не знаешь, когда что-либо сломается. И всегда полезно иметь бэкапы. Вот, как это работает у меня:
— весь код живёт в директории Codebase в Dropbox. Автоматическая синхронизация.
— почти весь код живёт на Github
— самый важный код живёт на двух частных зеркалах – одно в школе, другое на моём AWS
Я потеряю свой код, только если настанет конец света.
6 Коммиты
Это должно быть вам знакомо. Загляните в историю, и вы увидите что-то вроде:
Исправил? Какую ошибку? В каком модуле?
Многие расценивают систему контроля версий как бэкап, а не как способ хранить историю. История из таких сообщений бесполезна. Допустим, через неделю после этого коммита вы решили что-то вернуть назад, потому что оно привнесло в проект новый баг. Но поскольку описания действия нет, вам нужно просматривать все изменения. Именно для предотвращения этого и создавались системы контроля версий.
Чтоб не напрягаться, просто воспользуйтесь следующей шапргалкой:
— у каждого коммита должен быть смысл. Исправление ошибки, добавление новой функции, удаление существующей?
— только одно изменение на один коммит
— включайте номер проблемы в сообщение о коммите
— включайте описание изменений. Это зависит от правил текущего проекта, но обычно вы упоминаете, что приводило к ошибке, как вы её исправили и как это тестировать
— пишите осмысленное сообщение:
добавил новую форму в заголовок, чтобы было легче собирать ссылки. закрыл #3
удалил всякое, ибо почему бы и нет, хех
7. Планируйте
Даже если вы выполняете все предыдущие правила и чувствуете себя богом программирования, всё равно может случиться всё, что угодно. Имейте план на самый плохой случай. Что, если трафик побьёт рекорды? Откуда вы возьмёте бэкапы, если система упадёт? Кому звонить ночью, если сервер навернётся?
Продумайте, но не перестарайтесь. Автоматизируйте всё, что возможно. Затем задокументируйте всё подробно. Так, чтобы тот, кто получит ваш код, тоже смог следовать плану. Иметь план – не только значит выглядеть умнее, это значит реально быть умнее.
Вот такие правила и определяют хорошую программу. Если вас они не убедили, ответьте мне на два вопроса:
1. Ожидаете ли вы от новичка, присоединившегося к вам, что он поймёт существующий код с лёгкостью?
2. Является ли рефакторинг кода простым и быстрым делом?
Если нет – перечитайте заново. Сохраните, поделитесь с командой.
Эти правила поначалу могут показаться очевидными. Так и есть. Плохой код постоянно создают, и, в конце концов, он умирает. Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Как писать компьютерные программы
Соавтор(ы): Archana Ramamoorthy, MS. Арчана Рамамурти — технический директор Workday (Северная Америка). Высококлассный специалист по продуктам, поборница безопасности, сторонница большего распространения интеграции на равных для всех условиях в индустрии технологий. Получила степень бакалавра в Университете SRM и магистра в Университете Дьюка. Работает в области продакт-менеджмента более восьми лет.
Количество просмотров этой статьи: 70 017.
По мере того как технология становится все более и более доступной широкой публике, растет и потребность в программистах. Написание компьютерных кодов и программ, оно же кодинг (от английского «сoding») — это навык, который приобретается и совершенствуется на протяжении долгого времени, но даже самый опытный программист когда-то был новичком. Существует большое разнообразие языков программирования, которые великолепно подходят для начинающих программистов, вне зависимости от того, в какой сфере деятельности вы хотите применять ваши навыки (например, JavaScript довольно сложен, так что лучше начать с HTML или CSS). Узнайте, как научиться писать компьютерные программы, прочитав эту статью.
Технический директор Workday
Наш специалист делится своей историей:: «Я пришла к написанию кодов, не зная ничего ни о компьютерном дизайне, ни о программировании. Когда я захотела научиться писать программы, я начала с чтения книг по языку и с использования информации из интернета. Сегодня в мире доступно так много ресурсов, что научиться новым навыкам очень легко!»
Разработка программного обеспечения для начинающих
Разработка программного обеспечения интересна как программистам, так и тем, кто таковыми хочет стать. В статье затронуты концепции, необходимые для старта.
Статья разделена на 4 части. Обратите внимание, что важные слова или словосочетания, введенные в этой серии, выделены жирным шрифтом. В конце каждого из четырех разделов будет приведена короткая викторина, проверяющая знания и подробно объясняющая некоторые моменты.
Часть 1 – Что такое программирование?
Самый простой и точный вариант ответа: «Программирование – это акт инструктирования компьютеров для выполнения задач». Еще его называют разработкой или кодингом.
Итак, что такое компьютерная программа? ПО представляет собой последовательность инструкций, выполняемых ПК. Компьютер же – это любое устройство, способное обрабатывать код. Сюда относятся стационарные ПК, ноутбуки, планшеты, банкоматы, Raspberry Pi, серверы etc.
Разработка программного обеспечения и аналогия
Во-первых, примеры программирования есть даже в повседневной жизни. Вселенная довольно предсказуема: день и ночь, времена года, восход и закат. Люди проходят через такие этапы, как встреча нового дня, посещение школы, университета или работа. Мы получаем инструкции от начальников и учителей. Также существуют рецепты, следуя которым можно приготовить блюдо.
Во-вторых, каждый раз, когда мы используем девайсы, встроенный в них код уже работает в фоновом режиме. Перемещение курсора с одной части экрана в другую может показаться простой задачей, но на самом деле за данный процесс отвечает немало строк написанного кода. Акт, столь же простой, как ввод букв в Google Docs, приводит к тому, что код выполняется в фоновом режиме. Это нормальные повседневные процессы, свойственные всем IT-устройствам.
Компьютерные программы также являются кодом. Однако лучше не использовать слово «коды»: это непрофессионально.
Естественный язык компьютера
Осваивайте языки программирования
Чтобы общаться с машинами, которые говорят на двоичном языке, мы осваиваем такие языки, которые максимально близки к нашему собственному, а именно – языки программирования. Они четко структурированы и должны быть тщательно изучены.
Существуют высокий и низкий уровни. Языки программирования высокого уровня находятся дальше от машинного, чем языки низкого уровня. Это «дальше» обычно называют абстракцией.
Компьютер нуждается в понимании нашего человеческого языка. Для этого понадобится переводчик.
Определение переводчиков
Исходный код относится к коду, написанному на выбранном языке программирования. Переводчики же несут ответственность за преобразование исходного кода в машинный язык (те самые единицы и нули). Мы можем ссылаться на двоичные файлы, такие как код объекта, программу или общепринятый сегодня термин – приложение.
Переводчики могут быть любыми:
Интерпретаторы
Чтобы разработка программного обеспечения прошла успешно, нужно понимать, что языки могут интерпретироваться. В таком случае переводчик обрабатывает исходный код по строкам и в готовой программе (приложении) также запускает каждую строку. Это означает, что интерпретируемый исходный код запускается до тех пор, пока не встретит ошибку. Затем интерпретатор перестает сообщать о таких ошибках.
Python – хороший пример интерпретируемого языка программирования.
Компиляторы
Компиляторы работают по-разному. Они полностью конвертируют исходный код с помощью компиляции в двоичный файл. Затем выполняется двоичный код. Если в исходном варианте были ошибки, они обнаруживаются и помечаются во время компиляции. Это прерывает процесс генерации двоичного кода.
Интерпретаторы работают построчно и выполняют одну линию перед тем, как перейти к следующей. Компилятор же переводит все строки программы в файл (двоичный) и выполняет его целиком.
Помните определение компьютерной программы? Это последовательность инструкций для компьютера. Выполнение программы обычно называется процессом. Такие ПО используют определенные ресурсы в компьютерной системе или любом другом девайсе. К ресурсам относятся память, дисковое пространство и файловая система.
Мы используем слово «run» при выполнении компьютерной программы. Время, затрачиваемое на запуск, называется временем выполнения программы.
Обычно рассматриваются продукты, известные как приложения. Еще мы ассоциируем программы с платформами или средами, в которых они работают или для которых предназначены. Существуют веб-приложения, запускаемые в браузерах, есть мобильные ПО, работающие на смартфонах, а также настольные, такие как Evernote.
Интерпретируемый исходный код выполняется из исходного файла, скомпилированный – преобразовывается в двоичный файл. Затем этот файл выполняется. Скомпилированный код может завершиться неудачно во время выполнения даже после успешной компиляции.
Гибридные переводчики
Гибридный переводчик представляет собой комбинацию интерпретатора и компилятора. Популярным гибридным языком программирования является Java.
Разработка программного обеспечения на Java удобна. Сначала исходный код компилируется в промежуточный формат, известный как Bytecode. Затем Bytecode интерпретируется и выполняется с помощью виртуальной машины. Это позволяет гибридным переводчикам запускать байт-код в различных операционных системах, делать его кроссплатформенным.
Ассемблеры
Ассемблер также используется для перевода низкоуровневого языка Ассемблер в двоичный, но мы сосредоточимся на языках высокого уровня.
Хороший способ понять различия переводчиков – лично увидеть их работу. Просто загрузите необходимые и установите на компьютер.
Часто задаваемый вопрос
Вот вопрос, который обычно задают начинающие: «С какого языка начать?»
Существуют сотни ЯП. Они оцениваются по популярности, комьюнити, долгосрочной поддержке, педагогике и использованию. Они также могут быть оценены по техническим параметрам. Например, являются ли они функциональными, императивными, статическими, сильными или слабо типизированными.
Некоторые языки программирования предназначены исключительно для образовательных целей, а не для использования в бизнесе. Хороший пример – ЯП для детей. Также существуют мощные языки, которые легко настроить и изучить. Python – один из них. Обычно его и рекомендуют начинающим.
Если вы заинтересованы в более подробном изучении вопроса, вот несколько хороших исследований.
Когда вы захотите изучить новый язык, понадобится переводчик языка. Это программа, которая устанавливается и настраивается в компьютерной системе.
Рекомендуем начать осваивать работу с командной строкой (CLI). Подумайте о терминале как об альтернативе графическому интерфейсу (GUI). Работая с компьютером посредством GUI, вы зависите от визуальных представлений каталогов и всего, что делаете. Но при использовании CLI вы взаимодействуете с компьютером напрямую, с помощью терминала и специальных команд.
В Windows встроенный терминал представляет собой командную строку. Для пользователей Mac и Linux по умолчанию установлен терминал Bash. Чтобы использовать его в Windows, установите Git Bash или PowerShell.
Двигаемся дальше
Приготовьтесь, ведь разработка программного обеспечения началась! Подготовимся к написанию первой строки кода. Для этого потребуется следующее:
Резюмируя вышесказанное, мы изучили основы с введением в переводчики. Слово «исходный код» уже не странно для вас. Более подробно мы рассмотрим его дальше.