Я долго думал как бы перевести на русский язык термин reusable code. Ничего лучше не придумал как использовать банальное выражение — повторяемый код. В конце концов ведь он действительно повторяемый, например, библиотека ничто иное как набор кода, который повторно используется во многих проектах.
В мире программирования есть одна очень важная аксиома суть которой заключается в том, что для того чтобы писать грамотный код, необходима практика. Постоянная практика. Практика написания кода, а также чтения своего/чужого кода. Никто сразу не может написать грамотный и красивый код.
Сначала мы пишем плохой код, учимся, анализируем свои ошибки, возвращаемся к своему коду и начинаем его рефакторить до тех пор, пока он не будет соответствовать нашему внутреннему стандарту качества. Когда этот стандарт повышается, то цикл повторяется снова.
Из этой аксиомы следует, что нам необходим источник знаний из которого мы будем питаться.
Книги
Статистика по чтению литературы обескураживает особенно сильно: средний разработчик программного обеспечения, к примеру, не имеет ни единой книги по предмету собственной работы и не может похвастать тем, что читал такую книгу
Программирование. Как начать писать программу?
Цитата взята с книги «Человеческий фактор». По опыту проведения собеседований скажу, что это правда. Мы привыкли учиться программированию по статьям из Google и по ответам из именитого сайта StackOverflow. И это пугает. Я сторонник фундаментальных знаний, а их можно получить только читая книги и общаясь с людьми.
Итак, от слов к делу.
Список книг
- Практика программирования / The Practice of Programming. Фундаментальная книга о программировании. В ней описываются основные принципы написания и проектирования программ: алгоритмы и структуры данных, отладка и тестирование и так далее. Это одна из тех книг, которые считаются классикой и соответственно не стареют. Весь код в книге написан на C/C++.
- Программист-прагматик / The Pragmatic Programmer. Пожалуй, это одна из моих любимых книг по программированию, правда есть одно но — новичкам она покажется сложной, так как зачастую они к этому времени ещё не столкнулись с проблемами из мира разработки ПО, как говорится «пороху ещё не нюхали». В ней есть мысли на тему прагматичного подхода в разработке ПО: автоматизации процессов и разделению подсистем на независимые модули (достижение ортогональности). Must read!
- Идеальный код / Beautiful Code. Книга-сборник практических примеров с интересными подходами в программировании. Например, в книге подробно расписано как реализован словарь в Python (dict), написание XML парсера и разбор алгоритма MapReduce.
- Совершенный код / Code Complete. Без комментариев.
На деле хороших книг намного больше. Эта лишь малая их часть. Читайте много книг, учитесь жадно. Будьте одержимы!
Принципы написания хорошего кода
- больше функций, меньше классов
- правильное именование переменных и функций/классов
- модульность кода
- одно действие — одна функция
- функция != процедура
- расширяемость кода != повторяемость кода
- наличие тестов
- самодокументируемый код
Разберём каждый пункт по порядку.
💩10 обязательных правил для начинающего программиста или как писать код, за который не стыдно?
Больше функций, меньше классов
Из собственной практики чтения чужого кода могу сказать, что объектно-ориентированный подход в программировании оказал своё влияние на умы молодых программистов. Они зачастую пишут его классами, но классы не панацея от всех проблем. Для себя я всегда в голове держу памятку: писать класс нужно в том случае, если имеются общие функции, делящие между собой одинаковое состояние, например, соединение с хостом. В большинстве же случаев можно обойтись простыми функциями.
Именование переменных, функций, классов
Очень важно давать объектам понятные и логичные названия. Сложно будет спустя длительное время после написания кода разобраться что делает функция под названием get_obj или что хранит в себе переменная xyz.
Модульность кода
Когда объем кода в системе переваливает за десятки тысяч строк, становится очень легко поломать работоспособность проекта одним лишь изменением файла, особенно если код перемешан в кучу (спагетти-код). Стремитесь к модульности; простыми словами — к написанию полноценных независимых друг от друга блоков. Их легче тестировать, сопровождать и изменять/расширять.
Одно действие — одна функция
При написании функций или методов необходимо стремиться к философии Unix, где имеется огромное количество утилит, выполняющих строго заданную работу. Разбивайте код на множество функций, если вам кажется, что он выполняет слишком много работы. Не нужно в одном методе делать и генерацию PDF файла и его отправку по электронной почте — разбейте их на две независимых друг от друга функции. У меня есть негласное правило, что 1 функция/метод должна помещаться в видимую область экрана без необходимости делать прокрутку.
Функция != процедура
Те из нас, кто хоть когда-нибудь программировал на таком замечательном языке как Pascal знают чем же отличается функция от процедуры.
Функция возвращает значение. Процедура меняет состояние (имеет побочный эффект при выполнении). При написании старайтесь выбрать что-то одно. Либо вы возвращаете значение, либо меняете состояние объекта, который передаётся на вход, так код будет предсказуемым и коротким.
Расширяемость кода != повторяемость кода
Частенько расширяемость и повторяемость кода принимают за одно и то же. На деле это не так. Писать расширяемый код сложно, подчас очень. Во многом всё сильно зависит от области в которой работает программист. В погоне за расширяемым кодом можно внести излишнюю сложность в последующее сопровождение.
Наличие тестов
Без тестов никуда. Если у вашего кода их нет, ваш код хрупок и непредсказуем. На эту тему написано множество книг и статей, более того, практически все современные языки программирования поставляются с набором библиотек для разработки автоматизированных тестов. Чаще всего написание тестов занимает значительный объем времени программиста, но в перспективе оно окупается с лихвой за счет надёжности и раннего этапа выявления ошибок (чем позже будет обнаружен баг, тем дороже он будет для разработчика и компании).
Самодокументируемый код
Я не призываю отказываться от комментариев в коде, наоборот, их нужно и важно писать (с умом), но также не стоит забывать о том, что код должен быть написан так, чтобы читать его было приятно и легко (правильное именование объектов, четкое логическое разделение на модульные блоки). В Python имеются так называемые docstring, используйте их при описании функций и классов, чтобы облегчить жизнь себе и людям, которые будут читать ваш код.
З.Ы. Пишите код так, будто его в будущем будет читать маньяк, знающий где вы живёте 🙂
- How to Write Reusable Code
- Stop Writing Classes
- Beyond PEP8
Присоединяйтесь к рассылке
Понравился контент? Пожалуйста, подпишись на рассылку.
Источник: khashtamov.com
11 советов, как писать хорошие приложения
В аппсторах уже миллионы приложений, а по настоящему популярны лишь несколько сотен из них. Почему так? Плохой UI, тормозит, глюкает – вот эти причины, с точки зрения юзера. Попробуем разобраться, что можно сделать с нашей стороны, чтобы приложения продвигались в рейтингах загрузок.
1) Применяйте стандартные протоколы. Или, по крайней мере старайтесь. Под “стандартными протоколами” имеются в виду HTTP и HTTPS, SSL, быть может еще изредка SFTP и RESTful, быть может еще подобные, столь же надежные и проверенные вещи.
Они стали стандартом, поскольку в них внедрены проверенные механизмы handshaking-а, описывающие как коммуницируют клиент и сервер, как обмениваются уведомлениями. “Приложения на стандартных протоколах” более гибкие, и лучше настраиваемые, хотя быть может и не идеально-функциональные. Нестандартные протоколы, например проприетарные, разработанные вендором, часто сложны для внедрения, требуют времени для настройки, а далее усилий для поддержания серверов и приложения в работоспособном состоянии. Все это обязательно скажется, если приложение будет скачано в десятках тысяч экземпляров.
2) Никогда не “стройте на песке”, например на предположении, что все сервисы, предлагаемые приложением, будут находиться всегда там же физически, где они находятся сейчас, и что можно выделить им диапазон IP-шников или доменных имен и забыть об этом. Лучше всего здесь пользоваться внешним реестром, который будет “ресолвить” ваши “эндпойнты”. Можно попробовать балансировщик нагрузки с валидным виртуальным именем, далее применять его для устранения проблем с маршрутизацией.
3) Применяйте библиотеки совместимости, или же пользуйтесь услугами middleware-инфраструктурных провайдеров. Вместо того чтобы во всем полагаться на возможности локальной системы.
4) Никогда не теряйте из виду такую вещь как масштабируемость. Чтобы иметь возможности расширяться с ростом загрузок, советуем делать “generic and stateless” приложения. Приложение должно быть достаточно простым в своей идее, и не терять способность масштабироваться, после достижения первых результатов, набора пользовательской базы.
5) Применяйте стандартные принципы безопасности. Задайте четкую стратегию авторизации и аутентификации. Например применяйте фреймворк OAuth2, или другие безопастностные механизмы.
6) Не полагайтесь на локальные файловые системы. Исходите из того, что в один момент случится выход из строя локальной системы. Вместо нее, советуем хранить данные “в службе”, к примеру SQL либо NoSQL. Это также будет полезно, когда понадобится “поднять” логи приложений.
7) Отходите от применения session state в приложении. Помните, что расширяемость любого приложения ограничивается его statefulness. Советуем всегда стараться уменьшать влияние session state. Этого можно добиться, возможно, подключая внешнюю базу данных, или же in-memory систему хранения данных.
8) Чтобы приложение получалось более надежным и производительным, рассмотрите возможность построения мультирегиональной архитектуры для него. Имейте план избежания недоступности приложения для отдельного региона.
9) Тщательно выбирайте между синхронной и асинхронной интеграцией. Если время ответа на запрос синхронизации становится все больше, следует продумать, как поддерживать приличную юзабельность системы; возможно, вместо системной интеграции нужно применять интеграцию сервисов.
10) При разработке избегайте применения “инфраструктурных” API. Попробуйте независимые от инфраструктуры вещи, возможно опенсорсные, или качественные лицензированные; это поможет сделать код не зависящим от излишних зависимостей, “подтягивающихся” по запросу.
11) Мониторинг приложения, проверка его состояния является крайне важной вещью, для проведения проактивных, а также и корректирующих мероприятий. Если приложение работает в облаке, мониторинг – простая вещь, легко проводится при помощи сторонних сервисов. Весь стек приложений можно будет анализировать, оптимизировать, при необходимости устранять возникшие проблемы.
Итак
Пишите код со всей ответственностью, применяя весь свой опыт. Работоспособность приложения зависит от того, как все его компоненты смогут работать в связке, как целостная система; а также от того, какие сложности вы смогли предвидеть и устранить.
Источник: gcoder.ru
Какие программы лучше писать
22 Июля 2012 Программирование 
9 
0
Интересный тут комментарий появился, в котором меня заинтересовал вопрос — нужен ли опыт работы в крупных проектах? Ну для начала, смотря какой. Если проект крупный, но код дерьмо, то лучше такого опыта не иметь. Неправильно заученный материал для многих – хуже незнания. Просто если вы не знаете, то можете спросить, как правильно.
А если вы воспринимаете некорректные технологии за хорошее правило (и хуже того если верите, что это хорошо), то это на много хуже.
Лично я ничего не воспринимаю на веру и для меня нет авторитетов, я человек мыслящий и сам анализирую все и вам советую. Уж много раз говорил вам, не творите себе авторитетов и в том числе мои слова не воспринимайте на безоговорочную веру. Я очень часто анализирую что-то и предполагаю, что может случиться. На пример, я часто пишу, что к концу года будет PS4, но это просто мои мысли, а не факт.
Мне повезло, я работал в нескольких хороших проектах и из каждого проекта, в котором я работал я вынес для себя что-то интересное. Особенно проект, в котором я работаю сейчас. И по прошествии времени могу сказать, что лучше работать в хороших проектах, а не крупных и лучше работать с отличными программистами в команде. Когда с вами работают хорошие программисты, то вы сможете научится большему.
Но тут нужно дать понятие определению «хороший программист». Ну во первых, это должен быть знающий программист, начитанный различной литературы (и не только программистской, но и классики) и главное умеющий использовать свои знания. И если такой коллега не чмо, то с ним можно работать. А понятия чмо у каждого свое – для кого-то чмо ботаник, а для кого-то алкоголик.
В общем, лучше работать в команде, в которой программисты знающие и вам приятно работать с ними как с людьми. И если даже проект небольшой, вы получите от него много хорошего.
Самое главное, что вы получите от такого проекта – обмен опытом. Даже если проект небольшой, вы все равно многому научитесь. Если база кода больше 10,000 строк кода, то уже придется применять патерны и правильно проектировать код. Математику научится писать несложно, это научат в любому книге, а вот правильно проектировать код, вы научитесь в хорошей команде.
Разница между проектами в 10,000 строк кода и в 100,000 строк нет. И тот и тот проект можно написать идеально, а можно насрать так, то 10,000 строковый проект превратится в 100 тысяч и будет выглядеть сложно.
Из своего опыта могу сказать – по фиг над какой сложности проектами вы работаете, главное с какими людьми и как выполняете свою работу.
Лично я предпочитаю работать в небольших проектах и разных. Сегодня я создаю сайт, завтра пишу iOS приложение, послезавтра десктопное приложение, потом опять сайт и таким образом я не только росту в глубь технологию, но и расширяю свой кругозор. Правда последний уже почти три года я застрял на одном большом проекте, но только потому, что проект реально сложный и у нас в компании на нем народ задерживаются не долго. Народ не выдерживает. Больше меня проработала только одна программистка – мой бывший начальник.
В Канаде мне пришлось начинать с нуля и все заслуги в России здесь не котируются. Но именно благодаря широкому пониманию различных систем я смог вырасти за 2 года из Application Developer в Technical Architect и даже вести команду (от чего я уже отказался правда по собственному желанию).
Если вы выберите путь работы над различными проектами, как я, то не стоит разбрасывать все свои знания слишком широко. Кругозор имеет смысл, когда вы все же знаете хотя бы одну технологию достаточно хорошо. Я работаю в разных системах и пишу на разных языках, но при этом все же как минимум 50% уделяю какому-то одному языку, в котором специализируюсь больше всего. Раньше это был Delphi, сейчас это C#.
Одна технология и один язык обязательно должен быть основным. Иначе вы просто нахватаетесь всего по кусочку, а глубокого понимания ни где не будет.
Если вы выберите работу только в одном вечно крупном проекте и не будете изучать ничего смежного, вы себя только ограничите в росте и я считаю, что это плохо.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Источник: www.flenov.info