Pull to refresh

Три ключевых принципа ПО, которые вы должны понимать

Website development *Programming *Designing and refactoring *
Translation
Tutorial

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

Все, что касается любви, применимо и к коду. Новых законов в коде нет. Если вы четко понимаете основные идеи разработки, вы способны максимально быстро адаптироваться к новым подходам. В этой статье я расскажу вам о трех основных принципах, которые, наряду с другими, позволяют регулировать сложность разработки. Я поделюсь своим видением вопроса, которое, надеюсь, поможет вам в повседневной работе.
Читать дальше →
Total votes 142: ↑128 and ↓14 +114
Views 190K
Comments 56

«Разбор полетов» — episode 20 — Программисты-оптимисты

Self Promo

Представляем Вашему вниманию юбилейный двадцатый выпуск подкаста «Разбор Полетов», в котором мы говорим о событиях и технологиях, которые взволновали нас на этой неделе, и будут волновать Вас!
В сегодняшнем выпуске мы поговорим:
Читать дальше →
Total votes 23: ↑18 and ↓5 +13
Views 1.1K
Comments 17

Красноярская конференция разработчиков Dev2Dev 2.0

Microsoft corporate blog Website development *Programming *
Это «гостевой пост» от команды энтузиастов сообщества Dev2Dev. Я очень рад, что подобная инициатива продолжает существовать и очень хочу их поддержать, по крайней мере информационно.



Красноярск — далекий сибирский город и глухая it-провинция. Но 30 мая 2015 года нашей активности позавидуют соседи. В этот день состоится вторая конференция разработчиков программного обеспечения Dev2Dev, версия 2.0. Конференцию организует молодое одноименное it-сообщество, объединяющее спецов отрасли из компаний города. Нам менее года, но мы растем. С самого начала мы работали для того, чтобы в Красноярске наконец появилась круто сваренное местное событие с большой активной аудиторией и заезжими докладами.

Концепция событий сообщества Dev2Dev проста: свободный вход, качественный контент и много общения для участников и спикеров. Событие — это в первую очередь фан, знакомства и накачка энергией. Сильные доклады и интересные спикеры делают это возможным, но само событие создают участники. 30 мая мы ждем 200-250 человек. Новая конференция соберет доклады по enterprise разработке, функциональному программированию, проектированию, тестированию приложений, управлению проектами и командой. Докладчики едут со всей Сибири — Новосибирск, Омск, Кемерово. Специальный гость прилетит из Чикаго.
Программа события насыщенная
Total votes 18: ↑15 and ↓3 +12
Views 3.7K
Comments 1

Любовь или брак по расчету с Dependency Injection?

.NET *IT Standards *
Sandbox
В своей статье хочу рассмотреть пример неправильного, на мой взгляд, использования Dependency Injection принципа и попробовать отыскать мотивацию для других разработчиков команды (а может и кому еще сгодится) писать новый код лучше, а также по мере сталкивания в рамках рабочих активностей с чужим кодом, написанным неграмотным образом, делать рефакторинг.

Итак, суть проблемы. На проекте мы используем OData WebApi и все контроллеры наследуются от базового, используют метод GetService из базового класса который вытягивает зависимости через статический класс ApiControllerScopeContextMediator.

public abstract class ODataControllerBase : ODataController
{		
	protected T GetService<T>()
        {
              return ApiControllerScopeContextMediator.GetService<T>(this);
        }		
}	
internal static class ApiControllerScopeContextMediator
 {		
	internal static T GetService<T>(ApiController controller)
        {
              return (T) controller.Configuration.DependencyResolver.GetService(typeof (T));
        }		
}
	

А в Global.asax конфигурируем подтягивание зависимостей для OData через StructureMap:

    GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(container);

Во всех action у контроллеров повсеместно используется метод GetService, как, например, здесь:

public class DisconnectedAppsController : ODataControllerBase
{
	public IHttpActionResult Get()
        {		
		var query = GetService<IQuery<IQueryable<DisconnectedAppDomain>, DisconnectedAppFilter>>();		
	}
}

Но почему? Ведь можно было бы просто использовать constructor injection:

public DisconnectedAppsController(IQuery<IQueryable<DisconnectedAppDomain>, DisconnectedAppFilter> query){
    _query = query;
}

Так что же все-таки: «Таити, Таити» (Constructor Injection) или «нас и здесь неплохо кормят» (GetService)?
Читать дальше →
Total votes 11: ↑4 and ↓7 -3
Views 7.7K
Comments 78

Liscript — web REPL: поцелуи, велосипеды и экскаваторы

Website development *Programming *Java *Lisp *Functional Programming *


Некоторое время назад я написал интерпретатор лиспоподобного языка, который назвал Liscript. Опубликовал несколько статей на Хабре, посвященных особенностям реализации ядра, TCO, GUI, REPL-ботов и т.п. Недавно добавил web-интерфейс REPL-у (ссылка в конце статьи).

При чем здесь поцелуи и экскаваторы? Думаю, большинству известны такие аббревиатуры, как KISS (keep it simple stupid — делай это проще, дурачок), YAGNI (You ain't gonna need it — Вам это не понадобится), а также высказывания людей разной степени великости про архитектурных астронавтов, «все должно быть сделано так просто, насколько возможно, но не проще», и т.п.

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

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

В общем, про выбор инструментов под задачи, и конкретные (подозреваю, что спорные) решения, которые я выбирал в процессе реализации проекта, под катом.
Читать дальше →
Total votes 8: ↑6 and ↓2 +4
Views 3.7K
Comments 24

Архитектурная пирамида приложения

Programming *System Analysis and Design *Perfect code *Designing and refactoring *ООP *
Программирование — достаточно молодая область знаний, однако, в ней уже существуют базовые принципы «хорошего кода», рассматриваемые большинством разработчиков как аксиомы. Все слышали о SOLID, KISS, YAGNI и других трех- или четырех- буквенных аббревиатурах, делающих ваш код чище. Эти принципы влияют на архитектуру вашего приложения, но помимо них существуют архитектурные стили, методологии, фреймворки и много чего еще.

Разбираясь со всем этим по отдельности, меня заинтересовал вопрос — как они взаимосвязаны? Пытаясь выстроить иерархию и вдохновившись небезызвестной пирамидой Маслоу, я построил свою пирамиду «архитектуры приложения».

О том, что из этого вышло — читайте под катом.
Войти в пирамиду
Total votes 17: ↑17 and ↓0 +17
Views 19K
Comments 15

Пирамида тестов на практике

Microformats *IT systems testing *Web services testing *Development Management *DevOps *
Translation
Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

Содержание

Примечания

Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Views 204K
Comments 4

Разработка формы на React. Принципы KISS, YAGNI, DRY на практике

JavaScript *Perfect code *ReactJS *
Sandbox
Здавствуйте, в этом туториале мы рассмотрим как разработать очень простую, но контролируемую форму в React, сфокусировавшись на качестве кода.

При разработке нашей формы мы будем следовать принципам «KISS», «YAGNI», «DRY». Для успешного прохождения данного туториала вам не нужно знать этих принципов, я буду объяснять их по ходу дела. Однако, я полагаю, что вы хорошо владеете современным javascript и умеете мыслить на React.
Читать дальше →
Total votes 11: ↑11 and ↓0 +11
Views 14K
Comments 34

Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама

НПП ИТЭЛМА corporate blog Programming *Perfect code *Designing and refactoring *Development Management *
Translation
image

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

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

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

Принципов много. Мы остановимся на семи самых важных. Их использование поможет вам в развитии и позволит стать лучшим программистом.

1. YAGNI

You Aren’t Gonna Need It / Вам это не понадобится

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

Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.

Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.
Читать дальше →
Total votes 22: ↑19 and ↓3 +16
Views 97K
Comments 9

CDD — Cli Driven Development

Abnormal programming *Self Promo C++ *ООP *
Sandbox

Все-таки самоизоляция не проходит бесследно. Сидишь себе дома, а в голову разные мысли приходят. Как, чем осчастливить человечество? И вот оно: CDD! (CDD - Cli Driven Development - Новый подход).

Читать далее
Total votes 14: ↑12 and ↓2 +10
Views 3.5K
Comments 4

OCP против YAGNI

Programming *System Analysis and Design *Perfect code *Designing and refactoring *ООP *
Translation

Эта статья является переводом материала OCP vs YAGNI.

В этом посте хочется осветить тему OCP и YAGNI – противоречия между принципом открытости/закрытости и принципом «вам это не понадобится».

Давайте начнем с того, что вспомним, что такое OCP. Принцип открытости/закрытости гласит, что: Объекты программного обеспечения (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации.

Впервые он был представлен Бертраном Мейером в его канонической книге «Конструирование объектно-ориентированного программного обеспечения». С тех пор его популяризировал Боб Мартин, когда он представил принципы SOLID.

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

Читать далее
Total votes 17: ↑17 and ↓0 +17
Views 7.3K
Comments 24

Как мы избавились от 80% своего кода, повысив скорость разработки и уменьшив количество ошибок

М.Видео-Эльдорадо corporate blog Perfect code *Server optimization *Development Management *
Translation


Оптимизация кода и развитие микросервисной архитектуры занимает значительную часть жизни команды разработчиков МВидео-Эльдорадо. Тем любопытней изучить опыт коллег за рубежом. Предлагаем вашему вниманию очередной пост на тему: «А как там у них».
Читать дальше →
Total votes 98: ↑90 and ↓8 +82
Views 60K
Comments 101

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

Хекслет corporate blog Programming *IT Standards *ООP *Development Management *

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

Читать далее
Total votes 49: ↑31 and ↓18 +13
Views 37K
Comments 50

Зарубежный опыт: как избавиться от 80% кода, увеличить скорость разработки и уменьшить количество ошибок

МойОфис corporate blog Programming *Designing and refactoring *IT-companies Microservices *
Translation
Tutorial

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

Под катом тех– и тимлид Йонас Тулструп, один из разработчиков датского сервиса MobilePay, демонстрирует, что отказ от излишних абстракций позволяет писать более чистый код. А именно: существенно уменьшать его сложность, повышать читабельность и удобство поддержки. Обсуждаемые подходы основаны на широко известных принципах KISS («Делай проще») и YAGNI («Вам это не понадобится»), и применимы к большинству видов разработки ПО.

Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

Читать далее
Total votes 27: ↑23 and ↓4 +19
Views 27K
Comments 6

SOLID – это не правила, а гайдлайны

Издательский дом «Питер» corporate blog Programming *Perfect code *Designing and refactoring *ООP *
Translation

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

Читать далее
Total votes 29: ↑25 and ↓4 +21
Views 18K
Comments 21