Анти-обрасци које бисте требали избегавати у свом коду

Сваки програмер жели да напише структурирани, једноставно планирани и лепо коментарисани код. Постоји чак и безброј образаца дизајна који нам дају јасна правила која треба следити и оквир који морамо имати на уму.

Али и даље можемо пронаћи анти-обрасце у софтверу који је написан неко време или је написан пребрзо.

Безопасно основно хаковање за брзо решавање проблема може створити преседан у вашој бази кода. Може се копирати на више места и претворити у анти-образац којем треба да се обратите.

Па, шта је анти-образац?

У софтверу, анти-паттерн је термин који описује како НЕ решавати понављајуће проблеме у коду. Анти-шаблони се сматрају лошим дизајном софтвера и обично су неефикасни или нејасни поправци.  

Углавном су додати и "технички дуга" - што је код морате вратити и поправити правилно касније.

Шест образаца против којих ћу разговарати у овом чланку су Шпагети код , Златни чекић , Сидро за брод , Мртви код , Пролиферација кода и Божји предмет .

Шпагети законик

Шпагети код је најпознатији анти-образац. То је код са мало према нули структури.

Ништа није модуларно. У насумичним директоријумима налазе се насумичне датотеке. Цео ток је тешко пратити и потпуно је запетљан (попут шпагета).

Обично се ради о питању када неко претходно није пажљиво размислио о току свог програма и тек почео да кодира.

Шта ради ?! Не могу да пратим ово

имаге.пнг

Ово није само ноћна мора за одржавање, већ онемогућава додавање нове функционалности.

Стално ћете ломити ствари, нећете разумети обим ваших промена или давати било какве тачне процене свог рада, јер је немогуће предвидети безброј проблема који се појављују када радите такву археологију / нагађања.

Овде можете прочитати више о анти-шаблону Шпагети кода .

Златни чекић

„Претпостављам да је примамљиво, ако је једини алат који имате чекић, према свему се понашати као да је ексер.“ Абрахам Маслов

Замислите сценарио са мном: ваш развојни тим је врло, врло компетентан у потпуно новој Хаммер архитектури. То је фантастично успело за све ваше прошле проблеме. Ви сте водећи светски тим Хаммер архитектуре.

Али сада некако све увек заврши користећи ову архитектуру. Вијак са равном главом? Чекић. Вијак са Пхиллипс главом? Чекић. Треба вам инбус кључ? Не, не, закуцај.

Почињете да примењујете архитектонски приступ који не одговара баш ономе што вам треба, али завршава посао. Превише се ослањате на један образац и треба да научите најбољи алат за најбољи посао.

Читав ваш програм могао би да заврши озбиљним хитом у изведби јер покушавате да квадрат набијете у облик круга. Знате да је потребно двоструко више времена за кодирање и извођење програма који користи архитектуру чекића за овај проблем, али то је лакше и оно што вам одговара.

Такође није баш предвидљиво. Различити језици имају заједничко решење проблема са којима се суочавају и своје сопствене стандарде. Не можете применити свако правило које вам је добро функционисало на једном језику на други, без проблема.

Не занемарујте стално учење у својој каријери. Изаберите прави језик за свој проблем. Размислите о архитектури и потисните своју зону удобности. Истражите и истражите нове алате и нове начине приступања проблемима са којима се суочавате.

Овде можете прочитати више о анти-узорку Златни чекић .

Сидро за брод

Брод Сидро против образац је место где програмери оставити код у базу кодова, јер им може затребати касније.

Нешто су кодирали изван спецификације и још увек није потребно, али су сигурни да ће то учинити следећег месеца. Дакле, не желе да га избришу. Пошаљите га у производњу и касније кад им затреба, могу брзо да га покрену.

Али ово узрокује ноћне море одржавања у бази кодова која садржи сав тај застарели код. Огромно је питање што ће њихове колеге тешко разрадити који је код застарео и не мења ток, у односу на код који то чини.

Замислите да имате хитно решење и очајнички покушавате да утврдите шта је одговорно за слање података о картицама купаца АПИ-ју за повлачење средстава из њихове банке. Могли бисте губити време читајући и отклањајући грешке у застарелом коду, а да не схватате да нисте ни на правом месту у бази кода.

Коначно питање је: застарели код вам продужава време израде и можете помешати радни и застарели код. Могли бисте чак и нехотице да почнете да га „укључујете“ у производњи.

Сада вероватно можете да видите зашто се то назива сидрено сидро чамца - тежак је за ношење (додаје технички дуг), али не чини ништа (дословно, код нема сврху, не ради).

Овде можете прочитати више о анти-узорку сидра брода .

Мртви код

Да ли сте икада морали да погледате код који је написао неко ко више не ради у вашој компанији? Постоји функција која изгледа да не ради ништа. Али зове се одасвуда! Питате се и нико други није сасвим сигуран шта ради, али сви су превише забринути да то избришу.

Понекад можете видети шта ради, али контекст недостаје. Можете читати и разумети ток, али зашто? Не изгледа више да морамо да погађамо ту крајњу тачку. Одговор је увек исти одговор за сваког различитог корисника.

This is commonly described as the Dead code anti-pattern. When you can't see what is "actual" code necessary to the flow and successful execution of your program, versus what was only needed 3 years ago, and not now.

This particular anti-pattern is more common in proof on concept or research code that ended up in production.

One time at a tech meet up I met a guy who had this exact problem. He had tons of dead code, which he knew was dead, and lots he suspected was dead. But he could not get permission from management to ever remove all the dead code.

He referred to his approach as Monkey testing, where he started to comment out and turn off things to see what blew up in production. Maybe a little too risky!

If you don't fancy Monkey testing your production app, try to frame technical debt to management as "technical risk" to better explain why you think it's so important to tidy up.

Or even write down everything your particular module/section does you want to re-write, and take an iterative approach to remove piece by piece the dead code. Checking every time you haven't broken anything.

You don't have to drop a huge rewrite with thousands of changes. But you will either understand why it's so crucial and document why it's needed, or delete the dead code as you desired.

You can read more here about the Dead code anti-pattern.

Proliferation of Code

Objects or modules regularly communicate with others. If you have a clean, modularised codebase you often will need to call into other separate modules and call new functions.

The Proliferation of Code anti-pattern is when you have objects in your codebase that only exist to invoke another more important object. Its purpose is only as a middleman.

This adds an unnecessary level of abstraction (adds something that you have to remember) and serves no purpose, other than to confuse people who need to understand the flow and execution of your codebase.

A simple fix here is to just remove it. Move the responsibility of invoking the object you really want to the calling object.

You can read more here about the Proliferation of Code anti-pattern.

God Object

If everywhere in your codebase needs access to one object, it might be a God object.

God objects do too much. They are responsible for the user id, the transaction id, the customer's first and last name, the total sum of the transaction, the item/s the user is purchasing...you get the picture.

It is sometimes called the Swiss Army Knife anti-pattern because you only really need it to cut some twine, but it also can be a nail file, saw, pair of tweezers, scissors, bottle opener and a cork screw too.

In this instance you need to separate out and modularise your code better.

Programmers often compare this problem to asking for a banana, but receiving a gorilla holding a banana. You got what you asked for, but more than what you need.

The SOLID principles explicitly discuss this in object orientated languages, to help us model our software better (if you don't know what the SOLID principles are, you can read this article).

The S in the acronym stands for Single Responsibility - every class/module/function should have responsibility over one part of the system, not multiple.

You can see this problem over and over again, how about the below interface?

interface Animal { numOfLegs: string; weight: number; engine: string; model: string; sound: string; claws: boolean; wingspan: string; customerId: string; } 

Can you see by even just briefly scanning this interface that the responsibility of this is far too broad, and needs refactoring? Whatever implements this has the potential to be a God object.

How about this?

 interface Animal { numOfLegs: string; weight: number; sound: string; claws: boolean; } interface Car { engine: string; model: string; } interface Bird { wingspan: string; } interface Transaction { customerId: string; } 

Interface segregation will keep your code clear about where the responsibilities lie, and stop forcing classes that only need wingspan to also implement the engine, customerId and model  and so on.

Овде можете прочитати више о анти-шаблону предмета Бога .

Закључак

У било којој великој бази кодова постоји стална равнотежа између управљања техничким дугом, покретања новог развоја и управљања редом грешака за ваш производ.

Надам се да вам је овај чланак дао око да уочите када се можда спуштате кроз зечју рупу анти-шаблона и неке алате за његово чисто решавање.

Поделим своја писања на Твиттеру ако сте уживали у овом чланку и желите да видите више.