Exemplos
Qual a saída do código abaixo?
let pessoa = new Pessoa("Clouvix");
console.log(pessoa);
NOTA: Este contenido se puede ver en formato de slide aquí!.
Aqui descreveremos um problema para ser resolvids por algoritmo usando as features de cada linguagem, nesse caso será resolvido nas linguagens Kotlin, Java e Golang.
Neste cenário, temos uma estrutura lógica (observada abaixo), onde recebemos uma relação de pessoas e precisamos retornar uma lista única, ordenada por Estados, em ordem alfabética. Além disso, também só deverão ser retornados os Estados com população igual ou superior à 100 mil habitantes e maiores de 18 anos.
@startuml | |
!include <C4/C4_Context.puml> | |
!include <C4/C4_Container.puml> | |
!include <office/Users/user.puml> | |
LAYOUT_WITH_LEGEND() | |
title UCS - High Level | |
Person(OperatorMeli, Operator Meli, "<$user>") |
# This file contains all available configuration options | |
# with their default values. | |
# options for analysis running | |
run: | |
# include test files or not, default is true | |
tests: false | |
# output configuration options | |
output: | |
# colored-line-number|line-number|json|tab|checkstyle|code-climate, default is "colored-line-number" | |
format: colored-line-number |
Nota: Esse conteúdo faz parte de um grupo de estudos sobre Kotlin, descrito aqui!
Diferente das linguagens de programação que se propõem à resolverem conjuntos genéricos de problemas, a DSL Domain Specific Language
foi criada para resolver um problema específico ou um conjunto de problemas que fazem parte de um mesmo domínio.
Um exemplo de DSL
, é a linguagem utilizada nos scripts de Gradle, que serve para configurar o build e dependências de um projeto JVM. Que é feito em Groovy ou Kotlin, percebemos que por mais que tenhamos uma linguagem de programação para fazer isso, a sintaxe se mostra bem diferente e orientada à resolver um pro
NOTA: Pense que sua função é como uma piscina, quanto mais longe e quanto mais tempo você fica longe da borda, mais chance você tem de se afogar!!!
Lembre-se, passamos muito mais tempo lendo os códigos do que os escrevendo então, muitas vezes, é justificável gastarmos mais tempo para escrever um código melhor, visto que o mesmo será lido várias vezes.
Normalmente o nível de indentação de um código está diretamente ligado a sua complexidade e complexidade ciclomática, quanto mais indentado, mais complexo e em GO isso não é diferente, GO ainda possui uma característica particular que pode tornar as funções um pouco mais longas e complexas, é o tratamento de erros. Nos nosso sistemas isso não é diferente, possuímos alguns códigos grandes e complexo e queremos debater algumas práticas evitar isso.
func (h *httpHandler) PostByPrinterType(w http.ResponseWriter, r *http.Request) {
printerType := server.URLParam(r, "printertype")
if err := h.validatePrinterType(printerType, r); err == nil {
if printerRequest, err := h.validatePost(r); err == nil {
if err = h.service.PrintByWorkstation(r.Context(), printerRequest, printerType); err == nil {
logger.Info(endpointLog).Log("PrintByWorkstation Succeeded",
"shipment_id", printerRequest.ShipmentID, "workstation_id", printerRequest.WorkstationID,
"warehouse_id", printerRequest.WarehouseID, "status", http.StatusOK)
w.WriteHeader(http.StatusOK)
Construir APIs utilizando as boas práticas de mercado, tendo boas documentações que sirvam como SAAS, fazendo a API ser autoexplicativa e bem documentada sem a necessidade de iteração com a equipe criadora para o entendimento e/ou consumo.
O time constrói e faz melhorias nas suas API REST, visando as boas práticas de mercado, níveis de maturidade REST e recomendações da Softplan? Levando em consideração o que se vê por fora (contratos API) para facilitar o consumo e a reutilização das mesmas.