Програмиране

April 3, 2016, By admin | Leave a reply

Общи насоки

Лесен за четене и разбиране (лесен за модификация и подръжка)
Коректно поведение при всички случаи на използване (тестван)
Добре структуриран и с ясен дизайн
Документиран
Добре форматиран
Правилно именуване

There are only two hard things in Computer Science: cache invalidation and naming things.

- Phil Karlton

Малки фирми

PHP, Python3, JavaScript, C, SQLite3, HTML5, CSS3, JSON, MQTT
Vue.js, Axios, jQuery, Lodash, Limonade PHP, Bulma, Font Awesome
Vim, Git
NGINX, HAProxy, Redis, Memcached, Mosquitto
ssh, byobu, sftp, ssh-keygen, ssh-copy-id, lynx, wget, curl, ctags
Linux, Ubuntu, Arduino, QEMU, virt-manager, Levinux, VirtualBox, VBoxManage, vagrant

Принципи

* Принципът KISS, „Keep It Short & Simple!“ / „Направи го кратко и просто!“ * (източник)
Принципът KISS се основава на две наблюдения:
1. Потребителите като цяло предпочитат продукти и услуги, които са лесни за разбиране, усвояване и употреба.
2. Фирмите, които произвеждат тези продукти или доставят тези услуги, могат да открият и за себе си преимуществата на простите решения: намаляване на разходите и времето за производство. Понякога началният етап на проектиране и разработка на по-прости решения може да отнеме повече време, но дългосрочният ефект да се изразява в по-лесни и евтини за производство продукти, повече и по-верни клиенти и по-дълъг пазарен живот на продукта

* DRY – don’t repeat yourself / Не се повтаряй * (източник)
Принципът DRY гласи, че “Всяко парче информация знание трябва да има единично, еднозначно и авторитетно представяне в рамките на една система.”. Принципът е формулиран от Анди Хънт и Дейв Томас в тяхната книга Прагматичният програмист. Когато DRY принципа се прилага успешно, модификацията на всеки един елемент на една система не се нуждае от промяна в други логически несвързани документи.
* Single source of truth / Единствен източник *
Всеки елемент от данни е съхранен само веднъж.
* SOLID * (източник)

Инициали	Акроними	Концепция
S	SRP Single Responsibility Principle	Принцип за единствена отговорност Класа трябва да има една единствена отговорност(т.е. само промени в софтуерните спецификации могат да предизвикат промяна в спецификациите на класа)
O	OCP Open-Closed Principle	Прицип отворен/затворен „Софтуерните единици трябва да са отворени за разширение, но затворени за промяна.“
L	LSP Liskov Substitution Principle	Принцип на заместване на Лисков Всеки наследник(подтип) трябва лесно да заменя всичките си базови типове.
I	ISP Interface Segregation Principle	Принцип за разделяне на интерфейсите „Много на брой малки интерфейси е по-добре от един голям общ интерфейс.“
D	DIP Dependency Inversion Principle	Принцип на обръщане на зависимостите Всички класове трябва да зависят от абстракции и нито един не трябва да зависи от конкретен клас.”

Принцип за единствена отговорност – SRP
Всяка една единица от кода има една единствена отговорност, т.е. една променлива, метод, клас, библиотеки, фреймуърци правят едно единствено нещо. По този начин кода става модуларен разпръснат на малки парчета и всяко парче върши строго специфицирана дейност. „Когато има нещо за промяна в един код не трябва да имаме повече от една причина да го променяме.“ – Роберт Мартин.
SRP се базира на принципите:
Strong Cohesion – силна сплотеност на функционалността на един клас, т.е. всички методи в него трябва да имат обща насока.
Loose coupling – класа да е максимално „разкачен“ от всички останали (хипотетично, ако се изтрие един клас, проекта да може да се билдне отново). В реалността няма как да се случи, но идеята е да се стремим по възможност да избягваме зависимости между класовете.

Конфигурация

Програмата има клас за достъп до конфигурацията си с default стойности
При стартиране, програмата записва файл default.config със стойностите си от класа
Програмата проверява за ENV променлива с определено име, за да открие текущия си config файл, например COMPANY-NAME_APP-NAME_ENV, със стойност "development", което означава "development.config"
Програмата презаписва default стойностите на config класа си със тези които са зададени в config файла, другите си остават непроменени
Програмата записва running.config файл с настройките с които работи в момента

Методологии

Defensive programming / Защитно програмиране
Test-driven development / Разработка чрез тестове
User stories / Потребителски истории
Class Responsibility Collaborator (CRC) model/cards / Клас Отговорност Сътрудничество карти
Mind maps / Мисловни карти
Bi-Directional Requirements Traceability / Двупосочно проследяване на изискванията
RESTfull API, web services
JSON, JSend
Microdata
Post / Redirect / Get pattern
Не позволявайте директен достъп до таблиците и сеченията им, а предоставяйте данните чрез предварително дефинирани view за всеки един логически обект.
Нормализирайте таблиците си минимум до 3 Нормална Форма
http://www.slideshare.net/nakov/nakov-rdbms-systems-intro
Осигурете интегритет на базата си с дефиниране на primary key, foreign keys, null / not null, unique.
Не изтривайте редове от таблиците си, а ги маркирайте с флаг, например IS_ACTIVE, IS_DELETED
Връзките/релациите между таблиците се осигуряват от физическите id на таблиците. Физическите id сочат към логическите id. Всеки ред има и глобален object_id, който се използва за закачане на атрибути към произволен ред.
Логическите номера на номенклатурите трябва да се издават само от централния офис, или да има твърд алгоритъм който да ги идентифицира еднакво за различните обекти. Използват се за справките, както и за импорт/експорт.
Период, приключен период с кеширане на номенклатурите и началните салда за всеки един период. Номенклатура за период (която се копира от базова номенклатура при откриването на период) с указател към базова номенклатура.
Разнасяне на документа при активация с кеширане на обекта, без редакция, сторно на позиции/документи.
Осигурете си полета за фирма, склад, офис, уникален логически номер на документа (пр.тип,фирма,дата и номер), потребител, консигнация, сторниране.
Осигурете аналитичност на данните си, използвайте сериен номер на обектите си, т.е. уникален номер, чрез който можете да следите движението на обекта през различните документи в системата си.
Спазвайте правилата за именуване на полета в базата данни:
tablename.tablename_id – for primary key field,
tablename.tablename_fieldname – for normal field,
tablename.tablename2_id – for foreign key field,
принципа на релационен синтез, т.е. всяко поле в базата данни да има уникално име. В случай на нужда от втори tablename.tablename2_id се изнася във свързващата таблица, със тип и индекс на връзката.
Права: йерархични – роля/длъжност; плоски/обхват – член на екип/офис; функционални – достъп до модул; Потребителя притежава множество от тези атрибути, Документа притежава също множество от тези атрибути и се вижда от потребител, с които има препокриващо се множество и от трите нива.

Функции

Псевдокод на функцията
Функцията зависи само от входните си параметри
Не променя параметрите си, а връща резултат
Защитно програмиране: валидация на входните паратметри; в случай, че не може да изпълни задачата си, метода предизвиква изключение/exception.
Къс код (не поввече от 2-3 страници)
Късно излизане (return е последната инструкция)
if then без else (без ELSE клауза, просто нормален код, след if клаузите в началото)
Променливите в метода трябва да имат значещи имена, и да се използват само за една задача.

Дизайн

Create factory pattern / Шаблон Фабрика за създаване на обекти
Adapter pattern / Адаптер шаблон
Separation of concerns / Разделянето на отговорности
При изграждането на базовия framework използвайте наследяване, а при Service, Business and DAL layers предпочитайте композицията.
Функции + класове -> базова библиотека,
DAL – слой за достъп до базата данни,
BL – бизнес слой (няма достъп до базата),
UI – потребителски интерфейс,
SL – слой на услугите (осигурява общото изпозлване на DAL + BL + UI чрез DTO обекти)
prototype / Прототип на потребителския интерфейс
Ако на конструктура му е подаден лог/log интерфейс/клас(обект) различен от NULL, класа/функията записва детайлен лог на работата си
Не задавайте твърди параметри в кода си, всички параметри трябва да бъдат достъпни чрез настройки
Видове информационни системи (влияе на дизайна):
-> чисто информационни, съдържа абсолютни данни – независещи от времето, т.е. постояно актуални
-> счетоводни / исторически – описва данни зависещи от времето и променящи се във времето
-> складови – съдържа данни описващи актуалното/текущото състояние на системата

10 препоръки при създаване на мобилни приложения

Връзка с Back-End системите – потребителски профил, който да се синхронизира на всички устройства.
Високо ниво на сигурност – златната среда.
Достъп отвсякъде – Облакът.
Пълна мобилност… – мобилно приложение замества … десктоп апликацията.
…и дори повече (мобилност) – Приложението трябва да улеснява хората и да извършва възможно най-много действия вместо тях.
API за по-бърз прогрес – в пъти по-бързо и по-ефективно.
Фирмени или потребителски приложения? – бизнесът би заплатил всякакви суми, стига това да спомогне за успеха и развитието му.
Обслужване на потребностите – Не пренебрегвайте никоя евентуална нужда на потребителите си. И не занемарявайте вече готовия си продукт.
Специализирани приложения – Често разработчиците започват да създават дадено приложение с ясна представа за профила на крайния потребител. Но постепенно добавят още и още функции и профилът се размива. А това само би объркало хората, които в последствие ще се опитат да го използват.
Представянето – всяка една фраза в описанието на приложението би могла да спечели или да отблъсне даден потребител.

Седем практични правила за правене на успешен бизнес според Питър Тийл

Ако искате да създадете и задържите стойност, не навлизайте в бизнес, където продуктът е унифициран.
Ако поставите краткосрочния ръст над всичко друго ще пропуснете най-важния въпрос: Ще просъществува ли бизнесът ми 10 години?
Собствената технология е най-значимото предимство, което може да има една компания, защото тя прави продукта ви труден или невъзможен за имитиране.
Всеки стартъп трябва да започне с много малък пазар. Винаги правете „грешката“ да започвате на дребно.
Идеалният целеви пазар за един стартъп е малка група със специфични потребности, събрана на едно място и обслужвана от малко или никакви конкуренти.
Да „продадете“ компанията си на медиите е точно толкова важно, колкото и продажбата на всеки друг.
Когато започвате нещо, първото и най-важното решение е с кого да го започнете. Изборът на съдружник е като брака, а конфликтът със съдружник е не по-малко грозна картинка от развода.

Най-честите грешки, които младежите допускат на работното място – Money.bg

Не задават достатъчно въпроси – Haй-дoбpият нaчин дa ycвoиш нeщo, ĸoeтo нe знaeш или нe paзбиpaш, e дa питaш.
Не се интересуват от това как се оценява работата им – ще знаят в каква посока да работят.
Работят до късно – прави служителя по-малко продуктивен по време на работа.
Правят нещата прекалено сложни – най-простите решения често са най-добрите.
Не виждат контекста на нещата – Hoвoзaвъpшилитe взeмaт тoлĸoвa нaвътpe paбoтaтa cи, чe чecтo ce зaxвaщaт c eдин пpoeĸт, миcлeйĸи, чe изпълнeниeтo мy e вcичĸo, ĸoeтo имa знaчeниe. Bcъщнocт тaĸa зaбpaвят, чe имaт и дpyги зaдaчи зa изпълнeниe и paбoтят в eĸип c дpyги cвoи ĸoлeги.

Разни

https://pragprog.com/the-pragmatic-programmer/extracts/tips – Extracted From The Pragmatic Programmer
http://www.cphpvb.net/network-security/8009-the-most-famous-software-bugs/ – големи софтуерни бъгове

Python

bottle – for web services
jython – for GUI development
brython – for frontend web development
bottle, gevent, bottle_sqlite, jsend, pyjade, requests, lxml, re, codecs, click – useful modules

WEB

PHP, jQuery, Java, Python, SQLite, UnQLite, nGinx, HAProxy, memcached, stunnel, rinetd, OpenVPN, w3schools, schema.org, jade, WordPress, sqlite-integration, gantry, nanomsg, monit

за Сократ, Талмуда и двамата в комина …

Преинсталация на Windows XP

You must be logged in to post a comment.

Програмиране

Leave a Reply

Recent Posts

Recent Comments

Archives

Categories

Meta